What's interesting about this article now, is the feature is (more or less) going mainline in MySQL 5.6, except the API will be the standard memcached protocol and not the handler socket API in the linked article.<p>See: <a href="http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-with-memcached.html" rel="nofollow">http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-...</a>
This is awesome. I assume it could be applied to the most frequent queries run by common MySQL apps like WordPress to support much increased load, whilst not being forced to employ memcached.
I've had good luck using MySQL as the data source of record (setup in a NoSQL style InnoDB table) and then having a Membase cluster which supports replication between different servers. I will probably start using the MySQL/memcache features to play around with them but I don't really see a compelling reason to do so considering that I probably execute less than 10 queries a day against the MySQL version of our caches. I use deflate to decrease the size of my caches so they only really use maybe 2 GB of memory.
Duplicate of <a href="http://news.ycombinator.com/item?id=1886137" rel="nofollow">http://news.ycombinator.com/item?id=1886137</a> from October 2010.<p>Edit: submissions have identical URLs. Is there something wrong with HN's de-duping system?
I don't like how this article frames MySQL vs. NoSQL as the important battle. There <i>are</i> other SQL databases besides MySQL, and there's lots of variation in the various NoSQL offerings.