Shuffling shards to balance the load
DSE Search uses a shuffling technique to balance the load, and also attempts to minimize the number of shards that are queried as well as the amount of data that is transferred from non-local nodes.
To balance the load in a distributed environment, choose from several strategies for shuffling the shards.
The shard shuffling strategy specifies how one node is selected over others for reading the search data.
The value of the
shard.shuffling.strategy parameter must be one of the following values:
Possible values of
Shards are selected based on the host that received the query.
Shards are selected based on the query string.
Shards are selected by host x query.
Different random set of shards are selected with each request (default).
Selects the same shard from one query to another.
Methods for selecting shard shuffling strategy
shard.shuffling.strategy = strategyto the HTTP API query. For example:
Issuing this query determines the shard shuffling strategy for this query only.
dse-search.propertiesfile and POST it to Solr. For example:
dse-search.propertiesfile with the following contents:
Post the command to DSE Search. For example:
curl -v --data-binary @dse-search.properties http://localhost:8983/solr/resource/wiki.solr/dse-search.properties
Posting the command determines the shard shuffling strategy for all queries to the specified Solr core. The strategy is propagated to all nodes and saved in the search index metadata.
Set the following parameters to use the
shard.shuffling.strategy=SEEDas a request parameter.
Specify a request parameter, such as an IP address or any string, using the
shard.shuffling.seedparameter. When you reuse the same seed value between queries on a stable cluster, the same shard strategy is in effect.
Every time you pass the same string, the same list of shards is queried, regardless of the target node you actually query; if you change the string, a different list of shards are queried.
Verify that the strategy was maintained by passing the
shards.info=true requestparameter. For example:
Shuffling does not always result in the node selection you might expect. For example, using a replication factor of 3 with six nodes, the best and only solution is a two-shard solution where half of the data is read from the originator node and half from another node. A three-shard solution would be inefficient.