本文主要分享一下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的完整支持，这是我们开源路线图一个支撑的因素。

《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL开源路线图（2） https://developer.aliyun.com/article/1232546?spm=a2c6h.13148508.setting.15.5e4f4f0ecmbIFO