Solr って、書き込みの Disk I/O が多くて、リアルタイム検索は不可能なのかしら
を読んでいて、pp.266-267 に、以下のような記載があった。
・Optimize の重要性
コマンドは Solr のインデックスを物理的に最適化するコマンドです。具体的には、Solr では commit のたびに一群 11 個のファイルを作成します。
つまり、細かく commit を繰り返す形で文書の投入や更新を繰り返すと、その分だけインデックスとして多くのファイルを使うようになり、ひいてはファイルディスクリプタが枯渇する事態に陥ります。
仮に枯渇しなくても、多くのファイルを開いて検索に利用することになるため、パフォーマンスに甚大な影響を与えてしまいます。
この事態を回避するため、目安として 5 回程度 commit を行ったら最低 1 回は optimize コマンドを発行するようにしてください。
optimize を行うことで、複数回分に分かれてしまっていたインデックスファイル群が１つにまとめられ、問題の発生を抑えることができます。
これって、
- 一定回数 commit する毎に全データの sorted merge join (あるいはそれ以上) の Disk I/O が発生するってこと
- 書き込みの I/O コストが保存済のデータ量に対して O(n)
- ただしシーケンシャルアクセスだとは思うけど
- 書き込みの I/O コストが保存済のデータ量に対して O(n)
- commit 間隔を短くできない
ってことですよね？ リアルタイム性が必要な検索とかでは使いものにならない？
optimize には maxSegments を指定できるみたいですが、それでも O(n) であることには変わりないし。
インデックスのサイズを倍々になるような設計にすれば、せめて O(log N) までは落とせると思うんですが、そういうパッチを誰か書いていないんでしょうか？
1台のマスターに対して100のスレーブがあるような大規模環境ならともかく、小規模な環境では、データの書き込み回数＞全文検索回数だったりするわけで。「誰でも使える全文検索」を狙うなら、これは相当辛いなんじゃないかなぁ。crash-safe なのは、とてもいいと思うんだけど。
私の誤認ならごめんなさい。
2010年2月24日追記: 松信さんから以下のような話をうかがった。なるほどなー
