1> You have to prototype, see: https://lucidworks.com/2012/07/23/sizing-hardware-in-the-abstract-why-we-dont-have-a-definitive-answer/
2> No. It could be done, but it'd take some very careful work. Basically you'd have to merge "adjacent" shards where "adjacent" is measured by the shard range of each replica, then fiddle with the state.json file and hope you get it all right. I'm not sure whether the new autoscaling stuff will handle this or not. 3> Yep. But why bother reducing the number of shards? Agreed, there's a little overhead in having more shards than you need, but you can host multiple replicas in the same JVM so as long as you get satisfactory performance, there's no particularly good reason to merge them that pops to mind. Best, Erick On Wed, May 2, 2018 at 6:22 AM, Greenhorn Techie <greenhorntec...@gmail.com> wrote: > Hi, > > I have few questions on sharding in a SolrCloud setup: > > 1. How to know the optimal number of shards required for a SolrCloud setup? > What are the factors to consider to decide on the value for *numShards* > parameter? > 2. In case if over sharding has been done i.e. if numShards has been set to > a very high value, is there a mechanism to merge multiple shards in a > SolrCloud setup? > 3. In case if no such merge mechanism is available, is reindexing the only > option to set numShards to a new lower value? > > Thnx.
