Slashdot Mirror
.org TLD Now Runs on PostgreSQL
johnnyb writes "The .org domain, which has long run on Oracle systems, is now being transferred to a PostgreSQL system. I guess we can now dispel the "untested in mission-critical applications" myth."
← Back to Stories (view on slashdot.org)
Because they don't take context or purpose into account at all. There are things that Postress may be better for and things that Oracle certainly shines at. I mean, hell, I love MySQL, too, but I wouldn't want to use it as the backend for _my_ system. Not that the others are hollisticaly "bad", it's just that Oracle is the most appropriate for this situation.
What's a TLD doing with a database? Making ridiculous numbers of extremely lightweight queries, and managing redundancy. That's not necessarily the same thing that everybody wants an "enterprise class" "tested" database to do for "mission critical" tasks.
:Wq
Not an editor command: Wq
No, it simply means that its going to be tested in a larger environment and if it does well then they get to party and say "woohoo it worked!" and if it flops they're all gonna feel really stupid. It doesnt mean its stable at all. The common practice of paraphrasing "LOOK!! Someone is using our product so it MUST work perfectly." is actually quite disturbing.
Parent is a joke, not a troll. /. moderators are TeH sUx0r
I don't think the issue is that PostgreSQL will crunch data as well as Oracle. It's just that PostgreSQL has always had an undeserved reputation as "the database to use when you can't afford a REAL database", when actually it's a very robust and secure system that can compete quite well with commercial systems.
I'd really like to see some serious tests done with PostgreSQL. Database systems, especially Oracle, can be an expensive part of a datacenter. Considering that with Linux/PostgreSQL your only cost is hardware/support, it may very well scale more cost effectively than Oracle.
There's currently way too much marketing and FUD to get a real idea how these systems compare though.
I'm not saying that's what they did; of course it would depend on whether they have enough work to hire the expert, for example. But I don't understand the reasoning that says "there's no way that we can hire competent staff, but surely if we pay another company enough, they'll have competent staff."
...and all the bank needs to manage your account is a paper ledger with holes punched for a nice ring-binder.
Data *management* is every bit as important as data storage and retrieval. And don't even get me started on statistics and reporting.
Competency isnt the issue here. I am assuming that whoever the actual developer of the fix is, that they will be extremely competent in fixing the problem. With an external entity, contractual terms of delivery will twist their arms into fixing severity 1 problems with the urgency that they deserve regardless of whether the fix is the best possible coding / architectural solution for the overall Postgres project. With an internal entity, the pressure will be less on them because if management threatens to "chop the head off" because of trying to do the "right thing" instead of just fixing the problem, they will have to stop and consider that they are damaging their own organization. It is always easier for management to be brutal with external entities rather than one of their own.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
Yeah. Or we could do that in regard to all the other mission-critical applications it's been in all this time! :)
If I here those words again, I think my head will explode. I don't remember anyone saying to use a wrench for a hammer if you have both. When people argue these things, they are argueing that a tool is the right tool for a job. PostgreSQL is being argued to be a tool that can be used for enterprise jobs. Either confront that or not, don't just state the obvious. No one said PostgreSQL is the only database to use.
I here this everytime a programming language is mentioned too. Either say Java can't do what perl can, or Java is slower than perl and back those up. Don't say Java is good and Perl is good because everyone knows that.
I don't mean to take my frustrations out on you poor poster, it's just high time people realize that this is like argueing philips or flat-head. It should be a poll option because it's preference, not because there ever is a right or wrong database for a job. It's a choice. After this has been going for a while without problems, we can then proceed to choose PostgreSQL to save money or because we like it better than Oracle or DB2.
It's as annoying as:
1: In soviet russia, Vi>Emacs
2: ?
3: goatse.cx, "MOD PARENT UP"
So you can "chop the head off" the consultant, because they're less important than internal employees. Therefore they are more valuable. Yeah, whatever.
I have to say, I'm pretty suspicious of any management theory which is predicated on the notion that your best option is the one that allows you treat people the shittiest. And god forbid anyone would do the "right thing".
Just exactly why do you think an internal employees idea of what constitutes the "right thing" would be inconsistent with managment's anyway? If indeed you find yourself dealing with employees who let the world collapse around them while they fritter away their time on trivia, they should, in fact, have their heads chopped off. But personally, I know precious few people who would behave in such a manner.
--Lawrence Lessig for Congress!
Oh yeah, Oracle just shines there. In any case, postgres 7.3 took me about 20 minutes to set up, don't know what everyone's bitching about.
sic transit gloria mundi
You are retrieving data from a 10 million row table using a very complex query and you are having performance problems? Who would have thought that?
Normally I get paid a lot of money to solve problems like this but I'll give you a little guidance for free since you didn't like Oracle's answer.
1) Maybe you should think about optimizing your query a bit. Running complex queries against 10+ rows can be problematic even when the RDMS has a good optimizer. Is there a less complex way to accomplish the same thing? If not, you may have to give the optimizer hints. Can you use an index to pull a smaller dataset into a working table where you do your complex operations?
2) Profile your system to determine where the bottleneck is to be found. Is it CPU bound or IO bound. If it's IO bound, would more memory help? Can your tablespace be spread across more disks? Would a beefier system be appropriate? Cost Effective?
This is why you hire qualified developers and administrators. I'm not surprised the tech team gave you that answer. You call the tech team when there is a real problem with the software. If you were paying Oracle to develop the database for you, you might have a case. But then, if that were true, you wouldn't have called tech support, would you?
But you'll notice he said the database was "locking up". No matter how inefficient your query, or whatnot, you shouldn't be able to lock up a database with a select query. Period. And reducing the amount of data is never the answer.
--- It is not the things we do which we regret the most, but the things which we don't do.
When I was in a .com being evaluated for being purchased by a major (top-1) portal; the guy doing due-dilegence had a great oracle comment.
We had a meeting where we went over all our cool redundancy, failover, oracle replication, etc; and at the end the guy turned to our CFO and said something like:
"looks good. but no CFO should let oracle run a high-traffic production web server"
his point was that while Oracle may scale well technologically, it doesn't scale as well financially.
Agreed. Whoever thinks that PostgreSQL is hard to set up has never set up Oracle!
In the recent past, I have set up PostgreSQL on Linux, Mac OS X, and Win32/Cygwin. Setting it up on Linux and Mac OS X is an incredible breeze, it doesn't matter if you are installing from source or a package. It is only difficult to set up on Win32, and only because the user accounts and permissions are (sort of) separately managed across Win32 and Cygwin.
And thank goodness PostgreSQL doesn't have that ridiculous TNS layer. If TCP/IP and DNS were good enough for Grandpa, they are good enough for me!
Do you know many thousands of .org domains are out there? With /etc/hosts, when you go to look up a domain name, it loads up /etc/hosts, and checks, line by line if the domain is in there.
/etc/hosts file has 50,000 hosts in it (which is NOT ALOT, considering the amount of existing domains out there). Now imagine the 2 billion people that are on the internet are hitting your /etc/hosts based nameserver to look up aolsucks.org.
Imagine that your
SQL servers, good ones, do table indexing and cacheing enableing lightning fast lookups even when there are hundreds of thousands of people accessing database (assumeing a fast enough server).
DNS does ALOT more then just mapping names to numbers. If you are interested head over to the dns rfc over here
The goal of computer science is to build something that will last at least until we've finished building it.
I run a text-chat site that is -- please don't lynch me -- based on Win2K and MS SQL Server. The site does about 10-12 DB transactions a second on a slow day and about 100-150/sec on a fast day. At peak hours we have something like 30% CPU usage on the average (it's a 700 Mhz box, not bleeding-edge).
A friend of mine put someone in touch with me who was trying to build a vaguely similar system and was having no end of problems. Transactions were timing out left and right, and his machine was more than twice as fast as mine. From his experiences -- and from what I've seen in a lot of parallel setups -- there is a difference between being able to code something functional and being able to code something that functions intelligently. I'd learned a lot of ways to cut down massively on system overhead -- use stored procedures, turn off locks when they're not required, don't use transactions unless they're absolutely needed, etc., etc. -- and all of them add up and pay off.
As far as PostgreSQL goes, it's probably going to depend on how good a job they do coding it into their system. If they do it well, I'd imagine PostgreSQL is gonna be quite solid. If they do it like idiots, not even the best database solution in the world -- not Oracle, nothing -- is going to save them.
Heck, even Oracle is going to break if you try to fetch a billion rows at once; the trick is to find smarter ways to partition and subdivide the data, to cut down the amount of time needed for every little step on the way. (I found out that adding ONE index in my system sped things up by about 30% alone, an index I would not have realized I needed until I ran a performance profile.)
Let's see how well they do before we sling tomatoes, OK?
Honorary Member of Jackie Chan's Kung Fu Process Servers
stop being such a ig-nant spinning motha focka.
Expanding a vast wasteland since 1996.