关于云计算:PolarDB-for-PostgreSQL-开源路线图

简介：作者：蔡乐

本文次要分享一下 Polar DB for PG 的开源路线图，尽管路线图曾经拟定，然而作为开源产品，所有参与者都能提出修改意见，包含架构外围个性的技术以及周边生态和工具等，心愿大家可能踊跃提供想法和倡议，帮忙产品晋升。

本文次要围绕我的项目的背景和路线图来开展，传统数据库产品曾经研发了 40 多年，出名厂家有很多，产品也是层出不穷。看看数据库排行榜，就晓得咱们面对如许丰盛的数据库产品族谱，加上最近 10 年来大数据 NoSQL、NewSQL 的衰亡，数据库产品逐步和大数据处理产生交融的趋势，任何一个新研发的数据库产品肯定离不开这些背景，抉择一个数据库产品的技术方向，同样受到大环境的影响和束缚。

本文将花一些工夫论述对这个背景的了解和剖析，并在此基础上提出产品开源的路线图及其所要达成的指标和须要解决的问题。

一、背景

（一）叶落归根，回馈开源，成就开源

首先介绍的背景是对于开源，讲讲当初数据库上云是如何利用开源的，而后如何回馈了到开源产品，并且最终成就开源。

过来数据库作为传统的 IT 基础设施，基本上垄断在几大主力的厂商手里。尽管开源数据库产品很多也很风行，比方 MySQL 等，都是叫好不叫座，挣钱能力有余，商业能力可能不是很好，这其实由上面的一些因素来决定。因为数据库作为外围的 IT 基础设施，因而对其可靠性、稳定性、性能全面性和性能要求很高，每个企业在选型数据库时十分审慎，开源数据库在 10 年前也没有拿出足够的能力来撼动这些商业数据库的位置。

其次就是在商业上，因为以前应用数据的大部分都是大客户，有短缺的资源，他们当然心愿被大公司来服务。上述两个因素造成了商用数据库的生态，用户 DBA 开发以及中间商，大家都是基于这些商用数据库工作，所以一个新产品如果想要进入，它面临的门槛是十分高的，天然就造成垄断，造成某些厂商一枝独大。

随着 IT 的云化，私有云市场的倒退，比方 AWS，阿里云等，这些前期的 IT 提供商从计算，存储，资源优化开始，为用户提供按需的资源，进而天然进入根底软件的供给。

显然，应用来自垄断厂商生产的商用数据库为云用户提供服务，将导致云的利润都被商用数据库厂商拿走，将开源数据库，特地是像 MySQL、PostgreSQL 推上火线，和商用数据库一争高下，是其背地的商业背景和目标决定的，其中的门路基本上有上面几步。

首先是欠缺这些数据库的企业级治理能力，也就是明天所谓的 RDS 服务，比方数据库的部署，数据库的启动、进行降级，扩容备份复原等操作。这些治理能力的云化和欠缺，使得上云的用户不再须要 DBA 来治理数据库，极大缩小了用户的经营老本。

因而，第一步是开源数据库上云，用云化治理来代替 DBA，实现对商用数据库的商业模式的超过。当然，云化的数据库资源的随用随取也是一个十分重要的点。实现这一步还不够，毕竟开源数据库在自身能力上和商业数据库是有肯定差异的。

要想获得商用数据库开拓的大市场，开源数据库的云化加强就开始了，因为补上差距是不够的，不可能吸引客户转投开源数据库，必须有超过商用数据库技术的的技术和竞争力。

比方阿里云开发了 PolarDB，首先对数据库依赖的存储系统进行云化革新，提供云延长的扩展性和资源弹性，同时对外维持开源数据库的所有个性，保障开源数据库的生态能够很好地被继承。

革新解决了商用数据库对底层存储硬件固有的依赖，比方其性能和容量齐全受限于存储硬件，不容易扩容，也不能实时在线地提供按需吞吐，后续引入的一写多读分布式以及 Global DataBase 的技术，使得云原生基于开源数据库的产品，实现了对传统商业数据库的技术超过，为用户提供了它们不能提供的价值和竞争力。

阿里云在应用开源数据库的同时，也在一直地为开源社区输入企业级的技术。比方阿里保护了 MySQL 分支 AliSQL，比方咱们推入 PG 社区的全局长期表性能。

