ユーザー管理による分散検索

従来のインデックスシャードを使用する場合は、ドキュメントのクエリ方法を検討する必要があります。

スケールアップまたはスケールアウトが必要な場合は、SolrCloud の使用を強くお勧めします。以下に説明する設定はレガシーであり、SolrCloudが登場する前に使用されていました。SolrCloudは、自動ルーティング、リーダー選出、楽観的同時実行制御、その他の分散システムで期待される整合性チェックなど、真に分散された機能セットを提供します。

このページのすべての内容は、分散検索のレガシー設定に固有のものです。SolrCloudを試用しているユーザーは、以下の手順や情報は実行しないでください。

更新は順序が変更される可能性があります（つまり、レプリカAは更新Xを次にYと見ることがあり、レプリカBは更新Yを次にXと見ることがあります）。deleteByQueryも同様に順序変更を処理して、レプリカの整合性を確保します。異なるレプリカに更新が異なる順序で到着した場合でも、シャードのすべてのレプリカは整合性が保たれます。

シャード間でのドキュメントの分散

SolrCloudを使用しない場合、サーバーファームの各シャードにすべてのドキュメントがインデックスされるようにする必要があります。Solrは、真の意味での分散インデックス作成（ルーティング）をSolrCloudモードでのみサポートしています。

レガシー分散モードでは、Solrはグローバルな用語/ドキュメント頻度を計算しません。ほとんどの大規模実装では、SolrがシャードレベルでTF/IDFを計算することが問題になることはありません。ただし、コレクションがサーバー間で大きく偏って分散されている場合、検索結果の関連性に誤解を招く可能性があります。一般的に、ドキュメントをシャードにランダムに分散するのが最適です。

shardsパラメータを使用した分散検索の実行

クエリリクエストにshardsパラメータが含まれている場合、Solrサーバーは、パラメータの引数としてリストされているすべてのシャードにリクエストを分散します。shardsパラメータは次の構文を使用します。

host:port/base_url,host:port/base_url*

例えば、下記のshardsパラメータは、検索を2台のSolrサーバー（solr1とsolr2）に分散します。両サーバーともポート8983で稼働しています。

https://127.0.0.1:8983/solr/core1/select?shards=solr1:8983/solr/core1,solr2:8983/solr/core1&indent=true&q=ipod+solr

ユーザーにshardsパラメータを明示的に含めることを要求するのではなく、通常はsolrconfig.xmlのRequestHandlerセクションでこのパラメータをデフォルトとして設定することをお勧めします。

標準のリクエストハンドラーにshardsパラメータを追加しないでください。そうすると、検索クエリが無限ループに陥る可能性があります。代わりに、shardsパラメータを使用する新しいリクエストハンドラーを定義し、分散検索リクエストをそのハンドラーに渡してください。

レガシーモードでは、クエリリクエストのみが分散されます。これには、分散検索をサポートする標準コンポーネントを使用するSearchHandler（またはorg.apache.solr.handler.component.SearchHandlerから拡張されたハンドラー）へのリクエストが含まれます。

SolrCloudモードと同様に、shards.info=trueの場合、分散応答にはシャードに関する情報が含まれます（各シャードは論理的に異なるインデックスまたは物理的な場所を表します）。

以下のコンポーネントは分散検索をサポートしています。

クエリに一致するドキュメントを返すクエリコンポーネント。
ファセットがカウントでソートされている場合（デフォルト）のfacet.queryおよびfacet.fieldリクエストを処理するファセットコンポーネント。
Solrがフィールド値に「強調表示された」一致を含めることを可能にするハイライトコンポーネント。
DocSet内の数値フィールドの簡単な統計を返す統計コンポーネント。
デバッグに役立つデバッグコンポーネント。

allowUrlsパラメータ

shardsパラメータで許可されるノードは、solr.xmlのallowUrlsプロパティで設定できます。この許可リストはSolrCloudでは自動的に設定されますが、ユーザー管理クラスタでは明示的な設定が必要です。詳細は、ShardHandlerFactoryの設定セクションを参照してください。

