PolarDB forPG 开源路线图|学习笔记

开发者学堂课程【PolarDB for PostgreSQL 入门：PolarDB forPG 开源路线图】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/813/detail/13920

PolarDB forPG 开源路线图

 

内容

一、背景

二、开源路线图

三、开放问题讨论

 

这个分享将主要围绕项目的这个背景和路线图来展开，传统数据库产品呢已经研发了四十多年，所以厂家有很多很多，对产品也是层出不穷，看看数据库排行榜就知道面对多么丰富的这个数据库产品族谱，加上最近十年来大数据的数据库产品，逐渐和大数据处理产生融合的这个趋势，任何一个新发展的这个数据库产品一定离不开这些背景，选择一个数据库产品的这个技术方向同样受到这个大环境的影响和约束，接下来讲讲我们对这个背景的理解和分析，并在此基础上提出产品开源的这路线图及其所要达成的这个目标和需要解决的问题，最后通过几个开放性问题的讨论来结束今天的这个分享。

 

一、背景

1. 开源：数据库上云是如何利用开源的，又如何回馈了到开源产品，并且能够最终成就开源。过去数据库作为传统的it基础设施，基本上垄断在几大主力的产商手里，虽然开源数据库产品很多也很流行，都是叫好不叫做挣钱能力不足，商业性能不是很好，这其实有下面的一些因素来决定，因为数据库作为核心的it基础设施，对其可靠性、稳定性、功能全面性和性能要求很高，每个企业在选型数据库时是非常谨慎的，开源数据库本身也在十年前也没有拿出足够的能力来撼动这些商业数据库的这个地位，其次就是在商业上由于使用数据的客户以前大部分都是大客户，有充足的资源，当然希望被大客户、大公司来服务，由于上述两个因素形成的数据库，商用数据库的生态用户 DBA 开发以及中间商都是基于这些商用数据库，所以对于一个新产品的进入，它的门槛是非常高的，所以自然就形成这样的垄断，后来发生了 it 公有云化的发展，比如阿里云、aws 这些后期的 it 提供商从计算、存储、资源优化开始、为用户提供按需的这个资源，进而自然进入基础软件的这个供应，显然使用来自垄断产生的商用数据库为云用户提供服务，将导致云的利润都被商用数据产生拿走，将开源数据库推上前线和商用数据库一帧高低是其背后的商业背景和目的决定的。

其中的路径有下面几步，第一先完善这些数据库的企业级管理能力，比如说最后的部署、数据库的启动、停止、升级、扩容，备份恢复等操作 这些管理能力的云化和完善，使得上云的用户不再需要 DBA 来管理数据库，极大的减少了用户的运营费用，所以第一步开元数据不上于就是用云化管理来替代 DBA 实现对商用数据库的商业模式的这个超越，云化的数据库的资源的随用随取也是一个非常重要的点，提到开源数据库在本身能力上和商用数据库是有一定差别的，那如何吃下商用数据库开辟了那么大市场，对开源数据库的云化增强就开始了。因为补善差距是不够的，是不能够吸引客户转投开源数据库的，必须有超越商用数据库技术和竞争力，比如阿里云开发了 polarDB，首先对数据库依赖的存储系统进行优化改造，提供云原生的扩展性和资源弹性，同时对外维持开源数据库的所有特性，保证开源数据库的生态可以很好的寄存，这个改造解决了商用数据库固有的对底层存储的硬件的依赖，比如其性能和容量完全受限于存储硬件，不容易扩容，也不能实时在线的提供按需的吞突，后续引入的一写多读分布式以及 database 的技术，使得云原生的基于开源数据库的产品完成了对传统商用数据库的技术超越，为用户提供了他们不能提供的价值和竞争力，阿里云在使用数据库，使用开源数据库，同时也在不断地为开源社区输出企业级的技术，其实不能够把社区就是推很多很多东西，你们评级社区是非常谨慎的，对每一个特性的需求和设计都有非常严格的这个要求，需要经过多位重量级的同意和竞争开发者同意，很多特性在社区历史上都被其他开发者开发过，只是设计角度和覆盖的方面没有满足了社区的需求而被搁置，那么任何一个能够最后被社区所接受的都需要超越以前的版本才能最终被接受，经过半年多的时间花了大概几十个来回的讨论就是最后最终才能够实现了，让这个特性被社会所接受，所以考虑的社区版本衍进的这个谨慎性，我们有许多技术 我可以回个开源社区，但是因为社区的这个相对谨慎，我们很难做到这个事情，因为其中周期非常长，这就成为我们开源 polarDB 的一个重要原因，我们希望我们开源的技术是被社区力核能力的辅助， 一个增强所以最好都是垂直于社区能力的，用户可以拿我们的开源软件加上社区的内核版本就可以同时享用两边的这个贡献，其实我目前选择开源高可用能力分布式扩展能力后续的云化运维能力等功能的主要的考虑因素，通过这些技术的开源我们就可以和社区共同，成长我们的技术就是社区的一份子，同时设计的发展也能够帮助我们更好的服务客户，最终收益的是开源社区和我们的用户，社区和开源社区开源数据库的用户获得了共同成长的利益和价值，而阿里数据库团队将成为其中的一个助力，这是我们对开源产品的理解。

