PolarDB MySQL版重磅推出了弹性多机并行(ePQ)引擎,可以将分析型查询的计算任务分发到集群内的任意节点执行,提升集群资源的利用率,从而大幅提升数据库的整体查询性能。
简介
对于复杂分析型查询场景,PolarDB MySQL版已支持的单机并行(PQ)特性提供了对大查询进行并行加速的能力,但它仅能利用单机多核CPU进行并行加速。节点规格(CPU核数)将成为制约加速能力的瓶颈,而且集群内其它节点即便有空闲计算的资源,也没有被有效利用而造成了浪费。

发布时间
2022年06月28日
版本要求
- PolarDB集群版本需为PolarDB MySQL版8.0.2版本且修订版本需为8.0.2.2.3或以上。
- 数据库代理Proxy的版本需为2.7.5或以上。
如何查看集群版本,请参见查看版本信息。
技术原理

- 并行优化器:在串行计划的基础上提取信息,然后基于代价的枚举并拆分出最优的子计划切片(Plan Slices)。
- 全局资源视图:维护集群内所有节点的实时负载信息。
- 任务协调器:根据实时资源负载情况,调度执行任务队列。
- ePQ执行器:负责将被调度的子计划切片(Plan Slices)生成对应的Physical Plan,然后交给Executor模块执行。如果是远程节点执行Physical Plan,还需要将Physical Plan序列化为二进制协议,通过内部网络通道传输到远程节点上执行。
- PolarDB基于共享存储的ePQ架构,在跨节点一致性视图机制的保证下,子任务在任意节点执行都能读取到正确的数据。
核心优势
- 实时性分析,统一的底层存储,数据实时可见;
- 零附加成本和运维成本,随集群部署,开箱即用;
- 打通节点间的计算资源,突破单机硬件性能瓶颈,优异的性能表现;
- 空闲计算资源得到充分利用,提升集群整体资源利用率;
- 按需扩容,更灵活的弹性计算能力。
适用场景
- 所有适用于单机并行(PQ)的应用场景。详情请参见应用场景。
弹性多机并行(ePQ)是单机并行(PQ)的下一代演进版本。所以,所有单机并行(PQ)的适用场景,同样适用于弹性多机并行(ePQ)。
- 海量数据分析查询
当面对大查询或者复杂查询时,单节点并行加速由于资源受限可能无法满足数据实时延迟要求。此时,您可以选择开启弹性多机并行(ePQ),系统会根据查询代价自动选择多机并行,突破单节点CPU、内存的资源瓶颈,并借助多节点的IO吞吐能力进一步利用共享存储的高带宽,获得更好的执行效率。
- 弹性计算场景
弹性计算是PolarDB MySQL版的核心能力,自动扩容功能提供了对短查询业务类型非常友好的弹性能力,但并不适用于分析类长查询业务。因为对于分析类长查询业务场景,某一条查询只能运行在单个节点上,无过通过增加节点对其进行加速。开启弹性多机并行(ePQ)的集群,新增加的节点也会自动加入到ePQ集群分组中,正好弥补了PolarDB弹性能力的这一块短板。
- 集群内资源负载不均衡场景
集群内的多个只读节点,借助数据库代理的负载均衡能力可以使每个节点的QPS大致相同。但是,由于不同节点上的查询计算量是有差异的,不同节点间依然会出现负载不均衡的现象。此时,开启弹性多机并行(ePQ)后,当节点计算资源不足时,可以将查询的部分任务或者全部任务调度到有空闲计算资源的节点上执行。从而提升集群的整体资源利用率,也降低了查询的时延。
- 在离线业务混合场景一般在线业务和离线业务会连接不同的只读集群地址,避免相互影响。开启弹性多机并行(ePQ)后,离线业务还可以有效利用在线业务低峰时段的空闲计算资源。
性能提升情况
- 测试方法:TPC-H是业界常用的一套基准,由TPC委员会制定发布,用于评测数据库的分析型查询能力。TPC-H查询包含8张数据表、22条复杂的SQL查询,大多数查询包含若干表Join、子查询和Group by聚合等。详细的测试流程请参见性能测试方法(OLAP)。说明 本文的TPC-H的实现基于TPC-H的基准测试,并不能与已发布的TPC-H基准测试结果相比较,本文中的测试并不符合TPC-H基准测试的所有要求。
- 测试数据量:1 TB
- 测试结果:下图展示了在32核256 GB独享规格的集群中,分别开启单机并行(PQ)、弹性多机并行(2节点)和弹性多机并行(4节点)后执行TPC-H的22条查询语句的性能对比情况。