从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这种架构，这是一个过渡时代。再往后我们会进入到真正的分布式数据库时代，它典型的标志是什么？是多写，在每一个节点上都平等地对待，可以在每一个节点上写，这里面的技术就又有多种，有的是伪的分布式，其把事务的所有写操作集中在单一的节点上去做，真的分布式是利用分布式并发访问控制算法，在每一个节点上去做数据一致性的保障。

3. 小结

数据库基本架构的演进就是经历了这么一个过程，总结一下，反过来从技术角度来看究竟是什么因素在推动分布式数据库系统的演进。其实数据库系统有一些内在的、本质性的需求在推动它，我们以前说数据库系统里面有“三高一易”，高可靠、高可用、高性能、易用性等等，这些基础因素在推动着分布式技术不断地向前发展，到后来演化成分布式数据库系统的时候，对于水平扩展的要求提上日程，所以我的个总结是针对扩展，不仅是垂直扩展，而且要水平扩展，所以对于扩展性下的多读多写场景，使得分布式数据库的结构变成纯粹的每一个节点都是对等的结构。在分布系统里要讲究可用性，包括数据层面的可用如共识协议下的数据多副本机制、也包括整个系统功能层面的可用。如果以较少的投入获得高的性能，那就可以对外支撑更多的业务，成本就会更低。所以对于数据库内在原生的要求从单机数据库系统到分布式数据库系统一直没有发生过变化。这是我分享的部分。

二、分布式事务与一致性

1. 数据异常

第二部分，我们来看看分布式数据库系统里面的技术层面会包含一些什么样的内容。事务型分布式数据库系统里面核心的，一定是事务处理技术。数据库的操作经过抽象以后就有两种，一种是读操作，一种是写操作，当有了并发存在的时候，至少有两个事务读写同样数据项的时候，就可能产生数据异常。

左边的图在说当读写在两个事务的正交之下，就是2×2四种情况，四种情况里只有读和读不会产生数据异常，其他的组合都会产生数据异常，这是数据异常产生的原因。因为有并发读写相同的数据项，事务处理就是要解决这样的问题。事务处理有ACID四个特性，其中的C是一致性，I是隔离性，其实C和I是相同的内容，就像硬币的两个面，保证一致、保证隔离，隔离级别弱一点，一致性会差一点，会允许一些数据异常存在，也就是右边这部分表示的，一些特定的数据异常现象会发生。

这幅图总结了部分数据异常现象，但实际上数据异常不只是这么一点点，TDSQL在做的一项工作是：系统化地研究数据异常到底有多少种。目前为止人类都不能够解释清楚数据异常到底有多少。

SQL标准定义了四种数据异常、四种隔离级别，James Gray在里1995年的一篇论文定义了八种数据异常、八种隔离级别，在这种情况下，如果突然又发现第9个数据异常，按照SQL标准，它应该被放在这两个体系下的哪一个隔离级别之下？这样的问题在目前是不能回答的，而这也是TDSQL在做分布式数据库研发过程当中所遇到的、所要解决的问题，只有回答了这样的问题之后，一个系统才能真正做到强一致，所幸我们目前对这样的一个基础问题有了明确的答案，并且秉持腾讯开源精神，把这项研究结果开源到了3TS系统（Tencent Transaction Processing Testbed System）。

解决数据异常的一些技术就是并发访问控制算法，而并发访问控制算法又有很多，比如基于封锁的、基于时间戳的、基于乐观机制的等等。TDSQL开源的系统是做基础技术研究的，即腾讯事务处理实验床，我们的系统叫做3TS，取刚才我说的那几个词里面的个字母T，所以有三个T，就是3TS。

而解决分布式数据库系统里面和事务相关的技术，比较重要的还有一种数据异常——读半已提交。读半已提交这样的数据异常是基于物理分布的系统上产生的，在一个节点上某个数据项已经提交了，转账的另一个节点上的还没提交，这时来第二个事务去读这两个节点，一定能读到已提交的那个节点上的数据，但是读不到未提交节点上的数据，也就是在未提交节点上所读到的数据是旧的数据，旧的数据和已提交的新数据二者之间不能保证数据一致性，所以会产生称之为读半已提交的数据异常，这就是分布式数据库在事务处理层面即一致性方面要解决的问题。

2. 缺少一致性面临的挑战与业界解决方案

但分布式数据库系统面临的不只这些问题。因为数据库从一个集中式系统扩展变成了每一个都逻辑独立的子系统，但对外它的行为还像一个物理单一的数据库系统要表现的一样，这就面临着新的挑战。单机数据库系统上做事务处理要保证ACID，分布式系统里面也要保证ACID，但是分布式系统里面要有分布式一致性，如：线性一致、顺序一致、因果一致，还有读后写、写后读等等，而这两个碰到一起就会产生新的问题，这是分布式系统要解决的。

不只是上面提及的问题，我们面对的问题更为复杂。例如，如下这张图概况了各种分布式一致性的概念，很复杂，这里面大约有近60种分布式一致性，光把这幅图弄清楚、把每一种一致性弄清楚，已经不容易了，再和事务的ACID结合，难度就会更大。

