SolrCloud分散リクエスト

Solrノードは、リクエストを受信した時点でZooKeeperと通信できなくても、認識しているすべてのシャードの少なくとも1つのレプリカと通信できれば、検索リクエストの結果を返します。これは通常、フォールトトレランスの観点から好ましい動作ですが、ノードがZooKeeperから通知されていないコレクション構造の大きな変更（シャードの追加、削除、サブシャードへの分割など）があった場合、古い結果または不正確な結果になる可能性があります。

リクエストを処理したノードがリクエスト時点でZooKeeperに接続されていたかどうかを示すzkConnectedヘッダーが、すべての検索レスポンスに含まれています。

リクエストを処理するノードがZooKeeperと通信できない場合に古い結果や不正確な結果を防ぐには、shards.tolerantパラメータをrequireZkConnectedに設定します。これにより、zkConnectedヘッダーをfalseに設定するのではなく、リクエストが失敗します。

クエリされた1つ以上のシャードが利用できない場合、Solrのデフォルトの動作はリクエストを失敗させることです。ただし、部分的な結果が許容される多くのユースケースがあるため、Solrはブール値のshards.tolerantパラメータ（デフォルトはfalse）を提供します。trueとfalseに加えて、shards.tolerantはrequireZkConnectedにも設定できます。以下を参照してください。

shards.tolerant=trueの場合、部分的な結果が返される可能性があります。返されたレスポンスに適切なすべてのシャードからの結果が含まれていない場合、レスポンスヘッダーにはpartialResultsと呼ばれる特別なフラグが含まれます。

shards.tolerant=requireZkConnected であり、検索リクエストを処理しているノードがZooKeeperと通信できない場合、潜在的に古いまたは不正確な結果を返すよりも、リクエストは失敗します。これは、shards.tolerant=false の場合と同様に、1つ以上のクエリ対象シャードが完全に利用できない場合にも、リクエストの失敗を引き起こします。

クライアントは、より詳細な情報を取得するために、shards.tolerant パラメータと共にshards.info を指定できます。

partialResults フラグがtrueに設定された場合のレスポンス例

trueに設定すると、distrib.singlePass パラメータは分散検索アルゴリズムを変更し、最初のフェーズですべての要求された保存済みフィールドを各シャードからフェッチします。これにより、保存済みフィールドをフェッチするための2回目のリクエストを行う必要がなくなります。

これは、非常に少ない数の小さな値を含むフィールドを要求する場合に高速化できます。ただし、大きなフィールドを要求する場合や、多くのフィールドを要求する場合は、すべてのシャードからネットワーク経由でそれらをフェッチするオーバーヘッドにより、通常の分散検索パスと比較してリクエストが遅くなる可能性があります。

この最適化は、分散検索のみに適用されます。ファセットなどの特定の機能では、リファインメントなどに対して追加のネットワークリクエストが行われる場合があります。

SolrCloudを使用する利点の1つは、さまざまなシャードに分散された非常に大規模なコレクションをクエリできることです。ただし、場合によっては、特定のドキュメントルーティングを使用してSolrを構成している場合があります。データ全体またはその一部を検索するオプションがあります。

SolrCloudはクエリを自動的にロードバランスするため、コレクションのすべてのシャードにわたるクエリは、shardsパラメータを定義しないクエリにすぎません。

これは、クエリを分散するためにshardsパラメータが必要となる、ユーザー管理クラスタとは対照的です。

クエリを1つのシャードのみに制限するには、論理IDでシャードを指定するshardsパラメータを使用します（例：…）

複数のシャードを検索する場合は、1つのリクエストでコンマで区切って各シャードを指定できます。

上記の両方の例では、特定のシャードのみがクエリ対象となりますが、シャードの任意のレプリカがリクエストを受け取ります。

シャードIDの代わりに、使用するレプリカのリストをコンマで区切って指定することもできます。

または、パイプ記号（|）を使用して異なるレプリカIDを区切ることで、単一シャードのレプリカのリストを指定してロードバランシングを行うことができます。

最後に、コンマで区切られたシャードのリスト（それぞれパイプで区切られたレプリカのリストで定義）を指定できます。

次の例では、2つのシャードがクエリ対象となります。1つ目はshard1からのランダムなレプリカ、2つ目は明示的にパイプで区切られたリストからのレプリカです。

Solrでは、shards.preferenceというオプションの文字列パラメータを渡して、分散クエリで各シャード内の利用可能なレプリカを優先順位の順にソートすることを指定できます。

構文は次のとおりです。shards.preference=property:value。プロパティと値の順序は重要です。最初のものが主要なソート基準、2番目が2番目のソート基準などとなります。

指定できるプロパティは次のとおりです。

例:

これらのパラメータをクエリ文字列で指定する場合は、適切にURLエンコードする必要があります。

collectionパラメータを使用すると、クエリを実行するコレクションまたは複数のコレクションを指定できます。これにより、複数のコレクションを一度にクエリすることができ、分散方式で動作するSolrの機能はコレクション全体で動作します。

_route_パラメータを使用して、対応するシャードを特定するために使用されるルートキーを指定できます。たとえば、一意のキー「user1!123」を持つドキュメントがある場合、ルートキーを「route=user1!」 （末尾の「！」文字に注意）として指定すると、そのユーザーをホストするシャードにリクエストがルーティングされます。コンマで区切って複数のルートキーを指定できます。このパラメータは、ユーザーごとにシャードデータがある場合に利用できます。ドキュメントルーティングの詳細を参照してください。