咱们无奈往社区推很多货色，因为 PG 社区十分审慎的，对每一个个性的需要和设计都有十分严格的要求，须要通过多位重量级的 Commit 的批准和竞争开发者的批准。很多个性在社区历史上都被其余开发者开发过，只是设计角度和笼罩方面没有满足社区的需要而被搁置。任何一个 Patch，都是须要超过以前的版本，最终能力被 PG 社区接管。

咱们通过半年多的工夫，最终实现了被社区所承受的个性。思考到社区版本演进的审慎性，咱们有许多技术能够回馈开源社区，然而因为社区的绝对审慎，咱们很难做到这个事件，其中的周期十分长，这就成为咱们开源 PalarDB 的一个重要起因。咱们心愿开源的技术是对社区内核能力的辅助加强，所以最好都是垂直于社区能力，用户拿咱们的开源软件加上社区的内核版本，就能够同时享受两边的奉献，就是咱们目前抉择开源高可用能力、分布式扩大能力、后续云化运维能力等性能的次要思考因素。

通过这些技术的开源，咱们就能够和社区独特成长，咱们的技术就是社区的一份子，同时社区的倒退也可能帮忙咱们更好地服务客户，最终收益的是开源社区和咱们的用户，社区和开源数据库的用户们取得了独特成长的利益和价值，而阿里数据库团队将成为其中的一个助力，这是咱们对开源产品的了解。

（二）数据库架构

接下来介绍的是对于数据库的架构，它是如何演进，当初有哪些数据库的架构。

上图列了三种架构，最右边的是单机数据库，一台服务器在运行一个数据库，存储就是本地磁盘零碎，用户通过网络连接数据库进行 SQL 查问和计算。

很显著，这种架构的问题是当数据库故障的时候，用户服务将会被中断，同时本地盘零碎的容量和吞吐无限，当用户负载减少的时候，单机数据库会呈现服务响应工夫过长等性能问题。但有些商用数据库、开源数据库、MySQL、PostgreSQL，它在一台服务器上部署的时候就是这种类型。

两头这个架构又称为共享存储或 Shared Everything 架构，其特点是多个数据库实例共享一个存储系统。个别这种存储系统它是由硬件厂家生产，或者通过云化的存储服务，具备更高的性能和容量。多个数据库实例除了能够共享这种零碎外，还能够共享一个数据库，包含其字典表、用户表等。这些数据库实例能够写也能够读，比方 Oracle 其数据库实例就是能够同时读写，共享存储。PolarDB 当初只有一个写节点，其余节点都是读节点。这个架构的特点是计算和存储拆散，数据库计算有专门的数据库节点来实现，而存储有专门的硬件或者云化存储系统来实现。

另外一个特点是当有实例故障的时候，能够疾速复原，疾速地切换负载到其余实例下来执行，中断工夫十分短。但用户负载和要求吞吐减少的时候，这个架构须要晋升硬件的规格来实现能力的晋升，比方减少数据库节点的 CPU 核数，减少共享存储的能力等，所以这种扩大能力咱们称之为垂直扩大或叫做 Scale up。

最左边这个架构称为 Shared Nothing 架构，或者叫分布式架构，每个数据库实例和单机数据库相似，有本人的存储和计算资源，每个数据库实例都是一个独立的数据库。然而，这些数据库通过肯定的 MetaData 和字典表的治理，实现对用户来看就是一个数据库。每一个数据库实例其实治理一个分片数据库，存储一部分数据库的数据，相互之间是逻辑和物理的隔离，所以称之为是 Shared Nothing 架构。其次要特点是当波及多个分片数据库时，须要执行分布式的 SQL 计算，须要通过分布式事务放弃事务一致性，这种架构的长处是零碎能够程度扩大。

当用户须要更大的存储容量，更高的计算吞吐时，就能够通过减少数据库分片，也就是数据库节点的形式来晋升零碎容量性能，这种扩大形式称为程度扩大或叫 Scale out。

开源的 Polar DB 将是前面两种架构的交融。

（三）数据库系统的演进

接下来介绍一下数据库系统的演进，以及演进对咱们开源数据库产品的路线的影响。

无论是传统的商业数据库，还是咱们开源数据库 MySQL 或 PG，它解决的都是关系型的数据，也就是结构化的数据。其中又分为两种,RDBMS 也就是关系型数据库管理系统，次要解决在线的交易型负载，比方 ATM，商家的在线交易等等。

