导语 | 每一个时间段总是一个新时代，新技术层出不穷使得数据库技术焕发新生。Spanner、CockroachDB、TDSQL 等分布式数据库正是这个时代的弄潮儿。本文由腾讯云数据库专家工程师 李海翔在 Techo TVP 开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」的《分布式数据库的演进》演讲分享整顿而成，带大家品尝分布式数据库架构、前沿技术和 TDSQL 技术实际，感触分布式数据库的技术之美。

一、分布式数据库架构

我明天所分享的内容次要集中在数据库技术层面，和腾讯近十年的分布式数据库技术倒退非亲非故，次要有三方面：第一是分布式数据库的历史倒退和演进；第二是分布式数据库里较外围的技术内容，包含相干的内容知识点；第三是腾讯 TDSQL 在前沿方面所做的工作。TDSQL 是一个基于 HTAP 的分布式数据库系统，尤其强调强统一。2017-2018 年咱们提出过“全时态数据库”的概念，过后提出实现了一个叫做 HTAC 的混合事务剖析处集群架构，HTAC 和 HTAP 十分靠近，在工程方面咱们称为 HTAC，用一个实践的名词来概括就是 HTAP（混合事务剖析解决零碎），所以在那时咱们就曾经推出本人的原创性产品，而这个产品这两年的演变始终专一于强一致性，在去年咱们推出了兼具实践与实际的产品，分明解释了“强统一”这个概念。该技术对应的产品，外部通过一段时间打磨后，载有该项技术的 TDSQL 将在 TDSQL 私有云等产品中很快推出。

1. 分布式系统经典架构概述
先来看第一局部，分布式数据库的倒退演进。这幅图在阐明什么？外面在谈一些基础架构：Shared Nothing、Shared Memory、Shared Disk、Shared Everything。这些是什么？最早从哪里来？硬件层面是做软件的根底，硬件层面的倒退决定着软件技术的倒退，硬件层面把一些根本的框架搭好后，数据库的软件或者说应用层、零碎层的软件都会在下面叠加，就像搭积木一样，一块一块地往上垒。对于数据库外部其实也是这样的，分模块、分档次，之后这些货色都能够搭建在一起。然而数据库有着紧耦合性较强的特点，搭在一起后就很难拆开，然而当初做分布式数据库的一个趋势是要尝试把这些货色拆分，再像搭积木一样往上垒，哪个中央须要什么样的组件，就去建设这样的组件，模块与模块之间要解耦，解耦之后更易搭建，把这个零碎搭得在未来更具扩展性。分布式数据库系统的底层根底是和硬件严密相干的。

2. 分布式系统架构经典支流技术
我从技术的角度展现一下数据库的代表技术。在这幅图中，第一个人是数据库界图灵奖的第二位得主——关系模型的创始人科德博士，他在 1970 年的时候以一篇论文奠定了关系型数据库的根底。1974 年时有两个典型的技术诞生，一个是 SQL 语言，另外一个是事务处理技术。50 多年前，数据库界第三位图灵奖得主 James Gray 开始钻研事务处理，并对失去了一系列的开创性的成绩，所以事务处理奠基于 70 年代，直至今日。同年，IBM 同样诞生了一个开创性的技术，就是咱们所熟知的 SQL，SQL 这个概念是从 IBM 在做数据库的钻研起就开始提出的结构化查询语言。

再往后，是 ER 模型，ER 模型是实体关系模型，可能帮忙咱们做数据库利用的建模。然而，在数据库技术的倒退过程当中呈现了很多模型，包含后面说的 1970 年之前的关系模型、层次模型，再往前的网状模型，这些模型和 ER 模型产生的初衷是一样的，都是要从数据、数据档次的角度与实体世界进行映射，以让数据世界具备表白、计算实体世界的能力。只不过 ER 模型在倒退过程中只被人们用于了关系建模（教科书撷取了精髓展现，读者的了解水平不再能全面粗浅），但它背地蕴含的内容其实和关系模型、层次模型是雷同的，如果咱们回顾历史还原其初衷，则能从历史当中看到的一些根本的货色。

