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

作者 | 张秋剑&＃xff0c;天云数据上海副总经理

责编 | 唐小引

头图 | CSDN 下载自东方 IC

出品 | CSDN&＃xff08;ID&＃xff1a;CSDNnews&＃xff09;

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

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

PostgreSQL 的前世今生

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

图片来源&＃xff1a;维基百科

Michael Stonebraker&＃xff0c;2014 图灵奖获得者&＃xff0c;PostgreSQL 数据库创始人。目前数据库领域一共有四位获得图灵奖&＃xff1a;

• 1973 年 Bachman&＃xff08;数据库与网状数据库&＃xff09;

• 1981 年 Codd&＃xff08;关系数据库&＃xff09;

• 1998 年 Gray&＃xff08;数据库与事务处理&＃xff09;

伯克利分校是 Postgres 的摇篮

&＃xff08;图&＃xff1a;伯克利分校著名地标萨瑟门&＃xff0c;CSDN 下载自东方 IC&＃xff09;

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

基于 PostgreSQL 的开源项目分支

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

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

分布式 PostgreSQL-X2 架构介绍

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

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

• 支持复杂的 SQL 和跨节点 JOIN&＃xff1b;

• 全局事务的强一致性&＃xff1b;

• 支持 Read commited 事务隔离级别&＃xff1b;

• 几乎支持所有单机数据库的 DDL 语句&＃xff1b;

• 支持跨节点的视图&＃xff1b;

• 支持跨节点的存储过程。

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

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

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

从上图的 X2 架构我们可以看到&＃xff0c;X2 主要由三个部分组成&＃xff1a;

• GTM&＃xff1a;全局事务管理&＃xff0c;提供全局事务的服务&＃xff1b;

• Coordinator&＃xff1a;存储全局的元数据&＃xff0c;接受用户请求&＃xff0c;负责生成并执行全局查询计划&＃xff08;全局查询计划由若干局部查询计划组成&＃xff0c;执行时将局部查询计划分发给 datanode&＃xff09;&＃xff1b;

• Datanode&＃xff1a;存储本地的元数据&＃xff0c;接受并执行 coordinator 的局部查询计划&＃xff08;局部查询计划也是 SQL&＃xff09;。

分布式 PostgreSQL-X2 的 CAP 分析

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

首先&＃xff0c;在一致性上&＃xff0c;PostgreSQL-X2 采用 GTM 来实现&＃xff1a;

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

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

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

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

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

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

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

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

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

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

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

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

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

我们已经提到数据库已经可以分为几类有&＃xff1a;

数据库经过 40 年的发展&＃xff0c;经过从 RDBMS 到 MPP 再到 NoSQL 数库&＃xff0c;如今我们开始关注 NewSQL 数据库。每个阶段的特点是怎样的呢&＃xff1f;

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

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

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

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

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

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

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

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

• 索引&＃xff0c;无法有效使用索引 —>Ad Hoc Query&＃xff1b;

• 协处理器无法分散计算任务 —>大表的 Join 查询&＃xff1b;

• SQL 以外的分析查询 —>Data Science / Machine Learning&＃xff1b;

• 访问其他数据源 —>和现有 Hadoop 数据联合查询&＃xff08;多源异构&＃xff09;&＃xff1b;

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

于是 NewSQL 呼之欲出。

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

一、Google F1/Spanner

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

F1 有如下特点&＃xff1a;

• 7×24 高可用。哪怕某一个数据中心停止运转&＃xff0c;仍然可用&＃xff1b;

• 可以同时提供强一致性和弱一致&＃xff1b;

• 可扩展&＃xff1b;

• 支持 SQL&＃xff1b;

• 事务提交延迟 50-100ms&＃xff0c;读延迟 5-10ms&＃xff0c;高吞吐。

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

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

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

二、F1 Query 对于 NewSQL 的奠基

2018 年&＃xff0c;Google 发表了论文“F1 Query&＃xff1a;Declarative Querying at Scale”&＃xff0c;意味着对 F1/Spanner 架构的升级。解决了如下几个核心问题&＃xff1a;

• 一是&＃xff0c;多种异构的存储平台&＃xff08;Bigtable,Spanner,Google Spreadsheets 等&＃xff09;共存&＃xff1b;

• 二是&＃xff0c;不同存储平台上的计算不统一&＃xff1b;

• 三是&＃xff0c;复杂的商业逻辑开始需要实时的分析和数据处理&＃xff08;HTAP&＃xff09;。

于是 F1 数据库延伸成了这样一种数据库&＃xff1a;

• 第一&＃xff0c;它是独立计算层&＃xff0c;底层对接了不同的数据源&＃xff1b;

• 第二&＃xff0c;它试图统一 OLTP、OLAP 和 ETL 的 Workload&＃xff1b;

• 第三&＃xff0c;它也是一个完整的 ETL 平台&＃xff1b;

• 第四&＃xff0c;它推出了几种访问数据的新形式&＃xff0c;UDF、UDA 和 TVF SQL&＃xff1b;