2.数据库架构：

上面图是列了三种架构，最左边的是单机数据库，一台服务器上运行一个数据库存储就是本地磁盘系统，用户通过网络连接数据库及行事故查询和计算，很明显之后价格问题是当数据库故障的时候，用户服务将会被中断，同时本地谈系统的容量和吞吐有限，但用户负载增加的时候，单机数据库会出现服务响应过程等性能问题，但商用数据库 开源数据库，有些开商用数据库元数据在一台服务器上部署的时候就是这种类型，那中间这个架构又称为共享存储，特点是多个数据库实例共享一个存储系统，一般这种存储系统它是有硬件厂家生产或者通过云化的存储服务，具备更高的性能和容量，多个数据库实例可以共享做的系统外，还可以共享一个数据库，包括其字典表，用户表等等，这些数据库实例可以写，也可以读。

比如 Oracle 数据库实例就是可以同时读写共享、存储，polarDB 现在只有一个写节点，其他节点都是读节点，这个架构特点是计算和存储分离，数据库计算有专门的数据库节点来完成，而存储有专门的硬件或者云化系统来实现，另外一个特点是当有实力故障的时候，可以快速恢复，快速的切换负载到其他实例上去执行，这个中断时间非常短，但用户负载和要求吞吐增加的时候，价格需要提升硬件的规格，来实现这个能力的提升，比如增加数据库节点的 cpu合数、增加共享存储的能力等等，所以这种扩展能力我们称之为垂直扩展，然后最右边这个架构称为叫分布式架构， 每个数据库实例和单机数据库类似，有自己的存储和计算资源，每个数据库实例都是一个独立的一个数据库，但是这些数据库通过一定的字典表的管理实现，对用户来看就是一个数据库，每一个数据库实例其实管理一个分片数据库，存储一部分数据库的数据相互之间是逻辑和物理的隔离，其主要特点是当涉及多个分片数据库时需要执行分布式的计算，需要通过分布式的事物保持事物一致性，这种架构的优点是系统可以水平扩展，但用户需要更大的存储容量、更高的计算程度的时候，就可以通过增加数据库分片，也就是数据库节点的方式来提升统的容量性的，这种扩展方式称为水平扩展或者 skill out ，我们开源的 polarDB 将是后面两种架构的融合。

数据库系统的演进：传统的商业数据库还是开元数据库 mysql 或者是 pg 他处理的都是关系型的结构化的数据，其中又分为两种 RDBI,也就是关系型数据库管理系统,主要处理在线的交易性和负债,比如 ATM 商家的在线交易等等，另外一类称为数据库一样都使用标准的 SQL 来处理数据，但是其附在设计大量数据很多表计算非常复杂，典型应用为 etl和在线分析计算，随着大数据的信息还都是平台的普及 用户希望处理的数据类型逐渐多样化，比如时间序列，地理数据图，向量文本等等，相应的数据处理产品用线，他们区别于关系型数据库的最大差别是，处理的数据类型和使用的处理语言是不一样，以及他们和大数据平台的融合，带来了极高的可用性和扩展性，能够水平扩展到几十大的几百台台服务器上，受这些产品的启发，许多新型数据库和系统开始转向分布式的高扩展，引入了共识协议实现高可用，同时维持对数据库处理语言 SQL 的支持，虽然这些 newSQL 实现了上世目标，但是其对身后支持的完整度上和开源数据库仍然有一定的这个差距，可以说只是后者的字迹，需要入很大的这个资源来完善这个功能，想法是不是能不能在开源数据库的基础上引入分布式、引入共识协议以及存储和计算层的弹性优化，实现产品的 newSQL 高可用、高扩展、高弹性、但是保留对开源生态的完整支持，这是开源路线图的一个支撑的一个因素。

