Hi -
My team has used Solr in it's single-node configuration (without SolrCloud)
for a few years now. In our current product we are now looking at
transitioning to SolrCloud, but before we made that leap I wanted to also
take a good look at whether ElasticSearch would be a better fit for our
needs. Although ES has some nice advantages (such as automatic shard
rebalancing) I'm trying to figure out how to live in a world without shard
splitting. In brief, our situation is as follows:
- We use one index ("collection" in Solr) per customer.
- The indexes are going to vary quite a bit in size, following something
like a power-law distribution with many small indexes (let's guess < 250k
documents), some medium sized indexes (up to a few million documents) and a
few large indexes (hundreds of millions of documents).
- So the number of shards required per index will vary greatly, and will
be hard to predict accurately at creation time.
How do people generally approach this kind of problem? Do you just make a
best guess at the appropriate number of shards for each new index and then
do a full re-index (with more shards) if the number of documents grows
bigger than expected?
Thanks!
- Ian
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/ded96e32-e1f1-4d09-8356-7367c86b1166%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