业界对于分布式事务的一致性，是有研究的。如下图，我大概解释一下这幅图的内容：左上角事务一致性，左下角分布式一致性，右上角有个隔离级别下的事务一致性问题，这是数据库里要处理的事情，但偏偏就在该图这个红色方框，分布式一致性和事务处理里面结合的这些地方目前为止没有相关的理论和技术来支撑，而这些也正是TDSQL在做分布式数据库系统当中致力于解决的问题。对比业界谷歌的Spanner，Spanner做到了真的强一致，这是目前我看到的的强一致系统，唯二是TDSQL。Spanner做到了线性一致加ACID数据一致性的融合，业界实际上早有这个概念叫做严格可串行化，它能在全局层面保证分布式系统下数据的一致性，这才是真的强一致（请注意，这里强调全局，即从任何一个节点看去读取数据，大家都能读到一样的结果，不可能不同节点获得不同的观察结果）。

但是如果对Spanner做一个测试或者理论推导，会发现Spanner系统的事务处理性能非常差。Spanner能用到什么地方？就是用到非实时性广告系统数据的处理上面，但是大家听说过Spanner用到过金融系统里面吗？没有，此种背景下，就对TDSQL构成新挑战了，因为TDSQL要用到金融系统业务里面，我们既要保证正确性，又要保证性能。

而做分布式数据库还面临着做高并发执行器需要的技术MPP。

从一开始我们就提到了数据库基于硬件系统搭建，受限于硬件，作为分布式数据库，还面临什么问题？我们在研究它和新硬件有什么关系，刚才盖老师谈到了Oracle21c，21c做了持久化内存和数据库的结合，但它是单机的结合，而TDSQL要做和分布式系统的结合。比如早期和SSD这样的硬件结合，现在和持久化内存、和RDMA结合，都是我们在做的事情。

所有这些事情都有一个外在的需求驱动，就是数据量的变化。数据量的变化有几个层面，个很重要，但大家可能并没有完全感受到，就是元数据。对于一个分布式数据库系统来讲，元数据会剧增，也会对数据库提出一些新的挑战，不仅如此，数据库系统里面还有什么？我们知道大家都在谈AI for DB，这时AI系统一定需要大量的数据，这大量的数据就要有一个存储，有些系统是把AI所需数据存储在数据库之外，而我们在考虑，能否存储在数据库之内？如果能又以什么形式存储？这都是作为分布式技术要研究、考虑的基础问题。

三、基于HTAP的TDSQL强一致性技术实践

所以分布式数据库包含了比较多的内容：事务处理数据量的存储层面、计算层面等方面的问题，基于这些需求，我们展开了基础研究，做了TDSQL的HTAC系统，里面包含多种多样内容。这是我们系统的基础架构图，它看起来像一个单机系统，但是里面会有很多小的细节，可以看出其是一个分布式系统。

在这个系统里会包含多种多样的技术，其中核心的就是我刚才谈到的和事务处理相关的——怎么保证强一致。

而根据我们的研究，发现数据异常有无数个，无穷尽的东西，怎么去认知？这又形成新的挑战。TDSQL在做的一项工作事就是对数据异常归类，把数据异常分成有限的若干种，对它进行认知，基于这样的认知就可以定义什么叫隔离级别、什么叫一致性，怎么去影响、看待现有所有的并发访问控制算法，怎么和分布式一致性去结合，这都是TDSQL在研的一些基础技术，也是刚才谈到的一致性技术里面的基础内容。

接下来分享下我们做出的工作。左上角是学术界的认识，左下角是业界的现有产品对于强一致的支持程度，右下角是我们得出来的结果，我们把左上角那棵树变成了右下角的一张网，意思是把树上很多看似没有关联关系的节点交织在一起联系起来，这里面就涉及到强一致性相关的技术内容。

基于刚才的技术，我们研发出了多级一致性技术，即多种级别的可串行化技术，使得在分布式系统下，可串行化又可以分为多种级别。我们在谷歌云上买了Spanner服务，对比了Spanner，在GreenPlum上实现了多级一致性技术，又在MIT开源的一个系统上对比了多种并发访问控制算法，实验结果表明，TDSQL的性能都更好（该技术在2020年的DTCC上做过公开分享）。

后总结，**分布式数据库的挑战、问题在哪里？**我以一个目录结构列出了这些内容。该目录结构分为两部分，左面部分是数据处理技术其自身对数据库的内在驱动需求，右面部分是基于数据库所处的外部环境对于数据库的驱动因素。大家可以观察目录所列的这些基本因素，以了解分布式数据库的相关技术点。数据库内在的需求其实有分布式和存储架构相关的，数据分布、存储管理、多副本、存算分离、多读多写、查询优化、MPP。这个思路其实和我刚才所分享的脉络是一脉相承的，又和高可用、和事务处理相关，这些都是分布式数据库的内在需求，驱动着数据库技术继续不断地前进。

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

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

后，如果大家对核心的基础技术感兴趣，可以关注我们3TS的系统，它的研究目标主要包括：比如分布式事务处理怎么去做，它和性能扩展性、安全性、一致性等等这些的关系是什么，怎么评价这个分布式数据库系统，数据异常有多少（我们回答了数据异常有无数个，但可以归类为有限种），并发访问控制算法怎么改进等技术。

期待和各位朋友深度交流。谢谢大家。

讲师简介

李海翔

腾讯云数据库专家工程师，负责腾讯TDSQL研发工作。中国人民大学信息学院工程硕士企业导师，CCF数据库专委会委员，DTCC（中国数据库技术大会）专家委员会委员。出版有《数据库查询优化器的艺术:原理解析与SQL性能优化》、《数据库事务处理的艺术：事务管理和并发访问控制》、《大数据管理》。申请与授权专利50+，VLDB等顶会论文若干篇。参与包括国家863重大专项、核高基、工信部、科技部等多项目。获北京市科技进步一等奖。

相关文章