2

次の仮定を考慮してください。

  1. フルテキスト検索に Lucene 3.0 を使用することを検討している Java 5.0 Web アプリケーションがあります。
  2. 1000K 以上の Lucene ドキュメントがあり、それぞれに 100 語 (平均) が含まれます。
  3. 新しいドキュメントは作成直後に検索可能でなければなりません (リアルタイム検索)
  4. Lucene ドキュメントには、quality という名前の整数フィールドが頻繁に更新されます。

Lucene 3.0 の準リアルタイム検索のコード例 (単純だが可能な限り完全) はどこにありますか?

頻繁に更新される可能性のあるドキュメント フィールド (品質) のいずれかでソートされたクエリ結果を取得することは可能ですか (既にインデックスが作成されているドキュメントの場合)。このようなドキュメント フィールドの更新は、Lucene インデックスの再構築をトリガーする必要がありますか? そのような再構築のパフォーマンスは何ですか？効率的に行う方法 - 完全なソリューションの例/ドキュメントが必要です。

ただし、この場合、インデックスの再構築が必ずしも必要ではない場合、検索結果を効率的に並べ替えるにはどうすればよいですか? 大量のドキュメント (>50K) を返すクエリが存在する可能性があるため、Lucene から並べ替えられていないドキュメントを取得し、品質フィールドで並べ替えて、最後に並べ替えられたリストをページ分割のためにページに分割するのは効率的ではないと考えています。

Lucene 3.0 は Java 内での最良の選択ですか、それとも他のフレームワーク/ソリューションを検討する必要がありますか? SQL Server自体が提供する全文検索かもしれません（私はPostgreSQL 8.3を使用しています）？

4

2 に答える 2

4

Lucene APIは、あなたが求めているすべての機能を備えていますが、それは簡単なことではありません。これはかなり低レベルのAPIであり、複雑なことを実行させること自体がかなりの演習です。

Lucene上に構築された検索/インデックス作成フレームワークであるCompassを強くお勧めします。非常に使いやすいAPIだけでなく、Luceneインデックスへのオブジェクト/ XML / JSONマッピングや、完全なトランザクション動作などの機能を提供します。トランザクションで更新されたドキュメントのリアルタイムの並べ替えなど、要件に問題はありません。

Compass2.2.0はLucene2.4.1に基づいて構築されていますが、Lucene3.0ベースのバージョンが開発中です。ただし、Lucene APIから十分に抽象化されているため、移行はシームレスである必要があります。

于 2010-01-09T21:50:58.300 に答える
1

Near Real Time Search は2.9 以降の Lucene で利用できます。Lucid Imagination には、この機能に関する記事があります (2.9 リリース前)。基本的な考え方は、IndexWriter から IndexReader を取得できるようになったことです。この IndexReader を定期的に更新すると、IndexWriter から最新の日付の変更を取得できます。

更新: コードは見たことがありませんが、大まかな考え方は次のとおりです。

すべての nw ドキュメントはIndexWriter、できれば で作成された に書き込まれ、RAMDirectory頻繁に閉じられることはありません。(このメモリ内インデックスを永続化するには、場合によってはディスクにフラッシュする必要があります。)

個々の IndexReader が作成されるディスク上にいくつかのインデックスがあります。これらの Reader の上に MultiReader と Searcher を作成できます。Reader の 1 つはインメモリ インデックスから取得されます。

定期的に (たとえば数秒)、MultiReader から現在の Reader を削除し、IndexWriter から新しい Reader を取得して、新しい一連の Reader で MultiReader/Searcher を構築します。

Lucid Imagination の記事 (上記のリンク) によると、彼らは 1 秒あたり 50 個のドキュメントを書き込もうとしましたが、速度が大幅に低下することはありませんでした。

于 2010-01-10T05:40:47.550 に答える