Python のいろいろな方法でキーと値の保存と検索をやってみようかと 書いたが、cdb、gdbm、qdbm、Tokyo Cabinet をそれぞれ使ってみるとパフォーマンスはどの程度なのだろうということで、取り組み始めた。やっぱり、cdb はどういうときでも別格に速い。スタティックなデータのルックアップあるいは、データの一方的な記録（参照せずに記録するだけで、データを使うのは別フェーズ）であれば、もう断然 cdb。これは Python から使っても問題なく速い。cdb の地位は揺るがない感じ。Python からは python-cdb 0.3 で今のところ問題なし。

でも、読み書き両方が交錯する場合は使えないので、何を使ったらよいか。

Berkeley DB に関して

何でもかんでも RDBMS に突っ込むのがいいかといえばそんなわけもなく、RDBMS を使わない方がいい場合もあるじゃないのというのは、当然なわけで、そんな折り、ちょうど Oracle も Why a Non-Relational Database? A Comparison of Berkeley DB and Relational Databases なんてまた出してきた。Oracle Berkeley DB: Performance Metrics and Benchmarks みたいなホワイトペーパーも出している。でもって、Oracle Berkeley DB なんてのも、ちゃんと市場のニーズを取りこぼしなく抑えておこうということなんだろう。この市場はどうあがいても捨てられないものね。AES encryption 版ってどの程度のパフォーマンスなんだろうか。

ということで、Berkeley DB 試すの忘れてた。Python Bindings for BerkeleyDB 3.3 thru 4.5 とかいう選択肢もある。標準モジュールでも、BSDDB は使えるが後付けでインストールするなら、これを使うといいかもしれない。標準モジュールの bsddb でも、どちらもパフォーマンス的には変わらない印象。下の QDBM のところにある GDBM と比較すると、書き込みのパフォーマンスが若干よい感じ。ちなみに現状で Python バインディングが正式に対応しているのは BDB 4.5 までで最新の 4.6 には対応していないようだ。

BSDDB btopen Write

Write

real    0m25.679s

user    0m13.754s

sys     0m6.946s



Read

real    0m13.858s

user    0m10.492s

sys     0m3.300s

QDBM に関して

QDBM: Quick Database Manager に関しては、GDBM の代わりに QDBM に置き換えたら、パフォーマンスがよくなった。

QDBM のバインディングは Python のコンパイル前に直接ソース(Module/gdbmmodule.c)や Module/Setup などを書き換えてコンパイルしたもので、GDBM を語って動く環境で試している。QDBMのチュートリアル を見ていて、いっそのことこれでやってしまえとやってみたら案外簡単だった。古い GDBM のデータは不要とかいうのであれば、従来の import gdbm とやっていたプログラムであっても、ソースの変更なしに使い続けられてパフォーマンスがあがりそう。ただ、書き込みは確実に速くなるのに対して、読み込みは場合によって同程度とかもデータによってはあり得る感じ。

そういう強引はだめよという場合は、QDBM Python bindingでも、ほぼ同じパフォーマンスが出せる。けど微妙に前述の方法の方が試した限りでは高速な感じ。

GDBM

-- Write --

real    0m27.888s

user    0m6.793s

sys     0m10.630s



-- Read --

real    0m12.878s

user    0m7.704s

sys     0m5.116s



QDBM

-- Write --

real    0m17.520s

user    0m5.988s

sys     0m8.471s



-- Read --

real    0m12.821s

user    0m6.757s

sys     0m6.017s

まあ、条件とかによって数値はいくらでも変わってくるところがあるが、どうあがいても QDBM と GDBM だと Python から使っても、QDBM の方に軍配があがる感じ。

Tokyo Cabinet に関して

感触として Tokyo Cabinet のPythonバインディングを書いている人いますか？ PyTCのリポジトリ のもは、実用レベルという感じ。100万文の登録・読み込みテストをやっても問題が生じなかった。パフォーマンス的にも良い感じ。単純な使い方をする限りは問題なさそう。

これはかなり使えそう。GDBM や QDBM ではパフォーマンスが劣化してしまうようなデータを使っても、pytc.BDB を使うと大丈夫だったりした。 pytc.HDB は、キーの長さが文章の一文相当で、値もその数倍というようなデータをたくさん追加していくと、劣化が激しいのに、BDB の場合はそれほど劣化しない。データの性質とか量によって、ちゃんと使い分けないといかんねという感じ。

Tokyo Cabinet BT

Write

real    0m9.947s

user    0m6.340s

sys     0m2.881s



Read

real    0m9.258s

user    0m6.499s

sys     0m2.643s



Tokyo Cabinet Hash

Write

real    0m18.427s

user    0m6.377s

sys     0m7.234s



Read

real    0m12.335s

user    0m7.177s

sys     0m5.101s

CDB に関して

CDB の速さは別格。用途が限られるけれど、CDB で大丈夫な用途であれば、CDB が一番。でも、データによっては Tokyo Cabinet をチューンしながら使ったら、そこそこ近いパフォーマンスが出せるのかもしれない。

CDB

Write

real    0m8.236s

user    0m4.916s

sys     0m3.154s



Read

real    0m7.379s

user    0m6.081s

sys     0m1.269s

ざっと見た感じ Tokyo Cabinet とその Python バインディングは、バランス的にかなり期待できそうな印象がある。これで信頼性と安全性が高まれば、CDB を使っていたところ用途でも使い分け面倒だし、これでいこうかという感じになるかもしれない。

データベースの選択にあたっては、表面上のパフォーマンスだけでなくて、壊れにくさとかそういうところもあるかもしれない。というか、それがかなり大きい選択の要因になるわけで、mixi で実用で使い始めましたとなれば、そのあたりもクリアできたんだろうという目安になるかな。まあ、長い間、使われているものは、いろいろなデータや使い方がされていているだけに隠れた地雷を踏む確率は低いわけだけど、とにかく速いの欲しいというところから使って枯れていけばかなりよいものになりそう。

全般的な印象として、Tokyo Cabinet はかなり期待できそうな印象が強い。Tokyo Cabinet + PyTC は、十分実用のために本格的に試して意味があるレベルにあると思う。いいなこれ。

以上、データによって、かなり変わるからあくまで参考レベルということで。なんて、この手のものを使う人にはあえて言う必要もないだろうけど。

追記 2007/11/24
pytc-0.1 - Tokyo Cabinet Python bindings公開 で、http://tasuku.suenaga.name/pub/pytc/pytc-0.1.tar.gz にとりあえず公開されたらしい。sourceforge には現在申請中とのこと