372812da98
This change makes it possible for custom routing values to go to a subset of shards rather than just a single shard. This enables the ability to utilize the spatial locality that custom routing can provide while mitigating the likelihood of ending up with an imbalanced cluster or suffering from a hot shard. This is ideal for large multi-tenant indices with custom routing that suffer from one or both of the following: - The big tenants cannot fit into a single shard or there is so many of them that they will likely end up on the same shard - Tenants often have a surge in write traffic and a single shard cannot process it fast enough Beyond that, this should also be useful for use cases where most queries are done under the context of a specific field (e.g. a category) since it gives a hint at how the data can be stored to minimize the number of shards to check per query. While a similar solution can be achieved with multiple concrete indices or aliases per value today, those approaches breakdown for high cardinality fields. A partitioned index enforces that mappings have routing required, that the partition size does not change when shrinking an index (the partitions will shrink proportionally), and rejects mappings that have parent/child relationships. Closes #21585 |
||
|---|---|---|
| .. | ||
| all-field.asciidoc | ||
| field-names-field.asciidoc | ||
| id-field.asciidoc | ||
| index-field.asciidoc | ||
| meta-field.asciidoc | ||
| parent-field.asciidoc | ||
| routing-field.asciidoc | ||
| source-field.asciidoc | ||
| type-field.asciidoc | ||
| uid-field.asciidoc | ||