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:
- Tokyo Cabinet (TC)
- CDB (Constant DB -- and probably a play on fact that 'C' follows 'B' in alphabet), and especially (?) its Java version, sg-cdb
- Redis
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!
