高峰只对攀登它而不是仰望它的人来说才有真正意义。

ES 5.x Bulk update重复的文档id性能低下

Elasticsearch | 作者 kennywu76 | 发布于2017年09月13日 | | 阅读数:10077

【携程旅行网  吴晓刚】

更新 @2018/07/20: ES 6.3解决了这个问题,对应的pull request: #29264

本文是针对社区问题question#2352的分析和总结

现在很多公司(包括我们自己)将ES用作数据库数据的索引,将多个数据库的数据同步到ES是非常常见的应用场景。所以感觉这个问题可能会困扰不止一个用户,而官方的文档也没有对update的底层机制及局限做特别说明,特将该问题的讨论和结论整理成文,供社区用户参考。


问题描述

在ES5.x里通过bulk update将数据从数据库同步到ES,如果短时间更新的一批数据里存在相同的文档ID,例如一个bulk update里大量写入下面类型的数据:

 {id:1,name:aaa} 
 {id:1,name:bbb}
 {id:1,name:ccc}
 {id:2,name:aaa}
 {id:2,name:bbb}
 {id:2,name:ccc}
 .......

则更新的速度非常慢。  而在ES 1.x和2.x里同样的操作快得多


根源追溯

update操作是分为两个步骤进行,即先根据文档ID做一次GET,得到最新版本的文档,然后在内存里做好更新后,再写回去。问题就出在这个GET操作上面。

core/src/main/java/org/elasticsearch/index/engine/InternalEngine.java 这个类里面,get函数会根据一个realtime参数(默认是true),决定如何获取原始文档。 

public GetResult get(Get get, Function<String, Searcher> searcherFactory, LongConsumer onRefresh) throws EngineException {
        assert Objects.equals(get.uid().field(), uidField) : get.uid().field();
        try (ReleasableLock lock = readLock.acquire()) {
            ensureOpen();
            if (get.realtime()) {
                VersionValue versionValue = versionMap.getUnderLock(get.uid());
                if (versionValue != null) {
                    if (versionValue.isDelete()) {
                        return GetResult.NOT_EXISTS;
                    }
                    if (get.versionType().isVersionConflictForReads(versionValue.getVersion(), get.version())) {
                        throw new VersionConflictEngineException(shardId, get.type(), get.id(),
                            get.versionType().explainConflictForReads(versionValue.getVersion(), get.version()));
                    }
                    long time = System.nanoTime();
                    refresh("realtime_get");
                    onRefresh.accept(System.nanoTime() - time);
                }
            }

            // no version, get the version from the index, we know that we refresh on flush
            return getFromSearcher(get, searcherFactory);
        }

可以看到realtime参数决定了是否以实时的方式获取数据。 如果设置为false,意味着不关心实时性,此时直接从searcher对象里面拿数据。因为searcher只能访问refresh过的数据,那些刚写入到indexing writter buffer里,还未经历过refresh的数据不会被访问到,故而该读取方式是准实时(Near Real Time)。 而这个realtime参数默认设置是true,说明需要以实时的方式访问数据,也就是说writter buffer里未经refresh的数据也要能被检索到,如何保证这块数据也能被实时访问呢?

从代码里可以看到,其中存在一个refresh("realtime_get") 的函数调用。这个函数调用会检查,GET的doc id是否都是可以被搜索到。 如果已经写入了但无法搜索到,也就是刚刚写入到writter buffer里还未refresh这种情况,就会强制执行一次refresh操作,让数据对searcher可见,保证getFromSearcher调用拿的是完全实时的数据。

实际上测试下来,正是这样的结果: 在关闭索引的自动刷新的情况下(设置refresh_interval: -1,只写入一条文档,然后对该文档ID执行一个GET操作,就会看到有一个新的segment生成。 说明GET的过程触发了refresh。

查了下文档,如果仅仅是做GET API调用,这个实时性可以人为控制,只需要在url里带可选参数realtime=[true/|false]。 参考: reference/5.6/docs-get.html#realtime

然而,不幸的是,update API的文档和源码都没有提供一个禁用实时性的参数。 update对GET的调用,传入的realtime参数是在代码里写死为true的,意味着update的时候,必须强制执行一次realtime GET.

为什么是这样的代码逻辑,仔细想一下就也就了然了。因为update允许对文档做部分字段更新,如果有2个请求分别更新了同一个文档的不同字段, 可能先更新的数据还在writter buffer里,没来得及refresh,因而对searcher不可见。如果后续更新不做一次refresh,前面的更新可能就丢失了。 

另外一个问题,为啥5.x之前的版本没有这个性能问题?  看了下2.4的GET方法源码,其的确没有采用refresh的方式来保障数据的实时性,而是通过访问translog来达到同样的目的。官方在这个变更里pull#20102将机制从访问translog改为了refresh。理由是之前ES里有很多地方利用translog来维护数据的位置,使得很多操作变得很慢,去掉对translog的依赖可以全面提高性能。

很遗憾,这个更改对于短时间反复大量更新相同doc id的操作,会因为过于频繁的强制refresh,短时间生成很多小segment,继而不断触发segment合并,产生显著的性能损耗。 从上面链接里的讨论看,官方认为,在提升大多数应用场景性能的前提下,对于这种较少见的场景下的性能损失是值得付出的。所以,建议从应用层面去解决。

因此,如果实际应用场景里遇到类似的数据更新问题, 只能是优化应用数据架构,在应用层面合并相同doc id的数据更新后再写入ES,或者只能使用ES 2.x这样的老版本了。


[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/273


16 个评论

每次都受益匪浅
每次wood叔都是干货满满,给力!!!
官方文件有建議做 bulk insert 時,關閉 refresh_interval。
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html#bulk
PUT /twitter/_settings
{
"index" : {
"refresh_interval" : "-1"
}
}
文中提到的问题,就是关闭refresh_interval情况下,依然会不断产生新segment,也就是说realtime GET会忽略这个设置。
新的segment 可先不管他,等bulk insert結束後再refresh,它就會在做segment merge。
你还没有理解 segment ,refresh和merge之间的关系。

只有refresh或者flush调用才生成新的segment, 而segment到了一定数量就会自动触发merge。这里的问题在于,即使关闭了refresh,一个bulk request由于包含了很多重复doc Id,导致在bulk执行过程中,REALTIME GET反复调用refresh,不断生成新segment,然后不断触发sgement merge。
@kennywu76 感謝你的指教。
啊。我们2.x 很多索引是相同 id 更新的场景啊,准备升级到5肿么办,会具体慢多少?
如果对于相同的id更新频率不高就没问题,文中说的问题,是短期有大量对相同id的更新操作。
这个真的不好控制。。
为什么有重复doc Id就导致GET反复refresh呢,不重复的id应该也回去refresh啊?没理解..
因为只有GET的doc id存在于indexing buffer里的时候,才会触发refresh。 而一个bulk请求里有重复doc id就刚好满足了这种场景。 前面的doc id刚写入到indexing buffer,后面update同一个doc id的时候,发现其在indexing buffer里,无法通过searcher读取,所以触发一次refresh。
看来得多看一些源码才可以啊
https://github.com/elastic/elasticsearch/pull/29264
貌似已经解决了
的确在这个pull request里解决了,需要update到6.3以上的版本。
你好,我这边有bulk,update相同ID的场景,经常出现版本冲突的情况,请问有什么方式避免

要回复文章请先登录注册