TDSQL-C for MySQL 版产品新特性

大家好，我是腾讯云关系型云数据库产品负责人刘迪，我主要会给大家分享到腾讯自研的云原生数据库 TDSQL-C for MySQL 版产品能力迭代以及后续产品规划。

TDSQL-C 这个名字大家不一定很熟悉，可能有的同学更熟悉它之前的名字，**它其实就是我们之前发布的存算分离云原生数据库 CynosDB**，因为统一品牌关系，把名字统一成了 TDSQL 系列，现在官网或对外品牌宣传上都以 TDSQL-C 做整体改名。

首先我们讲一下，TDSQL 的分类。把数据库类型按照关系型和 NoSQL 来分的话，TDSQL-C for MySQL 版的类型会归到 NewSQL 的类型里面，对于 NewSQL 的定义，不管是各个论文还是厂商都有不一样的定义，更多宏观上简单理解是关系型数据库的事务能力加上 NoSQL 扩展性的组合，不单单是加成的关系。

**NewSQL 分为两类，一是基于 Google Spanner 的架构来演进**，类似于很多 AP 类数据库都是用的 Shared Nothing 架构，最典型的就是 TiDB，TiDB 的底层 KV 存储整体中间层做了协议层的兼容。**二是 TDSQL-C for MySQL 版**在存算分离上，除了真的计算层和存储层进行完全的分离部署以外，它的存储层基于存储引擎层进行了改造，在底层用的是分布式文件系统，不再是原生的 MySQL InovDB 底层存储。

NewSQL 从传统数据库到云原生数据库的演进，也是数据库在架构上不断随着业务和技术的迭代创新的过程。TDSQL-C 整体架构其实是把计算层和存储层进行了完全分离，实现了计算节点无状态方式，100%兼容 MySQL 协议。

TiDB 架构，TiDB 中间做了一层协议兼容，所以它整体对于 MySQL 的兼容并不能做到 100%，这也是目前用户在使用 TiDB 比较大的痛点。**而我们可以做到 100%的兼容，兼容性上 TDSQL-C for MySQL 版完全兼容 MySQL**。扩展上除了做存散分离，更重要的是在数据分离中完全去掉，完全用 Re 读物理日志的方式进行同步，主从延迟上就有非常大改进，可以认为它的主从延迟平均下来在 20 毫秒以下，所以在延迟上相比传统架构的 MySQL 有非常大优势。

基于这种存散分离架构，把资源进行分离，下面用池化的技术做整个存储的资源池。支持它的无状态服务 Serveless 上具有天然的架构优势，在故障恢复和备份上有非常大级别提升，它是快照回档。基本上 MySQL 两种回档：一是物理回档；二是逻辑回档。逻辑回档是 30M/秒，物理回档是 300-400M/秒。对于 CynosDB 或者 TDSQL-C for MySQL 版来说，它的快照备份的回档效率大概能到 GB 级/秒的级别。

**存储上，是 CynosDB 和 MySQL 集中适合云原生存散分离架构优势比较大的，目前现网最大规格存储支持到 128TB，**预计明年上半年会突破存储体量超过 PB 级别，对于海量存储业务来说，不用在频繁的分库分表进行拆分，单库的容量完全可以满足用户的需求。

下面看 2021 年上半年 TDSQL-C for MySQL 版发布了哪些产品功能。首先是支持库表级别回档和实例克隆，像 TDSQL-C for MySQL 版支持的回档力度已经对齐了其他关系型数据库，能达到表力度回档，进行同一个实例克隆。第二个是双向同步，大家关注的从 MySQL 到 CynosDB 再从 CynosDB 到 MySQL 双向同步的 DTS 工具现在已经完成了发布，所以说我们可以通过 DTS 进行迁移，反向链路支持反向数据迁移，包括数据的同步链路，可以方便用户根据自身业务的特性来选择 MySQL 还是 TDSQL-C。

存储资源，因为 Cynos 特殊架构关系，它是可以无限扩展，对容量没有限制，大家可能在使用 MySQL 之前会有定式，一个月要预估容量，买 50G、60G，用完以后需要进行扩容。在 Cynos 这里，它的存储是按量计费，按量计费和大家平常买其他产品按量计费不一样，它不是按照规格的量计费，而是按使用量计费，因为支持存储扩展上限比较高，所以一开始计费方式就是提供用户按使用多少算多少的方式。

