什么是ElasticSearch搜索引擎

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。于是,探寻出一条满足人类认知规律、以极少的假定推演出其它局部的途径,就成了要诀所在。

【本文关键词】:ElasticSearch