共计 2566 个字符，预计需要花费 7 分钟才能阅读完成。
更好的文章格局，可参考：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。于是，探寻出一条满足人类认知法则、以极少的假如推演出其它局部的门路，就成了要诀所在。