7

単一の Solr インスタンスに単一のインデックスを作成するか、単一の Solr インスタンスに複数のコアを作成し、各コアがインデックスにサービスを提供するかを決定する際に、支援が必要です。私の理解では、solr の単一のインデックスは通常、1 つのタイプのドキュメントにインデックスを付けるために実装されます。ドキュメントの種類が異なる場合のベスト プラクティスは何ですか? たとえば、請求書トランザクションの詳細をインデックス化する場合、次のように請求書トランザクション ドキュメントのフィールドを含むスキーマを作成できます。

  • 請求書の日付
  • 期日
  • 請求書概要
  • 請求連絡先
  • 請求書明細
  • ノート

製品の詳細のインデックスも作成したいとします。次のようなスキーマを使用して新しいドキュメント タイプを作成します。

  • 製品コード
  • 製品説明
  • 販売価格
  • 購入価格
  • 手元に
  • 平均費用
  • ノート

Solr で新しいコアを作成して、製品ドキュメントのインデックスを作成しますか? または、次のようにトランザクションと製品の両方を 1 つのスキーマにマージしますか?

  • 請求書の日付
  • 期日
  • 請求書概要
  • 請求連絡先
  • 請求書明細
  • 製品コード
  • 製品説明
  • 販売価格
  • 購入価格
  • 手元に
  • 平均費用
  • ノート

「請求書」コアと「製品」コアが2つの異なるドキュメントにインデックスを付ける代わりに、上記のドキュメントにインデックスを付けるコアが1つだけありますか?

フィールドが類似している場合、 Solr wikiで提案されているように単一のフラット インデックスを持つことは理にかなっていると思いますが、上記のような例では、データは別々のエンティティであるため、互いにリモートで関連付けさえされていません。テーブル名フィールドなど、さまざまなエンティティを区別するために追加のフィールドを追加し、テーブル名フィールドに基づいてクエリをフィルター処理することを提案するケースを見てきましたが、これはうまくいくと思います。次のようなユースケースがある場合、それがどこまでスケーラブルかはわかりません。

"キーワード「John」で請求書を検索します。検索するフィールドは「billingContact」、「invoiceSummary」、「notes」です。クエリ時に「billingContact」フィールドをブーストします。また、「John」で製品を検索します。検索するフィールドは「 productDescription', 'supplier', 'notes'. クエリ時に 'supplier' をブーストします. 100 の請求書と 100 の製品のみを返します."

私が取り組んでいるアプリケーションでは、単一のフォームから請求書と製品を検索する必要があります。アプリケーションには、さまざまなものを検索するさまざまな部分はありません。

すべてを 1 つのインデックスにまとめることに対する私の懸念。

1) インデックスのサイズが大きい 例: 5,000 万件の請求書 + 5,000 万件の製品 (単一インデックス)

2) そのサイズのインデックスの再インデックス。

3) インデックスの調整: 単一のインデックスでそれを行うよりも、特定の予想される検索結果を提供するために、個々のインデックスを微調整/調整する方が簡単ではないでしょうか?

4) 今後、請求連絡先の詳細もインデックス化することを決定します。これにより、インデックスを作成するフィールドがさらに追加され、ポイント 1) および 2) の私の懸念に貢献します。

4

1 に答える 1

0

100 の請求書と 100 の製品のみを返します。

また

クエリ時に「billingContact」フィールドをブーストするクエリ時に「supplier」をブーストする

これは、同じ用語を検索していても、それらを別の概念として検索していることを示唆しています。

これと共通フィールドの欠如に基づいて、個別のコレクションから始めることをお勧めします。

于 2013-10-28T02:59:13.270 に答える