集中数据库的业务痛点：

在线业务超高并发，扛不住!

（1）PolarDB 将业务数据及访问压力分摊至多个计算存储节点之上，平稳解决在线业务超高并发难题。

（2）复杂分析查询，性能慢!

针对在线业务 PolarDB 提供并行计算加速能力，可大幅提升海量数据下复杂分析查询的执行效率。

（3）海量业务数据，存不下!

通过水平拆分 PolarDB 可线性扩展数据存储空间，提供百 PB 级存储能力，高效解决单机数据库存储瓶颈。

（4）单表数据量过大，效率差!

数据库单表数量过大后，将导致数据库吞吐能力下降，整体性能迟缓。PolarDB 将单表数据水平拆分至各个存储节点中，有效解决单表数据量膨胀问题。

 

技术趋势背景：

最后背景将主要讨论一下数据库技术的这个技术趋势背景的，但数据库技术很多很多的，不可能每一个点都覆盖，主要从云化的这个角度去理解，因为毕竟数据库产品现在文化是主要的方向，从云化角度来说，首先数据库需要发的技术是什么，我们得看云画的核心是什么，云化的核心就是要极大的减少用户使用数据库的这个代价，或者叫 tcu total cost of ownership =，这个代价主要包括管理、运维、软件、硬件代价基于这个核心，目前公有云数据库服务首要提供的就是管控功能，帮助用户减少和避免管理和运维的投入，同时云化服务，支持按需的软硬件配置，发挥软硬件的最大效率，并保证实施的弹性，保证用户能够最有效的支持负载水平所需的资源，云化技术目标可以总结为简单易用、性价比最高。

其数据库还需要分布式技术，不管是存储的分布式还是计算层，还是事务一次性层，甚至是故障恢复数据冗余方面都需要分布式的这个技术，业务层面上，现在的数据库系统需要支持海量的数据业务所带来的高并发负载和混合负载，从云化角度，分布式能力是实施弹性所需要的核心能力，所以也是云化的必要条件，最后是进入趋势是资源要共享资源要隔离 实现换资源或看系统分层的独立扩展，比如计算和存储的分离，就可以实现数据库计算按需扩展，相应的如果容量需要增加，则需要增加存储的资源和节点，这种隔离和独立扩展能力可以扩展到内存，扩到计算、存储、网络甚至数据库的一些核心处理能力，比如事务处理和复杂查询处理等等，在上述的趋势下，看云化数据库需要发展的一些核心技术的特性，首先数据库的高可用简称为重力重点发力的地方， 因为这关系到数据库的核心能力，经简化用户运维管理代价，如果一款数据库产品，在任何故障下，用户都不掉线，查询都不受影响，那极大提升用户对产品的信心和简化背后管理的复杂度，同时如果数据库任何运维操作，比如备份恢复、增删节点，都不会中断负载，使用户在使用体验上更上一层楼，也为数据库调优提效提供更加自由和更多维度的方便，其次，另外一个集中的方趋势就是扩展性，包含各种能力的扩展、存储、计算事务和复杂查询。另外一方面这种扩展是否有瓶颈，在分布式下 mvc 需要全局之中或者全局排序的数列，产生这个全球数列将对扩展规模形成约束，就是因为这个产生全球序列的服务可能就成为这个扩展的，设计了自己的始终机制来应对这样的这个约束，在具备了极高的高可用和多层次的扩展性以后，弹性的一幕将会为产品带来云化所必须的按资源使用的这个特性，为什么这个科弹性的以什么样的这个弹性颗粒度来进行弹性操作，以多快的这个速度提供资源的这个扩缩，用户负载和性能是否受到影响等等都是弹性技术所需要面对的，再回到对用户应用性上的个支持，用户经常已经有很多应用，跑在传统数据库或者跑在开源数据库产品上，但是他有云化的基础，没有云化的这些技术的知识，比如应用和高效的这个网购对，极致的高好用等。

