テーブルにデータが非常に少ない場合は、4つのテーブルすべてを1つのコアにインデックスするべきです。各ドキュメントにテーブル識別子をインデックスし、クエリ時にその識別子を使用できます。

// personテーブルの場合

{
  "name": "neha",
  "type": "person"
}

// departmentテーブルの場合

{
  "name": "information technology",
  "type": "department"
}

// sportテーブルの場合

{
  "name": "cricket",
  "type": "sport"
}

これらのすべてのドキュメントにはnameフィールドがありますが、typeフィールドに基づいて区別することができます。

よろしくお願いします。
Saurabh

これはフィルタークエリを使用するのに適した場面でもあります。特に、テーブルの任意の組み合わせから結果を取得したい場合に有効です。

ここでSaurabh Sharmaさんの意見には同意しません。

もし本当にそれらのテーブルのデータ間に関係がないなら、それぞれを別々のコア、またはクラウドモードで実行している場合はコレクションとしてインデックスするべきです。このほうが設定がシンプルになり、一つのテーブルの変更が結合されたコア全体に問題を引き起こす可能性が低くなります。そうした影響は変更されたテーブルのコアに限定されます。

複数のテーブルからのデータに同じフィールドを使用できる場合、Luceneのファイル形式の働き方によって、4つのインデックスを1つにすることで若干のスペース節約が実現できることがあります。しかし、ほとんどの設定では、そのスペース節約はデータを結合しないことで回避できる問題に比べて非常に小さいです。

複数のデータベーステーブルからのデータを同じコアにする意味があるのは、テーブル間に明確な関係がある場合だけです。DBサーバーで定期的にJOINクエリを使用しており、それが検索にも拡張される場合、SolrがJOINを行わずに作業を達成できるようにすると、Solrのパフォーマンスが向上します。Solrのクロスコアジョイン機能は非常に限定的であり、特にパフォーマンスの面では、データベースジョインに詳しい人が期待するものとは異なります。

Daveが述べたように、もしデータを結合するなら、必要に応じて結果をフィルタリングできるように、少なくとも1つのフィールドをインデックスする必要があります。

よろしくお願いします。
Shawn

同じ名前のフィールドに対して異なるフィールドタイプを考慮していませんでした。例えば、あるテーブルがフィールドにファセットを求めているが、他のテーブルは同じフィールド名でテキスト検索だけを求めている場合、これが問題を引き起こすでしょう。

文脈がないと質問に答えるのが難しくなります。例えば、すべてのテーブルに対して1つのクライアントなのか、それぞれに1つずつのクライアントがいるのか、あるいは……そもそもリレーショナルデータベースを使用しているのに、関係がないならなぜ使うのか？

4つのコア（コレクション）を作成することをお勧めします。1つのコアにまとめると、スキーマがすべてのテーブルの統合になり、管理が複雑になります。どのフィールドがどのテーブルに属しているかについて、多くのコメントが必要になるでしょう。

4つのコレクションを作成し、それぞれのテーブルに対応する4つのスキーマを用意しましょう。これにより、それぞれを独立してロードし、スキーマを独立して更新することができます。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

私たちも異なる種類のエンティティをすべて1つのコアに入れるという似たような設定をしています。フォールディング、ステミング、管理されたシノニムなどはすべてのエンティティタイプで同じでなければなりません。ビジネスニーズに合わせて1つのスキーマを更新する方が簡単だと感じています。インデックスに新しいエンティティタイプを追加するのは、通常コードだけで完了します。REST APIを介してシノニムを管理するロジックは、これらの変更を認識する必要すらありません。

私たちのスキーマには3つの必須フィールドがあります：

• uid はuniqueKey（type + idの組み合わせ）で、アトミックアップデートやIDによる削除に使用されます
• type はフィルタークエリで使用される文字列フィールドです
• id はデータベースからの（通常はオートインクリメント）識別子で、ほとんどのクエリがこれを取得します

その他のフィールドはすべて動的です。ほとんどのデータが自然言語テキスト、逐語的な文字列、日付、またはデータベースの外部キーである整数なので、動的フィールド定義を追加することは非常に稀です。

このアプローチのもう一つの利点は、共通フィールドで「テーブル間のクエリ」を実行し、エンティティタイプごとのファセットカウントを取得できることです。

これは私たちにはうまく機能しています。もしテーブル間のファセットを必要としない場合、Solrで異なるフィールド名を一致させたくないために各フィールドを明示的に定義したい場合、各テーブルごとに特定のスキーマ要件がある場合、管理されたシノニムに煩わされたくない場合など、テーブルごとにコア（コレクション）を持つ方が良いかもしれません。

Thomas