As far as I know, a round robin is used to distribute searches between
replicas. So if a node is slower, queries hitting shards on that node
would normally be slower.
My understanding is that adding replicas help with concurrent queries.
If you run one query at a time, your searches should be just as fast.
Regarding the situation your trying to address, I think a solution
might be to divide your data into multiple indices - based on how
"hot" that data is. So I'd put data that is queried more frequently on
the faster nodes, using shard allocation filtering:
And you have to make sure that, within your application, you query
only the needed indices, not all of them.
http://sematext.com/ -- ElasticSearch -- Solr -- Lucene
On Tue, Oct 30, 2012 at 12:48 AM, T Vinod Gupta firstname.lastname@example.org wrote:
when a non-data node receives a search request, how does it go about
choosing the nodes that have replicas of a shard? e.g if number of replicas
is 1 and there are 2 data nodes then both nodes have complete index data and
shards. if there is a non-data node fronting these 2 nodes and it gets a
search request, how does it distribute the work? is there a setting to make
it fire parallel redundant requests to both nodes and return the results as
soon as they are ready (without waiting for both nodes to respond)?
i guess the situation im trying to address is a case where a slow node in a
cluster bottlenecks the cluster as a whole.