另外一个称为 Data Warehouse，也就是数据仓库。和 RDBMS 一样，都应用规范的 SQL 来解决数据，然而其负载波及大量数据，很多表计算非常复杂，典型的利用为 ETL 和在线剖析计算。

随着大数据的衰亡，Hadoop 平台的遍及，用户心愿解决的数据类型逐步多样化，比方工夫序列、天文数据、图、向量、文本等等。相应的数据处理产品涌现，它们区别于关系型数据库的最大差异是解决的数据类型和应用的解决语言是不一样的，以及它们和 Hadoop 等大数据平台的交融，带来了极高的可用性和扩展性，可能程度扩大到几十台甚至几百台、上千台服务器上。

受这些产品的启发，许多新型数据库系统开始转向分布式的高可用、高扩大，引入了共识协定，实现高可用，同时维持对数据库解决语言 SQL 的反对，典型例子有 Google 的 Spanner，尽管这些 NewSQL 实现了上述指标，然而其对 SQL 反对的残缺度上和开源数据库依然有肯定的差距，能够说只是后者的子集，须要投入很大的资源来欠缺这部分性能。

咱们的想法是是否在开源数据库的根底上引入分布式，引入共识协定，以及存储和计算层的弹性优化，实现 NewSQL 产品的高可用、高扩大、高弹性，然而保留对开源生态 SQL 的残缺反对，这是咱们开源路线图一个撑持的因素。

（四）业务痛点剖析

上面咱们来剖析一下以后看到的传统数据库或者集中数据库的业务痛点。

尽管有这些痛点，这些数据库依然可能服务用户的很多需要。然而随着互联网挪动 IoT 还有人机交互形式的一直演进，数据量和并发量一直地减少，逐步超过了单机数据库或集中式数据库的吞吐，比方超高并发，每秒上千上万的病房，对于大部分单机数据库来说是很难解决的，要么就就义性能，延时极大，并且随同着大量的超时查问，要么零碎可能就会被击垮。

集中式通过读写拆散和存储计算分布式，无限地晋升了应答这种并发的能力，然而依然存在单点解决能力有余的瓶颈。同样的，业务通过 ETL 产生的数据，对存储容量的需要逐步超过单机或集中式可能提供的限度，这些其实都能够通过分布式化的 Shared Nothing 的产品架构来应答。比方将查问事务摊派到多个计算节点，来成倍地晋升吞吐，退出更多节点来实现存储容量的程度扩大等。

不仅如此，通过简单大数据查问的散布化，在各个计算节点上并行运行，能够大大晋升单机或集中式对这些查问的解决效率。另外一方面，对于 MySQL 这样的 IoT 表来说，单表太大，也将影响查问性能。程度分区无效缩小单个数据库内的表的大小，防止查问性能受到比如说像缓存命中降落，Scan 效率升高的影响。

这些业务痛点其实都是提出了对分布式和程度扩大的需要，也是思考咱们技术路线图的一个因素。

（五）技术趋势：云化，分布式，资源共享

背景方面，咱们最初次要讨论一下数据库的技术趋势背景，但数据库技术很多，咱们不可能每一个点都笼罩，因而次要从云化的角度去了解，因为毕竟数据库产品当初的次要方向是云化。

从云化角度来看，首先数据库须要云化的技术是什么呢？

咱们得看云化的外围是什么，云化的外围就是要极大地缩小用户应用数据库的代价，或者叫 TCO（Total Cost of Ownership）。这个代价次要包含治理、运维、软件、硬件代价。基于这个外围，目前私有云数据库服务首要提供的就是管控性能，帮忙用户缩小和防止治理和运维的投入。同时，云化服务反对按需的软硬件配置，施展软硬件的最大效率，并保留实时的弹性，保障用户可能最无效的反对负载程度所需的资源。云化技术指标能够总结为简略易用，性价比最高。

其次数据库还须要分布式技术，不论是存储的分布式还是计算层，还是事务一致性层，甚至是故障复原和数据冗余方面，都须要分布式的技术。

业务层面上，当初的数据库系统须要撑持海量的数据业务所带来的高并发负载和混合负载。从云化角度，分布式能力是实时弹性所须要的外围能力，所以也是云化的必要条件。

