【技术硬核】庖丁解牛 | PostgreSQL与NewSQL大解析（一）

天云数据

于 2020-06-02 11:15:55 发布

阅读量569

点赞数

文章标签：数据库 sql

本文链接：https://blog.csdn.net/qq_39918081/article/details/106491944

版权

近日，有传闻PostgreSQL会发布13版本，这是去年9月发布12版本之后，PG社区紧锣密鼓的又一大动作，包括提升查询性能，特别是对大数据集，总的空间利用率等方面。同时，国内以华为GaussDB 200从PostgreSQL 9中继承而来，PostgreSQL在中国的生态变得空前火热。这与近两年来以Google F1理论为代表的NewSQL数据库一起，形成了数据库在这个时代的两支牛角，气势如虹地改变着TI数据中心架构的新世界。我们今天就来“庖丁解牛”一把，看看两种技术路线的不同之处。

在这里插入图片描述

一、PostgreSQL的前世今生

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

目前数据库领域一共有四位获得图灵奖
● 1973年Bachman（数据库与网状数据库）
● 1981年Codd（关系数据库）
● 1998年Gray（数据库与事务处理）

伯克利分校是Postgres的摇篮
在这里插入图片描述
PostgreSQL的特点可以用以下这张图来概括，PostgreSQL的架构最合适做企业级数据库。

二、基于PostgreSQL的开源项目分支

述说完了PostgreSQL的历史，我们来聊聊PostgreSQL在开源社区世界的发展，我们知道，数据库近40年来的发展，基本上是从RDBMS到OLTP/OLAP分离，再到分布式数据库发展的这样一个历程。PostgreSQL的历程也是如此，从PostgreSQL内核开始，也经历了OLTP分支、OLAP分支，再到大势所趋，两者重新融合，往混合OLA/TP的分布式数据库方向演进。
在这里插入图片描述

三、分布式PostgreSQL-X2架构介绍

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

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

● 支持复杂的SQL和跨节点JOIN
● 全局事务的强一致性
● 支持Read commited事务隔离级别
● 几乎支持所有单机数据库的DDL语句
● 支持跨节点的视图
● 支持跨节点的存储过程

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

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

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

在这里插入图片描述
从上图的X2架构我们可以看到，X2主要由三个部分组成：

1、GTM：全局事务管理，提供全局事务的服务
2、Coordinator：存储全局的元数据，接受用户请求，负责生成并执行全局查询计划（全局查询计划由若干局部查询计划组成，执行时将局部查询计划分发给datanode）
3、Datanode：存储本地的元数据，接受并执行coordinator的局部查询计划（局部查询计划也是SQL）

四、分布式PostgreSQL-X2的CAP分析）

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

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

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

在这里插入图片描述
MVCC英文全称为Multi-Version Concurrency Control,翻译为中文即多版本并发控制。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 可能无法收到。系统设计的时候，必须考虑到这种情况。这种情况，目前主要是大型云厂商如：Amazon QWS S3、Google Spanner和阿里云的OceanBase去着重打造。Postgres-X2我们只从数据中心的高可用性上探讨：
在这里插入图片描述
高可用方面，GTM不像Greenplum只有一个master节点，不适合OLTP业务。虽然Postgres-X2本身也没有自动的高可用性，但可以通过SPOF（single point of failure）分析，根据不同的业务情况进行高可用建设，例如上图是采用Primary–Standby的方式来构建高可用架构。另外，原来的Postgres-XC的D-Node间不能传数据，数据需要汇聚到C节点进行处理Postgres-X2之后允许D-Node间进行数据传输。