2

別の製品 (「prod2」と呼びましょう) と「統合」したい製品 (「prod1」と呼びましょう) があります。「統合」とは、prod1 + prod2 が「prod3」になることを意味します。また、prod3 にさらに「製品」を追加する計画もいくつかあります。

ここまでは順調ですね。

Solr を使用して両方の製品でユーザーの検索を提供していますが、どちらのインデックスも非常に大きく、1 秒あたりの呼び出し数が多い可能性があります。すべてを 1 つのサーバーに任せると、スループットは最悪になります。

そこで、シャーディングの使用について考えています (これが正しい用語だと思います。間違っていたらすみません) が、それについていくつか質問があります。

  1. 「マシンごとに1つの製品インデックス」などでインデックスを分割することは可能ですか? はいの場合、どのようにすればよいですか？

  2. (question 1 == true) の場合、prod1 インデックスが machine1 で、prod2 インデックスが machine2 であると仮定します。machine1 と 2 の両方で検索を実行して、結果をスコア、オフセットなどと "簡単" に "マージ" できますか?そして正しい方法は？

  3. 複製因子について読んだことがありますが、正しく理解していないと思います。その目的は一体何なのでしょうか？

  4. ここで正しい用語を使用しているかどうかわからないので、誰かがコア、シャードなどとは何かを明確にすることができるかもしれません。このタイプの「単純な」疑いは、私のチームで多くの誤解を引き起こしています。

ここまでで、質問です。後で編集して追加するかもしれません。

前もって感謝します。

4

1 に答える 1

9

質問に順番に答えるには:

  1. ドキュメントの配布方法を定義するのは、ユーザー次第です。ドキュメントのインデックスを作成するサーバーを選択します。1 つの製品インデックス pr に対してそれを行うことにした場合は、. サーバー、それはあなたの決定です (ドキュメントの元の製品に基づいて、インデックス作成に使用するサーバーを選択してください)。

  2. はい。Solr に送信されるクエリ文字列の shards=- パラメータは、検索して 1 つの応答にマージする必要があるサーバーを示します。可能性のある問題としてオフセットが高くなることを見ない限り、これは問題になりません (高いオフセットの問題は、Solr が各サーバーから最大 (オフセット) のドキュメントを取得する必要があることです。すべてのシャードでスコアリングを行うため)。

    シャード=server1:8080/solr/コア名、server2:8080/solr/コア名

  3. レプリケーション係数は SolrCloud に関連しており、手動でシャーディングを行う際の複雑さの一部を隠します (ただし、一部は導入されます)。SolrCloud を使用すると、Solr はストレージに使用するノードを独自に決定し、レプリケーション ファクターによって、ドキュメントを保存するサーバーの数が Solr に通知されます。レプリケーション ファクターが 3 の場合、少なくとも 3 台のサーバーに障害が発生すると、ドキュメントに到達できなくなります。手動でシャーディングを行っている場合は、自分でレプリケーションをセットアップし、通常の Solr セットアップで行うように、どのサーバーがバックアップ サーバーであるかを把握する必要があります。

  4. シャード = インデックス内のすべてのドキュメントのサブセットのみを保持するサーバー、コア = 1 つのサーバー上の 1 つのインデックス - サーバーには複数のコアが含まれる場合があり、各コアは構成とスキーマの個別のセットです (以前は 1 つのコアしか持てませんでした)。各 Solr インスタンスで - Solr には 1 つのインデックスしかありませんでした)。SolrCloud は、Solr 4.0 で初めてリリースされ、勢いを増し始めています。

Solr Wikiは、これらの概念に関する詳細情報を探し始めるのに適した場所です。

于 2012-11-29T22:12:57.400 に答える