最初的技术趋势是资源要共享，资源要隔离，实现按资源或按零碎分层的独立扩大。比方计算和存储的拆散，就能够实现数据库计算按需扩大，相应的如果存储容量须要减少，则只须要减少存储层的资源和节点、这种隔离和独立扩大能力能够扩大到内存，扩大到计算、存储网络，甚至数据数据库的一些外围解决能力，比方事务处理和简单查询处理等等。

在上述的趋势下，咱们来看云化数据库须要倒退的一些核心技术和个性。

首先数据库的高可用将成为重点发力的中央，因为这关系到云数据库的外围能力，即简化用户运维和治理的代价。如果一款数据库产品在任何故障下，用户都不掉线，查问都不受影响，那将极大晋升用户对产品的信念，简化背地治理的复杂度。同时如果数据库任何运维操作，比方备份复原、增删节点、Scale up 节点等等都不会中断负载，不仅用户在应用体验上更上一层楼，也为数据库调优、提供更加自在和更多维度的不便。比方 Scale up 操作，就能够更加动静地进行，使得硬件能力更加贴近负载。

其次另外一个技术趋势就是扩展性，蕴含各种能力的扩大，存储 / 计算事务和简单查问。比方事务存储是否能够按需扩大，比方并发数是否能够扩大，比方简单查问是否依据数据量扩大分布式计算能力，从而缩小查问延时。

另外一方面，这种扩大是否有瓶颈？比方为晋升事务吞吐，咱们个别会采纳 MVCC 机制，也就是所谓的多版本并发管制。在分布式下，MVCC 须要全局时钟或者全局排序的数列，产生全局数列将对扩大规模造成束缚，因为产生全局序列的服务可能就成为扩大的瓶颈。Google Spanner 的 Truetime 就是为解决这个瓶颈而设计的，咱们也设计了本人的时钟机制来应答这样的束缚。

在具备了极高的高可用和多层次的扩展性当前，弹性地引入将会为产品带来云化所必须的按资源应用的个性。以什么样的弹性颗粒度来进行弹性操作，以多快的速度提供资源的扩缩，用户负载和性能是否受到影响等等，都是弹性技术所须要面对的。

另外一个层面的弹性叫 Serverless，大家可能都据说过，或者看过别的产品在实现这方面的技术。所谓的 Serverless 实际上就是一个自动化的弹性，按需应用，不必时主动回收，这须要上述这些技术的综合，并且可能提供自动化的资源管理能力。

最初回到对用户应用性上的反对，用户常常曾经有很多利用跑在传统数据库或者跑在开源数据库产品上，然而它没有云化的根底，没有云化的这些技术的反对，比方利用和高效的管控，极致的高可用，分布式扩大以及 Serverless 弹性等。如何让用户的这些利用能够顺利简略地以较低的代价迁徙到云化产品上，将是产品应用性的首要思考。这其中维持 SQL 和生态的兼容性至关重要，比方用户利用的 SQL 程序都不须要改变，能够间接切换到云化的数据库，是否能够缩小大量的用户投入，来革新利用。比方用户的利用依然能够应用雷同生态类的工具，那么用户就不须要购买新的工具，省去为适配这些工具而须要的开发工作。

往往这些方面的一些应用性的缺失，是造成用户迁徙的次要阻力。那么兼容性和易迁移性也将是咱们思考的重点。

所以概括起来，咱们对云化数据库技术趋势就是 4 个方面，高可用、扩展性、弹性和兼容性。

（六）背景小结

基于以上背景，最初咱们总结出开源 Polar DB 应该走哪些路线，而后实现哪些指标，如上图所示。

在架构上咱们要反对分布式，技术上咱们要云化，同时解决客户的业务痛点，在生态上拥抱开源。

二、开源路线图

（一）开源路线图

基于背景、技术架构等方面的考量，咱们最终提出了开源产品的路线图。

首先开源的版本是基于 X-Consensus 共识协定的高可用集群版本，该版本主打的是高可用个性，让用户能够疾速自建一个和阿里团体内能力一样的数据库集群底座。

在实现极高吞吐的状况下，反对 Leader 跟 Follow 间的全局一致性，故障时保证数据不失落，并且 Follow 可能疾速地升为 Leader，对外进行服务，该版本解决用户对高可用的一些最基本、最初步的需要。

