elasticsearch在执行完forcemerge 后查询性能可能更差了,为何?

发布时间:2023年12月17日

? 在此之前,我始终任务,forceMerge会带来更好的检索效果,能够大幅度提升检索的性能。因为forceMerge能够减少底层检索文件的个数。将M个小文件的IO,转变为一个文件的IO。

? 但是今天看到了这篇文章,让我有了新的理解和认识,并不是合并的越少越好。还要分情况讨论。还要考虑到缓存的影响。原文:forcemerge,类型选择和 oom | easyice

通常我们认为一个 LSM 架构的系统,其文件数量 merge 到更少总会带来查询性能的提升,但Elasticsearch 和 lucene 确实有他的复杂之处,最近遇到一个案例,当索引 forcemerge 为 1 之后其查询延迟和查询 QPS都降低了,主要原因是, forcemerge 之后,查询语句构建 query cache的代价更大。

这个特殊场景是查询语句的 lead 子查询只在少数段上有命中。 绝大多数段上无命中,因此 leadCost 为 0,可以跳过构建 query cache 的过程。而 merge 为 1 之后 lead 条件必然是有命中的,有更大的几率要去构建 query cache。

可以跳过构建 query cache 的依据是子查询的 cost 除以 250 大于 leadCost,当 leadCost为 0 自然就不再构建了。

题外话:在 query cache 的 skip 机制是个很好的策略,但250并不适用所有场景,目前 Elasticsearch 没有可以调节的接口

另一种极端情况是 merge 为 1 之后文件数少了,如果有很高的并发读取单一的段文件,niofs 由于各线程使用同一个 FileChannel读文件,其线程安全特性会导致很多线程在等锁,但这种情况比较少见。
要确定一个查询语句是否只在少数分段有命中比较困难,如果你想要 forcemerge 的话,在现有机制下可以考虑两种方式可以避免这个问题,一是 merge 的目标段数量不再倾向于 merge 为尽量少的段,例如目标段数量可以按照每个段 1GB 来计算,第二种是如果 cache 命中率不高,可以考虑降低 250 这个数字。https://www.easyice.cn/archives/386

文章来源:https://blog.csdn.net/star1210644725/article/details/135047791
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。