Sharding always adds overhead, which balances against splitting the
work up amongst several machines.
Sharding works like this for queries:
1> node receives query
2> a sub-query is sent to one replica of each shard
3> each replica sends back its top N (rows parameter) with ID and sort data
4
Did the test while back . Revisiting this again. But in standalone solr we
have experienced the queries more time if the data exists in 2 shards .
That's the main reason this test was done. If anyone has experience want to
hear
On Tue, Jun 30, 2020 at 11:50 PM Jörn Franke wrote:
> How many docum
How many documents ?
The real difference was only a couple of ms?
> Am 01.07.2020 um 07:34 schrieb Raji N :
>
> Had 2 indexes in 2 separate shards in one collection and had exact same
> data published with composite router with a prefix. Disabled all caches.
> Issued the same query which is a
Had 2 indexes in 2 separate shards in one collection and had exact same
data published with composite router with a prefix. Disabled all caches.
Issued the same query which is a small query with q parameter and fq
parameter . Number of queries which got executed (with same threads and
run for same
What did you test? Which queries? What were the exact results in terms of time ?
> Am 30.06.2020 um 22:47 schrieb Raji N :
>
> Hi ,
>
>
> Trying to place multiple smaller indexes in one collection (as we read
> solrcloud performance degrades as number of collections increase). We are
> explori
Hi ,
Trying to place multiple smaller indexes in one collection (as we read
solrcloud performance degrades as number of collections increase). We are
exploring two ways
1) Placing each index on a single shard of a collection
In this case placing documents for a single index is manual and
au
