4

リレーショナル データベースのアナロジーに基づいて、Solr がどのように適合するかを知りたいと思います。私がこれまでに考えたことに基づいて、Solrの「ドキュメント」はSQLの「行」に似ており（SQLテーブルに100行ある場合、solrに100のドキュメントを挿入する必要があります）、「コア」は「テーブル」に似ています（またはデータベース?!?)。

質問は次のとおりです。無関係な情報が 2 セットある場合、車の情報 (ID、名前、シリーズ、色、説明) を含むテーブルと、ユーザー情報 (ID、名前、住所、年齢、性別) を含むテーブルがあるとします。これらのものをSolrに挿入しますか? 2 つのコア (core_car、core_user) を作成し、それぞれに対応するテーブルのドキュメントを入力しますか? または、1つのコア（core_general）を作成し、そこに両方の​​テーブルからすべてのドキュメントを挿入します（方法がわからない方法で分離されています）。

2 つのコアを使用する最初のケースでは、それぞれに 1 つのテーブルを持つ 2 つのデータベースを作成しているように感じます (やり過ぎ)。2番目に、関連のないすべてのフィールドが一緒にまとめられた1つのテーブルを作成しているように感じます（これは、何らかの形式の分離があった場合には当てはまりません-現時点ではわかりません）。

私の推測を確認してください。前もって感謝します。

4

1 に答える 1

2

質問を投稿する前に調べていただきありがとうございます。これが私の意見です。

Solr ドキュメント: おそらく、この概念を理解するためのより適切な方法は、結果の観点から考えることです。各 Solr ドキュメントは、検索クエリを実行した後の結果セット内の 1 つの結果エントリにすぎません。

ウィキペディアのインデックスを作成する場合、各記事は Solr ドキュメントになります。「ソート アルゴリズム」で検索すると、「バブル ソート」や「マージ ソート」などの結果が表示されます。それぞれが記事、Solr ドキュメント、および結果セット内の結果です。

これを rdbms の概念に関連付けたい場合は、各検索結果 (つまり、Solr ドキュメント) が sql-query の結果セットの行になる可能性があると言いたいです。その行は、単一のテーブルからの行、または結合されたテーブルからの行である可能性があります。

Solr Coreは、1 つの lucene インデックスのラッパーにすぎません。各 Solr Web アプリは、複数の Solr コアを操作できます。

理解を早める最善の方法は、Solr の概念を RDBMS に関連付けないようにすることです。

RDMBSが(効率的に)提供しない Solr の機能を調べる

ここにあなたを助けるかもしれない別のリンクがあります：Solr Terminology

あなたのユースケース

Solr/Lucene の優れている点は、柔軟なスキーマです。スキーマがないと言えます。各ドキュメントは、以前に索引付けされたドキュメントとはまったく異なるフィールドと属性を持つことができます。

それらが完全にスケーラブルである限り、同じ lucene インデックス (あなたの場合は Solr Core) に異なるタイプのドキュメント (車、人物など) を含めることはまったく問題ありません。

たとえば、5 億台の車のエントリと 30 億人のエントリがある場合、それらを別々にインデックス化することは理にかなっています。100 万人の人物と 50 万台の車がある場合、エンティティ タイプを含む識別子フィールドを使用して、それらすべてを同じインデックスに詰め込むことができます。

あなたの質問は非常に主観的です。私が言ったことに誰もが同意するわけではありません。1 つのコアまたは複数のコアのどちらを選択するかは、さらに多くの要因に依存します。

例えば、

  1. 製品の機能をサポートするために、これら 2 つのエンティティ (人と車) は互いに補完し合い、論理的な塊として機能しますか?
  2. クエリに対して両方のタイプの結果を取得する必要がある状況はありますか?
  3. 各タイプのエンティティを更新する頻度。(Solr には更新オプションはありません。削除して再追加するだけです。)
  4. それらは異なる製品機能に属していますか?
  5. それらは異なるチームによって所有されていますか？
于 2013-10-19T23:26:21.590 に答える