Elasticsearch shard 生命周期

January 6, 2017
作者:星爷
出处:http://lxWei.github.io/posts/Elasticsearch-Shard-%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F.html
声明:转载请注明作者及出处。

Elasticsearch 说自己是一个准实时的搜索引擎,为什么能做到准实时呢?

往索引里写了一条数据,为什么有时需要等一段时间才能搜到?

往索引里写了一条数据,搜不出来,进行一下refresh或者flush操作就能搜出来了,是为什么呢,flushrefresh有什么区别?

Elasticsearch 是如何保证索引持久化且不丢数据的?

这篇文章将解释这些问题。

动态索引

众所周知,搜索引擎的基础是倒排索引,一般情况下,索引中的数据都是实时变化的,那么,索引系统如何实时反映这种变化呢?在搜索引擎中,普遍采用动态索引来做,如下图所示。

老系统架构

在这个动态索引中,有三个关键的索引结构:倒排列表、临时索引、已删除列表。倒排索引是已经建好的索引结果,倒排列表存在磁盘文件中,单词词典在内存中。临时索引是在内存中实时建立的倒排索引,结果与倒排列表一样,只是存在于内存中,当有新文档时,实时解析文档并加到这个临时索引中。已删除列表存储已被删除的文档的文档ID。另外,当一个文档被更改,搜索引擎中一个普遍的做法是删除旧文档,然后新建一个新文档,间接实现更新操作,这么做的原因主要是索引文件存储在磁盘文件,写磁盘不方便。

当用户搜索时,搜索引擎同时到倒排列表和临时索引进行查询,找到包含用户查询的文档集合,并对结果进行合并,之后利用删除文档进行过滤,形成最终结果,返回给用户。这样就实现了动态环境下的准实时搜索功能。

Elasticsearch 实现

上面简单介绍了搜索引擎实现准实时搜的原理和普遍做法,下面看看Elasticsearch的具体实现。

Elasticsearch 动态更新

Elasticsearch 基于Lucene开发,Lucene 提供了 segment 的概念,segment 代表 Lucene 的一个完成的索引段,通常一个索引包含多个 segment,每个segment 包含一个 commit point,这些segment对外提供搜索服务。

当往索引里新写数据时,新文档先写到内存中的一个buffer中,当buffer被commited时,就写到磁盘中,生成一个新的segment,并对外提供服务,同时,buffer被清空。

每个 commit point 维护了一个.del文件,存储已被删除的文档,即上一节介绍的已删除文档列表。

Elasticsearch 准实时搜索

要把数据写到磁盘,需要调用 fsync,但是fsync十分耗资源,无法频繁的调用,在这种情况下,Elasticsearch 利用了filesystem cache,新文档先写到in-memory buffer,然后写入到 filesystem cache,过一段时间后,再将segment写到磁盘。在这个过程中,只要文档写到filesystem cache,就可以被搜索到了。

Elasticsearch 持久化

必须调用fsync将segment刷到磁盘上,才能保证数据不丢失。

同时,Elasticsearch 使用translog 来记录Elasticsearch中的操作。

translog持久化存储了所有没有flush到磁盘的操作。当启动Elasticsearch时,Elasticsearch 首先根据最后的commit point 从磁盘恢复已知的segment,然后重放translog恢复没有commit的文档。这样,既实现了持久化,也能保证不丢数据。

refresh VS flush

在Elasticsearch中,refresh是轻量级的写和打开一个新segment的操作,默认情况下,每个分片每秒refresh一次,这就是我们说Elasticsearch是一个准实时搜索引擎的原因,因为每个文档的修改,最多经过一秒钟就可以知道了。虽然refresh是一个轻量级的操作,但是,还是会带来一定的消耗,所以,还是要注意不要太频繁的操作,而且,我们很多应用并不需要这么实时,比如在ELK中,我们可以将这个时间设置到30s甚至更大。

在Elasticsearch中,执行commit操作并删除translog的操作叫flush,每个shard每30分钟或translog太大时自动flush一次,使用者很少需要手动进行flush操作。

段合并

如果不停的产生新的segment,Elasticsearch中很快就会段爆炸,每个段都要消耗文件描述符、内存、CPU 周期,且每个search请求都需要遍历所有的segment,会造成搜索操作很慢。

所以,Elasticsearch会在后台对segment进行合并,在段合并的过程中,被删除的文档被丢弃。

Elasticsearch 提供了 optimize 接口,可以看做是一个强制进行段合并的API,使shard进行段合并到指定段数目,从而可以提高查询性能。

需要注意的是,merge操作会消耗大量的CPU和I/O,默认情况下,Elasticsearch 会控制merge操作的资源使用,从而不至于影响正常的search操作。但是,如果是手动进行optimize操作,这时,Elasticsearch 不会对merge使用的资源进行控制,从而消耗大量I/O,影响正常的搜索和集群的稳定。

总结

本文首先介绍搜索引擎中普遍的做法,然后,介绍了Elasticsearch的具体做法,一是明白了Elasticsearch的原理和中这几个操作的不同,同时,也可以看出,具体形式多变,仍然摆脱不了发明多年的搜索引擎的基础。

参考

  1. Elasticsearch: The definitive guide
  2. 这就是搜索引擎
  3. 信息检索