|
|
|
|
|
|
by apendleton
4665 days ago
|
|
|
Having just gone through the exercise of picking an embedded key-value store for a project, some things that would be nice: how does it compare to other things besides leveldb (which, to be frank, isn't a stellar performer)? In particular, how does it compare to Tokyo/Kyoto Cabinet, Lightning MDB, or Sqlite4's LSM? Does it support data compression (either with a single pre-selected algorithm like LevelDB and Snappy, or in pluggable fashion like LSM)? How does it deal with concurrent access by multiple processes? |
|
|
What really concerns me is why never in benchmarks they perform on already filled database (like, 14G, 28G, 60G)? Because "add 100k random keys into an empty database" is very different from "add 100k random keys into a large database". And that is where more novel algorythms start to shine.
Yes, read speed of leveldb (and, i assume, sophia) with its fancy sst's is lower than of plain old b-trees or hashtables (kctree/kchash), but it is still high enough for most tasks. Write performance of kc* (and btree-based libraries in general) is, however, unacceptable, at least on hard drives, and even with a reasonable-sized database (~90% of RAM) it degrades to a couple of random write per IOPs (so, 200-300 writes per second on a consumer-grade HDD, or up to 1000 on a 2x10k sas hdd in raid-0, if i remember correctly)
It may be reasonable to use kc* on SSD, but i did not test that.