海量存储、智能扩容，这款数据库架构为什么深受用户喜好？

导语 | 数据库正处在变革期，变革的动力同时来自于外因和内因，外因是用户需求的变化，内因是新技术的爆发。用户需求从强调物理上拥有数据到逻辑上拥有数据，所以云服务的形式被愈来愈普遍地接受；新技术的爆发体如今新的存储介质的产品化。腾讯云原生数据库就是这种变革的产物，腾讯云原生数据库以云服务的方式提供更好的数据库性能，可用性和可靠性。本文由腾讯云数据库技术总监 张青林在 Techo TVP开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」 的《腾讯云TDSQL-C架构探索和实践》演讲分享整理而成，为你们详尽介绍腾讯云原生数据库的架构、在核心指标上的突破以及探索。

​点击可观看精彩演讲视频

1、腾讯云原生数据库的前世此生

咱们今天的分享主要由三部分组成，第一部分是咱们作TDSQL-C这款产品的背景，即为何作TDSQL-C、它的架构和现状如何。第二部分主要介绍TDSQL-C有哪些突破性的创新，以及从用户视角来看咱们主要作了哪些能够方便用户的事。第三部分是TDSQL-C将来的RoadMap，偏技术。

首先看第一点。咱们以前是作CDB的产品运营研发相关工做，但在作的时候遇到了一些在传统数据库领域难以解决的问题：首先是存储容量问题，当单机磁盘容量达到必定程度时，就会对业务带来相应的麻烦。第二个是扩展性，熟悉数据库运维的朋友应该知道，典型的场景是在业务有活动的时候咱们加机器，在业务活动结束以后要减机器，它的过程通常是通过备份、组件、实例，效率较差。第三是可用性，典型的就是灾备，从DBA的角度来看，灾备发生HA的时候，这个时间点是不可控的。第四是可靠性，由于单机传统的MySQL架构，它的一主一备，而且存储是在本地存储，当咱们本地磁盘损坏的时候，它的数据可靠性会有问题，传统的MySQL作数据备份以及数据恢复，若是出现了大数延迟或者DDL这种问题的时候，这个时候若是再发生HA，那么此时数据库服务其实是不可用的。

基于在传统数据库领域运维遇到的问题，再结合业内的一些架构，咱们自主研发了腾讯的一种存储和分离的数据库产品。

这是咱们总体TDSQL-C的架构图，它和传统的MySQL相似，支持一个读写节点、多个备库节点，备库节点最多能够支持15个读节点。它分为计算和存储两部分，计算节点主要负责数据库的传统业务逻辑领域，包括像事务、锁以及经常使用的DML，传统数据库领域里全部在数据库的操做，除了两部分不在计算层之外，其余都在计算层，计算层不负责数据的持久化操做，数据的持久化操做会下发到存储层，存储层来负责数据的持久化操做。存储层是 HiStore （网络存储），自己最大支持的存储规模如今有1PB。而主备之间和原生MySQL不一样的是它使用Redo log进行主备数据同步，Redo log发送到备库以后只负责同步备库之间的BP。

咱们来看总体原生的MySQL一主一备的架构和如今TDSQL-C的架构。原生的MySQL里的存储是在本地进行的，依赖于本地的Dict存储，受限于本地的存储空间；TDSQL-C里的存储是网络云盘，它分为两级存储，上面是HiStore，负责存储数据，下面负责存储备份。

它的计算和存储分离，可是计算节点的主备节点会共享存储，就是下面这个HiStore。和传统MySQL架构不一样，它是一个可计算存储，体现了两点：主节点的计算节点会把产生的Redo日志下发到存储层，存储层会依赖于它的Base page以及所产生的Redo log来负责数据的持久化操做，存储层在收到Redo log后才会向计算层反馈信息，说明Redo log已经持久化，证实如今的事务已经结束，可让业务逻辑继续进行。业务逻辑在进行的同时，存储层会异步处理Redo log，计算中存储下来的Redo log共同生成新的，由这个新的持久化到HiStore里负责，从而将数据持久化操做。因此它和传统的CDB或传统的MySQL架构下面没有数据的持久化操做，也就不会有WAL带来的一些性能抖动问题。

在HiStore把数据持久化以后，会把以前Redo log所占的内存空间回收。而咱们的存储也有如下特性：咱们在把本地磁盘映射到网络存盘时，是根据它的物理地址映射到底下存储空间的某一个cell中，因此它的日志是按照页面来进行分发，每个cell里都有相应的数据页和Redo log，由于子节点和主节点是共享存储数据的，因此要求咱们的存储支持数据多版本，它的数据多版本是由咱们的Base page加上从计算中传递下来的Redo log共同生成的一个具备指定版本的数据来进行的。

