High-end MySQL use
To a large extent, MySQL lives in two different alternate universes from most other DBMS. One is for low-end, simple database applications. For example, of all the DBMS I write about, MySQL is the one I actually use in my own business — because MySQL sits underneath WordPress, and WordPress is what runs my blogs. My largest database (the one for DBMS2) contains 12 megabytes of data in 11 tables, none of which has yet reached 5000 rows in size.
The other alternate universe for MySQL is Very Large Internet Companies. Often, via a technique called sharding, a very simple schema is massively partitioned, with different partitions on different machines. Consider, for example, the following quote from the High Availability MySQL blog:
It almost never crashes for me now, but you might not be able to make the same claim. Well, if you use MyISAM rather than InnoDB you might be able to make the claim, but in that case you really need it to not crash as MyISAM might not recover to a transaction consistent state. The fix is not in the official release. This is almost a repeat of a recent post, but one thing has changed. We deployed the fix for bug 32149 and eliminated the cause of the majority of crashes from software bugs. We still get crashes on a daily basis, but hardware is the cause.
On a first read, that seems ridiculous — crashes are daily, they used to be worse, and this is called “High Availability”?? But let’s look at the first sentence of the author’s bio:
Mark is the lead for the MySQL Engineering team at Google that supports a large MySQL deployment.
Suddenly the whole thing makes a lot more sense. Google’s basic approach to computing is to run farms of 100s or 1000s of servers, each of which may have an individual Mean Time Between Failures measured in months.
While we’re at it, I got that bio from an April, 2008 talk. The talk’s abstract is revealing as well:
The InnoDB storage engine is an amazing work of engineering and art. But it has a flaw. It was designed for servers with few CPU cores and few disks. Design decisions made then limit the scalability of InnoDB on today’s commodity servers, which happen to have many disks and CPU cores. InnoDB and the MySQL community are working hard on fixing these problems. I will describe the performance problems in the official release and fixes for the problems that have been developed by InnoDB, Google and the MySQL community.
If you want a highly industrial-strength DBMS, and you don’t want to co-develop it yourself, MySQL probably isn’t for you. But that doesn’t mean it isn’t a fine product for other uses, or other users.
Comments
One Response to “High-end MySQL use”
Leave a Reply
The good bits of our work are now in official InnoDB — http://www.innodb.com/wp/2009/08/11/innodb-plugin-104-released.