2513529 ランダム
 ホーム | 日記 | プロフィール 【フォローする】 【ログイン】

傀儡師の館.Python

PR

日記/記事の投稿

カレンダー

キーワードサーチ

▼キーワード検索

カテゴリ

バックナンバー

2020年01月
2019年12月
2019年11月
2019年10月
2019年09月
2019年08月
2019年07月
2019年06月
2019年05月
2019年04月

フリーページ

プロフィール


kugutsushi

サイド自由欄

設定されていません。
2007年11月22日
XML
カテゴリ: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 には対応していないようだ。

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 には現在申請中とのこと


なかのひと







最終更新日  2007年11月24日 18時24分20秒
コメント(0) | コメントを書く
[Python] カテゴリの最新記事

Copyright (c) 1997-2020 Rakuten, Inc. All Rights Reserved.