刚才介绍了咱们自己的架构，而从总体上的架构来看，TDSQL-C有如下特性：第一是海量存储、智能扩容。存储由HiStore支持，网络存储最大可支持1PB，相对于如今单机容量几十T或者几T来讲，不是一个级别的。第二是咱们总体的QPS存储量能够达到百万级别，因此它的性能也获得了线性扩充。第三是兼容MySQL和PG，也没有分布式事务锁带来的一些问题，不进行数据分片，因此是自然支持分布式的。其次是扩展性，相对于传统的CDB架构或者传统RDS架构来讲，它不依赖于本地的物理备份或者逻辑备份导数据来进行扩容，而是直接从文件系统作一个快照，快照加上Redo log来作扩容，因此整个扩容的时间基本在一分钟之内，能够说是秒级扩容。再次是和Serverless、备份以及故障切换相关的，咱们下面一一来看。

2、腾讯云原生数据库在核心指标上的突破

1. 突破一

这是总体上TDSQL-C的一些架构和所支持的特性，也是咱们的现状。在实现TDSQL-C这款计算和存储分离的分布式产品里，咱们为解决用户实际问题而作的一些特性：

首先是Serverless场景。在支持Serverless以前，咱们在作业务开发和运维时，会先购买一个计费的数据库实例，包括存储空间、网络存储空间和计算资源，都会从购买的这一刻起开始计费。可是在业务开发的时候确定是属于低频使用时期，那么在咱们总体的开发场景，使用数据库的场景较少，在Serverless场景下会根据你所使用的时间来进行计费，每5秒对这个实例打一个点，一分钟内会有12个点，一小时以内有720个点，真正在打点的时候使用时间才会做为真正的计费时间。在Serverless场景之下买一个实例时，你会有一个计算资源和一个存储空间，真正使用时是所有计费的，但你不使用时，它的计费空间只是存储空间，因此能下降咱们的消费，而且用户利润能够达到最大化。

也不用关心何时启动和关闭Serverless，当对它没有访问的时候就自动关闭，当再一次发送请求时，咱们会有中间的方式来自动界定它须要再次访问，那么它会迅速的把这个实例拉起来。因此它有两个特性，第一个是智能极致弹性：极速启停，第二个是真正的按使用计费。

为了实现Serverless，咱们作了如下事情。因为咱们是本地网络，因此网络延迟会增长，为了实现极速启停，咱们把BP独立在MySQL以外，在购买MySQL实例的或在建立BP的时候，实际上它是独立于MySQL进程以外的。

由于分析到整个MySQL启停过程当中耗时间，咱们也作了并行化处理，为了可以知足真正的“所用即所费”。由于在MySQL里建立一个表，这时会预先分配表的空间，不管用或不用，这些空间都会做为使用空间，咱们在分配空间的时候是以exten或者1兆来进行分配的，若是你没有使用这1兆的话，那么这1兆就不会在你的计费空间之内，只有真正当你写数据在1兆空间的某一页时，才会真正灾容计费存储量。因此从用户的角度出发，把用户的计费存储量基本降到最低，后续咱们还会继续优化，真正作到页级别的使用计费。

2. 突破二

咱们单机容量可能在几G或几十G，这个时候它的内存是比较小的，好比只有几百个G的内存或者不到一个T，可是存储空间可能会有几百个T，这时属于典型的IO Bound类型，为了解决这个问题，咱们把这种BP内存放到本地作二级缓存，在IO Bound场景之下，实际上并非淘汰，而是把它淘汰到咱们本地的SSD存储或者本地的AEP存储，下次用的时候，能够直接从本地读取，这样就能够最大限度下降网络IO的消耗。在咱们的测试场景里，当命中率比较低，甚至在50%如下的时候，总体的性能是呈指数级性能提高的。

另外是咱们愈来愈本地的磁盘空间作二级缓存的时候，首先是容量可控的，能够自动配置这一块占用多大的存储空间做为本地BP的二级缓存。内存规格以及内存管理也和BP的内存管理是相似的，淘汰的时候会首先淘汰本地的二级缓存，当本地文件不够大的时候，它也会遵循一系列淘汰算法来进行淘汰。磁盘管理独立于本地文件，因此它走的不是网络IO，那么用本地IO能够弥补总体网络IO的消耗，所以总体性能的收益比较明显。这张图就是咱们本地二级缓存的架构图。

3. 突破三

突破三是无感知备份。传统CDB架构或传统RDS架构，咱们在作备份时通常都使用逻辑备份或者物理备份，这里面会有典型的两个问题，不管是逻辑备份仍是物理备份，都涉及大量的IO操做，会极大占用集体资源。为了获取位点作以后的增量备份，会有一把大锁。

