Apache Ignite 查询优化器中的 UNION_MERGE 规则内存问题分析

在分布式数据库系统 Apache Ignite 的查询优化过程中，我们发现了一个值得深入探讨的性能问题。这个问题涉及到查询计划生成时的内存消耗激增现象，特别出现在包含大量 UNION ALL 操作和子查询的复杂 SQL 语句场景中。

问题背景

Ignite 的查询优化器基于 Apache Calcite 框架实现，采用基于成本的优化(CBO)策略。在优化阶段，系统会应用一系列规则来转换查询计划，其中包括 UNION_MERGE 规则。这条规则的设计初衷是将多个相邻的 UNION ALL 操作合并为一个，理论上可以减少查询执行时的中间结果处理开销。

然而，在实际应用中，当遇到包含大量 UNION ALL 和复杂子查询的 SQL 语句时，这条优化规则反而会导致严重的性能问题。具体表现为查询优化阶段的内存消耗呈指数级增长，最终可能引发 Java 垃圾收集器(GC)的频繁工作甚至系统卡顿。

问题机理分析

问题的核心在于查询计划空间的爆炸式增长。以一个实际案例为例，当 SQL 查询包含 9 个 UNION ALL 操作，且每个子查询有 7 种可能的执行计划时，理论上会产生 7^9 (约 4000 万)种可能的组合。这种组合爆炸现象直接导致了两个严重后果：

1. 内存消耗剧增：在 TraitUtils#fillRecursive 方法中，用于存储中间结果的 HashSet 会占用大量内存空间。每个可能的执行计划都需要被存储和评估，导致内存需求呈指数级增长。

2. 优化时间延长：查询优化器需要评估所有可能的执行计划组合，计算成本的时间复杂度也随之呈指数增长。

技术细节

在 Ignite 的实现中，UNION_MERGE 规则属于 CoreRules 的一部分，在 PlannerPhase#OPTIMIZATION 阶段被应用。该规则会将多个 IgniteUnionAll 操作符合并为一个具有多个子节点的操作符。虽然这种合并能够减少执行时的操作层级，但在复杂查询场景下，它带来的代价远大于收益。

类似的问题也存在于其他集合操作规则中，包括：

• MINUS_MERGE（差集合并规则）
• INTERSECT_MERGE（交集合并规则）

这些规则都面临着相同的组合爆炸风险，特别是在处理包含大量子查询的复杂语句时。

解决方案与建议

针对这一问题，我们建议采取以下措施：

1. 规则禁用：在查询优化阶段完全禁用 UNION_MERGE、MINUS_MERGE 和 INTERSECT_MERGE 规则，避免计划空间的爆炸式增长。

2. 启发式限制：如果必须保留这些优化规则，可以引入启发式限制条件，例如：

   • 当 UNION ALL 操作数量超过阈值时跳过合并
   • 当子查询复杂度超过特定指标时禁用规则
   • 基于统计信息预测计划空间大小，动态决定是否应用规则

3. 内存保护机制：在优化器实现中加入内存使用监控，当检测到内存消耗接近危险阈值时，自动回退到更保守的优化策略。

4. 替代优化策略：考虑实现基于规则的优化(RBO)与基于成本的优化(CBO)的混合策略，对已知会导致问题的查询模式采用更确定的优化路径。

系统设计思考

这一问题的出现引发了我们对分布式数据库查询优化器设计的深入思考：

1. 优化规则的适用性：并非所有优化规则在所有场景下都适用，需要根据查询特征动态调整优化策略。

2. 资源消耗与收益平衡：查询优化本身也是需要消耗资源的操作，需要在优化深度和执行效率之间找到平衡点。

3. 防御性编程：对于可能引发资源问题的操作，应该预先设置保护机制，防止单个查询耗尽系统资源。

4. 复杂度管理：在处理复杂查询时，可能需要采用分阶段优化策略，先进行粗粒度优化，再进行局部精细优化。

结论

Apache Ignite 查询优化器中的 UNION_MERGE 及相关规则在特定场景下会导致严重的性能问题。通过深入分析问题机理，我们认识到在分布式数据库系统的查询优化过程中，必须谨慎处理可能引发组合爆炸的优化规则。理想的解决方案应当结合规则禁用、启发式限制和资源保护机制，在保证查询性能的同时避免系统资源被过度消耗。这一案例也为分布式数据库查询优化器的设计提供了有价值的实践经验。