到了 1980 年，数据库界呈现基于代价的查问优化技术，它可能较好的选出一个近乎最优的执行打算。尔后，数据库又演变出了基于火山模型的执行器，推动数据库的技术进一步倒退。从这副图中能够看出，数据库技术倒退基本上是从没有事务到有事务概念这条主线上推动的，到了 1993 年的时候有了 AP 和 TP 的分叉，这归功于科德博士，他除了提出关系模型，又提出了 OLAP 的概念——在线剖析事务处理，以前的主线就变成了 OLTP 和 OLAP 两条分支。

随着时光的持续推移，2014 年，有意思的事呈现了，一个并不是学术研究机构而是对行业的钻研机构——Gartner，推出一个概念：HTAP，冀望在事务型的零碎上加强剖析的性能。这个概念这几年大火，仿佛在补救事务型数据库的重事务处理弱剖析能力的缺点（概念分家，指导思想发生变化，看来还是有害处的）。人们总是有一个美妙志愿，在一个零碎内搞定所有的事件。这同人类的需要和一直变动的认知存在关系。

但在这之前，2012 年谷歌的 Spanner 零碎诞生了，它标记着人们从不要 SQL 到拥抱 SQL 拥抱数据库的事务处理技术，演变成了 New SQL 零碎。

前述这些技术，是数据库的经典技术，无论单机数据库还是分布式数据库，都基于这些基础性的技术。尽管 TDSQL 是一个分布式数据库，但外面 90% 甚至更多的根底外围性能来自于单机数据库系统，所以技术的演进其实是踏着后面的根底而一直演变的，分布式数据库的技术离不开后面咱们谈到的关系模型、事务处理等根底技术。因而我认为做分布式数据库离不开单机数据库系统，意识分布式数据库要先从单机数据库系统动手，单机数据库系统实际上就有了分布式数据库的五脏六腑，它曾经比拟全面。只是分布式数据库在根底技术之上，因零碎架构的变动，有了一些新挑战。

上面，咱们以 MySQL 的数据库系统架构为例，来分享单机数据库系统蕴含了哪些模块和组件。

左上角的 SQL 是一个入口，它执行完的后果在这个箱子里转了一圈后将后果返回用户，进入到数据库系统里。右边的是 MySQL Server，左边是它的存储引擎，实际上整个数据库能够分为三层：右边的 Server，左边的存储引擎，存储引擎上面和操作系统紧密结合的是和内部文件相干的一部分内容。Server 在接管用户的 SQL 语句并解析，就像编译器，对于 SQL 语句做解析失去一棵语法树，这棵语法树通过查问优化器的转换变成逻辑查问打算，再变成物理查问打算，过程中会做很多优化，就像子查问优化，表达式怎么去重、化简等工作。再往后它就要交给执行器去执行，执行器实际上和存储系统是严密绑定的，存储系统的两大部分，一部分是执行器，各种 SQL 语句的执行，DDL、DML、DQL 等，它的执行过程当中又受到横向的事务处理与它正交的组合，在事务处理零碎的管制之下，各种 SQL 语句高并发地执行，并通过各种模块。

模块从底层往上看，数据库系统最底层的是一个文件，因为它要存在操作系统上，而操作系统上是以文件为单位来组织数据的，所以大家能够看到最底层的是一些物理文件，物理文件有它的格局，格局上就有数据库本人定义的各种数据格式。数据能够分为两局部，一部分是用户数据，一部分是数据库系统本身要保护的日志数据，数据能够读入写出有物理的 IO 产生，其要和存储引擎，也就是执行器加存储系统打交道。数据被读入后进入内存，不同的数据库有其本人特定的数据格式，这须要 access 解析格局，初始面对的是一个一个物理页面，把它们先加载到缓存区里，而后做格局的转化，物理页面被解析成一个一个的记录和列，便于下层对它进行计算。当这些解析实现后，比方有两个客户端连进来，那就有读写同样数据的可能，因而有并发存在，就可能会产生数据异样，事务处理零碎这时候就要产生作用——防止数据异样、保证数据的一致性，通过计算之后再把后果通过 SQL Server 向上返回。作为一个分布式数据库系统而言，它离不开这个执行过程，也离不开这外面所蕴含的根底模块和组件。

