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_period
2index.translog.flush_threshold_size
3index.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运行周期，这样导致段越多搜索就越慢。

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

合并结束的时候，老的段将被删除，新的段将被打开用于搜索。合并大的段需要消耗大量的I/O和CPU资源，如果大的segment一直合并会影响搜索性能。默认对合并流程进行资源限制，optimize API大可看做是强制合并，会指定大小的段的数量，通过检索段的数据来提升搜素性能。

9存储文件类型和格式

9.1存储类型

默认文件系统的实现为fs,以下部分列出了支持的所有不同存储类型：

1）fs

将根据操作环境选择最佳实现，该操作环境目前mmapfs在所有受支持的系统上，但可能会发生变化。

2）simplefs

Simple FS类型是SimpleFsDirectory使用随机访问文件直接实现文件系统存储（映射到Lucene ）。此实现具有较差的并发性能（多线程将成为瓶颈）。niofs当你需要索引持久性时，通常最好使用它。

3）niofs

NIO FS类型使用NIO将分片索引存储在文件系统上（映射到Lucene NIOFSDirectory）。它允许多个线程同时从同一个文件中读取。由于SUN Java实现中存在错误，因此不建议在Windows上使用。

4）mmapfs

MMap FS类型MMapDirectory通过将文件映射到内存（mmap）来将分片索引存储在文件系统上（映射到Lucene ）。内存映射使用进程中虚拟内存地址空间的一部分，等于要映射的文件的大小。在使用此类之前，请确保您已经拥有足够的虚拟地址空间。

默认情况下，Elasticsearch完全依赖操作系统文件系统缓存来缓存I/O操作。可以设置index.store.preload 以便在打开时告诉操作系统将热索引文件的内容加载到存储器中。但需要注意，这可能会减慢索引的打开速度，因为它们只有在数据加载到物理内存后才可用。

9.2 文件格式

Lucene负责写和维护Lucene索引文件，而Elasticsearch在Lucene之上写与功能相关的元数据，例如字段映射，索引设置和其他集群元数据。找到Lucene索引文件之前，让我们了解下Elasticsearch编写的外部级别数据。

10启动Elatisearch时生成的文件

1）图中的路径/data1/es/data/nodes/0，这部分（/data1/es/data）在每个节点可以通过elasticsearch.yml配置path.data即可，可以多目录，不过多目录没有rebalance功能。nodes是恒定的文件夹名。

2）node.lock文件用于确保一次只能从一个数据目录读取或写入一个ES相关安装信息。

3）global-15.st文件。global-前缀表示这是一个全局状态文件，

4）而.st扩展名表示这是一个包含元数据的状态文件。

11Lucene中文件命名

/data1/es/data/nodes/0/indices目录的下一级目录是index的uuid，再下一级是分片id，如图下图所示的tree型图中，第一级就是uuid。

个段的所有文件具有相同的名称，有不同的扩展名。当使用复合索引文件的时候，这些文件将被压缩成单个.cfs文件。保存磁盘的时候，会创建一个从未使用过的文件名字。下表总结了Lucene中文件的名称和扩展名。

索涉及相关的文件格式的流程，在贝壳智搜发布的《搜索原理和lucene简介》中有详细的介绍，这儿就不过多阐述。

12内容总结

本文对提出的问题进行分析底层原理，以上内容原理属于ES核心基础的其中一部分，对实时查询大数据级的需求可以很好的支持，能了解存储和查询的的内部运行原理，对于理解内部原理有很好的帮助。如果对以上内容讲解不是很清楚，可以参考《ES官网》文档进行分析理解。

作者介绍：
喜羊羊（企业代号名），目前负责贝壳找房实时方向平台建设及大数据应用拓展。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/25BW6ll9m1KA7hhUUE2PLw

创作场景

ElasticSearch 存储原理解析（下）