Hatena::ブログ(Diary)

kazuhoのメモ置き場

2010-02-22

Solr って、書き込みの Disk I/O が多くて、リアルタイム検索は不可能なのかしら

Apache Solr入門 ―オープンソース全文検索エンジン を読んでいて、pp.266-267 に、以下のような記載があった。

・Optimize の重要性

 <optimize/> コマンドは Solr のインデックスを物理的に最適化するコマンドです。具体的には、Solr では commit のたびに一群 11 個のファイルを作成します。

 つまり、細かく commit を繰り返す形で文書の投入や更新を繰り返すと、その分だけインデックスとして多くのファイルを使うようになり、ひいてはファイルディスクリプタが枯渇する事態に陥ります。

 仮に枯渇しなくても、多くのファイルを開いて検索に利用することになるため、パフォーマンスに甚大な影響を与えてしまいます。

 この事態を回避するため、目安として 5 回程度 commit を行ったら最低 1 回は optimize コマンドを発行するようにしてください。

 optimize を行うことで、複数回分に分かれてしまっていたインデックスファイル群が1つにまとめられ、問題の発生を抑えることができます。

これって、

  • 一定回数 commit する毎に全データの sorted merge join (あるいはそれ以上) の Disk I/O が発生するってこと
    • 書き込みの I/O コストが保存済のデータ量に対して O(n)
      • ただしシーケンシャルアクセスだとは思うけど
  • commit 間隔を短くできない

ってことですよね? リアルタイム性が必要な検索とかでは使いものにならない?

optimize には maxSegments を指定できるみたいですが、それでも O(n) であることには変わりないし。

インデックスのサイズを倍々になるような設計にすれば、せめて O(log N) までは落とせると思うんですが、そういうパッチを誰か書いていないんでしょうか?

1台のマスターに対して100のスレーブがあるような大規模環境ならともかく、小規模な環境では、データの書き込み回数>全文検索回数だったりするわけで。「誰でも使える全文検索」を狙うなら、これは相当辛いなんじゃないかなぁ。crash-safe なのは、とてもいいと思うんだけど。

私の誤認ならごめんなさい。

2010年2月24日追記: 松信さんから以下のような話をうかがった。なるほどなー

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証