索引、路由、分片

索引

索引由多个分片组成。一个 索引 类似于传统关系数据库中的一个 数据库 ，是一个存储关系型文档的地方。索引仅仅是逻辑上的命名空间， 这个命名空间由一个或者多个分片组合在一起。

分片

每个分片是一个Lucene 索引（倒排索引），当索引一个文档的时候，文档会被存储到一个主分片中。

每个分片是有代价的：

• 一个分片的底层即为一个 Lucene 索引，会消耗一定文件句柄、内存、以及 CPU 运转。
• 每一个搜索请求都需要命中索引中的每一个分片，如果每一个分片都处于不同的节点还好， 但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。

路由

决定每个文档存储在哪个分片中，routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

路由公式：shard = hash(routing) % number_of_primary_shards

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

多索引好还是多分片好？

搜索 1 个有着 50 个分片的索引与搜索 50 个每个都有 1 个分片的索引完全等价：搜索请求均命中 50 个分片。(30-50G)

定义好，单个分片最优容量：

1. 基于你准备用于生产环境的硬件创建一个拥有单个节点的集群。
2. 创建一个和你准备用于生产环境相同配置和分析器的索引，但让它只有一个主分片无副本分片。
3. 索引实际的文档（或者尽可能接近实际）。
4. 运行实际的查询和聚合（或者尽可能接近实际）。

基本来说，你需要复制真实环境的使用方式并将它们全部压缩到单个分片上直到它“挂掉。” 实际上 挂掉 的定义也取决于你：一些用户需要所有响应在 50 毫秒内返回；另一些则乐于等上 5 秒钟。

一旦你定义好了单个分片的容量，很容易就可以推算出整个索引的分片数。 用你需要索引的数据总数加上一部分预期的增长，除以单个分片的容量，结果就是你需要的主分片个数。

建议：在最佳的分片容量下，减少分片命中数（拆索引、走路由）,拆索引可以快速的删除旧数据，直接删除整个索引。