Interesting article. I've recently been doing some load-testing of key-value stores for caching, and also found that MySQL compares pretty favourably with some

Interesting article. I've recently been doing some load-testing of key-value stores for caching, and also found that MySQL compares pretty favourably with some of the new kids on the block. Just talking a "create table (key char(64) not null, value blob not null, index (key))" schema. (Plus some MySQL performance tweaks, which I won't go into here) Some advantages: * When it comes to redundancy and failover, you can re-use the existing master/slave replication functionality in MySQL, rather than worry about whether your k/v store of choice supports anything like this, how stable it is and how to configure and manage it etc. One less thing to worry about especially if you're already doing mysql replication for other data. * MySQL can keep hot data in RAM and cold data on disk, and is pretty tuneable in this regard; some of the trendy k/v stores aren't so hot on this front (eg Redis, although they're addressing it in version 2) * With InnoDB tables (which are pretty good for k/v functionality) you get the transaction support which can save your ass from some nasty race conditions with concurrent processes writing back to a cache. Especially handy if your main relational dataset is also in MySQL since you can update the normalised data and the cached data in one transaction * You can join 'relational-style' tables directly to the 'k/v-style' tables, rather than having to fetch a bunch of IDs and then look them up (for some stores, one at a time) in a separate store. Which is a great when you have some infrequently-changed data that can be denormalised as cached blobs, and some frequently-changing data which refers to it. * Possibly more...