最速KVS研究第Redis V.S. LevelDB

最速KVS研究第4弾 - なぜか数学者にはワイン好きが多い
どこまでも続きます．

目的が全く違う2者ですが，敢えて比較してみました．
もちろん，Google LevelDBと似たコンセプトのものとの比較も今後進めますが．．．

とりあえず，キー長はmd5ハッシュの長さ固定，バリュー長を変化させ，かつ同時アクセス数をスレッドアクセスで変化させて読み書き時間を測ってみました．

まず，バリューの長さが100バイトと短い場合のベンチ．

同時アクセス数を表すスレッド数が少ないときはLevelDBの書き込みが爆速，読み込みはなぜか遅い．．．redisはスレッド数に関わらず安定して読み書きとも中間な感じです．

次，バリューの長さが1000バイトの中間的ベンチ．

やはりLevelDBはスレッドが1だと書き込みが最も速く，同時アクセス数が増えると遅くなる．
読み込みの方は，redisよりは遅いものの同時アクセス数が増えると共に速くなる．明らかに書き込み時のロック排他制御が強力で遅くなっているようです．

最後，バリューの長さが10kバイトのロングバリューベンチ．

LevelDBの書き込み遅い．．．読み込み速いですね．．．バリューが短い時は読み込みが遅かったのに．．．
これらは，LevelDBが圧縮するかどうかとか，キャッシュサイズとかを自動的に制御するからと思われます．
実に面白いです．

凄いことに，Tokyo Cabinet/Tokyo Tyrant/Kyoto Cabinet/Kyoto Tycoonの作者が，組み込み型DBのLevelDBをネットワーク透過型にする方法をいち早く書いておられます．
http://fallabs.com/blog-ja/promenade.cgi?id=130
http://fallabs.com/blog/promenade.cgi?id=30

今日，Kyoto CabinetのネイティブC++APIを使ってみて，そのDBアクセス速度とMapReduceの速度に驚きました．
まだまだ最速KVSシリーズ続きます．