强制清除Elasticsearch中已删除的文件

Elasticsearch是建立在Apache Lucene基础上的实时分布式搜索引擎,Lucene为了提高搜索的实时性,采用不可再修改(immutable)方式将文档存储在一个个segment中。

也就是说,一个segment在写入到存储系统之后,将不可以再修改。那么Lucene是如何从一个segment中删除一个被索引的文档呢?

简单的讲,当用户发出命令删除一个被索引的文档#ABC时,该文档并不会被马上从相应的存储它的segment中删除掉,而是通过一个特殊的文件来标记该文档已被删除。

当用户再次搜索到#ABC时,Elasticsearch在segment中仍能找到#ABC,但由于#ABC文档已经被标记为删除,所以Lucene会从发回给用户的搜索结果中剔除#ABC,所以给用户感觉的是#ABC已经被删除了。

Elasticseach会有后台线程根据Lucene的合并规则定期进行Segment Merging合并操作,一般不需要用户担心或者采取任何行动。

被删除的文档在segment合并时,才会被真正删除掉。在此之前,它仍然会占用着JVM heap和操作系统的文件cache等资源。在某些情况下,我们需要强制Elasticsearch进行segment merging,已释放其占用的大量系统资源。

 POST /{index}/_optimize?only_expunge_deletes=true&wait_for_completion=true

_optimize命令可强制进行segment合并,并删除所有标记为删除的文档。Segment merging要消耗CPU,以及大量的I/O资源,所以一定要在你的ElasticSearch集群处于维护窗口期间,并且有足够的I/O空间的(如:SSD)的条件下进行;否则很可能造成集群崩溃和数据丢失。

下图展示了我们在进行强制expunge时,所观察到的CPU和磁盘I/O的使用情况。该集群运行在微软的Azure云平台IaaS虚拟机上,所有的数据节点都采用 D13 虚拟机,数据存储在本地的SSD磁盘中。该集群是一个备份集群,为了保证合并顺利进行,在此期间暂停了所有对其进行的写操作,仅有少量的读操作。这里需要注意: expunge操作是一种不得已而为之的操作,即在Elasticsearch不能有效自动清除删除文件的情况下才执行该操作。同时建议在此操作期间,最好停止对集群的所有读/写操作,并暂停止shard的自动分配 ( cluster.routing.allocation.enable= none ),以防有节点被踢出后shard自动分配造成的数据丢失。
http://openskill.cn/uploads/article/20160604/c3abe3368f5ecb3b06dfa0a9ebe46d5f.png
http://openskill.cn/uploads/article/20160604/bd4e2f998921a7eabf8cc11c441eb447.png
下面两个设置可以用于控制清除时的处理速度,其中给出值是默认值,可以根据需求进行调整,具体请参见Merge

此外, 还可以临时将所有索引的replica设置为0,这样只用针对Primary进行expunge,以减小I/O压力。

PUT /{index}/_settings
{
    "settings": {
        "index.merge.policy.expunge_deletes_allowed": "10",
        "index.merge.policy.max_merge_at_once_explicit" : "30" 
    }
}

参考资料:Lucene‘s Handling of Deleted Documents
分享阅读:http://blog.csdn.net/quicknet/article/details/46421505

0 个评论

要回复文章请先登录注册