lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Sharding configuration
Date Thu, 30 Oct 2014 23:44:00 GMT
This is not too surprising. There are additional hops necessary for a
cloud setup. This is the sequence, let's say there are 4 shards and the
rows parameter on the query is 10 and you're sorting by score

node1 receives request.
node1 sends the request out to each shard
node1 receives the top 10 doc Ids back with the  score (note, not the
node1 sorts the 4 lists of 10 docs into the final top 10.
node1 then requests the actual docs from the nodes that they reside on
node1 then gets the results back and assembles them into a final list
node1 then returns the list to the client.

Contrast this with a single shard
node1 receives the request
node1 finds the top 10 docs locally
node1 return the docs to the client

You should only resort to sharding when you have too many docs
to fit in a single shard (and give you acceptable search times). If
all your docs fit comfortably on a single machine, you can _still_ use
SolrCloud, just with a single shard. This configuration deals with all
the replication, NRT processing, self-repair when nodes go up and
down and all that, but since there's no second trip to get the docs
from shards your query performance won't be affected.

And using SolrCloud with a single shard will essentially scale linearly
as you add nodes for queries.


On Thu, Oct 30, 2014 at 8:29 AM, Anca Kopetz <> wrote:
> Hi,
> You are right, it is a mistake in my phrase, for the tests with 4
> shards/ 4 instances,  the latency was worse (therefore *bigger*) than
> for the tests with one shard.
> In our case, the query rate is high.
> Thanks,
> Anca
> On 10/30/2014 03:48 PM, Shawn Heisey wrote:
>> On 10/30/2014 4:32 AM, Anca Kopetz wrote:
>>> We did some tests with 4 shards / 4 different tomcat instances on the
>>> same server and the average latency was smaller than the one when having
>>> only one shard.
>>> We tested also é shards on different servers and the performance results
>>> were also worse.
>>> It seems that the sharding does not make any difference for our index in
>>> terms of latency gains.
>> That statement is confusing, because if latency goes down, that's good,
>> not worse.
>> If you're going to put multiple shards on one server, it should be done
>> with one solr/tomcat instance, not multiple.  One instance is perfectly
>> capable of dealing with many shards, and has a lot less overhead.  The
>> SolrCloud collection create command would need the maxShardsPerNode
>> parameter.
>> In order to see a gain in performance from multiple shards per server,
>> the server must have a lot of CPUs and the query rate must be fairly
>> low.  If the query rate is high, then all the CPUs will be busy just
>> handling simultaneous queries, so putting multiple shards per server
>> will probably slow things down.  When query rate is low, multiple CPUs
>> can handle each shard query simultaneously, speeding up the overall query.
>> Thanks,
>> Shawn
> Kelkoo SAS
> Société par Actions Simplifiée
> Au capital de € 4.168.964,30
> Siège social : 8, rue du Sentier 75002 Paris
> 425 093 069 RCS Paris
> Ce message et les pièces jointes sont confidentiels et établis à l'attention
> exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
> message, merci de le détruire et d'en avertir l'expéditeur.

View raw message