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，所以我们的分布式开源产品将来也会做针对存储计算分离，或者是利用云存储这样的架构的优化跟提升。

第三个问题是关于扩展分布式数据库生态，我们既然已经有了分布式数据库，它天然就具备一致性，扩展性和分布式计算等能力。那么我们是否可以通过新的数据访问接口和引入新的用户定义计算功能，来扩展它所能支持的服务能力，比如将它扩展成其他服务的存储系统，扩展成其他服务的计算执行系统，这些都是非常值得我们去思考的，但是前提条件是我们先打造出一个完整、功能完善、稳定的开源分布式数据库，这样在此基础上，我们就可以做更多更加有意思的多生态的工作。

原文链接

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