Elasticsearch 无法支持document partially update

众所周知,ES的 index_API 和 update_API, 去更新一个文档的某个属性的时候,其实都是需要把整个文档重新load回来,去替换某部分的字段,最终这个文档是需要重新建索引。这是和Lucene 索引文件的 append_only 特性有关。

这个特性其实是为了最大限度取得建索引的性能来决定的,但是在非常多的场景里,我们往往只是频繁的更新某个field,或者是大批量的去更新某个field,这个特性则必须把整个文档重新索引,反而又严重的影响了整体的索引性能。

本来也是心存疑虑,Lucene 索引文件只写不修改这个能理解,但是为什么不是每个 doc_value 之间相互隔离呢,Lucene 的index API 非得传入整个Document 呢?
翻查了许多的文档,其实从ES 1.x 开始则陆陆续续有人提问相关问题,这篇文章主要是把一些讨论收集起来,去思考一下为什么Lucene直到现在还没有提供基于单个 docvalue 的update 操作。


可能有人最先想到的是Solr,Solr所谓基于field的 update,但是也是有先决条件的,它要求每个field都需要设置 store 属性,那其实本质上来说,它还是把所有字段重新获取回来重新索引了,和Elasticsearch的机制没有本质区别,只不过ES 自己搞了一个 _source 字段来搞这事而已。


https://stackoverflow.com/questions/11791803/update-a-new-field-to-existing-document


先看看为什么Lucene 其实是不支持只update 一个字段?
首先在StackOverflow 上,有个人是非常精辟就回答了这个问题


https://stackoverflow.com/questions/12185406/why-lucene-doesnt-support-any-type-of-update-to-an-existing-document

这个说法是有点道理的,因为很多时候建索引是相对于整个文档而已,牵一发动全身,对于修改了文档的某个地方,其实为了避免出问题,最好的办法还是重新索引整个文档。

后来我又找到了一个人提了一个比较好的idea,他建议Lucene 去把所有的字段归纳成 hot-search-fieldscold-search-fields 然后可以自行根据策略去决定分别去update 这两部分的索引。
其实这应该就是一个这种的方案,不过就是该要做的工作,使用是要做,因为,如果这样实现的话,其实还是需要在Lucene 上引入向前segment 追加查询文档的能力(为什么Lucene需要这样做,我在下面会说明)

field family segment design : hot-search-field with more frequent segment merge. #31464

后来ES的作者也回答了这种设计本质来说Lucene 是不支持的。这篇issue上面同事也引了另外一个人的提问,同样提出这样的问题。这里就不再介绍。


接下来我想说的,上面的帖子最后被duplicate到一篇原始的需求,在这篇帖子里,ES的开发者们进行了详细的讨论(只可惜最后这是落下一些 open questions,仍然没有进去实施阶段)但是讨论还是很细致的,因此我打算逐个部分贴出来讨论一下。

Support in-place update for single-valued non-indexed non-stored numeric doc value based fields. #30433

这段话比最开始那段解释,更详细的解释了为什么ES并不支持单个field的更新,因为Lucene 的索引还是基于segment 文件来走,写好一个加载一个,而查询的命中是基于segment 的,那就意味着,如果一个文档的字段跟新被写进去了新的 segment 去了,要在新的segment 去过滤文档的属性,其他字段也必须存在,而内部segment则采用一个不断自增的 doc_id 去实现 append_only的逻辑。
想象一下,如果去掉了这个逻辑,那么就意味着,要查找一个文档,必须每个字段都记录它最后保存的segment,而segment中的倒排文档数据结构则是用posting-list,这个结果几乎无法快速拆解和搬迁,因此可以认为是不迁移的,最终这样搞的话则会对搜索的效率大打折扣了。

那知道为什么Lucene 不能做到的话,下面可以看看几种选择,还有利弊,ES作者是高度概括,大家可以看看

一种方式无非就是用多个type 和parent/child 做个正交分解,但是这样的查询效率并不高,而且在高版本其实会带来兼容问题,作者明确是不爽这个方式。
第二种方式就是要实现基于docvalue 更新,则需要重写整个segment的实现,看样子短时间Lucene 是不太愿意做。
最后就是要实现向前追踪了。

帖子后面还有一些讨论,大家有兴趣可以去看看,总结就是目前来看,方案还是有些利弊,至于Lucene 要向那个方向来实现,还是拭目以待吧(这个issue 仍然Open状态)!

推荐阅读更多精彩内容