Am 14.05.2012 05:56, schrieb arjit:
Thanks Erick for the reply. I have 6 cores which doesn't contain duplicated data. every core has some unique data. What I thought was when I read it would read parallel 6 cores and join the result and return the query. And this would be efficient then reading one big core.
No, it's not. When you request 10 documents from Solr, it can't know in prior which shards contain how many of those documents. It could be that each shard only needs to fill one or two documents into the result, but it might be that only one shard conatins all ten docuemnts. Therefor, Solr needs to request 10 documents from each shard, then taking only the 10 top documents from those 60 ones and drop the rest. And it gets worse when you set an offset of, say, 100.
Sharding is (nearly) always slower than using one big index with sufficient hardware resources. Only use sharding when your index is too huge to fit into one single machine.
Greetings, Kuli
