ぱぱネット（仮）

_ [開発][Linux] Tokyo Cabinet / Tyrantで遊ぶ(3)

一番気になっているのは、Q-GRAM転置インデックスを作成するだけで、登録時間がわずかではあるが級数的に伸びていること。これがlogみたいなグラフを描くのなら安心して使えるのだが 2000万件超えた当たりで1登録あたり257時間かかりますね(^^; とか言われるとマジ死ぬ。

わかったことをいくつか。インデックス生成含め検索操作の関数群はtctdb.cにほぼ全てまとまっている。 そこでtctdbsetindeximpl関数をみると

  case TDBITQGRAM:
    idx->db = tcbdbnew();
    idx->cc = tcmapnew2(TDBIDXICCBNUM);
    idx->name = tcstrdup(name);
    tcxstrprintf(pbuf, "%cqgr", MYEXTCHR);
    if(dbgfd >= 0) tcbdbsetdbgfd(idx->db, dbgfd);
    if(tdb->mmtx) tcbdbsetmutex(idx->db);
    if(enc && dec) tcbdbsetcodecfunc(idx->db, enc, encop, dec, decop);
    tcbdbtune(idx->db, TDBIDXLMEMB, TDBIDXNMEMB, bbnum, -1, -1, bopts);

てなわけでB+木データベースそのものらしい。実際に出来上がった*.qgrファイルをhoge.tcbという ファイル名にリネームしてtcbmgrでダンプしてみる。

$ tcbmgr inform hoge.tcb
path: hoge.tcb
database type: btree
additional flags:
comparison function: lexical
max leaf member: 64
max node member: 256
leaf number: 34150
node number: 191
bucket number: 9209
alignment: 256
free block pool: 1024
inode number: 1171692
modified time: 2010-03-24T10:44:13+09:00
options: large
record number: 594699
file size: 305556224

あー....20万行しか登録してないのに59万個の単語にわかれているのか。 そりゃ遅いかもな。でも、BTreeの素直な実装だと検索時間はO(log n)に依存し、登録操作もほぼ同様なはず（どくらいの単位でひとまとめにしてるかに依存するが）。 でもこれって、6万行を超えたあたりから急速に処理時間が延びる説明にはならないんだよね。

まあdcbdbtuneを読んでいる箇所はわかったので、 基本仕様書のB木チューニングの章を 読んでチューニングしてみたが、これまた芳しくない。一応、

tcbdbtune(idx->db, 24, TDBIDXNMEMB, bbnum, 12, -1, bopts)

が一番速いようだがせいぜい数％.....ボトルネックは別にあるのかな。

リーフ内メンバ数やバケット数をいじっても、ほとんど変わらないかむしろ悪化する場合が大半だった。

1. TDBIDXLMENBを24に変更
2. bbnumを20000000変更
3. TDBIDXQGUNITを3から4に
4. TDBFTSBMNUMを524287から687903に変更
5. tcbdbsetxmsiz(idx->db, 1024*1024*1024);

などなど。

_ [開発][Linux] gprofの結果

TC/TTのconfigureはプロファイル出力をサポートしており

$ ./configure --enable-profile

でコンパイルしなおすとgmon.outを作ってくれる。これでインデックスありとなしを比べれば 特徴的な処理が洗い出せる....はずだと思ったんだけど。

インデックス一切無しの場合：

Q-GRAMインデックス有りの場合：

正直パーセンテージだけ見ると違いがわからん。Q-GRAMの時だけ、特定関数がものすごい勢いで 呼ばれてるとか、とても時間を食う関数が呼ばれているとか、そういう単純な問題ではないようだ。 総合的なI/Oスループットの問題だとすると、チューニングは実に厄介だ。

_ [開発][Linux] 抜き身のナイフ

読んでみてなんとなくわかったのは設計思想で、 Tokyo Cabinetはいわゆる安全側に振ってあるRDBMSとは全く違う。抜き身のナイフのようなもの。 俺みたいな素人がお気軽に手を出せるモンじゃねーな.....

例えば。tcmapput関数などを生でmmapしたファイルにガンガンポインタベースでmemcpyしちゃう。 「え？普通じゃん？」と思うかもしれないけど、RDBMSではまずやらない。 書き込めない場合の回避処理が大変だからね。

実際、昨日のサンプルを、少量のtmpfsを切った上で実行したら ttserverがバスエラーで落ちてワロタ 。バグじゃなく仕様なんだろうなあ、これ。

ああ、TCのネガティブキャンペーンをしている訳ではありませんので。念のため....。