如何让用户的这些应用可以顺利简单的以较低的代价迁移到云化产品上，将是产品应用性的首要，产品上产品应用性的首要考虑，这其中维持 SQL 和生态的监控性至关重要，如用户 SQL 的程序都不需要改动，可以直接切换到云化的这个诉求 ，那是否可以减少大量的这个用户投入来给到应用，比如用户的应用仍然可以使用相同生态类的这个工具，那么用户就不需要购买新的工具 省区为适配这些工具要需要开发工作，往往这些方面的一些应用性的缺失是造成用户迁移的这个主要阻力，那么兼容性和易牵引性也将是考虑的重点，所以概括起来技术趋势，优化数据库机构趋势就是四个方面，高可用性、扩展性、弹性、和兼容性。

二、开源线路图

首先开源的这个版本的是基于 X-Consensus 共识协议的一个高可用集群版本，该版本主打的是高特性，让用户可以快速自建一个和阿里集团内应用使用一样的这个能力，一样的数据库进行底座，在实现极高情况下支持全局一致性，故障时保证数据不丢失，并且能够快速的对外进行服务，那该怎么解决用户对高可用的一些最根本和最初步的一些需求。

第二阶段我们将推出基 于HLc 的高扩展等分布式版，这个版本将实现架构支持数据库进行的水平扩展。

解决单机存储应该出现问题，并支持高并发和高冲突的事务处理，通过分布的是五个分布的始终会消息做到分布式全局一致，也就是说整个数据库数据库集群对外呈现单击数据的特性，用户应用向使用像是用单机数据那样获得 id 的支持。

第三阶段我们把这两阶段积累的大部分能力以进化的形式改写，包括分布式事物，分布式计算的弹性，从而使得我们工作对社区内核的开发是垂直的，可以互补，这样我们用户就以快速的升级数据库那个版本，同时保留我们提供的分布式弹性和高可用的特性，这个路线图简洁的体现了我们对文化数据库的这个需求的这个理解，通过开发和社区互补的工作，实现对社区增强，同时保持社区的兼容 实现生态统一，最小化用户的使用和升级代价。

1. X-Consensus 高可用集群版

围绕高可用打造的产品特性，下图为高可用版本架构图。包括多个组件，比如leader、follower、logger数据库节点，其内核都是 PG，CM 集群管理组件负责系统启动节点和停止、集群操作等等。

核心是 X-Consensus 阿里自研的共事协议，在 X-Consensus 支持下，polarDB 实现了节点故障不能恢复的时候，已提交数据不丢失，并且保证对外一致性，在实现层面上，polarDB 仍然使用 PG 自带的，而且是通过 X-Consensus 共事协议，保证节点间日志同步位点同步，好处是不改变内核数据复制协议，减少对内核的侵入性修改，同时维护对工具生态的兼容。

这个选择反应了在开源项目中坚持的原则，做的功能最好是垂直于社区的功能和发展，共事协议的稳定性和正确性及核心能力，使用的协议已经被使用在阿里集团内部业务，成千上万的数据库经过多年高压测试和实际负载的打磨，相信作为一个开源数据库被大家接收会成功这个方向的标杆产品。

除了稳定性和正确性保证，这个开源项目还使用了多角色能力，使 leader、follower、logger，其中 follower 没有数据库只保留一份日志参与选举但是不能被选举，logger 被引入将减少三分之一的存储，同时保留共事协议的一些能力。

logger 开以选举就可以在自动选组时快速找出多数派。共事协议保证了快速正确的选组。

2. HLC 高扩展分布式

核心是对分布式内核的扩展，扩展后的系统能够最大限度的兼容单机的能力，同时保留单个数据库对外的能力，二者的目的就是保证分布式扩展后的系统对用户大部分的应用仍然像单机那样减少迁移和开发的工作量。

 