数据库系统是倒退和逐步演进的。实际上晚期做单机数据库的大家都相熟主从架构，MySQL 的主从架构是基于逻辑和物理混合的，但更多是偏差逻辑地做主从架构的数据传输。而后纯正的单机数据库系统推动了一步，成为近似于散布的，物理节点曾经变成多个，然而一主多备，多备只能去做读，还不是纯正的分布式数据库系统，所以数据库系统实际上架构的倒退分成两代，第一代是纯的单机零碎，第二代是分布式系统，介于第一代和第二代之间就有这么一个过渡性的阶段，我把它称之为 1.5 代，然而它还归属于单机数据库系统，所以有了这样一个主从架构。典型的每一个数据库都做了基于物理日志的，像 Oracle、PG 流复制等，但 MySQL 基于逻辑日志这样的格局去做主从构造的。

时光推移到七八年前，亚马逊的 Aurora 零碎诞生，它实质上还是主从架构、一主多备式的，提高的中央在于做成了一个云上的存算拆散的零碎。所以 1.5 时代的产品，典型的代表是相似于晚期的主从 +Aurora 这种架构，这是一个过渡时代。再往后咱们会进入到真正的分布式数据库时代，它典型的标记是什么？是多写，在每一个节点上都平等地看待，能够在每一个节点上写，这外面的技术就又有多种，有的是伪的分布式，其把事务的所有写操作集中在繁多的节点下来做，真的分布式是利用分布式并发拜访控制算法，在每一个节点下来做数据一致性的保障。

小结

数据库根本架构的演进就是经验了这么一个过程，总结一下，反过来从技术角度来看到底是什么因素在推动分布式数据库系统的演进。其实数据库系统有一些外在的、本质性的需要在推动它，咱们以前说数据库系统外面有“三高一易”，高牢靠、高可用、高性能、易用性等等，这些根底因素在推动着分布式技术一直地向前倒退，到起初演化成分布式数据库系统的时候，对于程度扩大的要求提上日程，所以我的第一个总结是针对扩大，不仅是垂直扩大，而且要程度扩大，所以对于扩展性下的多读多写场景，使得分布式数据库的构造变成纯正的每一个节点都是对等的构造。在散布零碎里要考究可用性，包含数据层面的可用如共识协定下的数据多正本机制、也包含整个零碎性能层面的可用。如果以较少的投入取得高的性能，那就能够对外撑持更多的业务，老本就会更低。所以对于数据库外在原生的要求从单机数据库系统到分布式数据库系统始终没有产生过变动。

最初，分布式数据库的挑战、问题在哪里？我以一个目录构造列出了这些内容。该目录构造分为两局部，右面局部是数据处理技术其本身对数据库的外在驱动需要，右面局部是基于数据库所处的外部环境对于数据库的驱动因素。大家能够察看目录所列的这些根本因素，以理解分布式数据库的相干技术点。数据库外在的需要其实有分布式和存储架构相干的，数据分布、存储管理、多正本、存算拆散、多读多写、查问优化、MPP。这个思路其实和我方才所分享的脉络是一脉相承的，又和高可用、和事务处理相干，这些都是分布式数据库的外在需要，驱动着数据库技术持续一直地后退。

从里面的来看，新硬件、智能数据库、云计算，这些是计算对于数据库系统的要求；HTAP，还有下一代所谓的 New SQL，数据库也在一直地演进，此过程中还会产生一些新的技术和内容。所以做分布式数据库，大部分就是基于单机数据库系统，再做一些和分布式相干的事。分布式相干的事件大略是我后面提到的那些支流技术，这张目录构造把没有包含的根本核心内容都蕴含了。

其中，特地阐明一点，是去中心化。做分布式数据库肯定要思考去中心化，也就是各个节点之间是对等的，思考一个并发拜访控制算法的时候，这个算法是不是去中心化的？它们之间的关系是不是对等的？都是要思考的。