Thursday, March 11, 2010

Move over BDB? On Tokyo Cabinet, CDB, Redis

Somehow I have managed to miss obvious competition that is creeping up for crown of best simple non-distributed persistent (disk-based) key-value store. So far choice has been (or so I thought) mostly between BDB flavours: BDB JE (Java Edition) and its slightly older big brother, BDB-C ("native"). And about only other choice would have been a Java clone, JDBM (which regrettably hasn't really woken from its hibernating state, despite interest).

But it turns out that there are many more choices out there, solid, mature, high-performing choices. Specifically:

The three are not exactly equivalent, actually: only Tokyo Cabinet can be seen as exact replacement of BDBs. CDB, for example, is a read-only store. And Redis is an in-memory store, but with memory backup (snapshot, or journaling), and slightly expanded value handling semantics (with some set and list value primitives, for aggregate operations).

This diversity is actually a good thing, however; as per "right tool for the job" thinking, they all should have specific sweet spots regarding usage. In fact, I could see each of them excel in slightly different tasks. And BDB, too, is probably still the best choice for some use cases; specifically BDB-JE that has pretty good behavior under heavy concurrency scenarios, thanks to its design.

But what would those optimal tasks be? That is something that would require actually using them, or at least playing with them, perhaps building simple benchmarks. That sounds like a good idea for some prototyping, for near-term future. :-)

UPDATE (16-Mar-2010): Looks like Redis is getting some more tailwind, as perthis announcement (Redis author joins VMWare, will work on Redis). Very cool!

blog comments powered by Disqus

Sponsored By

Related Blogs

(by Author (topics))

Powered By

About me

  • I am known as Cowtowncoder
  • Contact me
Check my profile to learn more.