共计 11470 个字符，预计需要花费 29 分钟才能阅读完成。
简介：对于并行查问的性能、个性、技术原理等，” 并行查问的前世今生 ” 这篇已做过具体的解读，明天这篇文章则次要聚焦于并行查问全新公布的下一代状态：弹性多机并行（Elastic Parallel Query）。
作者 | 梁辰 (遥凌) 起源 | 阿里开发者公众号背景并行查问（Parallel Query）是自 PolarDB MySQL 诞生伊始就致力于研发的企业级查问减速性能，这与 PolarDB 的产品定位密切相关，基于云原生的计算存储拆散使底层数据量远冲破单机容量的限度，而针对更海量数据的简单剖析、报表类业务也成为用户自然而然的需要，同时因为 PolarDB 是服务于在线业务（OLTP）的关系数据库系统，用户会心愿剖析业务能具备 ” 在线 ” 的能力，即针对最陈腐的数据进行实时甚至交互的查问，这也是当初概念上很炽热的 HTAP 数据库的次要能力。对线上海量实例的日常监控和运维中，咱们发现云上计算资源的利用率广泛是偏低的（e.g CPU…），而利用闲置的 CPU 资源来做计算减速就是并行查问实现的事件，通过更充沛的资源利用升高查问响应工夫、晋升用户体验的同时也晋升了性价比。对于并行查问的性能、个性、技术原理等，” 并行查问的前世今生 ” 这篇已做过具体的解读，明天这篇文章则次要聚焦于并行查问全新公布的下一代状态：弹性多机并行（Elastic Parallel Query）。概念顾名思义，多机并行意味着利用更多计算节点的资源实现查问，PolarDB 的计算层是一写多读的部署形式，已有的并行查问是指在单个 RW/RO 节点内的多线程并行，这对于较小的数据量（几百 GB）是比拟 ok 的，但很多用户随着本身业务倒退，数据开始达到了 TB 级别，有的甚至单表就有 20~30TB，这曾经超过了单个节点的解决能力，而多机并行正是为了应答这种场景，通过冲破单机的 CPU/IO 瓶颈将整个计算层的资源买通，实现资源的全局平衡与全局利用。
看起来这和传统的 MPP 架构有些类似，通过将查问的子工作散发到多个节点来以高并发实现计算。但两者有着实质的不同：传统的 MPP 架构是计算与存储耦合的，查问的子工作要下发到数据所在的节点实现本地化计算，再通过后续散发，到下层节点中实现聚合计算 PolarDB 基于云上基础设施实现了计存拆散，任何节点都能够看到全量数据，这使极致的弹性和灵便的调度成为可能，例如实例的规格能够依据负载的需要即时或定时升 / 降，而无需做任何数据迁徙，同时无状态的计算工作实践上能够散发到任意节点执行弹性多机并行除了具备前者利用多节点并行的减速能力外，更重要的是，它会实时监控集群内的拓扑变动和资源应用，从而实现随计算资源的变动动静适配并行策略，无论是单个节点的规格晋升（scale up）、或是引入了新的 RO 节点（scale out），都能够自适应的做并行度调整和子工作散发，在防止单节点计算热点的同时、尽可能保障依照用户指定的并行度实现查问，从而达到更高的资源利用率。劣势连续了并行查问的个性，弹性并行查问具备如下的一些劣势：100% 兼容性并行查问基于 MySQL 开发，具备 100% 的 MySQL 兼容性，包含语法、类型、行为的全方位兼容，除了查问工夫更短外，用户是感觉不到查问是否开启了并行的。极致性价比性价比来源于四个方面：数据：复用了底层同一套业务数据做 in-place 剖析减速，而无需独自保护一套额定正本，没有附加的存储成本计算：基于原生的执行引擎实现，购买实例后默认的读写集群即可开启多机并行性能，除非须要退出更多节点实现计算，否则并无额定计算成本。调度：通过自适应调度来进步资源利用率，举个简略的例子：一个查问在单节点并行时须要 4 个线程实现，但以后节点只剩 3 个线程资源，而其余节点仍有闲暇，则能够通过跨机调度散发一个计算工作，利用闲置资源保障减速成果。弹性：随实例规格的弹性变动实时调整并行策略，在 ” 降本 ” 的同时依然保障 ” 增效 ” 能力极低运维老本用户在现有或新建集群中，只需勾选是否开启跨机并行、并设置单节点并行度即可，放弃了极简配置、开箱即用的状态，无需业务侧批改任何代码，升高应用和保护复杂度。实时在线剖析绝对于 RDS 传统的主从 binlog 同步，PolarDB 基于 innodb 的物理复制实现，节点间同步提早在 ms 级或更低，这样即便查问下发到 RO 节点，也可失去 100% 新鲜度的实时数据，同时联合更高并行度的计算在更短时间内失去查问后果，能够让业务在第一工夫获取到 insight，满足企业疾速倒退中随时可能变动的业务需要。灵便的利用模式很多企业用户有在一套数据上进行多品种剖析的需要，不同品种可能来源于不同业务部门，查问的个性也各不相同，例如针对大量数据的批量报表、针对局部数据的实时交互等。PolarDB 一写多读的架构自身就很适宜这样的多样化场景，不同业务能够通过应用不同节点形成的子集群实现物理隔离，而不同子集群能够通过设置不同的并行策略来应答相应的剖析场景。实用场景弹性并行查问（ePQ）是并行查问（PQ）的下一代演进，同时也放弃了对 PQ 的齐全兼容，因而并行查问自身实用的场景[1]，弹性并行依然实用。除此之外，ePQ 能应答的场景更加灵便而宽泛：- 海量数据分析场景后面曾经提到，在更大数据量的状况下，单机的 CPU/Memory/IO 都可能遇到瓶颈，如果突破这个瓶颈，查问响应工夫就能够持续线性晋升。这里可能有同学会问，能不能通过降级单个节点的规格（最高 88core）来实现对更大数据量的解决？跨机肯定是必须的吗？答案是必定的，起因在两方面：即便是最大 88 核的规格，解决能力仍是有下限的，而且如果数据量达到 TB 级别，这个规格应答剖析查问仍是不够的，只有扩大进来能力利用更大的总体资源即便单机资源没有遇到瓶颈（多核大内存），在数据库内核中会存在很多共享资源（page hash/readview/pages…），查问中的 worker 线程会并发拜访这些资源，导致并发管制带来的耗费，查问性能无奈很好的线性扩大。但如果 worker 线程散布到多个节点中，争抢会升高很多，依然能够保障良好的减速比资源负载不平衡场景集群内的多个只读节点，借助数据库代理的负载平衡能力能够使每个节点的并发连接数大致相同。但因为不同查问的计算复杂度、资源应用形式各有差别，基于连接数的 load balance 无奈完全避免节点间负载不平衡的问题。同所有分布式数据库一样，热点节点也会对 PolarDB 造成肯定的负面影响：如果 RO 节点过热使得查问执行过慢，可能造成主节点无奈 purge undo log 导致磁盘空间收缩。如果 RO 节点过热导致 redo apply 过慢，会导致 rw 节点无奈刷脏升高主节点的写吞吐性能。为此咱们更须要在内核中建设更为全面的负载平衡能力，弹性多机并行引入了全局资源视图机制，并基于该视图做自适应调度，根据各节点的资源利用率和数据亲和性反馈，将查问的局部甚至全副子任务调度到有闲暇资源的节点上，在保障指标并行度的根底上平衡集群资源应用。
弹性计算场景如前所述，弹性是作为云原生数据库的 PolarDB 的外围能力之一，主动扩 / 缩容性能提供了对短查问类业务十分敌对的弹性能力，但之前并不适用于简单剖析类业务，因为对于大查问场景，单条查问仍无奈通过减少节点实现提速。而当初开启弹性多机并行（ePQ）的集群，新扩大的节点会主动退出到集群分组中共享计算资源，补救了之前弹性能力上的这一短板。
在离线业务混合场景后面提到了多个子集群的物理资源隔离能力，最彻底的隔离形式是将在线交易业务和离线剖析业务划定为不同节点汇合，但如果用户在意老本，这种模式会显得有些节约，因为很多状况下，在、离线业务会有不同的高、低峰个性，更经济的形式是通过错峰应用，让不同业务共享局部集群资源，但应用不同的集群地址承接业务。通过开启弹性并行，让离线业务重叠应用在线业务低峰期的闲暇资源，进一步降本增效。
技术实现对于并行查问的技术细节，在之前的 ”PolarDB 并行查问的前世今生 ” 中已有具体阐明。本文将次要介绍为实现弹性的多机并行，咱们额定做了哪些工作，如果大家感兴趣，能够连同前一篇一起对照看下，会有个更整体的概念。内核架构
和之前相比，弹性跨机并行在优化器 / 执行器 / 调度 / 一致性等方面都做了进一步优化或分布式革新，逐个介绍如下分布式优化器多阶段的分布式优化器曾经实现了对各种状态并行打算的穷尽式枚举，因而后续的革新次要集中在依据全局资源视图以及调度策略，抉择适合的全局并行度，例如：如果全局资源均不短缺，禁止应用并行如果查问代价或表扫描行数超过阈值，等比例扩大单机并行度到多机，更充分利用多核资源减速计算否则放弃现有并行度不变，并在枚举打算空间中，思考跨节点的数据散发代价此外，因为实现了更多的并行执行策略，在优化器层面也要反对更简单打算状态的枚举，详见下节。并行执行策略在单节点 PQ2.0 中，曾经实现了全算子的并行执行反对，但大量算子仍不够欠缺，例如对于 Semijoin Materialize 这种执行形式，原有的并行策略是全量下推到 worker 中，这意味着每个 worker 都须要执行全副的 semijoin 物化操作，这显著不是最高效的。新的并行执行策略包含：semijoin-materialization 并行物化 sjm 是 MySQL 对 semijoin 的一种物理执行算法，通过将子查问的 join 后果物化为长期表，参加到外层表的 join 中，并行查问中对其原有的反对如下：
能够看到，每个 worker 都实现了 it1 和 it2 表的全量 join 和物化操作，这个反复的动作有可能代价很大，且没有必要，更无效的办法可能是这样：
这样的打算状态，能够使每个 worker 都实现更小的计算量，当然这只是一个极简例子，理论状况可能简单的多。当然如果物化自身波及的计算量曾经很小，打算状态 1 兴许更优，这要通过分布式优化器的枚举框架，基于统计信息 + 代价来抉择，确保找到最优解。有了 sjm 并行物化的反对，TPC-H 100G Q20，在 32 并行度下提速 5.8 倍。derived table/cte 并行物化相似于 semijoin，MySQL 对于无奈 merge 到外层的 derived table/view 也会先物化下来并参加到外层 join 中，这个过程同样能够分片实现，因为示意图与下面十分类似，因而不再给出，不过相熟 MySQL 源码的同学应该晓得，semijoin-materialize 和 derived table materialize 有着齐全不同的优化门路和执行机制，因而 PolarDB 外部的并行实现逻辑是齐全不同的。有了 derived table 并行反对，TPC-H 100G Q13，在 32 并行度下提速 2.2 倍。节点间交互为实现跨机，节点间要建设高效的管制 + 数据通道，同时两者间要有必要的协调控制来确保正确的 early-stop，错误处理等机制。管制通道咱们扩大了 MySQL 的命令协定来实现下发打算、执行管制、回收状态等性能，最 naive 的做法是 1: worker 数的形式，即对每个 worker 都建设一个命令通道，但这不仅意味着连贯的减少，也会造成同一节点内的很多工作反复执行（e.g 打算模板反序列化，执行环境重建 …），因而咱们设计了如下管制通道拓扑：
在每个下发的子节点上建设一个 migrant leader 角色，该线程是节点上的代理，负责与 leader 的管制信令交互、生成打算模板和执行上下文等共享信息，同时也要负责创立 worker、治理 worker 执行状态等，这个角色的计算量很小根本不占什么资源。通过这种形式，管制通道优化为 1:node 数。数据通道目前实现了基于 TCP 的数据交互协定，在 leader 构建执行上下文时会查看不同子打算的 worker 间，是否位于同一节点，如存在跨机则应用网络通道，并将相干信息（e.g IP/Port…）随打算片段序列化到近程节点的 migrant leader 上，并传递给对应 worker 用来建设非阻塞的数据通道，数据通道拓扑如下：
高效的数据传输是查问性能的关键因素之一，为此咱们做了一系列针对性优化端口复用每个 worker 可能须要建设多个数据通道，并且可能同时是数据发送方和接管方（上图 slice1），如果每个连贯都应用独立端口，可能会导致节点端口用尽。为防止这一问题，咱们优化为在同一节点内的所有 worker 共用同一端口接管上层 worker 的两头后果数据，并应用全局的 Exchange manager 线程治理连贯并映射到指标收端 worker。缓冲队列因为流水线的执行模式，如果每从 iterator 吐出一条数据就向网络发送，必然带来频繁零碎调用的开销，为此在收发端均引入了循环缓冲队列，实现了流控和 batching+pipeling，晋升传输性能。异步设计为了升高网络传输不稳固以及 worker 负载不平衡的影响，数据通道应用了全异步化设计，对于各个通道的读 / 写均是非阻塞的，如果某个通道临时无奈收发，则切换到下一个通道持续操作，这显著晋升了整体的 cpu 利用率和传输效率。但仍存在一些问题：在高并发度的 shuffle 中，数据通道会产生经典的连贯爆炸问题（N * N 的连接数），这对于集群的网络开销还是比拟高的，为此咱们后续有两方面的布局：实现 proxy 模式的数据交互协定，多路数据复用同一连贯，以应答更大规模的并行（e.g 参考 Deepgreen）应用 RDMA 实现数据传输协定，彻底 bypass 网络协议栈和 kernel 的解决开销，进一步晋升性能执行打算序列化分布式执行打算的打算片段如何传递到近程节点并转换为精确的物理执行打算，是分布式计算引擎必须要解决的问题。Microsoft Synapse 和 Oracle PX 通过将打算片段转换为 SQL 语句，下发到集群中各子节点，并在节点本地从新解析生成执行打算来实现子打算的散发。还有一些零碎（e.g Greenplum）会散发物理打算的逻辑形容，并在子节点上基于形象形容从新构建物理打算。但 PolarDB 思考到 MySQL 实现的特点并兼顾打算生成的高效性，抉择了序列化打算模板的形式，具体如下：
leader 在实现分布式优化后生成物理打算片段的模板（相似 MySQL 的物理打算），而后序列化该模板二进制的打算模板散发到各子节点的 migrant leader 上 migrant leader 反序列化后，还原出本地打算模板和执行上下文信息（e.g variables/readview…)各 worker 线程从本地模板中 clone 出本人的物理执行打算，理论执行跨节点 parallel scanPolarDB 的并行查问能力与 innodb btree 的逻辑分片 + 并行拜访密不可分，因为不是 share nothing 的架构，为了保障对共享表的并行读取，在 innodb 层对 leaf page 依照页粒度做了逻辑切分，而对于切分后的各个 granules，各 worker 有两种不同的拜访模式：round-robin 每个 worker 轮流获取 1 个 granule 并实现后续算子的计算工作，而后读取下一个 granule，各个 worker 间通过一个全局偏移计数器协同对 granule 的读取。这个做法能够尽可能的保障各 worker 的负载平衡，因为 granule 的切分数量远大于 worker 数，因而执行快的 worker 能够抢到更多 granule 去执行，保障各个 worker 间执行工夫比拟平衡，防止 skew 问题。pre-assign 对所有切分出的 granules，在 worker 间事后调配，每个 worker 拜访指定的分片汇合，这种形式是动态的，初始各个 worker 调配到的数据量是差不多的，但因为后续执行的过滤等操作，worker 之间的计算量可能会各有不同，导致 skew 问题。显然咱们心愿在跨机时依然能应用第一种计划，但很遗憾这个全局的偏移计数是无奈跨机共享的，Oracle PX 的实现形式是由 leader 作为协调者，通过网络通信来协调对 granule 的获取，但这样也引入了额定的通信老本，因而 PolarDB 的跨机 parallel scan 目前采纳了一种折衷方案：节点内做 round-robin，节点间 pre-assign。对于切分出的所有 granules，事后依照参加查问的节点数调配为若干 range 区间，各个 range 内的 granule 间断排列。在理论执行中，每个节点内的所有 worker 线程利用所属 migrant leader 的共享计数器，争抢所调配 range 内的 granules 汇合。
查问内事务一致性在单节点并行查问中，各 worker 线程通过共享 leader 的 readview，来保障在 innodb 层应用对立的读视图读到合乎事务一致性的表数据。但在跨机的状况下这个机制就呈现了问题：不同节点间的读视图如何放弃与 leader 统一？为了做到这一点，须要三方面的工作：读写事务信息同步为了保障集群级别的事务一致性，RO 节点必须可能感知到 RW 上产生的读写事务，并依据这些信息构建本地的沉闷事务信息，来同步 RW 的事务零碎状态，为此 innodb 层会将读写事务的相干信息写入 redo log 复制到 RO，RO 解析 redo 后从新构建沉闷事务链表。全局统一位点的同步只是有了沉闷事务链表并不足够，因为 RO 上的信息总是落后于 RW 的，如果一个查问的 worker 工作达到 RO 时，该查问在 leader 的沉闷事务信息还没有在 RO 上 apply 进去，worker 是不能开始读取的，须要期待全局事务信息复原到 leader 创立时的状态，为此须要有个期待同步点的过程。初始时咱们采纳了基于 lsn 位点的期待：leader 在构建 readview 时记住所在的 lsn 位点 lsn3，并传递到 worker，worker 在 RO 期待晓得 apply 位点达到目标值 lsn3 后，再构建出和 leader 一样的 readview，做数据读取
能够看到，基于 lsn 机制的同步粒度是较粗的，实践上，在 RO 复原 lsn2 之后，worker 就能够构建同样的 readview 信息了，因而在新计划中咱们进行了优化，利用 innodb 层提供的 SCC 全局强统一能力来更及时的同步 RW/RO 之间的事务状态，并基于这个信息作为同步位点，进一步升高 query 内提早。对于 SCC 性能能够参考官网文档[2]。读视图的复制有了以上两点的保障，这里就非常简单了，只须要将 leader 获取到的 readview 同步给所有 worker 即可，具体就是通过对 readview 相干构造（e.g 上图的 trx1/trx2…）实现序列化 + 反序列化。基于资源的自适应调度弹性多机并行反对以下 3 种调度策略 LOCAL 节点内并行，相当于敞开了 ePQ 引擎 MULTI_NODES 全局并行度随节点数线性减少，实用于海量数据的简单查问 AUTO（default）自适应并行，会依据集群内节点的实时负载信息做调度，本地节点资源有余时，尝试抉择有闲暇资源的节点调度执行，同时如果查问代价 / 扫描行数超过阈值则切换到 ”MULTI_NODES” 模式
例如：用户设置并行度为 2，当开启 AUTO 模式时，如本地节点资源短缺则抉择本地执行 (上图左)，否则会将 worker 协调到其它有闲暇资源的节点（上图中）。当查问代价 / 扫描行数超过特定阈值且集群内有足够闲暇资源，DoP 弹性调整为 2 *3=6，应用集群内所有节点进行减速（上图右）这种 AUTO 模式下的自适应调度能力通过分布式任务调度器实现，调度机制整体框图如下：
分布式任务调度器任务调度器为无核心架构，每个计算节点均可承受查问并通过本地 Coordinator 实现查问调度。首先优化器生成的分布式执行打算会进入 FIFO 队列，Scheduler 从队首获取工作，通过全局资源视图（见下）为计算工作申请计算资源池（CRB List）。如资源有余则持续期待，直到有闲暇资源或超时回退串行。全局资源视图该模块负责收集和保护各节点的资源负载信息（e.g CPU/Memory/Concurrency…），每个节点定时采集本身负载信息并以 UDF 报文播送到集群中，这样每个节点都会保护一份全局资源信息的快照。计算资源估算计算资源估算（Compute Resource Bugdet. CRB）是对节点负载资源的一个评估值，代表该节点残余的计算能力。因为资源信息播送是异步的，无奈完全避免因为 stall 导致的不精确调度，为防止资源分配过载 / 有余，在计算单个节点的无效估算时咱们引入了一个自适应因子，该因子会按如下策略调整：间断 N 次负载信息无显著稳定，factor 上调 10%；间断 N / 2 次负载信息有显著回升，factor 下调 20%；指标节点并行资源耗尽，factor 间接下调为 0，禁止调配 worker 调配 CRB 当获取到资源池后，池中的列表会波及多个节点，那如何将 workers 汇合调配到这些节点中呢？这里会思考基于两个因素 1、cache 亲和度：针对最上层 leaf workers 失效，后面已提到，在为表切分 granules 时，会以 pre-assign 形式将各 granules 汇合绑定到各节点上，每个 worker 会依据本人所属的 granule range 映射到指标节点，如果该节点有资源估算供该 worker 执行，则执行散发（复用节点中可能缓存的 pages），否则只能调度到其余节点执行
2、最小化跨机数据传输：针对非 leaf workers 失效，下层 worker 在调配时要参考上层 worker 尽量做 ” 竖向 ” 切分，缩小跨机数据交互，例如下图左侧的数据散发总量会少于右侧
性能评估性能的体现形式能够有很多种，这里咱们既会关注个别产品都会测试的 TPC- H 查问性能，也会针对后面提到的几个特定场景来逐个做下评估，确定弹性多机并行的行为是否合乎设计预期。注：本测试是通过购买 PolarDB 8.0.2 版本线上实例，敞开了 2 个属于试验状态的优化器参数。set optimizer_switch=”hash_join_cost_based=off”;
set cbqt_enabled=off;
而后在集群配置页面上开启多节点并行并设置单节点并行度即可，无需其余操作和调优，根本属于开箱即测。测试应用规范的 TPC-H [3]数据（主外键）和语句。单机 v.s 多机后面咱们提到的一个问题，就是雷同总体并行度的状况下，大规格单机会比小规格多机更好吗？为了验证咱们应用如下测试方法：1node 32c 的 polar.mysql.x8.4xlarge v.s 2node 16c 的 polar.mysql.x8.2xlarge，两者 CPU/MEM 资源持平，对用户来说老本也雷同 CPU boundTPC-H 100G，22 条查问每条执行 3 次取第 3 次后果，此时数据齐全 cache 在实例内存中无 IO，比照如下：
能够看到根本所有查问都变得更快了，这也合乎咱们对并发资源争抢消减的预期 IO bound 应用 TPC-H 1T 做 power run，因为内存严重不足，因而肯定会产生大量读 IO，后果比照如下：注：power run 指重启实例所有节点的 docker 实例后，程序执行 22 条查问 SQL
能够看到因为有了两个节点，总体的 IO 带宽也扩充了一倍，可能更好的利用底层共享存储的大吞吐，少数查问有了晋升，但局部查问会变慢，察看发现这些查问次要都存在多个大表 join 的状况，这是因为在做多表 join 时，基于主外键的 nested loop join 会带来肯定的二级索引随机回表，在单节点时，同一个主键索引 page 在被淘汰之前很可能被某些 worker 线程复用而减速了那些 worker 的执行，但扩散到多节点后这种复用率升高了，产生了更多的 page thrashing。但总体执行工夫依然多节点是更快的，晋升了 21%。横向扩容这里咱们来看下随着集群的横向扩容（scale out），查问的扩展性如何，依然思考 CPU bound/IO bound 两种场景 CPU bound 同样应用 TPC-H 100G，22 条查问每条跑 3 次取第 3 次后果，应用 16c 的 polar.mysql.x8.2xlarge 规格的节点，从 2 节点开始顺次翻倍节点数
IO bound 依然应用 TPC-H 1T 做 power run，也是从 2 节点开始顺次翻倍
能够看到从 16DoP 到 256DoP，冷热查问的性能均失去了线性晋升。在离线混合为评估之前提到的在离线混合场景的成果，咱们建设了一个 1rw+3ro 的实例，并创立 oltp、olap 两个集群别离模仿在线事务 (rw1+ro1+ro2) 和离线剖析 (ro1+ro2+ro3) 负载。
应用 2 个 client：Client- 1 连贯 oltp cluster，应用 sysbench 做短事务读写压测。Client- 2 连贯 olap cluster，应用 tpch 数据革新后的 sysbench，但为看出成果，这里也没有应用很大的长查问，仅为了使其足够应用多机资源。测试流程：Client-1 暂停，模仿 oltp 业务闲暇。Client-2 开始间接连贯 ro3 节点，察看 qps。Client- 1 复原，将 oltp cluster 资源占满，此时察看 Client- 2 的 qps 变动。再次暂停 Client- 1 的压力，察看 Client- 2 的 qps 变动下图给出 Client- 2 的 sysbench 截图
能够看到在 oltp cluster 有压力时，Client- 2 的查问只在 ro3 节点内并行，吞吐也较低。当 tp 业务闲暇时，ap 查问的负载散发到 ro1/ro2 节点，吞吐量立即回升。当 tp 业务再次忙碌时，ap 的查问能力从新回落到单节点程度对负载变动的响应提早在 1 - 2 秒左右。TPCH 针对相对性能咱们在各种 [节点数 并行度] 的组合下进行了大量测试，这里仅给出 16 16 = 256 并行度 的数据 100G hot
1T hot
能够看到，无论是 100G 还是 1T 的数据量，多机并行都失去了十分不错的性能数据，作为一款次要面向高并发 TP 负载的事务型数据库，这曾经体现出了 PolarDB MySQL 不俗的实时剖析能力。总结与瞻望 PolarDB MySQL 的弹性多机并行（ePQ）为面向大数据量的简单剖析查问提供了更弱小的实时减速能力，但其作用不止于此，作为 PolarDB 云原生个性的一部分，它更重要的能力是横向买通集群的计算资源，将集群中的各节点作为一个整体来思考，或是对大表查问进行减速，或是对查问进行动静调度，从而保障剖析的实时性和资源的充沛平衡利用。此外与弹性能力的联合让并行可能利用到更宽泛的场景中，为客户提供更极致的性价比。多机并行的工作远没有完结，后续还有很多的优化和利用场景期待咱们开掘：加强 MySQL 原生优化器，给出更优的 join tree 状态（bushy join/hash join），解决大量 nested loop index lookup 产生的 IO thrashing 问题进一步加强 MySQL 的统计信息能力，晋升最优串行 / 分布式打算的准确性应用 RDMA 作为数据通道底层协定反对 partition-wise join/cluster-aware partition-wise join 反对对导出到对象存储（oss）的冷数据做分布式查问反对对各类表面的联邦查问在分布式执行中引入自适应机制，晋升执行效率。。。敬请期待参考资料：[1]https://help.aliyun.com/docum…[2]https://help.aliyun.com/docum…[3]https://www.tpc.org/tpch/ 举荐浏览 1. 如何写出一篇好的技术计划？2. 阿里 10 年积淀|那些技术实战中的架构设计办法 3. 如何做好“防御性编码”？PolarDB for PostgreSQL 从入门到实战 PolarDB for PostgreSQL 是阿里云自主研发的一款云原生关系型数据库产品，100% 兼容 PostgreSQL，采纳基于 Shared-Storage 的存储计算拆散架构，具备极致弹性、毫秒级提早、HTAP、云原生、多模计算、金融级高牢靠和高可用的能力，实用于高并发在线事务、实时简单计算和查问剖析、实时图文搜寻、金融等业务场景。本书由阿里云及网易数帆、美创科技、CUUG、恒辉信达等开源生态合作伙伴独特出品，从装置部署到运维实际、开发工具，八大章节轻松入门 PolarDB for PostgreSQL 开源数据库。点击这里，查看详情。原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。
