Using MySQL as NoSQL Store(yoshinorimatsunobu.blogspot.com)
yoshinorimatsunobu.blogspot.com
Using MySQL as NoSQL Store
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html
3 comments
Absolutely fascinating, agree. So just by talking on other ports they use the NoSQL or SQL approach, depending on whether they are doing primary-key-reads or more complicated joins.
And the best part - they released the plugin to the public. Gotta try it!
And the best part - they released the plugin to the public. Gotta try it!
This is a fascinating post.
Some systems already have two parallel ways of looking up data built in -- an SQL backend such as MySQl and a fast key-value store cache such as memcached. Such a system might be able to be modified to treat the fast direct InnoDB lookup as the cache level, without modifying too much code.
Some systems already have two parallel ways of looking up data built in -- an SQL backend such as MySQl and a fast key-value store cache such as memcached. Such a system might be able to be modified to treat the fast direct InnoDB lookup as the cache level, without modifying too much code.
It's similar to how FriendFeed uses (used?) MySQL:
http://bret.appspot.com/entry/how-friendfeed-uses-mysql
http://bret.appspot.com/entry/how-friendfeed-uses-mysql
One of the things I don't understand is how the ACID properties carry over. InnoDB is fully transactional and ACID-compliant, but how does it manage this without the SQL locking that was slowing it down? Said another way, if the table/row locking overhead from SQL queries was such a problem, why is it in MySQL at all?
Also, the problems he identified don't seem like they should be problems. Shouldn't you be able to all but eliminate SQL parse costs with prepared statements? Why are his PK inserts and reads causing table locks (since Google tells me you can turn this off)? This strikes me as weird.