首页
/ OpenSearch布尔查询性能回归分析与解决方案

OpenSearch布尔查询性能回归分析与解决方案

2025-05-22 05:38:35作者:姚月梅Lane

问题背景

在OpenSearch 3.0版本中,某些特定类型的布尔查询出现了明显的性能退化现象。具体表现为当查询包含布尔连接条件时,特别是当使用BitSetConjunctionDISI包装ImpactsDISI的情况下,查询执行时间显著增加。这种退化主要出现在以下场景中:

  1. 当主迭代器(匹配较少文档)是文本字段上的match查询时
  2. 当次迭代器(匹配较多文档)是数值范围查询产生的BitSetIterator时

性能对比数据

通过对http_logs数据集的两个典型查询进行测试,我们获得了以下性能对比数据:

查询1:文本匹配+时间范围过滤

"bool": {
  "must": {"match": {"request": "js"}},
  "filter": {
      "range": {
      "@timestamp": {
        "gte": "1998-06-10T00:00:00Z",
        "lt": "1998-06-13T00:00:00Z"
      }
    }
  }
}

性能对比(毫秒):

  • P25:从8.41增加到33.72(+301%)
  • P50:从11.83增加到39.15(+231%)
  • P75:从16.53增加到41.18(+149%)

查询2:多值匹配+时间范围过滤

"bool": {
    "must": {"terms": {
          "request.raw": [...]
        }},
    "filter": {
        "range": {
        "@timestamp": {
          "gte": "1998-06-10T00:00:00Z",
          "lt": "1998-06-13T00:00:00Z"
        }
      }
    }
  }
}

性能对比(毫秒):

  • P25:从21.51增加到32.64(+52%)
  • P50:从23.07增加到33.66(+48%)
  • P75:从23.98增加到34.35(+43%)

问题根源分析

通过火焰图分析和代码追踪,我们发现性能退化的根本原因在于Lucene 10.0中BooleanScorerSupplier.requiredBulkScorer()方法的leadCost计算逻辑发生了变化。

在Lucene 9.x版本中,leadCost取的是MUST和FILTER子句中所有ScorerSupplier cost的最小值。而在Lucene 10.0中,计算逻辑变为:

long leadCost = subs.get(Occur.MUST).stream().mapToLong(ScorerSupplier::cost).min().orElse(Long.MAX_VALUE);
leadCost = subs.get(Occur.FILTER).stream().mapToLong(ScorerSupplier::cost).min().orElse(leadCost);

这种计算方式会导致当FILTER子句的最小cost大于MUST子句的最小cost时,错误地使用FILTER子句的cost作为leadCost。这会导致系统选择性能较差的执行路径,特别是会触发PointRangeQuery的BKD树遍历操作,而不是使用更高效的DocValues路径。

解决方案

该问题已在Lucene 10.2版本中得到修复。修复后的版本恢复了正确的leadCost计算逻辑,确保总是使用MUST和FILTER子句中最小的cost值。测试表明,应用此修复后,OpenSearch 3.0的性能退化问题完全消失,查询性能恢复到与2.19版本相当的水平。

临时解决方案建议

对于无法立即升级到包含修复版本的用户,可以考虑以下临时解决方案:

  1. 将FILTER子句改写为MUST子句:在某些情况下,这种改写可以避免性能退化
  2. 确保查询设计使MUST子句的cost低于FILTER子句:这可以避免触发有问题的代码路径
  3. 监控特定查询模式的性能:特别关注包含文本匹配+范围过滤的组合查询

总结

OpenSearch 3.0中出现的布尔查询性能退化问题源于Lucene 10.0中leadCost计算逻辑的变化。该问题已在Lucene 10.2中得到修复,用户只需等待OpenSearch升级到包含此修复的Lucene版本即可解决性能问题。在此期间,通过查询重写可以部分缓解性能影响。

登录后查看全文
热门项目推荐

热门内容推荐

最新内容推荐

项目优选

收起
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
149
1.95 K
kernelkernel
deepin linux kernel
C
22
6
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
980
395
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
192
274
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
931
555
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
145
190
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
金融AI编程实战金融AI编程实战
为非计算机科班出身 (例如财经类高校金融学院) 同学量身定制,新手友好,让学生以亲身实践开源开发的方式,学会使用计算机自动化自己的科研/创新工作。案例以量化投资为主线,涉及 Bash、Python、SQL、BI、AI 等全技术栈,培养面向未来的数智化人才 (如数据工程师、数据分析师、数据科学家、数据决策者、量化投资人)。
Jupyter Notebook
75
66
openHiTLS-examplesopenHiTLS-examples
本仓将为广大高校开发者提供开源实践和创新开发平台,收集和展示openHiTLS示例代码及创新应用,欢迎大家投稿,让全世界看到您的精巧密码实现设计,也让更多人通过您的优秀成果,理解、喜爱上密码技术。
C
65
518
CangjieCommunityCangjieCommunity
为仓颉编程语言开发者打造活跃、开放、高质量的社区环境
Markdown
1.11 K
0