关于数据库:海量存储智能扩容这款数据库架构为何深受用户喜爱

导语 | 数据库正处在改革期，改革的能源同时来自于外因和内因，外因是用户需要的变动，内因是新技术的暴发。用户需要从强调物理上领有数据到逻辑上领有数据，因而云服务的模式被越来越宽泛地承受；新技术的暴发体现在新的存储介质的产品化。腾讯云原生数据库就是这种改革的产物，腾讯云原生数据库以云服务的形式提供更好的数据库性能，可用性和可靠性。本文由腾讯云数据库技术总监 张青林在 Techo TVP 开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」的《腾讯云 TDSQL- C 架构摸索和实际》演讲分享整顿而成，为大家详尽介绍腾讯云原生数据库的架构、在外围指标上的冲破以及摸索。

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

一、腾讯云原生数据库的前世今生

咱们明天的分享次要由三局部组成，第一局部是咱们做 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、备份以及故障切换相干的，咱们上面一一来看。

二、腾讯云原生数据库在外围指标上的冲破

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 的一系列个性，咱们能够实现主动的无感知备份以及秒级回档。

三、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 内核开发和相干架构、产品化工作。