曖昧文字列マッチングのindexをtrieにしたのだが、前よりもモッサリした感じになった。

以前のバージョン 1.0.x では、”Kanji”というクエリに対して、1.6MByte程度のインデックスがKVSから１回で返ってき ていた。 例 MASTER::(ka) ka … kanji … (1.6MByteもある)

今回のtrieを使ったバージョン 1.1.x (開発版) ではtrieのツリーを辿りながら、曖昧文字列マッチングをするという方式に変えた。 文字列の流さが10文字であれば、悪くて100回程度のKVSへのリクエストが飛ぶ可能性がある。 例 Master::Index::k a$ Master::Index::ka n Master::Index::kan j Master::Index::kanj i$ . .

良くなった点

登録が軽くなった。 ユーザー辞書に新規の語彙を追加した時にも重くならない。 read/writeのバランスが良くなった。 1.0.xでは辞書登録中は重くて10秒以上レスポンスが返ってこないことも多かったが、1.1.xでは辞書登録の影響はほんとんど無くなった。 1.0.xではインデックスの更新に、1.6MByteのwriteが発生することになるので、かなりDISK I/Oに負荷を掛けていたに違いない。 1.1.xでは小さいエントリを沢山細切れに書くようになる。writeの合間にreadも可能だ。

悪くなった点

* 変換レスポンスが悪くなった。

Tokyo Cabinetを使った時の体感的なレスポンスが悪くなった。 sekka-benchmarkコマンドでベンチマークを取ると３倍ほど速くなっているんだけど、それはベンチマークの方法が悪いということで… Redisを使った時はほとんど劣化は無いような気がする。

* 辞書が大きくなった

辞書のリストア用TSVイメージであるSEKKA-JISYO.SMALL.tsvが223Mから381Mに増えた。 結果、redis-serverが消費するRAM容量が800MByteから1.4GByteに増えた。 redis-serverが消費する容量の増加具合が比例していない気もするが、Redisのkeyのインデックス分なのではないかと推測する。 KVSのエントリ数は 3873011件 から 11533536件 に増えた。エントリ数は約３倍だ。

改善案

1.0.x は Tokyo Cabinetが使うメモリ容量は64MByteだが、それを256Mや512Mくらいに設定してやれば、もしかしたら良いバランスに落ちつく可能性がある。 要はDISKのreadを適度に抑制してやる必要があるわけだ。 RedisはDISK I/Oが無いので高速なのは当然だが、メモリが大量にある人向けのオプションだなぁ。 自分はRedisを使うけど。

感想

なんかローカルにsekka-serverを立てる場合、良くなったのか悪くなったのかわからないなぁ。 多分、今回の変更でスケールアウトするようになったのは確実なのでそのあたりも調べてみたい。 しかしスケールアウトするといってもぴったりマッチするKVSも無いわけだが… (Redis Clusterか？) うーん、何だか趣味の領域を脱出できてない気がする…