And further, adding these new sub-indexes which compromise one composite
index is just a way to hide the creation of shards.
This is just a lazy / poor man's shard splitting and is prone to problems.
Specifically, as your cluster grows you have to re-index all your data to
rebalance.
... so t
It should be easy to export all _source fields and reindex on client side.
Because the creation of new index with new shard count and data copy should
be an atomic operation, this is non-trivial on cluster side, and difficult
to manage (cluster may run out of resources).
Jörg
Am 05.12.2014 18:40 s
That works ok if you are inserting but updates and deletes become more
complex. Scoring can get a bit funky too because your shards don't have
roughly equal frequencies. All and I'll I'd argue the adding more indecies
behind and alias is only sometimes a solution to the problem.
Nik
On Fri, Dec
Because too few shards is not optimal and neither is too many.
The zen is the right number of shards per node which is why shard splitting
is important.
You want the index to fit the hardware / cluster properly.
On Thursday, December 4, 2014 10:08:53 PM UTC-8, David Pilato wrote:
>
> Why not
Let say you start with a 3 nodes cluster with one index A1, 3 shards, 1 replica.
Then you feel like 3 shards is not enough. You want to add 2 new nodes and have
5 shards for your data.
Create an index A2 with 2 shards and 1 replica.
Use an alias A on top of A1, A2. You will then search into 5 sha
I've never found myself wanting shard splitting. I always have an analysis
update I want to apply when I want to reshard data anyway so I just scan
from one index into one with new settings.
I do find the the FAQ a bit odd though. Elasticsearch allows you to do lots
of inefficient things and that
Why not using aliases and add more index/shards when you need to?
What is wrong with this design?
David
> Le 5 déc. 2014 à 01:56, Kevin Burton a écrit :
>
> I just assumed that ES was planning on building in shard splitting at some
> point since it's a glaringly obvious addition to the feature
I just assumed that ES was planning on building in shard splitting at some
point since it's a glaringly obvious addition to the feature set.
Then I saw this:
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/overallocation.html
> Users often ask why Elasticsearch doesn’t support