ユーザー管理分散検索の制限事項

Solrの分散検索には、以下の制限事項があります。

インデックスされる各ドキュメントには、一意のキーが必要です。
Solrが重複するドキュメントIDを検出した場合、Solrは最初のドキュメントを選択し、後続のドキュメントを破棄します。
分散検索の第1段階と第2段階の間にコミットが発生すると、分散検索のインデックスが一時的に同期しなくなる可能性があります。これにより、一度クエリに一致したドキュメントがその後変更され、クエリに一致しなくなった場合でも、そのドキュメントが依然として取得される可能性があります。ただし、この状況は非常にまれであり、単一のクエリリクエストでのみ発生する可能性があります。
シャードの数は、GETメソッドのURIで許可される文字数によって制限されます。ほとんどのWebサーバーは少なくとも4000文字をサポートしていますが、多くのサーバーはDoS（サービス拒否）攻撃に対する脆弱性を軽減するためにURIの長さを制限しています。
検索リクエストにfl=id, [shard]を含めることで、分散検索の各ドキュメントにシャード情報を返すことができます。これにより、シャードのURLが返されます。
分散検索では、コア記述子のデータディレクトリがsolrconfig.xmlのデータディレクトリをオーバーライドします。
更新コマンドは、分散インデックスが正しく設定されている任意のサーバーに送信できます。ドキュメントの追加と削除は、一意のドキュメントIDのハッシュに基づいて、適切なサーバー/シャードに転送されます。commitコマンドとdeleteByQueryコマンドは、shardsにリストされているすべてのサーバーに送信されます。

以前は、TF/IDF関連性の計算がシャードローカルの統計のみを使用するという制限がありました。これはデフォルトで依然として当てはまります。データがランダムに分散されていない場合、またはより正確な統計が必要な場合は、ExactStatsCache を設定できます。

分散デッドロックの回避

SolrCloudモードと同様に、シャード間のリクエストは分散デッドロックにつながる可能性があります。SolrCloud分散リクエストセクションの手順に従うことで回避できます。

リクエストのロードバランシング

ユーザー管理のSolrクラスタを管理する場合は、各シャードフォロワーにわたってクエリリクエストをロードバランシングする必要があります。これにより、クエリ処理能力の向上と、サーバーがダウンした場合のフェイルオーバーの両方が実現します。

このシナリオでは中央集権的なクラスタ管理がないため、この構成内のリーダーシャードは互いを認識しません。ドキュメントは各リーダーにインデックスされ、インデックスは各フォロワーにレプリケートされ、その後、検索は各シャードから1つのフォロワーを使用してフォロワーに分散されます。

高可用性のために、各シャードのフォロワーセットに対してロードバランサーを使用して仮想IPを設定する必要があります。ロードバランシングが初めての場合は、HAProxy（http://haproxy.1wt.eu/）は優れたオープンソースのソフトウェアロードバランサーです。フォロワーサーバーがダウンした場合、優れたロードバランサーは（一般的にはハートビートシステムを使用して）障害を検出し、障害が発生したフォロワーで提供された残りのライブフォロワーにすべてのリクエストを転送します。次に、単一の仮想IPを設定して、リクエストが単一のIPにヒットし、検索フォロワーの各仮想IPにロードバランシングされるようにする必要があります。

この構成により、完全にロードバランスされ、検索側のフォールトトレラントなシステムが実現します。受信した検索は機能しているフォロワーの1つに渡され、フォロワーは構成内の各シャードのフォロワーに検索リクエストを分散します。フォロワーは各シャードの各仮想IPにリクエストを発行し、ロードバランサーは利用可能なフォロワーの1つを選択します。最後に、結果は単一の結果セットにまとめられて返されます。フォロワーのいずれかがダウンした場合、ローテーションから外され、残りのフォロワーが使用されます。シャードリーダーがダウンした場合、問題を修正してリーダーを運用に戻すまで、フォロワーから検索を提供できます。