[Lucene] IndexReader/Searcherのオーバーヘッドとは

Question

Luceneのドキュメントのほとんどは、新しいReaderを開くためのオーバーヘッドのために、indexReaderの単一インスタンスを保持して再利用することを推奨しています。

しかし、私は、このオーバーヘッドが何であり、何がそれに影響を与えているのかを知ることは難しいと感じています。

これは、実際に開いているIndexReaderのオーバーヘッドがどのくらいかかりますか？

この質問のコンテキストは次のとおりです。 現在、ServletContainerからフルテキストを実行するクラスタ化されたTomcatスタックを実行しています。 これらの検索は、クライアントごとに個別のLuceneインデックスで行われます。これは、各クライアントが自分のデータのみを検索するためです。これらの索引の各々は、数千から（現在）約100,000の文書までの範囲を含む。

クラスタ化されたtomcatノードのため、どのクライアントも任意のtomcatノードに接続できます。 したがって、IndexReaderを開いたままにすると、実際には各Tomcatノードに数千のindexReaderを開いたままにしておくことになります。これは悪い考えのように思えますが、常に再開は非常に良いアイデアのようには見えません。

Luceneを配備する方法を多少変更する可能性はありますが、必要がない場合はむしろそうしたいと思います。

Answer 1

通常、フィールドキャッシュはウォーミングアップするのに最も遅いLuceneの部分ですが、フィルタやセグメントポインタなどの他の要素も寄与します。キャッシュに保持される特定の金額は、特に索引付けされたデータとは異なり、どのくらいのデータが格納されているかなど、使用状況によって異なります。

あなたの環境に適したメモリ使用量調査ツールを使用して、Lucene自体がアプリケーションにどれくらいの時間を費やしているかを知ることができますが、「ウォームアップコスト」は、OSとファイルシステムは開いたままにします。おそらくtopに表示されません。

何千ものインデックスを持つことはよくあることではありません。標準的なアドバイスは、インデックスを共有し、フィルタを使用して適切な結果が返されるようにすることです。

パフォーマンスに興味があるので、サーバー上に何千ものインデックスがあると、何千ものファイルがディスク全体に広がってしまいます。あなたは大きなインデックスを1つだけ持っていました。要件に応じて、これが問題になる場合もあります。

Luceneにとって大きなパフォーマンスのヒットであるネットワークファイルシステムを使用しているようです。