Slashdot Mirror
MySQL Creator Contemplates RAM-only Databases
Aavidwriter writes "Peter Wayner asks Michael 'Monty' Widenius of MySQL, 'When will RAM prices make disk drives obsolete for database developers?' From Monty's answers, it sounds like hard drives may be nothing but backups before long." From experience, I'd wager that RAM failure rates are less than hard drive failure rates, so it might also mean more stability from that perspective.
Surely a well tuned database server stores uses quite a lot of RAM for buffering?
Well, a professional database like Oracle manages its own cache, but MySQL really only relies only on the OS-level cache. The problem with that approach is that the database knows a lot more about what you're doing, so it can make much smarter decisions about what to cache, what to age out, what to prefetch, etc. On an Oracle server, you want to lock the buffer in memory, and leave as little as possible over for the OS filesystem cache. You see, if a block doesn't exist in the cache, it has to be fetched from disk into the database cache, and if it does, the db will go straight to its own cache. Another caching layer inbetween provided by the OS is just wasted.
I don't think Monty understands any of this; in the article he seems to say that ACID, rather than being a fundamental principle of relational databases, is just something you need to do because disks are slower than RAM. The only reason that you might not want full ACID and use semaphores instead, as he suggests, is because you are only updating one record in one table in a single transaction!
Further, if he is thinking in terms of a few Gb of data, then he is a little out of touch with modern database usage. SouthWest airlines do not have a database that stores 10 bytes of data for every seat on every flight, and I have a hard time figuring out why they would want to - the database of seats would be tied into the customer records, the freight/baggage handling database, the billing records, the accounting system. That is the point of relational database, that you can query data based on data that exists elsewhere. Monty thinks in terms of databases that have only a few tables, because that's all you can do in MySQL. He says that database programmers are forced to be very careful about the consistency of their data - well those using MySQL are, but those using Oracle (or any other database with real transactions and real integrity constraints) find it's all taken care of transparently.
From the article:
Umm, no. There is no difference in the ACID algorithm whether the database is stored in memory or on disk. The only thing that is easier to do in memory is to fake it, because for low levels of concurrency you can serialize everything without anyone noticing. But that strategy will collapse under load. Far better to do it properly the first time. Yeah, it slows you don't with a single user, but when you have tens or hundreds of users connected, it'll still work.
Actually, the algorithms are the bottleneck on disk too. Monty would know this if he had a query optimizer like the one in Oracle (or had even looked at an explain plan).
Nonsense - you need ACID if there is any conceivable case in which two users might want to access the same data at the same time, or if there is any conceivable case that a write could fail, or if you want to support commit/rollback at all. In other words, if you're running a database and not a simple SQL interface to flat files. Hell, there's an ODBC driver for CSV that does all that MySQL does.