• 第五&＃xff0c;Shading-nothing&＃xff0c;这个之后会详细介绍。

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

三、NoSQL 谢幕&＃xff0c;NewSQL 登场

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

NewSQL 是指这样一类新式的关系型数据库管理系统&＃xff0c;针对 OLTP&＃xff08;读-写&＃xff09;工作负载&＃xff0c;追求提供和 NoSQL 系统相同的扩展性能&＃xff0c;且仍然保持 ACID 和 SQL 等特性&＃xff08;scalable and ACID and (relational and/or sql -access)&＃xff09;。

NewSQL 一经问世&＃xff0c;发展至今&＃xff0c;已经形成一个庞大的技术 family 了&＃xff1a;

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

一、分布式架构

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

• 客户端通过不同的接口访问形式&＃xff0c;直接访问主服务节点服务&＃xff1b;

• 主服务节点收到服务请求进行分析处理&＃xff0c;分配到不同的分配服务节点执行&＃xff1b;

• 分片服务节点收到执行请求&＃xff0c;进行 SQL 解析处理并执行 SQL 计划&＃xff1b;

• SQL 执行服务底层存储数据进行处理访问&＃xff0c;并反回处理结果&＃xff1b;

• 通过 Raft 协议确保服务之间数据同步&＃xff1b;

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

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

二、从分库分表走向 Sharding 与 Partition&＃xff08;分片与分区&＃xff09;

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

数据分区

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

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

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

数据分片

在分布式存储系统中&＃xff0c;数据需要分散存储在多台设备上&＃xff0c;数据分片&＃xff08;Sharding&＃xff09;就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的&＃xff1a;

• 分布均匀&＃xff0c;即每台设备上的数据量要尽可能相近&＃xff1b;

• 负载均衡&＃xff0c;即每台设备上的请求量要尽可能相近&＃xff1b;

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

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

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

在 Raft 中三种角色&＃xff1a;

Leader&＃xff1a;负责接收客户端的请求&＃xff0c;将日志复制到其他节点并告知其他节点何时应用这些日志是安全的&＃xff1b;

Candidate&＃xff1a;用于选举 Leader 的一种角色&＃xff1b;

Follower&＃xff1a;负责响应来自 Leader 或者 Candidate 的请求。

• 所有节点初始状态都是 Follower 角色&＃xff1b;

• 超时时间内没有收到 Leader 的请求则转换为 Candidate 进行选举&＃xff1b;

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

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

Raft 状态机&＃xff1a;

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

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

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

四、分布式事务

• 事务开始&＃xff0c;记录事务唯一 ID&＃xff0c;执行操作&＃xff0c;记录修改的 shard&＃xff0c;执行预提交动作&＃xff0c;提交或回滚&＃xff1b;
  

• 写入时当前采用锁机制&＃xff1b;

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

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

五、存储层——KV 存储

在存储方面&＃xff0c;我们有两种选择&＃xff1a;

• 堆存&＃xff1a;数据可以通过 key 获取&＃xff0c;同时可以直接读取数据&＃xff1b;

• 非堆存&＃xff1a;数据只能通过 key 来获取&＃xff0c;无法直接读取到数据。

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

• 客户端通过不同的接口访问形式&＃xff0c;直接访问主服务节点服务&＃xff1b;

• 主服务节点收到服务请求进行分析处理&＃xff0c;分配到不同的分配服务节点执行&＃xff1b;

• 分片服务节点收到执行请求&＃xff0c;进行 sql 解析处理并执行 SQL 计划&＃xff1b;

• SQL 执行服务底层存储数据进行处理访问&＃xff0c;并反回处理结果&＃xff1b;

• Zookeeper 保证相关服务应用的高可用&＃xff1b;

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

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

六、多源异构与数据邦联

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

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

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

综合以上六点&＃xff0c;通过对 NewSQL 的&＃xff1a;

• 分布式架构&＃xff1b;

• 数据的分区分片&＃xff1b;

• 数据同步与一致性&＃xff1b;

• 分布式事务&＃xff1b;

• 存储层&＃xff0c;KV 存储设计&＃xff1b;

• 数据库多源异构。

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

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

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

推荐阅读

• 一文带你认识keepalived&＃xff0c;再带你通关LVS&＃43;Keepalived&＃xff01;

• 那个分分钟处理 10 亿节点图计算的 Plato&＃xff0c;现在怎么样了&＃xff1f;
  

• “谷歌杀手”发明者&＃xff0c;科学天才 Wolfram

• 数据库激荡 40 年&＃xff0c;深入解析 PostgreSQL、NewSQL 演进历程

• 超详细&＃xff01;一文告诉你 SparkStreaming 如何整合 Kafka &＃xff01;附代码可实践

• 5分钟&＃xff01;就能学会以太坊 JSON API 基础知识&＃xff01;

  真香&＃xff0c;朕在看了&＃xff01;