简介： 对于并行查问的性能、个性、技术原理等，"并行查问的前世今生"这篇已做过具体的解读，明天这篇文章则次要聚焦于并行查问全新公布的下一代状态：弹性多机并行（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...本文为阿里云原创内容，未经容许不得转载。