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

问题背景

在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版本即可解决性能问题。在此期间，通过查询重写可以部分缓解性能影响。