OpenSearch项目中Star-Tree索引对布尔查询聚合的支持方案

背景与现状

在OpenSearch的聚合查询优化中，Star-Tree索引作为一种预计算结构，能够显著提升特定查询模式的性能。当前版本中，Star-Tree已支持对term、terms和range查询的聚合加速，这些查询通过DimensionFilterMapper转换为底层过滤器，用于筛选Star-Tree文档进行预聚合计算。

然而，实际业务场景中经常需要更复杂的布尔逻辑组合查询（如AND/OR/NOT），现有实现尚未支持这类查询在Star-Tree上的优化执行。这导致包含布尔条件的聚合查询无法利用预计算索引的优势，存在明显的性能优化空间。

技术挑战分析

实现布尔查询支持需要解决三个核心问题：

1. 查询形状识别：并非所有布尔查询都适合Star-Tree优化。例如字段A同时等于1和2的冲突条件（A==1 && A==2）应当被识别为无效查询。

2. 子查询分解：需要将布尔查询递归拆解为已支持的原子查询（term/terms/range），并确保每个子查询都能转换为对应的Star-Tree过滤器。

3. 过滤器合并：设计合并算法将原子过滤器组合为复合过滤器，包括：

   • 范围查询与枚举条件的合并（Terms+Range）
   • 多枚举条件的合并（Terms+Terms）
   • 复杂逻辑的优先级处理（MUST/SHOULD等子句）

实现方案设计

阶段一：查询支持性验证

建立布尔查询的语法树分析机制，通过以下规则验证查询是否可优化：

• 检查所有叶子节点是否为支持的基础查询类型
• 排除同一字段存在逻辑冲突的条件组合
• 识别包含NOT子句的特殊处理场景
• 验证嵌套布尔查询的最大深度限制

阶段二：查询分解与转换

采用访问者模式遍历布尔查询树：

1. 对每个叶子节点生成对应的DimensionFilterMapper
2. 对每个中间节点记录其布尔逻辑类型（AND/OR/NOT）
3. 构建包含逻辑关系的过滤器表达式树

阶段三：过滤器合并优化

设计分层合并策略：

1. 同字段条件合并：
   • 范围查询与枚举值合并为值域集合
   • 多个枚举值集合求并集/交集
2. 跨字段条件处理：
   • AND条件转换为多维联合过滤
   • OR条件转换为多分支结果合并
3. 特殊子句处理：
   • MUST_NOT转换为排除过滤器
   • SHOULD条件需结合minimum_should_match参数

性能考量

实现时需注意以下性能关键点：

• 建立过滤器合并的成本评估机制，避免复杂合并操作抵消预计算收益
• 对高频查询模式建立合并结果缓存
• 支持查询重写优化，如将(A>1 OR A>3)简化为(A>1)
• 并行处理独立子查询的过滤器生成

未来扩展方向

当前设计为后续扩展预留了接口：

1. 支持更多基础查询类型（如prefix/wildcard）
2. 引入成本模型动态选择优化路径
3. 支持混合查询模式（部分条件走Star-Tree，部分走常规索引）

该方案实施后，OpenSearch的聚合查询能力将获得显著提升，特别是在需要复杂过滤条件的OLAP场景中，查询性能可提高数个数量级。这为实时分析、交互式仪表盘等应用场景提供了更强大的技术支持。