P.S. Sorry for misspelling your name, Jan
2013/5/7 Stanislav Sandalnikov <s.sandalni...@gmail.com> > 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 >> >> >
