ElasticSearch分片原理与规划

1、分片内部原理

分片是ES中较难理解的一个概念，它的核心概念和流程如下：
一个ES索引中包含很多分片，一个分片是一个Lucene索引（完整搜索引擎），Lucene索引又由很多分段Segement组成，每个分段都是一个倒排索引。在Lucene中，同时还会维护一个文件commit point，用来记录当前所有可用的Segement，当我们在这个commit point上进行搜索时，就相当于在它下面的Segement中进行搜索，每个Segement返回自己的搜索结果，然后进行汇总返回给用户。

新增和更新越多，段数也越来越多，这些段会定期合并为更大的段。这一过程称为合并。由于所有段都是不可更改的，这意味着在索引期间所用磁盘空间通常会上下浮动，这是因为只有合并后的新段创建完毕之后，它们所替换的那些段才能删掉。合并是一项极其耗费资源的任务，尤其耗费磁盘 I/O。

官网给这个分片写了一个系列文章，也就是回答下面的这五个问题：

• 为什么搜索是近实时的？
• 为什么文档的 CRUD (创建-读取-更新-删除) 操作是实时的?
• Elasticsearch 是怎样保证更新被持久化在断电时也不丢失数据?
• 为什么删除文档不会立刻释放空间？
• refresh, flush, 和 optimize API 都做了什么, 你什么情况下应该使用他们？

source: 分片原理

这有一篇文章深入分片原理，已经把上述原理进行了很好的总结。

2、如何合理规划分片

因为ES是个分布式的搜索引擎, 所以索引通常都会分解成不同部分, 而这些分布在不同节点的数据就是分片. ES自动管理和组织分片, 并在必要的时候对分片数据进行再平衡分配, 所以用户基本上不用担心分片的处理细节，一个分片默认最大文档数量是20亿。

我们要熟知以下几点内容：
1.每分配一个分片，都会有额外的成本。
2.每个分片本质上就是一个Lucene索引，因此会消耗相应的文件句柄，内存和CPU资源。
3.每个搜索请求会调度到索引的每个分片中。如果分片分散在不同的节点倒是问题不太。但当分片开始竞争相同的硬件资源时，性能便会逐步下降。
4.ES使用词频统计来计算相关性。当然这些统计也会分配到各个分片上。如果在大量分片上只维护了很少的数据，则将导致最终的文档相关性较差。

不过, 你最好还是能描述出每个节点上只放一个索引分片的必要性. 在开始阶段, 一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片. 例如：如果你有3个节点, 则推荐你创建的分片数最多不超过9(3x3)个.

source : Elasticsearch究竟要设置多少分片数？