咱们在备份中追求两个目标：第一是无感知备份，让用户没有察觉；第二是极速回档，由于在传统的备份恢复时，恢复是基于本地的，若是是逻辑备份，要导数据，若是是物理备份，要拷贝数据，再加上增量备份。因此咱们的目标是无感知备份和极速回档，真正作到这两个才能实现秒级扩容。

这就是在TDSQL-C里的备份和回档，备份其实是依赖于HiStore作的文件系统的快照备份，至关于我若是发送一个备份命令，这时首先会对我以前的HiStore打一个快照，以前的写操做会写到新的数据存储的地方，那么在备份时就会直接拷贝我原先的数据，同时把它上传到COS里，由于咱们底层的备份是分散到多个cell里，因此备份也是并行备份。在回档的时候也属于并行回档，它得把Redo log下发到cell里，那么这个cell包含原始数据以及Redo log，它在回档的时候每一个cell会自行来应用这些Redo log。因此不管是备份仍是回档，咱们都是实现并行的，而且在回档的时候不是像Binlog的逻辑修改，而是直接定位到一些物理修改，回档速度也是GB级的。依赖于本地的可计算存储以及HiStore的一系列特性，咱们能够实现自动的无感知备份以及秒级回档。

3、TDSQL-C的将来探索

基于咱们如今所作的一系列事情，一方面是0-1，另外一方面是结合在运维过程当中遇到的问题，TDSQL-C后续的发展方向有两点：第一点是极简数据库运维。从运维的角度来鉴定以后的发展方向，首先是智能挑战，用过MySQL或CDB的人都应该会在MySQL的优化器上遇到一些问题，好比升级时发现它的执行计划走错，或者当数据量达到必定程度的时候执行计划也会走错，TDSQL-C的内核会在优化器里优化总体的统计信息，而且对它的执行计划进行断定，动态调优。好比在升级的时候，若是发现它的执行计划出错，能够自动对它进行纠正，而且发给运维。

由于在实现计算和存储分离产品的时候咱们对内核的代码修改量较大，而且要增长存储量，在读写极致性能优化上咱们也作了相应的修改，因此咱们为了保证它的逻辑严谨性也会作相应的事，包括会引入业界相关的设施，从原理上进行把控对于内核的修改。从成本的角度来看，在Serverless场景下成本大部分是存储所带来的，因此要下降用户的成本。能够从两方面：一方面是用户真正用的才是他所须要付费的内容。这里有一个存储空间的概念，存储空间咱们要真正作到页级别，另一种如今是三副本，能够经过数据压缩存储、纠删码等技术下降存储空间，把自己的灾容数据存储空间下降在1/3左右，这也是咱们后续的一个发力方向。

第三点是效率问题，由于作DDL，当咱们单机单表容量达到上T级别的时候，在MySQL内部会首先扫描它的索引，来扫描全部这个索引相关的数据，每一个进行排序，再作归并排序，再创建索引，这一系列的过程其实是很费时的。针对这种操做，咱们有两方面的优化思路：第一方面是instant DDL，对于每一个字节所占用大小之间的改变，会支持更多的instant DDL。第二是经过它建立索引的这个过程，会把刚才所涉及到的像扫描B树、排序、建B+树这一系列过程所有并行化，若是可以走instant DDL的，能够实现秒级 ddl 操做，若是不能走instant DDL的操做，会进行parallel index 处理。

面向业务的Low Database开发，特别是在TDSQL-C这款产品里，数据存储规模会比较大，好比上几百个T或者相似于最大容量的P级别，那么这个时候数据分析能力就要提高，首先咱们会提高它的最大存储量，经过优化器以及并行执行框架，最大限度地使用机器的资源来提高单机存储量。咱们在存储方面会利用新的介质，好比AEP或者SSD，来极大提高本地的好比刚才所介绍的二级缓存，或者是把一系列能够在本地操做的作到最大加速。

从业务类型来看，好比金融或是政务容灾合规这类业务，咱们会进行全链路审计，包括字段加密，同时也会就全球异地容灾、就近访问的原则优化 TDSQL-C 的产品能力。

最后是会在TDSQL-C产品里集成AP的能力，咱们如今正在开发一款列存产品，内置到TDSQL-C里，在本地用列存来启动整个场景加速。

---

讲师简介

张青林

腾讯云数据库技术总监腾讯云数据库CDB、TDSQL-C数据库内核研发负责人。腾讯云数据库技术总监，腾讯云布道师，MySQL架构师，现腾讯云架构平台部云原生数据库内核研发团队技术负责人，Mariadb 基金董事会 & Mariadb 社区版本开发成员，专一于MySQL内核开发和相关架构、产品化工做。