Skip to content

Key-Value Stores For Ruby Part 2: Tokyo Cabinet

engineyard.com
13 pointsLocke1 comment
On HN

Comments

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.