2つの異なる（シャードされていない）Luceneインデックスのマージ方法

Question

2つの別々のインデックスがあり、インデックスのすべての検索可能フィールドが含まれています。たとえば、最初の索引はすべての文書の索引付きテキストを保持し、2番目の索引は各文書ごとにタグを保持します。

以下の例は、私がエンティティの名前を変更したためちょっとしたものです。 index1に： テキスト 文書-ID

インデックス2： タグ名：「非常に重要」 ユーザー：「フレッドのID」

継続的に更新するために、無駄なようだと私はインデックスが別々に保管したいと思いますユーザーがタグを追加/削除するたびに1つのインデックス。

これまでのところ、私は2つの検索結果を処理し、手動で（コードで）マージする必要があるかもしれないと思います。

別個の/断片化されたインデックスをマージしたくありません。

Answer 1

Luceneは、この配置をサポートするタイプがIndexReaderです。— ParallelReaderです。

レコードのLuceneドキュメント識別子は、両方のインデックスで同じでなければならないため、少し使いにくい場合があります。実際には、これは両方のインデックスに同じ順序でドキュメントを追加することを意味します。私はいくつかのケースでは、文書の削除とインデックスの最適化によってLuceneにこれらの文書識別子を再割り当てさせる可能性があることを読みましたが、これが真であるかどうかを調べるために実験していません。既存のレコードが変更された場合は、追加の注意が必要になることがあります。新しいレコードだけが追加された場合、問題はありません。

このアプローチは、「水平パーティショニング」またはシャーディングとは対照的に、一般に「垂直パーティショニング」と呼ばれます。

Answer 2

コード内のインデックスをマージする必要があるようです。私が正しく理解していれば、用語を検索するときに、文書のテキストやタグに一致するものがあり、各タグは関連する文書IDで索引付けされます。次に、2つのヒットリストをマージします。タグとフルテキストは非常に異なるエンティティであるため、良いランクに達するためには重み付けが必要になります（検索時のフィールドブースト）。

a、bは経験的に決定係数になります

score(k) = a*tagscore(k)+b*fulltextscore(k)

：したがって、次のような式を使用して文書のkに対してタグヒットとフルテキストヒットをマージすることができます。

さらに詳しい説明については、Grant Ingersollのfindabilityおよびdebugging relevance issues in searchの記事を参照してください。

Answer 3

このアプローチの主な問題は、デフォルトのアルゴリズム（およびたぶんほとんどのカスタムアルゴリズムは、例外を除いて）が用語頻度と逆文書頻度に基づいているため、文書の順位付けと関連があります。

つまり、Scorerは、用語がドキュメント内に何回表示されるか、およびその用語を含む他のドキュメントの数を知る必要があります。この情報は、索引の各用語ごとに保管されますが、複数の索引にまたがる集約には保管されません。

この問題に対する共通の解決策は、2段階アプローチです。まず、各索引に対してクエリが実行され、各用語が含まれるドキュメントの数が決定されます。次に、結果が集約され、クエリが再度実行されますが、今回は逆文書頻度も一緒に送信されます。

これは、単一のインデックスに対してクエリを実行するのと同様に機能しませんが、何も無料ではないので、複数のインデックスにまたがってドキュメントを格納することとのトレードオフと思われます。