PolarDB MySQL版重磅推出了弹性并行查询（ePQ）引擎，可以将分析型查询的计算任务分发到集群内的任意节点执行，提升集群资源的利用率，从而大幅提升数据库的整体查询性能。
简介
对于复杂分析型查询场景，PolarDB MySQL版已支持的单机并行（PQ）特性提供了对大查询进行并行加速的能力，但它仅能利用单机多核CPU进行并行加速。节点规格（CPU核数）将成为制约加速能力的瓶颈，而且集群内其它节点即便有空闲计算的资源，也没有被有效利用而造成了浪费。
PolarDB MySQL版重磅推出了弹性并行查询（ePQ）引擎，可以将分析型查询的计算任务分发到集群内的任意节点执行。一是能够突破单机并行加速的瓶颈；二是能够有效利用集群内的空闲计算资源，提升集群资源的利用率，从而大幅提升数据库的整体查询性能，更好的满足复杂分析型查询场景的低时延需求。如下图所示：
发布时间
2022年06月28日
版本要求
PolarDB集群版本需满足如下条件：
PolarDB集群版本需为PolarDB MySQL版8.0.2版本且修订版本需为8.0.2.2.3或以上。
数据库代理Proxy的版本需为2.7.5或以上。
如何查看集群版本，请参见查看版本信息。
技术原理
弹性并行查询（ePQ）的目标是打通节点间的计算资源，基本原理是将一个复杂查询任务拆分为多个子任务，子任务可以被派发到同集群内的任意节点来完成计算，从而有效利用集群内其它节点的空闲计算资源（CPU、内存等）来加速查询。基本原理如下图所示：
并行优化器：在串行计划的基础上提取信息，然后基于代价的枚举并拆分出最优的子计划切片（Plan Slices）。
全局资源视图：维护集群内所有节点的实时负载信息。
任务协调器：根据实时资源负载情况，调度执行任务队列。
ePQ执行器：负责将被调度的子计划切片（Plan Slices）生成对应的Physical Plan，然后交给Executor模块执行。如果是远程节点执行Physical Plan，还需要将Physical Plan序列化为二进制协议，通过内部网络通道传输到远程节点上执行。
PolarDB基于共享存储的ePQ架构，在跨节点一致性视图机制的保证下，子任务在任意节点执行都能读取到正确的数据。
核心优势
弹性并行查询（ePQ）能够有效利用集群内所有节点的计算资源进行并行加速。具体优势如下：
实时性分析，统一的底层存储，数据实时可见；
零附加成本和运维成本，随集群部署，开箱即用；
打通节点间的计算资源，突破单机硬件性能瓶颈，优异的性能表现；
空闲计算资源得到充分利用，提升集群整体资源利用率；
按需扩容，更灵活的弹性计算能力。
适用场景
所有适用于单机并行（PQ）的应用场景。详情请参见应用场景。
弹性并行查询（ePQ）是单机并行（PQ）的下一代演进版本。所以，所有单机并行（PQ）的适用场景，同样适用于弹性并行查询（ePQ）。
海量数据分析查询
当面对大查询或者复杂查询时，单节点并行加速由于资源受限可能无法满足数据实时延迟要求。此时，您可以选择开启弹性并行查询（ePQ），系统会根据查询代价自动选择多机并行，突破单节点CPU、内存的资源瓶颈，并借助多节点的IO吞吐能力进一步利用共享存储的高带宽，获得更好的执行效率。
弹性计算场景
弹性计算是PolarDB MySQL版的核心能力，自动扩容功能提供了对短查询业务类型非常友好的弹性能力，但并不适用于分析类长查询业务。因为对于分析类长查询业务场景，某一条查询只能运行在单个节点上，无过通过增加节点对其进行加速。开启弹性并行查询（ePQ）的集群，新增加的节点也会自动加入到ePQ集群分组中，正好弥补了PolarDB弹性能力的这一块短板。
集群内资源负载不均衡场景
集群内的多个只读节点，借助数据库代理的负载均衡能力可以使每个节点的QPS大致相同。但是，由于不同节点上的查询计算量是有差异的，不同节点间依然会出现负载不均衡的现象。此时，开启弹性并行查询（ePQ）后，当节点计算资源不足时，可以将查询的部分任务或者全部任务调度到有空闲计算资源的节点上执行。从而提升集群的整体资源利用率，也降低了查询的时延。
在离线业务混合场景
一般在线业务和离线业务会连接不同的只读集群地址，避免相互影响。开启弹性并行查询（ePQ）后，离线业务还可以有效利用在线业务低峰时段的空闲计算资源。
性能提升情况
相对于串行查询模式，开启单机并行（PQ）后，TPC-H的查询性能加速比已有约19倍，具体请参见性能指标。弹性并行查询（ePQ）在单机并行（PQ）性能提升的基础上，随着节点数的扩展查询性能得到进一步的线性提升。
测试方法：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条查询语句的性能对比情况。
