Hi Yan,

Thanks for the quick reply.

Thus, replication seems to be the preferable solution. QTime decreases
proportional to replications number or there are any other drawbacks?

Just to clarify, what amount of documents stands for "tons of documents" in
your opinion? :)


2013/5/7 Jan Høydahl <jan....@cominvent.com>

> Hi,
>
> It depends(TM) on what kind of search performance problems you are seeing.
> If you simply have so high query load that the server starts to kneal, it
> will
> definitely not help to shard, since ALL the shards will still be hit with
> ALL the queries, and you add some extra overhead with sharding as well.
>
> But if your QPS is moderate and you have tons of documents, you may gain
> better performance both for indexing latency and search latency by
> sharding.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 7. mai 2013 kl. 13:09 skrev Stanislav Sandalnikov <s.sandalni...@gmail.com
> >:
>
> > Hi,
> >
> > We are moving to SolrCloud architecture. And I have question about search
> > performance and its correlation with shards or replicas. What will be
> more
> > efficient: to split all index we have to several shards or create several
> > replications of index? Is parallel search works with both shards and
> > replicas?
> >
> > Please share your experience regarding this matter.
> >
> > Thanks in advance.
> >
> > Regards,
> > Stanislav
>
>

Reply via email to