PythonとMySQL、TokyoCabinet、KyotoCabinetによる単語頻度集計のベンチマーク
http://bit.ly/eiYS1S で随時更新。この日記も随時変更します。
今ちょっとyuka_でもっと質の高いreplyをやろうと思ってて、そのためにまず必要な単語の共起回数を取っています。
例えば「おはようございます」に対して「@hoge おはようなのよ」ってあった場合、「おはよう ござい ます」「おはよう なのよ」と分割して、{おはよう:{おはよう:1, なのよ:1}, ござい:{おはよう:1, なのよ:1}, ます:{おはよう:1, なのよ:1}}みたいな形にしていきます。
でこれをMySQLでやってると気の遠くなる時間がかかるのでTokyo Cabinet(TC)やKyoto Cabinet, Hadoopと比較していいやつ使うといいかなぁと思います。あくまでイイヤツを採用するだけでベンチマークが主ではないです。
今んとここんな結果です。単位は[sec]です
| 処理件数 | 1000 |
| MySQL | 1524 |
| Tokyo Cabinet | 2.72 |
| Kyoto Cabinet | 2.67 |
| MySQL(input file) | 1050 |
| Tokyo Cabinet(input file) | 0.57 |
| Kyoto Cabinet(input file) | 0.51 |
通常時で50倍くらい違います・・なのでmysqlはなし。尤もTC側はインデックスを全く作ってなかったりするのでその処理加えるともっと時間かかりますが。
補足
- 実験環境は以下の通りです
| PC | PhenomII X4 945, DDR2 8GB, 500GB HDD(OS), X25-M 80Gx2 Raid0(MySQL, TC) |
|---|---|
| OS | Ubuntu 10.04 x64, Linux 2.6.32-27-generic |
| MySQL | 5.5.8 |
| Tokyo Cabinet | 1.4.46 |
| Python | 2.6.5 |
- pytc, sqlalchemyとか使用
- なんかソースコードが1つになってたのを分割したら結構早くなった・・(MySQLで1800->1500, TCで6->2.7)pythonのコンパイルって結構影響あるんですね
- 処理の流れとしては、
- 文章とそれに対する返信の文章を取ってくる
- それぞれmecabで単語に分割
- 分割したやつを上の述べた感じにdictにする
- これとは別に1,2を事前に処理してファイルから読み込んで3の処理をするのも用意しています(input fileってやつ。あとでHadoopとの比較で使う？)
- あとこう言ったデータは本来はTrieに入れたほうがいろいろ便利なんでしょうねぇ
続きの作業
- Kyoto Cabinet。Python-legacy使えばいけそう
Kyoto Cabinet, あっさり動いた。本体とpython-legacyバインディングの最新版をビルド→インストール。pytcとの違いはDBつくるとこが若干変わった(BDB→db = DB;db.open()？)のと、addintじゃなくてincrementにしたとこ。ただ何故かファイルが出来ない？ちょっと勘違いしてそうだし見直す。BDB→DBじゃなくてBDB→db = DB;db.open()が正解だったみたい。時間もちょっと遅くなった。
