直面两大挑战！OceanBase 4.0 凭多重技术，提升分布式执行引擎性能

对于不少与OceanBase 有合作的企业来说，OceanBase 3.x 已经足以满足现实需求了。但对于精益求精的OceanBase 来说，升级蜕变是无止境的。在整个 3.x 版本的大规模应用中，OceanBase 发现了部分业务场景中遭遇的性能问题。

比如在特定的分布式场景中生成了不优的执行计划、执行引擎对于不优的执行计划的容错能力、特定场景下没法充分利用所有的并行度来加快查询的执行等。为解决问题，OceanBase 找准切入点，从分布式查询优化和分布式执行引擎两个层面展开优化改进。

提升性能不容易，先要应对两大挑战

数据库查询性能的关键是查询优化，查询优化从根本上就决定了查询的性能。而OceanBase 是一个分布式关系数据库系统，意味着 OceanBase 天生就需要解决分布式查询优化的问题。这就要求 OceanBase 需要应对计划枚举空间、维护更多的物理属性的分布式查询优化和更加精准的分布式代价模型这两大挑战。

在单机的场景下，算子的实现方法只需要考虑单机的实现，但是在分布式的场景中，算子的实现方法除了要考虑单机实现之外，还需要考虑其分布式的实现。这些分布式的实现方法正交上单机的实现方法就会大大增加分布式查询优化的计划枚举空间，会让整个分布式查询优化变得更加有挑战。

在单机的查询优化中，算子序是一个非常重要的物理属性，本质上就是运行完这个算子之后，数据库中的元组是不是按照特定的序输出的。算子序跟特定的算子实现有关系，而且它可能会影响后续算子的代价，所以在每个算子执行之后，查询优化都会维护序这个物理属性，并且在做计划裁剪的时候会保留有用序的执行计划。再加上同样具有物理属性的分区信息，从根本上决定了一个算子的分布式算法的选择，增加了整个分布式查询优化的复杂性。

此外，在查询优化中，代价是衡量一个执行计划好坏的标准，通常代价代表了一个执行计划的执行时间或者对数据库系统资源的占用量，包括 CPU 资源、IO 资源、网络资源等。分布式的场景中，除了考虑 CPU 和 IO 的代价之外，还需要考虑网络传输代价、查询的并行度以及一些分布式特定优化场景的代价，这些因素从根本上提升了分布式代价模型设计和拟合的复杂性，也从一定程度上增加了整个分布式查询优化的复杂性。

提升性能有捷径，全力打造多重技术

OceanBase 4.0在提升分布式执行引擎性能的过程中，先针对“ OceanBase 执行引擎对优化器产生的不优的执行计划没有任何的容错能力”这一问题，朝着自适应的方向发展。在OceanBase 看来，一个执行引擎发展到一定阶段一定要通过自适应技术来尽量解决优化器产生的不优的执行计划的问题。

为此，OceanBase 4.0 先实现了自适应的 Group by/Distinct 并行下压技术，把 Group by 算子下压下去做部分的数据预聚合，通过预聚合的方式可以减少网络传输，从而达到提升性能的目的。为战胜“如何判断下压的算子是否具备足够好的预聚合能力”这一难点，OceanBase 采用了控制下压算子的 HASH 表在 L3 cache 之内(控制 Hash 表的性能)以及多轮采样的策略(确保数据连续非聚合性带来的误判)来判断下压算子是否具备足够好的预聚合能力。

除此之外，OceanBase 还关注到并行下压技术的重要性，但是并行下压技术一种包含 distinct 的聚合函数的分布式执行性能。OceanBase 采取的了三阶段并行下压的逻辑来应对这一挑战。即先从下压 distinct 逻辑去做数据部分去重，再按照去重列做一次数据重分区、做完全去重和部分预聚合计算，然后将第二阶段的结果做最终的聚合，最终彰显了OceanBase 4.0 分布式性能查询价值，展现了技术演进的亮点。

随着挑战得以战胜，目的得以达成，OceanBase 4.0 也有了对价值和技术的进一步思考。未来，OceanBase 4.0 将继续夯实数据库的本质是基础软件这一认知，站在软件「使用者」的角度来看，力求在4.x 版本中，通过分布式查询优化和执行引擎技术的创新能力，帮助用户带来更易用的使用体验和更快速的查询性能。