MongoDB: A Light in the Darkness
engineyard.com
engineyard.com
For us, we're using tokyo and it explodes at 70GB of data, though I'm guessing its a configuration issue or something. We purge it every week now since its just used as a persistent cache and I haven't looked into why, but it puzzles me how it can just basically break at a certain limit and not just start pushing things to disk.
To cut through the noise, can anyone here vouch for a simple "plug and play" kv store that actually works as advertised, at scale, and ideally is distributed so I can just add nodes as needed? Third party tall tales and anecdotes don't count, I want you to explain in detail your own personal experience running one of these things on a real, live, many-noded system. CouchDB, MongoDB, Tokyo, Redis, HBase, MemcacheDB, Voledmort, Cassandra, the list goes on (I realize not all of these are strict k-v stores), who out there other than the original authors can get up front and say these things work well?
I can't resist giving you an anecdote, though:
can anyone here vouch for a simple "plug and play" kv store that actually works as advertised, at scale, and ideally is distributed so I can just add nodes as needed
Yes, MongoDB :) With the caveat that the sharding support is alpha at the moment, database-level sharding is ready right now. Timeline is agressive in getting this solid, too.
I've been looking at and waiting for the right document-oriented database for over a year now (almost 2, it seems) and I settled on Mongo after lots of experimentation.
Someone has to step forward and try it. You did that with tokyo and noticed it doesn't. Report your bug and after it's fixed it will work better for the next person to try.
can anyone here vouch for a simple "plug and play" kv store that actually works as advertised
It doesn't exist. For the simple reason that most K/V stores are under 2 years old and haven't gotten enough real world exposure to work all the corner cases out.
If you want rock-solid then you're looking at the wrong market. Use PostgreSQL. It's not optimized for that use-case, but it's as chuck-norris as you'd expect after 20 years of development and production vetting. It won't segfault under load, it won't corrupt the datastore and it won't plot sawtooths while plowing through a large index.
And at the end of the day a K/V store is a table with two columns, right?
Second, we use PostgreSQL for our RDMBSes -- I can't really say we've tried using it with the same use cases we'd be using for our K-V store and if it would work. We're talking tens of millions to hundreds of millions of HTML documents keyed by URL, and I'm skeptical the performance we'd get would be close to the 1000-10000 tps we experience with tokyo. Would be a good experiment, though!
At the same time, these articles can be very valuable for us right now. Yes, this particular piece is a bit fluffy, but they invite skepticism and many of the feedback people give.
We've never used Voldemort in production, but in heavy load testing we were able to stuff in a few hundred million records with only three instances. Retrieval remained acceptably quick, even while the inserts where going on. However, when we looked it didn't support repartitioning/rebalancing of the data set. This may have changed.
Cassandra and MongoDB offer a great deal more functionality than, say, Voldemort or Tokyo. Cassandra seems like a really awesome choice, but is currently under heavy development.
(I work for rackspace and we have an internal app going live on Cassandra in the coming days. But it doesn't technically qualify for "in production" yet.)
Inserts and indices, however are very very fast, and the bug was fixed incredibly quickly and now works in trunk.
It doesn't seem quite cooked yet, but it's a very very nice start, and promises much. I prefer it to the other KV stores that are out there right now, anyway.