ElasticSearch 索引的存储机制推演

更好的文章格式，可参考： https://www.yuque.com/terencexie/geekartt/es-index-store

ElasticSearch 做为开源的搜索引擎，须要依赖的一个重要数据结构就是 inverted index（倒排索引）。inverted index 一般庞大、且创建过程至关耗时，因而，如何存储 inverted index 就变成了一件极为要紧的事情。

显然，inverted index 不能简单地被放在 memory 中，它还必须作对应的持久化，让这些已经创建的 inverted index 能够被复用。ElasticSearch 是基于 Lucene 来构建的，在 Lucene 的世界里，inverted index 就是存放于 disk 的一块 immutable 的 segment。

因而，关于 ElasticSearch inverted index 的存放问题，就转换为了「如何可以高效地存储 disk 文件 segment」。

既然是 disk file，那么最直观的优化方式即是使用 memory 来作批量堆积，经过累积 data batch 来节省 disk I/O overhead。因而，ElasticSearch 引入了 in-memory buffer 来暂存每一个 doc 对应的 inverted index。当这些 doc inverted index 累积到必定量后，就能够从 in-memory buffer 刷到 disk 了。

另外一方面，在 Lucene 的世界里，一切「搜索」行为，都依赖于 disk segment，没有 disk segment 就没有对应的「可搜索」。

如此，如上图所示，「索引的建立」和「索引的可搜索」之间出现了 time gap（这是 ElasticSearch 被称为 near realtime search engine 的缘由）。显然，咱们的下一个目标，就是要尽量地缩短这个 time gap。

一个马上能被联想到的工具是 OS（operating system）提供的 disk page cache。disk page cache 也是 OS 为了优化 disk I/O 所作出的努力，其指导思想同 ElasticSearch 引入 in-memory buffer 是同样的，都是但愿经过 data 的批量累积，来尽量地减小 disk I/O。

但 disk page cache 不一样与用户本身建立的 memory buffer 的地方是，一旦 data 被放入了 disk page cache，它对整个 OS 来说，从 “概念上” 就能够被当作是一个真正的 disk file 了（虽然它实际不是，还在 memory 中）。因而，放入 disk page cache 的 inverted index，天然就能够被当作是 disk segment，对于 ElasticSearch 来说，它就是「可搜索」的！

而且，因为 disk page cache 毕竟是在 memory 中，从 in-memory buffer 到 disk page cache 所须要的时间，将会远远少于从 in-memory buffer 到 disk segment 的时间。

因而，经过引入 disk page cache，咱们缩短了 ElasticSearch 从「建立索引」到「索引可搜索」的时间，也便是让它更接近于 realtime。引入了 disk page cache 以后的两段 data pipeline，分别对应了 ElasticSearch 的两个重要 API：

• 从 in-memory buffer 到 disk page cache 的过程，对应 ElasticSearch 的 refresh() API，默认 1s 触发一次；
• 从 disk page cache 到 disk 的过程，则对应 ElasticSearch 的 flush() API，默认 30min 触发一次。

在这样的结构下，咱们不由要问，若是 disk page cache 的内容还未被 flush 到 disk，而此时所在的 server 出现了 power off 等极端异常状况，那么这部分保存于 disk page cache 的 data 是否会丢失？！

固然是会的！

因而，ElasticSearch 又引入了 disk page cache 的一个临时 disk backup：translog，用于持久化当前 disk page cache 中的内容。

能够看到，虽然 translog 的本意是将 disk page cache 中的 inverted index 作持久化备份，但它本身做为 OS 的 file，一样须要经历 disk page cache（translog 的 disk page cache，而不是 inverted index 的 disk page cache）到 disk 的过程。默认 translog 本身从 disk page cache 到 disk 的持久化，是 5s 一次。

因为 translog 仅仅是 inverted index 在 disk page cache 的临时备份，当 ElasticSearch 触发了 flush() API 时，对应的 translog 就会被清空。由于它临时部分的 data 在此时已经被真正持久化到了 disk，因而就再也不须要这个临时的 disk backup 了。

如此，ElasticSearch 就将 data lost 减低到 translog 的 5s，即：最多可能会丢失 5s 的数据。

幸运的是，ElasticSearch 还有 replica node 这样的 data backup，即使是在某个 node 上丢失了 5s 的数据，还可以从其它的 replica node 上将数据取回来。因而这就进一步下降了 data lost 的几率（固然，理论上仍是存在 data lost 的可能性，但只要下降到工程上可接纳的几率之下就能够了。工程上永远没有百分之百的保障，只有可接受的精度范围）。

如此，咱们便将整个 ElasticSearch 的机制给传串起来了。整个机制围绕着如何高效地存储 disk segment 来展开：

• 为了下降 disk I/O 的 overhead，引入了 in-memory
• 为了下降「建立索引」和「索引可搜索」的 time gap，而引入了 disk page cache。
• 为了对 disk page cache 作临时备份，而引入了 translog

在技术的学习中，咱们每每会面临各类繁杂的「知识点」，它们既不容易记忆，也不利于咱们掌握其背后的宏观 intuition。因而，探寻出一条知足人类认知规律、以极少的假设推演出其它部分的路径，就成了要诀所在。