0

私は Lucene .Net インデックスを持っています (現在バージョン 2.9.2 を実行していますが、すぐに新しい 3.0.3 にアップグレードする予定です)。

検索パフォーマンスの問題については、DocId からアプリケーション ID へのメモリ内マッピングを作成する必要があります。そのため、格納された値をインデックスから取得する必要はありません (検索結果で数千のドキュメントが返される可能性があります...)。インデックス作成の反復が多いため、このマッピングを何度も更新または再作成する必要があるため、迅速に行う必要があります。

この問題を正確に解決しようとするこの素晴らしい記事を見ました。Lucene のFieldCacheメカニズムを使用して結果を取得するかTermPositions、一意のインデックス付きフィールドで列挙を使用して時間を比較します。著者が言ったように、実際に を使用してそのマッピングを作成することTermPositionsは、Lucene の を使用するよりもはるかに高速ですFieldCacheが、その理由を理解することは私にとって非常に重要です。舞台裏でTermPositionsとの両方が何をしているのか、誰か説明してもらえますか?FieldCache

4

2 に答える 2

0

LuceneのTermPositionsは高度な機能です。私は一度だけそれを使用しました（あなたがそうであったように2.9.xから3.0.3 RC2に移行するとき）。TermPositionsは、データ構造としてのアクセスを高速にし、また小さいTupleを使用して非常に効率的に格納されるため、用語「positions」を含むペイロードの取得も高速です。

私は実際に「LuceneinAction」という本のサンプルを調べました...これはJava用ですが、Lucene.NET3.0.3に最適なLucene3.0.3に基づいています:)

私はこれについて言及します。なぜなら、FieldCacheはその本でかなり深くカバーされており、もしあなたがカバーの下に入りたいのなら（それを深く理解する）...私は最初にそこを見るでしょう。

ところで...その記事はLucene2.2に基づいており、2.3-> 2.9.xは「ほぼリアルタイムの検索」を追加し、多くのメソッドを廃止したときにかなり大きなジャンプでした...3.0.3もそれを変更します、そのため、それらの数は何が起こっているかを反映していない可能性があります。

于 2012-10-30T03:41:55.907 に答える
0

理由は非常に簡単です。Lucene はフィールド値を文字列として保存します。呼び出したときGetIntsに値がキャッシュ内にない場合は、文字列を読み取ってから整数に解析する必要があります。

ペイロードを使用する場合、int をバイト配列にエンコードし、それを int に変換します。この方法では、Lucene に特定の位置で生の 4 バイトを読み取るように指示し、int に変換し直します。

ここで大きな違いを生むのは、文字列の読み取り/解析操作です

于 2012-11-01T19:42:56.000 に答える