ElasticSearch存储原理解析（下）-InfoQ



 写点什么

4.3 动态更新索引

为了保持不变性的前提下实现倒排索引的更新，通过增加新的补充索引来反映最近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到,从最早的开始,查询完后再对结果进行合并。

索引在 Lucene 中除表示所有段（segment）的集合外，还增加了提交点的概念，一个列出了所有已知段的文件，从上图中可以看出一个 Lucene 索引包含一个提交点和三个段。

新的文档会被收集到内存索引缓存（In-memory buffer）中。

5 近实时搜索

若涉及到磁盘，就有一个不可避免的影响效率问题，对于实时性要求比较高，如果没有这步处理方式，实时性是不够的，所以这步的操作还有个中间状态：

1）内存索引缓存生成一个新的 segment，先是刷到文件系统缓存中，Lucene 这个时候是可以检索这个新的 segment 的；

这一步刷到文件系统缓存的步骤，在 Elasticsearch 中，是默认设置为 1 秒间隔的，对于大多数应用来说，几乎就相当于是实时可搜索了。refresh 接口中，可以通过设置 refresh_interval，调整每个索引的刷新频率。

6Translog 提供的磁盘同步控制

保证这期间发生主机错误、硬件故障等异常情况，数据不会丢失。

Refresh 只是保证写到文件系统缓存，而写到磁盘这通过这步的操作来控制的。ES 把数据写到内存缓存的同时，其实还同时记录了一个 translog 的日志数据。refresh 发生的时候，translog 日志文件依然保持原样。

Refresh 完成后, 缓存被清空,但是事务日志不会。在这期间发生异常，ES 会从 commit 位置开始，恢复整个 translog 文件中的记录，保证数据一致性。Translog 文件要等到 segment 刷到磁盘，而且 commit 文件更新的时候，才能清空。

以上的进程会继续工作，更多的文档被添加到内存缓冲区和追加到事务日志，事务日志不断积累文档。

Translog 变得越来越大，索引被执行 flush；一个新的 translog 被创建，并且一个全量提交被执行。在 flush 之后，segment 被全量提交，并且事务日志被清空。执行一个提交并且截断 translog 的行为被称一次 flush,默认参数 30 分钟一次 flush,或者 translog 文件大小超过 500M 的时候，可以调整以下参数：

1index.translog.flush_threshold_period2index.translog.flush_threshold_size3index.translog.flush_threshold_ops

复制代码

7Translog 的安全性

文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘，或者在每次写请求完成之后执行。在 2.0 版本以后，为了保证不丢数据，每次 index、bulk、delete、update 完成的时候，一定触发刷新 translog 到磁盘上，才给请求返回 200。这个改变在提高数据安全性的同时当然也降低了一点性能。设置如下参数：

1"index.translog.durability": "async"2"index.translog.sync_interval": "5s"

复制代码

文件系统缓存被提交，新的段被追加到倒排索引序列后面，新的段被开启，而且可以被搜索，此时内存缓存被清空，等待接受的文档。

8 段合并（Segment merging）

自动刷新流程每秒会创建一个新的段，段的数据会暴增，段太多会消耗文件句柄、内存和 CPU 运行周期，这样导致段越多搜索就越慢。

为了解决这个问题，利用小的段合并到大的段，然后继续合并大的段，合并过程中会把已删除的文档从文件系统中清除，这个过程是自动运行的，开发人员无感知。图中可以看出来将两个提交了的段和一个未提交的段正则进行到一个更多的段中。这个阶段如果有索引，刷新操作会创建新的段并将段打开，并提供给搜索使用，在合并过程中不会中断索引。