Hi Kuli, In a client engagement, I did see this (N shards on 1 beefy box with lots of RAM and CPU cores) be faster than 1 big index.
Otis ---- Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm >________________________________ > From: Michael Kuhlmann <k...@solarier.de> >To: solr-user@lucene.apache.org >Sent: Monday, May 14, 2012 7:56 AM >Subject: Re: Solr Shards multi core slower then single big core > >Am 14.05.2012 13:22, schrieb Sami Siren: >>> 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. >> >> If you're not constrained by CPU or IO, in other words have plenty of >> CPU cores available together with for example separate hard discs for >> each shard splitting your index into smaller shards can in some cases >> make a huge difference in one box too. > >Do you have an example? > >This is hard to believe. If you've several shard on the same machine, you'll >need that much memory that each shard has enough for all its caches and duch. >With that lot of memory, a single Solr core should be really fast. > >If dividing the index is the reason, then a software RAID 0 (striping) should >be much better. > >The only point I see is the concurrent search for one request. Maybe, for >large requests, this might outweigh the sharding overhead, but only for >long-running requests without disk I/O. I only see the case when using very >complicated query functions. And, this only stays true as long as you don't >run multiple concurrent requests. > >Greetings, >Kuli > > >
