

Key-Value Stores For Ruby Part 2: Tokyo Cabinet - Locke
http://www.engineyard.com/blog/2009/key-value-stores-for-ruby-part-2-tokyo-cabinet/

======
jhancock
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.

