数据库激荡 40 年，深入解析 PostgreSQL、NewSQL 演进历程

作者|张秋剑，天云数据上海副总经理

责编|唐小引

出品|CSDN（ID：CSDNnews）

近日，有传闻PostgreSQL会发布13版本，这是去年9月发布12版本之后，PG社区紧锣密鼓的又一大动作，包括提升查询性能，特别是对大数据集，总的空间利用率等方面。同时，国内以华为GaussDB200从PostgreSQL9中继承而来，PostgreSQL在中国的生态变得空前火热。

这与近两年来以GoogleF1理论为代表的NewSQL数据库一起，形成了数据库在这个时代的两支牛角，气势如虹地改变着TI数据中心架构的新世界。我们今天就来“庖丁解牛”一把，看看两种技术路线的不同之处。

PostgreSQL的前世今生

PostgreSQL是一个功能强大的开源对象关系型数据库系统，它使用和扩展了SQL语言，并结合了许多安全存储和扩展最复杂数据工作负载的功能。PostgreSQL的起源可以追溯到1986年，作为加州大学伯克利分校POSTGRES项目的一部分，并且在核心平台上进行了30多年的积极开发。直到2019年9月，已经正式发布到了12版本。

MichaelStonebraker，2014图灵奖获得者，PostgreSQL数据库创始人。目前数据库领域一共有四位获得图灵奖：

1973年Bachman（数据库与网状数据库）

1981年Codd（关系数据库）

1998年Gray（数据库与事务处理）

伯克利分校是Postgres的摇篮

（图：伯克利分校著名地标萨瑟门，CSDN下载自东方IC）

PostgreSQL的特点可以用以下这张图来概括，PostgreSQL的架构最合适做企业级数据库。

基于PostgreSQL的开源项目分支

述说完了PostgreSQL的历史，我们来聊聊PostgreSQL在开源社区世界的发展，我们知道，数据库近40年来的发展，基本上是从RDBMS到OLTP/OLAP分离，再到分布式数据库发展的这样一个历程。

PostgreSQL的历程也是如此，从PostgreSQL内核开始，也经历了OLTP分支、OLAP分支，再到大势所趋，两者重新融合，往混合OLA/TP的分布式数据库方向演进。

分布式PostgreSQL-X2架构介绍

既然PostgreSQL已经发展到了混布阶段，那么我们就直接从本文主旨开讲，看一看X2架构的特点。

首先，X2是基于PostgreSQL源代码改造成的分布式数据库，所以几乎拥有与单机数据库的所有功能：

支持复杂的SQL和跨节点JOIN；

全局事务的强一致性；

支持Readcommited事务隔离级别；

几乎支持所有单机数据库的DDL语句；

支持跨节点的视图；

支持跨节点的存储过程。

其次，X2主要目的实现数据是水平分片，也就是说需要基于分库分表来解决数据线性扩展的问题。

再次，X2针对OLAP是shared-nothing架构，所以是一种MPP的技术原理，可以实现ETL的数仓加工。

最后，API完全兼容，外部应用程序可以透明的访问Postgres-X2，原先的jdbc等不同编程语言的驱动也基本不需要修改就可以访问Postgres-X2。

从上图的X2架构我们可以看到，X2主要由三个部分组成：

GTM：全局事务管理，提供全局事务的服务；

Coordinator：存储全局的元数据，接受用户请求，负责生成并执行全局查询计划（全局查询计划由若干局部查询计划组成，执行时将局部查询计划分发给datanode）；

Datanode：存储本地的元数据，接受并执行coordinator的局部查询计划（局部查询计划也是SQL）。

分布式PostgreSQL-X2的CAP分析

我们知道CAP原理是考量一个数据库标高的评价标准，在RDBMS时代，Oracle、MSSQLServer都能较好地接近CAP。在分布式数据库时代，CAP理论依然是我们评价的主要工具。AP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partitiontolerance）。CAP原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

首先，在一致性上，PostgreSQL-X2采用GTM来实现：

GTM对事务强一致的保护是比肩传统RDBMS的，这一点上具备生产级。与2PC和MVCC相比，有先进之处。然而，总体开销会比较大，如果是巨大的互联网应用场景，动作上亿的并发访问，性能难于优于MySQL。

2PC又称两阶段提交（two-phasecommitprotocol）,2pc是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。

MVCC英文全称为Multi-VersionConcurrencyControl,翻译为中文即多版本并发控制。MVCC的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。

客观上，我们认为它就是乐观锁的一整个实现方式，就是每行都有版本号，保存时根据版本号决定是否成功。