性能优化方面，首先是针对快速启动做了极速启动，MySQL 的 HA 高可用是通过 Mast、slaf（57：30）两个节点去做数据同步，在主实例挂了以后进行路由的切换，使得 Slaf 节点变为主节点去提供服务，完成高可用方式。

对 CynosDB 来说，它的计算节点是无状态的，不会带有数据节点要同步数据，因为下面是共享一份的资源池数据，所以多个节点，包括只读节点，两个只读节点、三个只读节点数据是一份，不用为了扩展计算资源再扩展存储资源。

**接下来一个功能是 Instant DDL，这个功能目前已经发布**。能够解决用户快速加列的问题，如果因 CynosDB 的存储很大，你可能存几十 T，几百 T 的数据，一旦遇到这种表我们要加一个列。这种表加列，DDL 操作时间是不可控的，有可能存储空间就爆了。如果用第三方工具去做，大概率存储就 Dubble 掉了，那时候中间产生的临时表会直接把存储爆掉。这个是用户无法接受的，但是 TDSQL-C MySQL 版支持 Instant DDL 以后，加列时间基本上是秒级完成。

性能优化的一个点，增加了一个二级缓存，为什么要增加二级缓存？看到上面存算分离架构，跟我们传统集中式部署这种一组多重架构有一个区别。极简 IO 只剩下 Redo 需要去抓盘，需要持久化，这个点我们在 IO 上面其实就精简了。第二点，通过二级缓存来去提升计算节点，本地去做了缓存底层的数据，不用每一次都回原到存储侧去形成这种网络 IO 交互，这一点也是我们提升了只读场景和读写场景的一个性能。

**最后一个就是数据库的审计，简单说就是记录所有 SQL 执行，你的执行记录，返回的行数，CPU 消耗，所等待时间一系列，不仅是 SQL 本身，还有这个 SQL 一些执行特性都可以去给到用户去返回。**

刚刚说了很多的性能优化，使得 TDSQL-C for MySQL 版它的只读和只写性能都会比我们传统云数据库有一定的提升，在性能上，不管是对标友商还是对标我们自身云数据库，其实它的读写能力都会比较有一些提升。

**那么下面最后给大家说一下 Serverless 的这个架构**，TDSQL-C Serverless，首先它是国内首款的 Serverless 云数据库，这个我们可以很骄傲地说，阿里，华为现在都没有做出，或者说现在也没有对外去发布基于 Serverless 的这种数据库，这是我们首发的一个数据库。

它真正能够做到按量计费，你不用的话是完全是不收费的，它的计算资源是非常弹性，弹性是零到一个阈值，这个阈值用户可以自己设，你可以设 0CPU 到 5 核 CPU，我们就会根据实际现在业务系统负载情况进行弹。

这个是目前 Serverless 形态被很多用户所青睐的一个点，它的计费方式，真正的能够灵活到按照用户的使用进行收费。虽然我们说 TDSQL-C for MySQL 版它的扩展不管是横向的加节点还是纵向规格的扩展已经非常快了，基本上我们可以做到 30 秒内，可以进行规格调。但是 Serverless 这种产品形态，去判断和操作的动作都帮你省掉，由系统自动来帮你去判断。

今天产品介绍就到这里，在给大家说明一下我们后面会做的事情。那么首作为 TDSQL-C for MySQL 版说要解决的它的整个的 Roadmap，它要解决是两方面问题。

**第一个是更加突出云原生架构所带来的核心价值，**比如一些海量存储场景，存储一些内容、文件，大量存储上面我们的上限非常高。在这些地方我们要去打造出核心的一个产品能力，让我们的矛更加的尖锐。

**第二个是提升我们性能的一个方式**，要去支持并行计算的一个能力，能够让我们的 SQL 去运用到更多 CPU 资源，提升 SQL 性能，包括并行扫描，并行的多表连接、排序、分组、聚合等等这种并行能力。

前面几个都是针对 CynosDB，它自身的云原生架构特性，我们会去做一些优化和产品功能的迭代，这个就基于我们一直要去持续做的产品完善度方面的优化。

首先就是性能，我们的性能对于 CynosDB 来说是一个生命线，不管是基于硬件还是基于全链路 RDMA 去实现这种读写性能的，能够再次突破现在百万 QPS 的一个能力，包括并行、完全去掉 blog 这样的情况，都会去持续迭代性能相关优化。那么在易用性上面，也会向很多用户关注的参数模板，监控指标优化以及备份和日志方面去提升。

今天的分享大概就是这些，非常感谢大家抽出时间来了解关系型数据库产品能力发布分享以及后续产品规划介绍。