，2014 图灵奖获得者， 数据库创始人。目前数据库领域一共有四位获得图灵奖：
伯克利分校是 的摇篮
（图：伯克利分校著名地标萨瑟门，CSDN 下载自东方 IC）
的特点可以用以下这张图来概括， 的架构最合适做企业级数据库。
基于 的开源项目分支
述说完了 的历史，我们来聊聊 在开源社区世界的发展，我们知道，数据库近 40 年来的发展，基本上是从 RDBMS 到 OLTP/OLAP 分离，再到分布式数据库发展的这样一个历程。
的历程也是如此，从 内核开始，也经历了 OLTP 分支、OLAP 分支，再到大势所趋，两者重新融合，往混合 OLA/TP 的分布式数据库方向演进。
分布式 -X2 架构介绍
既然 已经发展到了混布阶段，那么我们就直接从本文主旨开讲，看一看 X2 架构的特点。
首先，X2 是基于 源代码改造成的分布式数据库，所以几乎拥有与单机数据库的所有功能：
其次，X2 主要目的实现数据是水平分片，也就是说需要基于分库分表来解决数据线性扩展的问题。
再次，X2 针对 OLAP 是 - 架构，所以是一种 MPP 的技术原理，可以实现 ETL 的数仓加工。
最后，API 完全兼容，外部应用程序可以透明的访问 -X2，原先的 jdbc 等不同编程语言的驱动也基本不需要修改就可以访问 -X2。
从上图的 X2 架构我们可以看到，X2 主要由三个部分组成：
分布式 -X2 的 CAP 分析
我们知道 CAP 原理是考量一个数据库标高的评价标准，在 RDBMS 时代，、MS 都能较好地接近 CAP。在分布式数据库时代，CAP 理论依然是我们评价的主要工具。AP 原则又称 CAP 定理，指的是在一个分布式系统中，一致性（）、可用性（）、分区容错性（ ）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
首先，在一致性上，-X2 采用 GTM 来实现：
GTM 对事务强一致的保护是比肩传统 RDBMS 的，这一点上具备生产级。与 2PC 和 MVCC 相比，有先进之处。然而，总体开销会比较大，如果是巨大的互联网应用场景，动作上亿的并发访问，性能难于优于 MySQL。
2PC 又称两阶段提交（two-phase ）,2pc 是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（）和 N 个参与者节点（）。
MVCC 英文全称为 Multi- ,翻译为中文即多版本并发控制。MVCC 的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。
客观上，我们认为它就是乐观锁的一整个实现方式，就是每行都有版本号，保存时根据版本号决定是否成功。
在可扩展性方面，-X2 的扩容，可以在 和 两个方面同时进行扩容。
-X2 符合分布式数据库线性扩展的标准，在 x86 横行的时代，通过横向对机器的方式扩展计算资源和存储资源是分布式的核心理念，在这一点上，-X2 也是这么做的。
但是， 本身的问题是数据量不能支持很大，数据量在 40 个 TB~200TB，做大型数仓仓库，性能随数据量增大，节点数增多，而出现衰减，不能够完全跟随线性扩展做线性性能叠加。这是容易被诟病的一点。
再一个，不能够很好地支持在线热插拔，热添加。如果新增节点，需要做停机重启，这样的话，实时 ODS 这一类的应用就不能够在 -X2 构建的 OLAP 上应用。
分区容错性不是 主要考虑的问题。因为多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。这种情况，目前主要是大型云厂商如： QWS S3、 和阿里云的 去着重打造。-X2 我们只从数据中心的高可用性上探讨：
高可用方面，GTM 不像 只有一个 节点，不适合 OLTP 业务。虽然 -X2 本身也没有自动的高可用性，但可以通过 SPOF（ point of ）分析，根据不同的业务情况进行高可用建设，例如上图是采用 – 的方式来构建高可用架构。另外，原来的 -XC 的 D-Node 间不能传数据sql数据库下载，数据需要汇聚到 C 节点进行处理 -X2 之后允许 D-Node 间进行数据传输。
以上，我们算是比较全面的了解了 和他的分布式项目 -X2，我们可以总结一下：
在“从数据库技术的 40 年发展历程看新征程”一文中，我们通过回顾数据库的发展史，重新理解了数据库的定义——数据库就是一个存放数据的仓库，这个仓库按照一定的数据结构（数据结构是指数据的组织形式或数据之间的联系）来组织存储的，我们可以通过数据库提供的多种方法来管理数据库里的数据。我们的程序都是在内存中运行的，一旦程序运行结束或者计算机断电，程序运行中的数据都会丢失,所以我们就需要将一些程序运行的数据持久化到硬盘之中，以确保数据的安全性。说白了，数据库就是存储数据的仓库。
我们已经提到数据库已经可以分为几类有：
数据库经过 40 年的发展，经过从 RDBMS 到 MPP 再到 NoSQL 数库，如今我们开始关注 数据库。每个阶段的特点是怎样的呢？
最经典的是传统关系型 OLTP 数据库，其主要用于事务处理的结构化数据库，典型例子是企业的转账记账、订单以及商品库存管理等。其面临的核心挑战是高并发、高可用以及高性能下的数据正确性和一致性。
其次是 NoSQL 数据库及专用型数据库，其主要用于存储和处理非结构化或半结构化数据（如文档，图，时序、时空，K-V），不强制数据的一致性，以此换来系统的水平拓展、吞吐能力的提升。
再者是分析型数据库(On-Line ，OLAP)，其应用场景就是海量的数据、数据类型复杂以及分析条件复杂的情况，能够支持深度智能化分析。其面临的挑战主要是高性能、分析深度、与 TP 数据库的联动，以及与 NoSQL 数据库的联动。
除了数据的核心引擎之外，还有数据库外围的服务和管理类工具，比如数据传输、数据备份以及数据管理等。
NoSQL 数据库解决了扩展性，高并发访问，但还有很多未尽如人意之处，比如：
于是 呼之欲出。
要说 数据库，我们要先从 的 F1/ 大规模分布式数据库说起。
一、 F1/
和众多互联网公司一样sql数据库下载，在早期 大量使用了 Mysql。Mysql 是单机的，可以用 -Slave 来容错，分区来扩展。但是需要大量的手工运维工作，有很多的限制。因此 开发了一个可容错可扩展的 RDBMS——F1。和一般的分布式数据库不同，F1 对应 RDMS 应有的功能，毫不妥协。起初 F1 是基于 MySQL 的，不过会逐渐迁移到 。
F1 有如下特点：
是 的全球级的分布式数据库(- )。 的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数以百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破 CAP 的枷锁，在三者之间完美平衡。
是个可扩展、多版本、全球分布式还支持同步复制的数据库。他是 的第一个可以全球扩展并且支持外部一致的事务。 能做到这些，离不开一个用 GPS 和原子钟实现的时间 API。这个 API 能将数据中心之间的时间同步精确到 10ms 以内。因此有几个核心的功能：无锁读事务，原子 修改，读历史数据无 block。
由于 F1/ 并不开源，通过现有公开资料仅仅只能窥得 F1/ 的沧海一粟，所以我们主要通过 的公开资料的学习和发展自身，这比拿来主义的 要难能可贵的多。
二、F1 Query 对于 的奠基
2018 年， 发表了论文“F1 Query： at Scale”，意味着对 F1/ 架构的升级。解决了如下几个核心问题：
于是 F1 数据库延伸成了这样一种数据库：
一种数据，在完美融合 CAP 原理之后，又破天荒的解决了同时支持 OLTP、OLAP、ETL 三种场景的数据库使用。可以说给我们带来了一片“新”天地，因为开创了数据库的“新”纪元。这个“新”，被 451 Group 的分析师 命名为“”。
三、NoSQL 谢幕， 登场
一词是由 451 Group 的分析师 在研究论文中提出的。它代指对老牌数据库厂商做出挑战的一类新型数据库系统。 是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有 NoSQL 对海量数据的存储管理能力，还保持了传统数据库支持 ACID 和 SQL 等特性。
是指这样一类新式的关系型数据库管理系统，针对 OLTP（读-写）工作负载，追求提供和 NoSQL 系统相同的扩展性能，且仍然保持 ACID 和 SQL 等特性（ and ACID and ( and/or sql -)）。
一经问世，发展至今，已经形成一个庞大的技术 了：
通过上文我们可以知道， 的优势在于 SQL 的支持能力、扩展性、实时性和事务的处理能力。在 蓬勃发展的前提下，许多新兴技术公司开始打造自己的新一代分布式数据库，其设计理念：
一、分布式架构
通过主节点下发任务的模式，每个节点都可以提供服务，在扩展性上， 不会是瓶颈。
而与之相比较， 现在的分布式都是 MPP 的架构，share ，存在增加、减少节点数据重新分配的问题。
二、从分库分表走向 与 （分片与分区）
通过我们前面对 的解读，数据分库分表是一种被迫的选择，无奈之举，如果能够不做分库分表，就尽量不要做这方面的设计，因为会对业务提出要求，或者改动业务。所以，我们在 的设计上，要多做 与 （分片与分区）的设计。
数据分区
分区就是把一张表的数据分成 N 个区块，在逻辑上看最终只是一张表，但底层是由 N 个物理区块组成的。
什么时候考虑使用分区呢？当一张表的查询速度已经慢到影响使用的时候，数据量大，SQL 经过优化，表中的数据是分段的，或者对数据的操作往往只涉及一部分数据，而不是所有的数据。
分区解决的问题主要是可以提升查询效率。
数据分片
在分布式存储系统中，数据需要分散存储在多台设备上，数据分片（）就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的：
三、数据同步与一致性 —— Raft/Paxos
目前主流的 数据库的数据同步是基于 Raft 协议的。
在 Raft 中三种角色：
：负责接收客户端的请求，将日志复制到其他节点并告知其他节点何时应用这些日志是安全的；
：用于选举 的一种角色；
：负责响应来自 或者 的请求。
Raft 状态机：
在这一点上，-X2 的架构是以主备的模式来确定的。
四、分布式事务
这样的好处是，数据的鲜活性可以实时保证，数据更新插入和分析可以一起完成，像实时数仓、实时统计汇总计算就能够实现了。而在 的 OLAP 虽然可以通过批量或者插入的方式实现更新，但要人工做优化，持续投入人力干预，性能被动式保证。
五、存储层——KV 存储
在存储方面，我们有两种选择：
非堆存储只能通过 key 来获取数据，会导致不断的离散的读取，所以不能适应于 AP 的场景。
与之相比较， 是本地化存储，存储也可以分为列存和行存等。
六、多源异构与数据邦联
的数据多源异构，要兼顾考虑对过去数据库的全面支持，尤其是 NoSQL 和 生态体系，因为毕竟这两者已经非常普及。
在多源异构方面， 是通过 FDW 支持多源异构，可访问 、PG、MySQL、 等，对 体系和 NoSQL 支持力度低，效率和性能也较难做到极致。
七、基于 的分布式数据库实践
综合以上六点，通过对 的：
我们综合设计研发，推出了一款自主可控的国产分布式数据库 —— 。 同时支持 OLTP 和 OLAP 场景，即在同一份数据上，实现事务型处理的同时支持实时分析，省去了费时的 ETL 过程。
最后，将 作为代表与 -X2 做一个横向分析，能够帮助我们更好地理解本文开篇所言 —— 分布式数据库的两支牛角各自的技术路线。
作者简介：张秋剑，天云数据上海分公司副总经理，资深金融行业大数据技术架构专家。计算机科学技术硕士学位后，曾就职于 IBM 等公司，九三学社金融委员会委员。目前主要为银行、证券和保险等金融行业客户提供大数据平台及人工智能平台的规划和方案设计工作。曾在 IEEE 等期刊发表多篇论文。
开源激荡 30 年：从免费社区到价值数十亿美元公司
理解 AI 最伟大的成就之一：卷积神经网络的局限性
标星 10,000+， 顶级项目 的开源之路
港科大郑光廷院士问诊未来，揭露 AI 最新应用与实践
大促下的智能运维挑战：阿里如何抗住“双11猫晚”？
以太坊2.0中的 Game及MPC实现
很用心的为你写了9道MySQL面试题，建议收藏！
限时特惠:本站持续每日更新海量各大内部创业课程，一年会员仅需要98元，全站资源免费下载
点击查看详情
站长微信:Jiucxh
