|
|
|
2007.11.22
カテゴリ：Python
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 には対応していないようだ。
QDBM に関してQDBM: Quick Database Manager に関しては、GDBM の代わりに QDBM に置き換えたら、パフォーマンスがよくなった。 QDBM のバインディングは Python のコンパイル前に直接ソース(Module/gdbmmodule.c)や Module/Setup などを書き換えてコンパイルしたもので、GDBM を語って動く環境で試している。QDBMのチュートリアル を見ていて、いっそのことこれでやってしまえとやってみたら案外簡単だった。古い GDBM のデータは不要とかいうのであれば、従来の import gdbm とやっていたプログラムであっても、ソースの変更なしに使い続けられてパフォーマンスがあがりそう。ただ、書き込みは確実に速くなるのに対して、読み込みは場合によって同程度とかもデータによってはあり得る感じ。 そういう強引はだめよという場合は、QDBM Python bindingでも、ほぼ同じパフォーマンスが出せる。けど微妙に前述の方法の方が試した限りでは高速な感じ。
まあ、条件とかによって数値はいくらでも変わってくるところがあるが、どうあがいても QDBM と GDBM だと Python から使っても、QDBM の方に軍配があがる感じ。 Tokyo Cabinet に関して感触として Tokyo Cabinet のPythonバインディングを書いている人いますか？ PyTCのリポジトリ のもは、実用レベルという感じ。100万文の登録・読み込みテストをやっても問題が生じなかった。パフォーマンス的にも良い感じ。単純な使い方をする限りは問題なさそう。 これはかなり使えそう。GDBM や QDBM ではパフォーマンスが劣化してしまうようなデータを使っても、pytc.BDB を使うと大丈夫だったりした。 pytc.HDB は、キーの長さが文章の一文相当で、値もその数倍というようなデータをたくさん追加していくと、劣化が激しいのに、BDB の場合はそれほど劣化しない。データの性質とか量によって、ちゃんと使い分けないといかんねという感じ。
CDB に関してCDB の速さは別格。用途が限られるけれど、CDB で大丈夫な用途であれば、CDB が一番。でも、データによっては Tokyo Cabinet をチューンしながら使ったら、そこそこ近いパフォーマンスが出せるのかもしれない。
ざっと見た感じ 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 には現在申請中とのこと お気に入りの記事を「いいね！」で応援しよう
Last updated
2007.11.24 18:24:20
コメント(0) | コメントを書く
[Python] カテゴリの最新記事
|