在可扩展性方面，Postgres-X2的扩容，可以在Coordinator和Datanode两个方面同时进行扩容。

Postgres-X2符合分布式数据库线性扩展的标准，在x86横行的时代，通过横向对机器的方式扩展计算资源和存储资源是分布式的核心理念，在这一点上，Postgres-X2也是这么做的。

但是，Postgres本身的问题是数据量不能支持很大，数据量在40个TB~200TB，做大型数仓仓库，性能随数据量增大，节点数增多，而出现衰减，不能够完全跟随线性扩展做线性性能叠加。这是容易被诟病的一点。

再一个，不能够很好地支持在线热插拔，热添加。如果新增节点，需要做停机重启，这样的话，实时ODS这一类的应用就不能够在Postgres-X2构建的OLAP上应用。

分区容错性不是PostgresSQL主要考虑的问题。因为多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

上图中，G1和G2是两台跨区的服务器。G1向G2发送一条消息，G2可能无法收到。系统设计的时候，必须考虑到这种情况。这种情况，目前主要是大型云厂商如：AmazonQWSS3、GoogleSpanner和阿里云的OceanBase去着重打造。Postgres-X2我们只从数据中心的高可用性上探讨：

高可用方面，GTM不像Greenplum只有一个master节点，不适合OLTP业务。虽然Postgres-X2本身也没有自动的高可用性，但可以通过SPOF（singlepointoffailure）分析，根据不同的业务情况进行高可用建设，例如上图是采用Primary–Standby的方式来构建高可用架构。另外，原来的Postgres-XC的D-Node间不能传数据，数据需要汇聚到C节点进行处理Postgres-X2之后允许D-Node间进行数据传输。

以上，我们算是比较全面的了解了PostgresSQL和他的分布式项目Postgres-X2，我们可以总结一下：

在“从数据库技术的40年发展历程看新征程”一文中，我们通过回顾数据库的发展史，重新理解了数据库的定义——数据库就是一个存放数据的仓库，这个仓库按照一定的数据结构（数据结构是指数据的组织形式或数据之间的联系）来组织存储的，我们可以通过数据库提供的多种方法来管理数据库里的数据。我们的程序都是在内存中运行的，一旦程序运行结束或者计算机断电，程序运行中的数据都会丢失,所以我们就需要将一些程序运行的数据持久化到硬盘之中，以确保数据的安全性。说白了，数据库就是存储数据的仓库。

我们已经提到数据库已经可以分为几类有：

RDBMS——关系型数据库的优点是：事务、索引、关联、强一致性，其缺点是：有限的扩展能力、有限的可用性、数据结构取决于表空间；

MPP——大规模并行计算数据库的优点为扩展性强、事务、索引、关联、可调一致性，缺点：应用级切分、数据结构取决于表空间；

NoSQL——超越关系型数据库，数据库其优点在于扩展性强、可调一致性、灵活的数据结构，而缺点是事务支持差、索引支持差、SQL支持差。

最经典的是传统关系型OLTP数据库，其主要用于事务处理的结构化数据库，典型例子是企业的转账记账、订单以及商品库存管理等。其面临的核心挑战是高并发、高可用以及高性能下的数据正确性和一致性。

其次是NoSQL数据库及专用型数据库，其主要用于存储和处理非结构化或半结构化数据（如文档，图，时序、时空，K-V），不强制数据的一致性，以此换来系统的水平拓展、吞吐能力的提升。

再者是分析型数据库(On-LineAnalyticProcessing，OLAP)，其应用场景就是海量的数据、数据类型复杂以及分析条件复杂的情况，能够支持深度智能化分析。其面临的挑战主要是高性能、分析深度、与TP数据库的联动，以及与NoSQL数据库的联动。

除了数据的核心引擎之外，还有数据库外围的服务和管理类工具，比如数据传输、数据备份以及数据管理等。

NoSQL数据库解决了扩展性，高并发访问，但还有很多未尽如人意之处，比如：

索引，无法有效使用索引—AdHocQuery；

协处理器无法分散计算任务—大表的Join查询；

SQL以外的分析查询—DataScience/MachineLearning；

访问其他数据源—和现有Hadoop数据联合查询（多源异构）；

交互式分析—复杂SQL查询的性能问题。

于是NewSQL呼之欲出。

要说NewSQL数据库，我们要先从Google的F1/Spanner大规模分布式数据库说起。

一、GoogleF1/Spanner

