Key-Value Stores For Ruby Part 2: Tokyo Cabinet

http://www.engineyard.com/blog/2009/key-value-stores-for-ruby-part-2-tokyo-cabinet/

by Locke • 17 years ago

13 1 17 years ago

jhancock• 17 years ago

I've recently been through testing out 4 different noSQL stores for my new app: Tokyo, Redis, CouchDB, and MongoDB.

For my needs, here's how I ended up with Mongo.

Tokyo - I really wanted this to be the answer as its more mature and fairly feature packed. What killed it was needing to run a different Tyrant for each table/collection. Maybe we'll see a multi-table-tyrant some day.

Redis - Limited by RAM; not full featured. Redis is probably a very good choice if looking for a better memcached. I would need two systems, my RDB and Redis. I want a one-size fits all for my new app. One killer feature of redis is "db-side" editing of collections and sets. Turns out mongo does some of this as well.

CouchDB - I've read mixed results on performance and scalability. The dev model is a bit awkward for me. There are simplifications on that, but I'm not interested in using some ActiveRecord look-alike as I want the unique features of the DB to be more transparent. Time may fix these issues.

MongoDB - more full featured than the above, sort of a healthy blend of each. I can use mongo as both a cache and a full-on DB, although I do not expect the cache to perform as redis would, I just expect it to be "good enough". The dev model is simple, the monogo-ruby-driver is a good mid-level API.

I'm still in the dev process for the new app. Hopefully, I won't run into a serious hitch with Mongo...time will tell. So far, I'm very pleased.

Key-Value Stores For Ruby Part 2: Tokyo Cabinet

Related Stories