ElasticSearch内部工作原理及生命周期

在讨论ElasticSearch内部工作原理之前，我们先抛出几个问题：
1.新增加文档是否需要重建整个索引？
2.为什么ES的搜索是近实时的（1秒后被搜到）？
3.ES如何保证断电时，不丢失数据？
4.为什么删除了文档，不会立刻释放空间？

下面进入正题，我们先理解以下一些概念

一.倒排索引不可变性

倒排索引采用Immutable Design，一旦生成不可更改。不可变性带来以下好处：
1.无需考虑并发写文件问题，避免了锁机制带来的性能问题。
2.一旦读入内核的文件系统缓存，便可以留在那里。只要有足够空间，大部分请求直接在内存中处理，不必访问硬盘。
3.缓存容易生成和维护，数据可以压缩。

但是不可变性带来了一个巨大的挑战：如果新增一个文档，要让它能被搜索，需要重建整个索引。这肯定是不可接受的，如何才能避免呢？后面分析。

二.Lucene Index

ES是基于Lucene实现的。ES数据是分片存储的，一个分片就是一个运行的Lucene实例。在Lucene中，单个倒排索引文件被称为Segment。Segment是自包含的，不可变更的。多个Segment汇总到一起，组成Lucene的index，对应es的shard。当新文档写入时，生成新的Segment，查询时会同时查所有的Segments，并且对结果进行汇总。Lucene中有一个文件，用来记录所有Segments信息，叫做Commit Point。删除文档，并不会立刻物理删除，删除的文档信息保存在.del文件中。

三.Refresh

1.Refresh是将Index buffer写入Segment的过程。Refresh不执行fsync操作。
2.Refresh频率默认是1秒，可通过index.refresh_interval设置。Refresh后，数据就可以被搜索了。
3.如果系统有大量的数据写入，那就会产生很多的Segment
4.Index buffer被占满时，会触发Refresh，默认值是JVM的10%
5.Refresh时，Index buffer被清空

四.Transaction Log

1.Segment写入磁盘的过程比较耗时，借助文件系统缓存，Refresh时，先将Segment写入缓存以开放查询
2.为了保证数据不丢失，所以在Index文档时，同时写Transaction Log到磁盘，每个分片有一个Transaction Log
3.Refresh时，Index buffer被清空，但Transaction Log不会清

五.Flush

ES Flush就是Lucene Commit，执行以下动作
1.调用Refresh，清空Index buffer
2.调用fsync，将缓存中的Segments写入磁盘
3.清空Transaction Log

可见Flush是比较重的，默认30分钟调用一次，另外Transaction Log写满时也会触发，默认512MB

六.Merge

Segment会越来越多，需要定期合并。Merge会自动进行Merge操作，将多个Segments合并成一个，以减少Segment数量。同时还会真实删除.del文件中标记为删除的文档，以释放空间。也可通过 POST index_name/_forcemerge 人工触发。

最后回答以下开始提出的问题

1.新增加文档是否需要重建整个索引？

不需要，倒排索引的不变性是指Segment一旦生成就不变。当新文档写入时，会生成新的Segment，查询时会同时查所有的Segments，并且对结果进行汇总。

2.为什么ES的搜索是近实时的（1秒后被搜到）？

Refresh操作将Index buffer写入Segment，写入Segment后，即使没有写入磁盘，即可进行搜索，Refresh频率默认是1秒。

3.ES如何保证断电时，不丢失数据？

Index文档时，写入Index buffer同时写Transaction Log到磁盘，Refresh时，Index buffer被清空，但Transaction Log不会清。由于Transaction Log保存在磁盘，断电后仍然可以通过Transaction Log找回数据。

4.为什么删除了文档，不会立刻释放空间？

删除文档只是逻辑删除，删除的文档信息保存在.del文件中。ES进行merge操作时，才会真实删除.del文件中标记为删除的文档。