和众多互联网公司一样，在早期Google大量使用了Mysql。Mysql是单机的，可以用Master-Slave来容错，分区来扩展。但是需要大量的手工运维工作，有很多的限制。因此Google开发了一个可容错可扩展的RDBMS——F1。和一般的分布式数据库不同，F1对应RDMS应有的功能，毫不妥协。起初F1是基于MySQL的，不过会逐渐迁移到Spanner。

F1有如下特点：

7×24高可用。哪怕某一个数据中心停止运转，仍然可用；

可以同时提供强一致性和弱一致；

可扩展；

支持SQL；

事务提交延迟50-100ms，读延迟5-10ms，高吞吐。

Spanner是Google的全球级的分布式数据库(Globally-DistributedDatabase)。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数以百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。

Spanner是个可扩展、多版本、全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。Spanner能做到这些，离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个核心的功能：无锁读事务，原子schema修改，读历史数据无block。

由于F1/Spanner并不开源，通过现有公开资料仅仅只能窥得F1/Spanner的沧海一粟，所以我们主要通过Google的公开资料的学习和发展自身，这比拿来主义的PostgreSQL要难能可贵的多。

二、F1Query对于NewSQL的奠基

2018年，Google发表了论文“F1Query：DeclarativeQueryingatScale”，意味着对F1/Spanner架构的升级。解决了如下几个核心问题：

一是，多种异构的存储平台（Bigtable,Spanner,GoogleSpreadsheets等）共存；

二是，不同存储平台上的计算不统一；

三是，复杂的商业逻辑开始需要实时的分析和数据处理（HTAP）。

于是F1数据库延伸成了这样一种数据库：

第一，它是独立计算层，底层对接了不同的数据源；

第二，它试图统一OLTP、OLAP和ETL的Workload；

第三，它也是一个完整的ETL平台；

第四，它推出了几种访问数据的新形式，UDF、UDA和TVFSQL；

第五，Shading-nothing，这个之后会详细介绍。

一种数据，在完美融合CAP原理之后，又破天荒的解决了同时支持OLTP、OLAP、ETL三种场景的数据库使用。可以说给我们带来了一片“新”天地，因为开创了数据库的“新”纪元。这个“新”，被451Group的分析师MatthewAslett命名为“NewSQL”。

三、NoSQL谢幕，NewSQL登场

NewSQL一词是由451Group的分析师MatthewAslett在研究论文中提出的。它代指对老牌数据库厂商做出挑战的一类新型数据库系统。NewSQL是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。

NewSQL是指这样一类新式的关系型数据库管理系统，针对OLTP（读-写）工作负载，追求提供和NoSQL系统相同的扩展性能，且仍然保持ACID和SQL等特性（scalableandACIDand(relationaland/orsql-access)）。

NewSQL一经问世，发展至今，已经形成一个庞大的技术family了：

通过上文我们可以知道，NewSQL的优势在于SQL的支持能力、扩展性、实时性和事务的处理能力。在NewSQL蓬勃发展的前提下，许多新兴技术公司开始打造自己的新一代分布式数据库，其设计理念：

一、分布式架构

通过主节点下发任务的模式，每个节点都可以提供服务，在扩展性上，Master不会是瓶颈。

客户端通过不同的接口访问形式，直接访问主服务节点服务；

主服务节点收到服务请求进行分析处理，分配到不同的分配服务节点执行；

分片服务节点收到执行请求，进行SQL解析处理并执行SQL计划；

SQL执行服务底层存储数据进行处理访问，并反回处理结果；

通过Raft协议确保服务之间数据同步；

存储根据AP、TP分为共享存储和非共享存储。

而与之相比较，PostgreSQL现在的分布式都是MPP的架构，sharenothing，存在增加、减少节点数据重新分配的问题。

二、从分库分表走向Sharding与Partition（分片与分区）

通过我们前面对PostgreSQL的解读，数据分库分表是一种被迫的选择，无奈之举，如果能够不做分库分表，就尽量不要做这方面的设计，因为会对业务提出要求，或者改动业务。所以，我们在NewSQL的设计上，要多做Sharding与Partition（分片与分区）的设计。

数据分区

分区就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的。

什么时候考虑使用分区呢？当一张表的查询速度已经慢到影响使用的时候，数据量大，SQL经过优化，表中的数据是分段的，或者对数据的操作往往只涉及一部分数据，而不是所有的数据。

分区解决的问题主要是可以提升查询效率。

数据分片

在分布式存储系统中，数据需要分散存储在多台设备上，数据分片（Sharding）就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的：