可以看到 Coordinator nodes 出现更多的组件，其中 data node 就是高可用集群，只是有更多的多个的这样的集群，基于 X-Consensus 复制组，每个复制组中有 leader、follower、logger，通过 X-Consensus 共事协议保持数据一致性，每个数据组复制数据库的部分数据，称为数据库分片。

用户查询先路由到协调节点，协调节点通过字典表和集群信息判断查询涉及的数据库分片，并发动查询到相应节点获得各个节点的反馈结果后，协调节点还会负责把结果反馈给用户。

TX manager 保证一个数据库在多个事物实例上时满足 acid，另外一个叫 HLC，目的是保证事物有一个全局的排序，从而实现分布式下的 MICC，采用混合终端的好处是分布式没有中心，在大规模启动下不会引用热点的瓶颈，同时可以避免新的组件增加管理和高可用的实现代价，通过 HLC 事物和操作进行时间意义上的全局排布，不仅仅需要实现HLC协议，同时需要数据库内核的支持，这个支持在一期已经完成了。所有的事物都按照时间排序时原有的 MICC 就可以正常的运行，保证数据多版本支持。

在分布式 Coordinator nodes 下，除了事物一致性外，如何处理分布式的 SQL计算也是一个事情，这期间的工作非常丰富，比如发送查询到数据库分片，节点的操作需要下推到某个节点。根据一起基础，data node 已经具备高可用，需要一个像 X-Consensus 方案，解决用户集群管理统一的高可用问题，所有将会实现一个分布式的高可用，二期将推出具备完整数据库。

其主要特性都是对现有单机的补充、增强和扩展，这些能力的大部分将在第三期成为插件，满足用户快速升级的需求。

3. Sharding 和插件化版

增强分布式能力，云化能力和社区兼容能力，架构图反应了三期的主要思路，DB Node 作为核心组件提供单机分布式能力、内核能力和组件能力，保持数据一致性，DB Node通过 X-Consensus 共事协议布局到 follower，维护节点级别的数据，有助于故障下的快速恢复，每个 DB Node 功能将通过对 PG 社区内核的支持加上对分布式的插件，实现这些功能，在 DB Node 上面维护一个 polarDB 服务层。

相对独立的用户层将有助于用户应用的对接，不受内核升级变化的影响。服务层可以随环境变化针对不同云提供商和专有云来进行提供支持，主要增强体现在 sharding，在细粒度主要加强 sharding 在源生内部相对单极化的架构，计算存储相对偶合，不利于云化分布式下弹性和扩展管理，支持在线 sharding 迁移，进一步支持弹性能力和云化迁移能力。

同时通过统一组件将协调节点和 Node 合二为一，成为统一的 DB Node 和数据库相关的功能，在一个组件里面提供使得云化部署和管理更加简洁，最后通过分布式和 sharding 能力插件化保持对社区版本的兼容保证用户可以快速的升级。

至此 polarDB 开源通过三项衍进实现了对 PG 内核的分布式扩展，保证分布式一致性，同时兼容 PG 内核solo的能力和版本的升级，具备云化的弹性和管理的简洁性，后续仍然有很大的优化空间，有很多特性持续推出，比如分布式计算的持续优化。

三、开放问题

1.传统市场以集中式为主，分布式能否成为主流？

答：将来很长时间，集中式可能仍为主体，分布式在完善功能在构建生态上会不断的进步，可以占据一定的市场分位。如果分布式能兼容集中式的模式，那么分布式产品既可以当作集中式使用，还可以按需扩展成分布式。

2.目前很多云数据库都是采用存储计算分离的架构，分布式数据库是否也可以采用存储计算分离?

答：应该是不冲突的，分布式系统是可以使用集中式存储的，很多云式都可以当作集中是来使用，分布式可以通过自身扩展性，更加有效的利用这些云存储的。

3.分布式数据库在 SQL 和存储的扩展性和弹性外，是否可以实现更多功能，对接更多生态?

答：天然就具备一致性、扩展性、分布式计算等，前提是打造一个完成的，可靠的开源数据库，在此基础上可以做更多更加有意义的多生态工作。