从TDSQL，看分布式数据库的技术之美
导语 | 每一个时间段总是一个新时代，新技术层出不穷使得数据库技术焕发新生。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，期望在事务型的系统上增强分析的功能。这个概念这几年大火，似乎在补救事务型数据库的重事务处理弱分析能力的缺陷（概念分家，指导思想发生变化，看来还是有坏处的）。人们总是有一个美好意愿，在一个系统内搞定所有的事情。这同人类的需求和不断变化的认知存在关系。
【从TDSQL，看分布式数据库的技术之美】但在这之前，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，数据库也在不断地演进，此过程中还会产生一些新的技术和内容。所以做分布式数据库，大部分就是基于单机数据库系统，再做一些和分布式相关的事。分布式相关的事情大概是我前面提到的那些主流技术，这张目录结构把没有包括的基本核心内容都包含了。
其中，特别说明一点，是去中心化。做分布式数据库一定要考虑去中心化，也就是各个节点之间是对等的，考虑一个并发访问控制算法的时候，这个算法是不是去中心化的？它们之间的关系是不是对等的？都是要考虑的。
推荐阅读
- 一个小故事，我的思考。
- Docker应用:容器间通信与Mariadb数据库主从复制
- 第三节|第三节 快乐和幸福（12）
- 开学第一天（下）
- 一个人的碎碎念
- 死结。
- 我从来不做坏事
- “成长”读书社群招募
- 拍照一年啦，如果你想了解我，那就请先看看这篇文章
- 危险也是机会