Apache
/
lucene
mirror of https://github.com/apache/lucene.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SOLR-11982: Ref Guide: remove deprecated content; break up long paragraphs

This commit is contained in:
Cassandra Targett 2018-06-08 15:16:16 -05:00
parent 4c7b7c0063
commit 4dacf90812
1 changed files with 22 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
solr/solr-ref-guide/src/distributed-requests.adoc
View File

@ -140,44 +140,50 @@ For example, a deadlock might occur in the case of two shards, each with just a
Deprecated, use `shards.preference=replica.location:local` instead (see below). Deprecated, use `shards.preference=replica.location:local` instead (see below).
Solr allows you to pass an optional boolean parameter named `preferLocalShards` to indicate that a distributed query should prefer local replicas of a shard when available. In other words, if a query includes `preferLocalShards=true`, then the query controller will look for local replicas to service the query instead of selecting replicas at random from across the cluster. This is useful when a query requests many fields or large fields to be returned per document because it avoids moving large amounts of data over the network when it is available locally. In addition, this feature can be useful for minimizing the impact of a problematic replica with degraded performance, as it reduces the likelihood that the degraded replica will be hit by other healthy replicas.
Lastly, it follows that the value of this feature diminishes as the number of shards in a collection increases because the query controller will have to direct the query to non-local replicas for most of the shards. In other words, this feature is mostly useful for optimizing queries directed towards collections with a small number of shards and many replicas. Also, this option should only be used if you are load balancing requests across all nodes that host replicas for the collection you are querying, as Solr's CloudSolrClient will do. If not load-balancing, this feature can introduce a hotspot in the cluster since queries won't be evenly distributed across the cluster.
== shards.preference Parameter == shards.preference Parameter
Solr allows you to pass an optional string parameter named `shards.preference` to indicate that a distributed query should sort the available replicas in the given order of precedence within each shard. The syntax is: `shards.preference=property:value`. The order of the properties and the values are significant meaning that the first one is the primary sort, second one is secondary etc. Solr allows you to pass an optional string parameter named `shards.preference` to indicate that a distributed query should sort the available replicas in the given order of precedence within each shard.
IMPORTANT: `shards.preference` only works for distributed queries, i.e., queries targeting multiple shards. Not implemented yet for single shard scenarios The syntax is: `shards.preference=_property_:__value__`. The order of the properties and the values are significant: the first one is the primary sort, the second is secondary, etc.
IMPORTANT: `shards.preference` only works for distributed queries, i.e., queries targeting multiple shards. Single shard scenarios are not supported.
The properties that can be specified are as follows: The properties that can be specified are as follows:
`replica.type`:: `replica.type`::
One or more replica types that are preferred. Any combination of PULL, TLOG and NRT is allowed. One or more replica types that are preferred. Any combination of `PULL`, `TLOG` and `NRT` is allowed.
`replica.location`:: `replica.location`::
One or more replica locations that are preferred. A location starts with `http://hostname:port`. Matching is done for the given string as a prefix, so it's possible to e.g., leave out the port. `local` may be used as special value to denote any local replica running on the same Solr instance as the one handling the query. This is useful when a query requests many fields or large fields to be returned per document because it avoids moving large amounts of data over the network when it is available locally. In addition, this feature can be useful for minimizing the impact of a problematic replica with degraded performance, as it reduces the likelihood that the degraded replica will be hit by other healthy replicas. One or more replica locations that are preferred.
+
The value of `replica.location:local` diminishes as the number of shards (that have no locally-available replicas) in a collection increases because the query controller will have to direct the query to non-local replicas for most of the shards. In other words, this feature is mostly useful for optimizing queries directed towards collections with a small number of shards and many replicas. Also, this option should only be used if you are load balancing requests across all nodes that host replicas for the collection you are querying, as Solr's CloudSolrClient will do. If not load-balancing, this feature can introduce a hotspot in the cluster since queries won't be evenly distributed across the cluster. A location starts with `http://hostname:port`. Matching is done for the given string as a prefix, so it's possible to e.g., leave out the port.
+
A special value `local` may be used to denote any local replica running on the same Solr instance as the one handling the query. This is useful when a query requests many fields or large fields to be returned per document because it avoids moving large amounts of data over the network when it is available locally. In addition, this feature can be useful for minimizing the impact of a problematic replica with degraded performance, as it reduces the likelihood that the degraded replica will be hit by other healthy replicas.
+
The value of `replica.location:local` diminishes as the number of shards (that have no locally-available replicas) in a collection increases because the query controller will have to direct the query to non-local replicas for most of the shards.
+
In other words, this feature is mostly useful for optimizing queries directed towards collections with a small number of shards and many replicas.
+
Also, this option should only be used if you are load balancing requests across all nodes that host replicas for the collection you are querying, as Solr's `CloudSolrClient` will do. If not load-balancing, this feature can introduce a hotspot in the cluster since queries won't be evenly distributed across the cluster.
Examples: Examples:
* Prefer PULL replicas: * Prefer PULL replicas:
`shards.preference=replica.type:PULL` `shards.preference=replica.type:PULL`
* Prefer PULL replicas, or TLOG replicas if PULL replicas not available: * Prefer PULL replicas, or TLOG replicas if PULL replicas not available:
`shards.preference=replica.type:PULL,replica.type:TLOG` `shards.preference=replica.type:PULL,replica.type:TLOG`
* Prefer any local replicas: * Prefer any local replicas:
`shards.preference=replica.location:local` `shards.preference=replica.location:local`
* Prefer any replicas on a host called "server1" with "server2" as the secondary option: * Prefer any replicas on a host called "server1" with "server2" as the secondary option:
`shards.preference=replica.location:http://server1,replica.location:http://server2` `shards.preference=replica.location:http://server1,replica.location:http://server2`
* Prefer PULL replicas if available, otherwise TLOG replicas, and local ones among those: * Prefer PULL replicas if available, otherwise TLOG replicas, and local ones among those:
`shards.preference=replica.type:PULL,replica.type:TLOG,replica.location:local` `shards.preference=replica.type:PULL,replica.type:TLOG,replica.location:local`
* Prefer local replicas, and among them PULL replicas when available TLOG otherwise: * Prefer local replicas, and among them PULL replicas when available TLOG otherwise:
`shards.preference=replica.location:local,replica.type:PULL,replica.type:TLOG` `shards.preference=replica.location:local,replica.type:PULL,replica.type:TLOG`
Note that if you provide the settings in a query string, they need to be properly URL-encoded. Note that if you provide the settings in a query string, they need to be properly URL-encoded.