共计 3385 个字符，预计需要花费 9 分钟才能阅读完成。
大家好，我是腾讯云关系型云数据库产品负责人刘迪，我次要会给大家分享到腾讯自研的云原生数据库 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 这样的状况，都会去继续迭代性能相干优化。那么在易用性下面，也会向很多用户关注的参数模板，监控指标优化以及备份和日志方面去晋升。
明天的分享大略就是这些，非常感谢大家抽出工夫来理解关系型数据库产品能力公布分享以及后续产品布局介绍。