在第二阶段咱们将推出基于混合逻辑时钟 HLC 的高扩大分布式版，这个版本将实现 Shared Nothing 架构，反对数据库集群的程度扩大，解决单机存储容量受限问题，并反对高并发和高吞吐的事务处理。

通过分布式事务和分布式时钟 HLC 做到分布式全局统一，也就是说整个分布式数据库集群对外出现单机数据库的个性，用户利用像应用单机数据库那样取得 ACID 的反对。

在第三阶段，咱们把前两个阶段积攒的大部分能力以插件化的模式改写，包含分布式事务，分布式 SQL 计算，Sharding 和弹性，从而使得咱们的工作对社区内核的开发是垂直的，能够互补，这样咱们用户就能够疾速地降级数据库内核版本，同时保留咱们提供的分布式弹性和高可用的个性。

路线图简洁地体现了咱们对云化数据库的需要的了解，通过开发和社区互补的工作，实现对社区的加强，同时放弃社区的兼容，实现生态对立，最小化用户的应用和降级代价。

（二）X-Consensus 高可用集群版

上面介绍每一个阶段的次要特点。

咱们第一期开源进去的我的项目称为高可用集群版，顾名思义就是围绕高可用打造产品个性。

上图右边显示的是版本架构图，这个架构中包含多个组件，比方 Leader、Follower、Logger 数据库节点，其内核都是 PG。CM 集群治理组件，负责零碎和节点的启动、进行、集群操作等。

惟一外围的是称为 X -Consensus 的阿里自研的共识协定。在 X -Consensus 的反对下，PolarDB 实现了节点故障不能复原的时候，已提交数据不失落，并且保障对外一致性。

在实际层面上，PolarDB 依然应用 PG 自带的 Streaming Repliation，而是通过 X -Consensus 共识协定，保障节点间日志同步的位点的同步。这样做的益处是不扭转内核的数据复制协定，缩小对内核的侵入性批改，同时保护对工具生态的兼容。

这个抉择反映了咱们在开源我的项目中保持的准则，就是做社区的补充，做的性能最好是垂直于社区的性能和倒退，共识协定的稳定性和正确性是其外围能力。咱们应用的协定曾经被应用在阿里团体外部业务成千上万的后盾数据库，通过多年的低压测试和理论负载的打磨，置信其作为一个开源数据库协定被大家承受，必定也会成为这个方向的一个标杆产品，后续这个协定将会作为独立开源产品被推出。

除了稳定性和正确性的保障，本次开源我的项目还应用了该协定的多角色能力，反对 Leader、Follower 和 Logger。其中 Logger 没有数据库，数据只保留一份日志参加选举，然而不能被选举。Logger 角色的引入将缩小 1 / 3 的数据存储，同时保留共识协定在上面一些的能力，比方主动选主，比方网络性能抖动时候对事务提交的影响。Logger 能够参加选举，就能够在主动选主时疾速找出多数派，当网络性能抖动时，事务提交须要的日志同步，能够在 Logger 节点和 Follower 节点间进行抉择，防止一些网络抖动的影响。

共识协定保障了疾速和正确的选举，数据库高可用的一个次要指标 RTO（Recovery Time Objective），反映的是从故障产生、用户服务中断到服务复原的工夫长度，所以除了故障检测时间和选主工夫外，还包含升主工夫和服务复原工夫，二者和数据库的日志回放速度无关。

咱们的测试发现，当 Leader 禁受十分大并发的时候，Follower 尽管实时地接管到了日志，然而其日志回放是串行的，所以 Follower 的同步状态常常落后 Leader 很长时间，当这种压力继续的时候，这个落后工夫将继续减少，甚至超过一个小时。能够设想如果 Leader 这个时候故障不能复原，那么 Follower 须要复原一个小时工夫，能力实现升主并对外服务，也就是说 RTO 可能会达到一个多小时以上，这个是大部分在线数据库利用难以承受的。

所以依据这个需要，咱们的我的项目中实现了 Follower 的并行日志回放，在保障回放后果正确统一外，实现了 Leader 即便有很大的并发压力，比方几十万 TPMC 的 TPCC 负载，Follower 上的回放落后工夫依然维持在几秒甚至更小的工夫范畴之内。

