I’ve been meaning to look into this for some time to get my head around these fancy new databases and find out when I should consider using them. I’ve come to the conclusion that you generally wouldn’t use an object/key-value database on it’s own. You have your main relational database for important data that is definitely required, and then you can have multiple key-value databases to do a lot of the firehose-data grunt work across multiple servers.
A setup might look like:
Relational Database:
You need your relational database for things that a user absolutely has to have every request (e.g. you always need to access the users login details).
NoSQL/Key-Value Database:
However for things that don’t really matter (like posts, tweets, comments) then you can use a key-value store because who cares if all the comments/tweets etc aren’t listed every request as long as you show something and you know it’s going to be correct at some point.
I believe this is how reddit works it has postgres server(s) and then multiple cassandra servers for submissions. I assume it’s similar for facebook except, I think, they use mysql & cassandra.
Conclusion:
For your next web app I’d start with your usual relational database of choice. Once you get to the stage when you have the performance/scalability issues to deal with then you might take a bigger look into the NoSQL/key-value stores.
Some interesting links:
- http://www.engineyard.com/blog/2009/key-value-stores-in-ruby/
- http://www.engineyard.com/blog/2009/key-value-stores-for-ruby-part-2-tokyo-cabinet/
- http://www.engineyard.com/blog/2009/cassandra-and-ruby-a-love-affair/
(facebook & reddit use this) - http://www.engineyard.com/blog/2009/key-value-stores-for-ruby-part-4-to-redis-or-not-to-redis/
- http://www.engineyard.com/blog/2009/mongodb-a-light-in-the-darkness-key-value-stores-part-5/
- http://blog.boxedice.com/2009/07/25/choosing-a-non-relational-database-why-we-migrated-from-mysql-to-mongodb/