es分片内部原理

新增文档被索引

倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。 不变性有重要的价值：

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

这种不变性使得elasticsearch可以快速的查找到匹配的文档。但也给我们带来了限制：不能修改索引。下面看看es是怎么解决文档更新或删除的问题的？

答案是：通过增加新的补充索引来反应新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到--从最早的开始–查询完后再对结果进行合并。

lucene引入了按段搜索的概念，每一段本身都是一个倒排索引，但索引在lucene中除表示所有段的集合外，还增加了提交点的概念-一个列出了所有已知段的文件。具体过程如下：

1. 新文档被收集到内存索引缓存。

2. 不时地, 缓存被 提交 ：

   • 一个新的段--一个追加的倒排索引--被写入磁盘。
   • 一个新的包含新段名字的 提交点 被写入磁盘。
   • 磁盘进行 同步 — 所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们被写入物理文件。

    

3. 新的段被开启，让它包含的文档可见以被搜索。
4. 内存缓存被清空，等待接收新的文档。

当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以保证每个词和每个文档的关联都被准确计算。

删除和更新

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

近实时搜索

提交一个新的段到磁盘需要一个fsync来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是fsync操作代价很大，如果每次索引一个文档都去执行一次的话会造成很大的性能问题。为了避免这个问题，es采用了一种新的策略：新段首先会被写入到文件系统缓存，这一步代价会比较低，稍后在被刷新到磁盘–这一步代价比较高。不过只要文件已经在缓存中，就可以像其他文件一样被打开和读取了。

Lucene 允许新段被写入和打开--使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

refresh API：写入和打开一个新段的轻量的过程叫做refresh。默认情况下每个分片会没秒自动刷新一次。这就是为什么说es是近实时搜索的。

在不同的使用场景中，可以设置这个刷新的时间间隔，比如在日志索引的过程中，可以把这个时间设置为30s。可以通过以下api设置：

PUT /my_logs/_settings
{ "refresh_interval": "1s" }

持久化变更

如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。

Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。通过 translog ，整个流程看起来是下面这样：

1、一个文档被索引之后，就会被添加到内存缓冲区，并且 追加到了 translog；

2、刷新（refresh）使分片处于 “刷新（refresh）完成后, 缓存被清空但是事务日志不会” 的状态，分片每秒被刷新（refresh）一次：

• 这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
• 这个段被打开，使其可被搜索。
• 内存缓冲区被清空。

3、进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志。

4、每隔一段时间--例如translog变得越来越大–索引被刷新（flush）；一个新的translog被创建，并且一个全量提交被执行。

• 所有在内存缓冲区的文档都被写入一个新的段。
• 缓冲区被清空。
• 一个提交点被写入硬盘。
• 文件系统缓存通过 fsync 被刷新（flush）。
• 老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过ID查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

flush api

可以执行一个新的提交并且截断translog的行为被称作一次flush。分片每30分钟被自动刷新（flush），或者translog太大的时候也会刷新。

translog并不保证操作不会丢失。在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。

段合并

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档 从文件系统中清除。 被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

启动段合并不需要你做任何事。进行索引和搜索时会自动进行。

1、 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。

2、 合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。

3、合并完成

• 新的段被刷新（flush）到了磁盘。   ** 写入一个包含新段且排除旧的和较小的段的新提交点。
• 新的段被打开用来搜索。
• 老的段被删除。

合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行。

optimize api

optimize API大可看做是 强制合并 API 。它会将一个分片强制合并到 max_num_segments 参数指定大小的段数目。 这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。

请注意，使用 optimize API 触发段合并的操作一点也不会受到任何资源上的限制。这可能会消耗掉你节点上全部的I/O资源, 使其没有余裕来处理搜索请求，从而有可能使集群失去响应。 如果你想要对索引执行 `optimize`，你需要先使用分片分配（查看 迁移旧索引）把索引移到一个安全的节点，再执行。所以该API不应该 被用在一个动态索引————一个正在被活跃更新的索引。

在特定情况下，使用 optimize API 颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。 老的索引实质上是只读的；它们也并不太可能会发生变化。

在这种情况下，使用optimize优化老的索引，将每一个分片合并为一个单独的段就很有用了；这样既可以节省资源，也可以使搜索更加快速：