所以这个版本咱们的次要个性就是打造高可用的数据库服务，包含共识协定的应用，多复制角色的反对，以及疾速和并行的日志回放。

（三）HLC 高扩大分布式版

下一个阶段，咱们开源的我的项目将会是一个 Shared Nothing 的分布式产品，但依然是基于第一期的高可用能力。这一期的外围是对 PG 内核的分布式扩大，使得扩大后的零碎可能最大限度地兼容单机 SQL 的能力，包含 DML、DDL 等，同时放弃对外出现单个数据库的 ACID 和 MVCC 的能力。

二者的目标就是保障分布式扩大后的这个零碎，对用户大部分利用依然像单机 PG 那样兼容，缩小用户迁徙和开发的工作量。

上图所示的架构中能够看到，分布式 Shared Nothing 零碎中呈现更多的组件，其中 data node 局部就是一期的高可用集群，只是有多个这样的集群，或称为基于 X -Consensus 复制组，每个 data node 复制组中有 Leader、Follower 和 Logger。通过 X -Consensus 共识协定保持数据一致性，每一个复制组负责整个数据库的局部数据，称为数据库分片。因为 data node 上实际上运行的独立的 PG 内核又称为数据库分片，这些数据库分片其实就是多个数据库实例，通过一个新的引入组件叫协调节点（Coordinator nodes），实现对外出现单个数据库的能力。

也就是对用户来说，看到的是一个数据库，一个字典表和一套用户表，然而在物理上每个数据库分片都存了用户表，只是一部分数据。用户查问先路由到协调节点，协调节点通过字典表和集群拓扑信息，判断查问须要波及的数据库分片，并发送查问到相应节点，取得各个节点的返回后果后，协调节点还将负责将后果组合返回给用户。

除了查问和表逻辑对外出现单个数据库个性外，散布数据库的 ACID 和数据一致性也须要保护。为此咱们引入另外两个组件，一个是分布式事务管理 TX Manager，保障一个事务在多个数据库实例上执行的时候满足 ACID。另外一个是混合逻辑时钟，叫 HOC，其目标是保障所有事务有一个全局的排序，从而实现分布式 Shard 的 MVCC，也就是实现分布式 Shard 的 SnapShot。

绝对于核心应用来说，采纳混合逻辑时钟的益处是混合时钟是分布式的，没有核心，在大规模集群状况下不会引入热点和瓶颈，同时能够防止新的组件，减少治理或者高可用的代价。

通过 HLC 对事务和操作进行工夫意义上的全局排序，不仅仅须要实现 HLC 的协定，同时须要数据库内核的反对。这个反对咱们在一期曾经实现了，是对 PG SnapShot 治理的加强，作为替换原来的沉闷事务列表，为提交序列数或者叫 CSN，作为 SnapShot，这样分布式的 HOC 和单机 PG 的 CSN 机制整合，实现了事务的全局排序，从而为实现分布式 MVCC 提供这个根底。当所有的事务都依照工夫排序时，那原有的 MVCC 机制就能够失常地运行，保证数据多版本反对，读写操作的并行执行。

在分布式 Shared Nothing 下，除了事务一致性外，如何分布式地解决 SQL 计算也是一个十分重要的个性。就像方才提到的，咱们首要的指标是最大限度地兼容单机的 SQL 能力，和事务一致性一起保障用户利用能够疾速在性能上适配分布式数据库系统，比方对 DDL 的反对，对简略 DML 的反对，对带子查问的简单 DML 的反对等等。

其次，须要在查问性能上进行优化，这两头的工作将十分地丰盛，比方发送查问到数据库分片节点的操作，须要思考是否整个或局部查问能够间接下推给某个或某些节点。查问打算在分布式下如何优化，如何联合分布式和单机的优化器的能力，如何在 data node 间交互，如何联合 MPP 和 SMP 等，都是咱们未来所须要思考的一些方向跟技术个性。

依据我的项目一期的根底，data node 曾经具备高可用，然而集群治理和分布式数据库的 MetaData 的治理都须要相似的高可用能力。咱们须要一个基于 X - Consensus 的共识协定的分布式计划，解决用户数据库协调逻辑，集群治理和 Meta 治理的对立的高可用问题，所以咱们将会在这个版本里实现分布式的高可用。