分布均匀，即每台设备上的数据量要尽可能相近；

负载均衡，即每台设备上的请求量要尽可能相近；

扩缩容时产生的数据迁移尽可能少。

三、数据同步与一致性——Raft/Paxos

目前主流的NewSQL数据库的数据同步是基于Raft协议的。

在Raft中三种角色：

Leader：负责接收客户端的请求，将日志复制到其他节点并告知其他节点何时应用这些日志是安全的；

Candidate：用于选举Leader的一种角色；

Follower：负责响应来自Leader或者Candidate的请求。

所有节点初始状态都是Follower角色；

超时时间内没有收到Leader的请求则转换为Candidate进行选举；

Candidate收到大多数节点的选票则转换为Leader；发现Leader或者收到更高任期的请求则转换为Follower；

Leader在收到更高任期的请求后转换为Follower。

Raft状态机：

所有一致性算法都会涉及到状态机，而状态机保证系统从一个一致的状态开始，以相同的顺序执行一些列指令最终会达到另一个一致的状态。

所有的节点以相同的顺序处理日志，那么最终x、y、z的值在多个节点中都是一致的。

在这一点上，PostgreSQL-X2的架构是以主备的模式来确定的。

四、分布式事务

事务开始，记录事务唯一ID，执行操作，记录修改的shard，执行预提交动作，提交或回滚；

写入时当前采用锁机制；

读取使用快照读取，存储层每次写入都是追加写入，通过覆盖机制进行数据变更。

这样的好处是，数据的鲜活性可以实时保证，数据更新插入和分析可以一起完成，像实时数仓、实时统计汇总计算就能够实现了。而在PostgreSQL的OLAP虽然可以通过批量或者插入的方式实现更新，但要人工做优化，持续投入人力干预，性能被动式保证。

五、存储层——KV存储

在存储方面，我们有两种选择：

堆存：数据可以通过key获取，同时可以直接读取数据；

非堆存：数据只能通过key来获取，无法直接读取到数据。

非堆存储只能通过key来获取数据，会导致不断的离散的读取，所以不能适应于AP的场景。

客户端通过不同的接口访问形式，直接访问主服务节点服务；

主服务节点收到服务请求进行分析处理，分配到不同的分配服务节点执行；

分片服务节点收到执行请求，进行sql解析处理并执行SQL计划；

SQL执行服务底层存储数据进行处理访问，并反回处理结果；

Zookeeper保证相关服务应用的高可用；

HDFS持久化底层存储数据，并利用三副本技术保证数据不丢失。

与之相比较，PostgreSQL是本地化存储，存储也可以分为列存和行存等。

六、多源异构与数据邦联

NewSQL的数据多源异构，要兼顾考虑对过去数据库的全面支持，尤其是NoSQL和Hadoop生态体系，因为毕竟这两者已经非常普及。

在多源异构方面，PostgreSQL是通过FDW支持多源异构，可访问Oracle、PG、MySQL、MongoDB等，对Hadoop体系和NoSQL支持力度低，效率和性能也较难做到极致。

七、基于NewSQL的分布式数据库实践

综合以上六点，通过对NewSQL的：

分布式架构；

数据的分区分片；

数据同步与一致性；

分布式事务；

存储层，KV存储设计；

数据库多源异构。

我们综合设计研发，推出了一款自主可控的国产分布式数据库——Hubble。Hubble同时支持OLTP和OLAP场景，即在同一份数据上，实现事务型处理的同时支持实时分析，省去了费时的ETL过程。

最后，将Hubble作为代表与PsostgreSQL-X2做一个横向分析，能够帮助我们更好地理解本文开篇所言——分布式数据库的两支牛角各自的技术路线。

作者简介：张秋剑，天云数据上海分公司副总经理，资深金融行业大数据技术架构专家。计算机科学技术硕士学位后，曾就职于IBM等公司，九三学社金融委员会委员。目前主要为银行、证券和保险等金融行业客户提供大数据平台及人工智能平台的规划和方案设计工作。曾在IEEE等期刊发表多篇论文。

☞开源激荡30年：从免费社区到价值数十亿美元公司

☞理解AI最伟大的成就之一：卷积神经网络的局限性

☞GitHub标星10,000+，Apache顶级项目ShardingSphere的开源之路

☞港科大郑光廷院士问诊未来，揭露AI最新应用与实践

☞大促下的智能运维挑战：阿里如何抗住“双11猫晚”？

☞以太坊2.0中的CustodyGame及MPC实现

☞很用心的为你写了9道MySQL面试题，建议收藏！