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)
Verisign runs the shared registry with Oracle, but the registrar-specific data was and still is stored using Ingres.
Open source software is becoming increasingly popular lately. A few years ago, many people laughed at the concept and thought that open source = security risk. Those who supported it have proven otherwise. Closed source programs end up having more bugs and security holes in the long run because open source programs get debugged by thousands of users.
.Org is just one shining example of how large organizations are beginning to lean toward open source, not necessarily in support of open source ideals, but because it's simply better quality.
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
org. is tld (top level domain).
. (dot) is the root.
the story on the wasted 98% was about the . (dot) root servers, not about a tld server. you (and sadly, too many others) should read rfc 1035.
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
Well, we ran Postgres as our primary database for a Managed Network System Security,a nd the postgres database stored all alerts coming in from all our sensors, which included a .EDU that had qutie a bit of traffic going through it (our own implemented honeypot). The only issue we ran into was with disk space with packet logging, which was unrelated to the Postgres Database. We would get any number of hits per data into the database (sometimes over a million in a weeks time). Ive come to prefer Postgres over MySQL, although Id still take Oracle over each if I could afford the license.
Someone who worked for the State of California, perhaps? There were a bunch of people who lost their jobs over that debacle.... See here for more info.<wry grin>
Catherine
Well, Red Hat is using PostgreSQL for their Red Hat Database package and presumably would provide support for it. You can also find support partners for PGSQL at http://www.pgsql.com/partnerlinks/.
from the artical it didn't look like TCO was a factor.
1: they liked versioning in postgress.
2: they liked the open source comunity.
3: Oracle didn't have anything over postgress[that wsa usefull]
Maybe 2 relates to TCO, the amount you'd have to pay to get the same level of developer support on oracle would be huge.
thank God the internet isn't a human right.
Short answer: MySQL simply doesn't have the feature set of either Oracle or PostgreSQL. Subselects, views, etc. ... (It does have transaction support now, fortunately.) These are features which have been on the "coming soon" list for a while, and which a lot of developers regard as essential.
...
Having worked pretty extensively with both MySQL and PostgreSQL, I'll say that what keeps me going back to MySQL is speed, speed, speed. Yeah, having to implement stuff in interface code (PHP or Perl) that I really ought to be able to do in SQL is a bummer, but the queries are so much faster that it makes up for it. But it's really a matter of personal preference. PostgreSQL is a very good DBMS.
Hoping to head off the apparently inevitable MySQL-PostgreSQL flamewar
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Just did another Oracle TAR (telephone assistance request) via their Metalink site.
In 5 minutes, there was real person working on it.
In 20 minutes, he explained the behaviour(oracle bug) and suggested the workaround.
Disclaimer: I do not work for them, do not rely on income from DBA work and do prefer Postgres for my own projects
...that the entire O'Reilly Practical PostgreSQL book was put online?
;) Looks like it is time to revisit postgres, especially for some db-agnostic PEAR apps I'm building. For me, it's the subselects that really make it worth the effort.
I've spent so much time lately in the (relatively) flat-table world of MySQL that I had forgotten about inherited tables, subselects, constraints in table definitions, and oh yes, vacuuming.
http://tinyurl.com/4ny52
MySQL performed better than Postgres, especially on select-only queries, until not too long ago. I did some profiling on a web-based app at work where MySQL outperforms Postgres, and it turns out, that only approx. 0.02% of queries are INSERTs or UPDATEs, so it seems MySQL still has an edge in some applications.
Postgres also seems to have an (unfair, IMHO), reputation for being hard to set up.
And yes, MySQL has come a long way in the last 3 years, and does support transactions now.
/Styx
It depends on what you're using it for!
:)
MySQL locks the entire table to insert a row, so no-one else can use the table during inserts - hence why slashdot runs so fsk'ing slowly.
PostgreSQL does better-than-row-level locking so inserts don't hold up the system. It can also scale much higher than mySQL ever could.
MySQL also has a tendancy to completely destroy databases during system failure... PostgreSQL doesn't suffer from this!
Postgres has a lot of SQL standard commands in, but mySQL will get them in v. 5 (2010???)
hope this helps!
The database is a buffer between the requests comming in from the registrars and the DNS resolvers. So you get a bunch of requests comming in once a day saying stuff like 'change asm.org DNS to 10.2.3.243' and the registry has to decide what to do with them. To do that they need to have a bunch of info stating what registrar owns the account at the time and so on. And yes it is not unknown for registrars to attempt to do things they should not.
The DNS infrastructure that is queried by you DNS server is completely separate. Every hour or so the SQL database will do a dump which will then be checked and if it passes will be sent to the production DNS infrastructure which is essentially a read only affair.
So no, this does not mean that every DNS lookup in .org is going to result in a mySQL transaction. Nor can you say anything about whether this deployment proves mySQL is ready for primetime, at least not yet you can't. You probably want to wait to see how the zone holds up over the next few months before drawing any judgements.
BTW the technical name for Oracle features is 'complications'.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
The real problem with Postgresql, however, is that if you are doing lots of updates where the keys increase forever, the index files grow forever. You can, of course, drop and recreate them (which we do in a cron job), but in a real 24/7 environment you've got a real problem when your queries all turn into table-scans because the indexes aren't built yet.
Here is some more information (seeIndex Maintenance? )
The only option I know if is to have two sets of tables and swap between them.
-- ac at work
The transition details can be found on the Public Interest Registry's Homepage. In short, they'll close the registry at 14:00 UTC tomorrow, transfer to Afilias's systems, and reopen the registrations on Sunday at 23:00 UTC.
I was wondering the same thing myself.
Over the past two years, I've spent a great deal of time working with postgresql with relation to an online game I've been helping to develop (Open Merchant Empires).
We've been able to get good performance out of postgresql as long as we don't expect 24/7/365 availability. They've made great progress in making the VACUUMs less intrusive, but we've always ran into trouble if we don't impose on the database availability with a regular maintenance schedule (very regular partial vacuums which slow the database down considerably, semi-regular full vacuums which lock up the database, and occasional full rebuilds).
I'd love to learn how they achieve the high availability I'd expect you'd need for a TLD database server.
As far as I know, there has never been any regulation as to who can and can't register a .org domain. The association with not-for-profits is a convention, not a rule. Same with .net, which initially was for ISPs and other network service providers.
.org and .net are largely used by registrants who couldn't get the .com they wanted. (On the other hand, I have two .org domains registered for legitimate non-profits, a town band and a cat shelter.)
Nowadays,
everything has your answer.
Along with the answer to, you betcha, everything else!
POST-GRES-CUE-ELL.
They have an mp3 on their web site.
I usually just call it "postgrez" or "pee-gee".
-h3
Yes, you are wrong, as of PostgreSQL 7.2 VACUUM can run without locking the table completely.
Garbage collection is a problem every database faces. Due to ACID requirements it is pretty much (absolutely?) impossible to run a database that updates rows without having multiple versions of the same row on disk at some time during the operation. So at some point in time you have to get rid of that duplicate. You can choose to do that after commit of a transaction (or the last transaction for which the row is still visible), but that would potentially make every transaction slower. So in PostgreSQL the choice was made to do this at an administrator determined moment (and I presume that choice also was the easy one).
In older versions of PostgreSQL VACUUM would lock the entire table and physically force all the valid rows to be rewritten consecutively and then reclaim the space at the end. This mode is still available as VACUUM FULL, but nowadays there is a new mode (sometimes called lazy vacuum) that only marks space safe to be overwritten. Subsequent updates/inserts will overwrite it eventually.
Regular running of this command will eventually lead to some steady state where there is some x% of bloat in the table, but there is no significant amount of locking required.
Because...
PostgreSQL is particularly good when you don't just store and retrieve data, but want to use complex queries, do a lot of calculations with the data, write your own functions etc. Not only is support for standard SQL more complete with PostgreSQL than with MySQL, PostgreSQL has many extensions that can be very useful. Using these extensions can, of course, mean that moving to another DB system will be difficult, but there are manuals how to port between Oracle and PostgreSQL (e.g. plpgsql and oracle pl/sql). Migrating applications that use extensions of the Microsoft SQL server would certainly be harder because there are fewer similarities than with Oracle.
I don't have very much experience with MySQL, when I saw some time ago how few in-built functions it has and and didn't see an easy way for programming own functions, I moved to PostgreSQL. It's possible that MySQL has become better in that respect in the meantime.
I mainly use PostgreSQL and Microsoft SQL server, and I'd say that from a programming perspective PostgreSQL is better for extensions. I'm not sure if newer versions of Microsoft SQL server now support writing your own aggregate functions and have got rid of the maximum nesting level in stored procedures, in any case none of this has been a problem with PostgreSQL for a long time.
As has been mentioned, an important reason why PostgreSQL isn't mentioned as often as MySQL probably is that it doesn't run natively on windows.
What you'll really missed in PostgreSQL for 24/7 is a good replication. But they are working on it.
By the way, are you sure you want 24/7/365? I think 24/7/52 will be more correct, no? I don't think that 7 years of uptime is a good idea when you want to upgrade your software (usually you stop/restart the service for it) about ever year.
Less is more !
PostgreSQL Inc. offers excellent support contract options, enterprise software additions (replication!), and traning, etc. for PostgreSQL. Check them out at:
http://www.pgsql.com/
Or the most common answer from Oracle tech team is "we know its a problem but we will not fix it in this release. Just buy the next version if you want it fixed ?
...according to my Oracle sales rep.
Actually, they suggest you upgrade to the newest version, not that you buy anything new. Licenses purchased from Oracle are for a product family for a length of time determined by the license. For example: if you bought a four-year single cpu Enterprise Edition license two years ago when 8i was the current release, you have the right to use 9i, and 10i when it appears, until the end of your license term.
Arr! The laws of physics be a harsh mistress!
Unfortunately, I haven't found new data, but here is a list of January 2001. .com: 21,174,751 .net: 2,806,721 .uk: 2,078,474 .de: 1,732,994 .org: 1,614,740 .nl: 416,842 .kr: 325,203
...
The top ranks are:
1.
2.
3.
4.
5.
6.
7.
The numbers have certainly changed since then, but perhaps the ranks are still similar. Maybe someone has found new data?
That is a bold faced lie. You sir, are a liar.
pg_dump not only runs WHILE the database is up, it does so in such a way as to ensure completely transactionally pure backups (i.e. snapshots) with virtually no impact on performance.
And they do so in SQL.
If you don't know anything about a subject you should keep you mouth shut. You only convince people you're ill informed and ignorant when you post lies.
--- It is not the things we do which we regret the most, but the things which we don't do.
My god.
Go crawl up your database and hide in a cell.
Firstly, reducing the amount of data is crap. What if you have 10 million records? Should the answer from *tech support* be "well, don't!"?? That's what you advocate.
Oracle dropped the ball here. First, because the database *crashed* on the query. If you're telling me that *any* query I run should be able to outright *crash* the database then go work for Microsoft on MS-SQL. Worst case, the database should thrash incessantly (and accept a kill) or consume too much RAM and kill itself off, but certainly not HANG. I can't believe you suggest that's the fault of the person running the query and not the developer.
But secondly, and most importantly, Oracle should definately offer tips on what to do. I mean, regardless of the situation, the thing ran, and *died*. Not slow. Not exceeding resources. Died. If it's a bug, fine. Then you offer a bloody workaround, *especially* if you have no intention of fixing the bug!
I mean since when is *crashing* an app not a reason to call tech support? Is it because you run Windows and are *used* to the tech support response of "Reboot, try again"??
Geez.
First question of the faq...
t ml #1.1
http://www.us.postgresql.org/docs/faq-english.h
I didn't say the data was locked into Oracle. What I said was that you cannot create an SQL file containing the data using just a *simple* *Oracle* command. I can write a one-line command that will dump the database into a proprietary Oracle binary file, but I cannot do that to dump the data to an SQL file. I *can* dump a postgres database to an SQL file using an one-line postgres command. That SQL file could be used (maybe a few small modifications would be needed) to import all my data into a MySQL database, for instance.
Check out DirectNIC.
I don't work for them or know anybody who does, but I've had all my domains on there for a couple years (after getting fed up with Networ... uh I mean Verisi... uh I mean Network Solutions) and have been very happy with the price and performance. Quick and clean management interface.
I did an informal benchmark on "enterprise level" queries when PostGreSQL 7.2 came out, and found that PostGreSQL came within a third of Oracle's speed on hash joins and within half of Oracle's speed on sorts, both on DSS type queries. Not bad at all for free, but not a cost-effective replacement for Oracle either.
From what I understand, Oracle stores numeric data in such a way that a straight byte-compare will return the proper order, and it looked to me like PostGreSQL was doing conversions for every compare. Oracle's hash joins are just mind-blowingly fast. Other operations are mind-numbingly slow.
Note however this is meaningless; Oracle performs differently on different hardware (this was Tru64/Alpha stuff) and different versions (8,8i,9i) can perform very differently on the same hardware.
There are lies, damn lies, and benchmarks.
I'll second that. I'm not proud of it but I hit /. at least 3 times a day. The response can be horrible sometimes. Many times, I get "server not found" errors or MySql errors (aka, "static page only whole MySql DB server is getting rebuilt/rebooted"). Of all the sites I frequent (FiringSquad, Tomshardware, Anandtech, etc.) this site as the worst performance. True, it does have the least amount of static comment (a huge threading system, but the other sites have small but active forums too). Still, Anandtech runs fricken Cold Fusion on Windows of all things and it runs better!
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Firstly, we were able to make some substantial assumptions about our database updating.
Finally, we put a layer on the front-end webserver, which feeds transactions to all of the backends in parallel. For transactions effecting change it waits for answers to be in agreement before passing the response on to the client. For enquiry transactions it just feeds the first response back as soon as it gets it.
Basically, we worked around the fact that there is no two-phase commit in PostgreSQL. There are a few gotchas in there that we had to workaround, (e.g. updates to any given domain are serialised) but the above was the plan, and it has worked out just fine in practice.
There is also a backend process to catch up the replication on any server that has to be taken out of the loop for a period of time. Since the backend servers are geographically distributed (with a VPN holding it all together) it is fairly easy for one to drop out of action for a short period.
All in all, the replication model we used took around 4 weeks effort to implement, which was probably a reasonable price to pay. Even with support for two-phase commit we would still have had a significant amount of effort to use it, and to do the automatic catch-up processing.
There's more information (a full technical architecture and prototype findings document) at the NZ Domain Name Commissioner's website
Andrew McMillan.