总体上，二期将推出一个具备残缺 SQL 和数据统一能力的分布式 Shared Nohting 数据库，其次要个性都是对现有单机 PG 的补充、加强和扩大，这些能力的大部分将在第三期成为插件，满足用户疾速降级的需要。

（四）Sharding 和 插件化版

第三期咱们将在后面两期根底上继续地加强分布式能力、云化能力以及 PG 社区兼容能力，上方的架构图反映了咱们在第三期的次要思路。

首先 DB Node 作为外围组件，提供单机数据库内核能力和分布式计算能力，同时治理每个 Shard 和跨 Shard 的事务，保持数据一致性，DB Node 本人通过 X - Consensus 共识协定复制数据到 Follower，保护节点级别的数据和逻辑冗余，有助于故障 Shard 疾速复原。每个 DB Node 的性能将通过对 PG 社区内核反对，加上分布式和高可用的插件的 Patch 实现这些性能。

在 DB node 上，咱们保护一个 PolarDB 服务层，提供像集群治理，各种运维操作，负载路由以及核心时钟，是一个 Option 的需要。绝对独立的服务层将有助于用户利用的对接，不受内核降级变动的影响，服务层能够随环境变动，针对不同云提供商和专有云来进行提供反对。

第三期次要的加强体现在以下几个方面。首先咱们增强了 Sharding，提供了细粒度的 Sharding 能力，细粒度 Sharding 次要增强了 PG 原生内核绝对单机化的架构，计算存储绝对耦合，不利于云化和分布式下弹性和扩大治理。通过细粒度 Sharding，使得用户表在存储层实现肯定水平上的隔离，反对在线的 Shard 迁徙，进一步晋升分布式的能力和云化弹性能力。

同时，通过统一化组件，将协调节点和 data node 合二为一，成为对立的 DB Node，和数据库相干的性能在一个组件外面提供，使得云化部署和治理更加的简洁。最初通过分布式和 Sharding 能力的插件化，放弃对社区版本的兼容，保障用户能够疾速地降级。

至此，Polar DB 开源我的项目通过三步演进，实现了对 PG 内核的分布式扩大，保障分布式一致性，同时兼容 PG SQL 能力和内核版本的降级，具备云化的弹性和治理的简洁性。当然，后续依然有很大的优化空间和很多个性会继续推出，比方分布式计算的继续优化、混合负载、HTTP 等。

（五）路线图小结

最初，用下图来小结咱们路线图的指标和心愿达成的方向。

咱们冀望开源 PolarDB 是一个高扩大分布式、细粒度、弹性、基于共享协定的高可用，以及易于兼容社区的插件化，每一个指标都反映了咱们对云化数据库根底需要的了解。

三、凋谢问题

最初有三个绝对凋谢的问题。

第一个问题是对于分布式和集中式数据库的市场的思考，从集体角度来看，传统数据库以集中式为主，市场也是如此，未来在很长时间内集中式依然会是主体。分布式在欠缺性能、构建生态上会一直地提高，能够占据肯定的市场份额。如果分布式可能兼容集中式的模式，那么分布式产品既能够当做集中式来应用，还能够按需扩大成分布式，那么更多市场份额就能够期待，这也是咱们为什么抉择把开源产品做成分布式次要的起因。

第二个问题是对于分布式和计算存储拆散的关系，集体了解二者是不抵触的，是垂直的关系。散布零碎是能够应用集中式的存储，甚至更加狭义地讲，很多云设施能够当成集中式来应用，比方云的块存储，对象存储等等。分布式能够通过本身的扩展性，更加无效地利用这些云存储的带宽和 IOPS，所以咱们的分布式开源产品未来也会做针对存储计算拆散，或者是利用云存储这样的架构的优化跟晋升。

第三个问题是对于扩大分布式数据库生态，咱们既然曾经有了分布式数据库，它人造就具备一致性，扩展性和分布式计算等能力。那么咱们是否能够通过新的数据拜访接口和引入新的用户定义计算性能，来扩大它所能反对的服务能力，比方将它扩大成其余服务的存储系统，扩大成其余服务的计算执行零碎，这些都是十分值得咱们去思考的，然而前提条件是咱们先打造出一个残缺、功能完善、稳固的开源分布式数据库，这样在此基础上，咱们就能够做更多更加有意思的多生态的工作。

原文链接
本文为阿里云原创内容，未经容许不得转载。