本期分享嘉宾
唐彦
腾讯云 数据库专家工程师
【嘉宾介绍】 浙江大学计算机博士，研究领域主要关注于分布式数据库、大规模数据密集型系统相关的关键技术，以第一作者身份在领域 Top 类期刊和会议上发表多篇论文。目前在腾讯主要负责分布式数据库 TDSQL 的元数据管理与集群管控调度相关工作。
以下为 DTCC大会 腾讯云数据库专家工程师唐彦的演讲实录：
腾讯云国产数据库 TDSQL 诞生十余年以来，以其强大的功能和出色的性能赢得了良好的业界口碑及客户的青睐。不仅如此， TDSQL 也对数据库新架构、新技术不断进行了积极的探索。 TDSQL 新一代产品 TDStore 版，正是腾讯云数据库团队技术探索的最新体现。本次分享，腾讯云数据库专家工程师唐彦，将为大家介绍 TDStore 的新技术演进之路。
TDSQL MySQL 产品族概述
第一部分阐述目前腾讯 云 内部 数据库的 MySQL 版本大家族的情况。
总体来说，目前 MySQL 有两款引擎产品，已推出的并被大家熟知的、目前在跑的一款就是 TDSQL InnoDB 版，在金融行业数据库应用非常多，今天着重跟大家分享的产品是腾讯在内部叫做 TDStore 的这 个 新引擎架构，以下分享会以新敏态引擎或 TDStore 混合称呼该款产品。
其实这款新引擎产品从功能特性就是敏态引擎，已经登录官网，目前作为
MySQL
其中一款引擎置于列表里，如有兴趣，可于官网浏览。
讲述 TDSQL 在架构引擎上的技术演进之前，不妨先了解下原有的这款在业界、金融界已取得良好口碑的 InnoDB 版具有哪些特性。
面向金融级 数据库应用 肯定要保持数据的强一致性，为了面对大规模数据以及异地容灾、合规性要求，这款产品 TDSQL 具有非常高的可扩展性、金融级的高可用。所有的这些特性在腾讯内部 一直在 进行不断更新和迭代 ， 为新敏态 引擎 打下 坚实的 基础。
在此基础上， 客户 在 使用上 不可避免地 会 陆续 碰到 一些痛点 ， 而 我们基于现有的痛点 便开始 进一步挖掘 TDSQL 还能够在哪 些地方 持续发力， 以 能 更好地持续 打造一款 服务更多客户的国产 分布式 数据库。
基于刚才的诸多对比 可以看出，我们 不断地从客户的使用反馈中深挖为何我们需要做一个更新的引擎，以更好地解决客户的痛点，而腾讯新敏态的引擎 TDStore 可以更为契合地为客户解决哪些问题。
很多客户也会提到我们在新一代的引擎中 SQL 的兼容度进一步提升了，他们使用起来更像是一款透明的分布式数据库，用户无需手动指定分布 ShardKey ，不用关注分步分表问题，所有路由打散、感知、迁移、扩缩容都是自洽地在产生并在产品本身里有所包含。
弹性能力进一步增强，新一代引擎具备容器化的管控能力，使得扩缩容能够做到更大的弹性，计算和存储都能够独立扩缩容。
高压缩的海量存储，用户的数据量越来越大，其实对存储的成本提出了更高的要求，很多用户对数据存储和冷热数据不同策略的分离都有提出非常多的要求。
基于以上种种，下文会再详细展开。我们打造更适合需要高度兼容 MySQL 的业务，需要频繁变更、灵活扩缩容的新型敏态业务，能够对高吞吐的写入以及低成本的存储的需求非常敏感的一些场景。
TDSQL新敏态引擎产品特点概述
目前 TDSQL 具有哪些特点，将展开阐述。 TDSQL 从之前的 InnoDB 稳态引擎进行技术演进到新敏态引擎，技术上发生了怎样的变化？图中比较简要地概括 TDSQL 敏态引擎内部迭代的第一个版本，就是架构是什么样子的。
可以清晰地看到整套敏态引擎分为计算、存储和管控，计算、存储和管控是非常松耦合的，能够解开，通过一个接入层，就是应用层的 MySQL 客户端接入之后，不用关心到底是接入哪个节点。
绿色这一层就是我们的计算引擎，也就是 SQL Enginne ，这是多写架构，每一点都可以独立响应读写请求，然后这些计算节点接收到用户的任务以后会根据用户数据、根据自己路由，就是管控层获取的实际路由分布，把请求发送到下面分布式存储层 TDStore ，其实就是腾讯内部自研的一款分布式存储引擎，作为能够完全符合 MySQL 标准的引擎版本，相当于替代了原生，直接嵌入 MySQL 下面作为分布式 KV 。
用户使用起来对分布式、存储式是没有感知的，就像使用单机 8.0 一样。管控层主要是管控所有的存储、数据的调度行为，所有的数据是按照一定规则打散在不同的存储节点，不同的节点是以 Raft 协议进行多副本的数据同步。
简单说一说，敏态引擎具有的四大产品特点，如下图所示。
非常高的 MySQL 兼容性，即对用户层无感知就能够让用户进行业务的迁移。高性能的计算和存储，正如上述看到的，我们的计算层是无状态的，计算和存储均可独立弹性扩缩容，所以不像传统的主备模式，只有主才能服务。
新敏态引擎架构下，所有的计算层都可以读写，单实例就可以非常轻松地支持具有千万级别 QPS 业务。
Online DDL 也是我们重点打造的业务能力，支持不用依赖于任何工具就能实现不阻塞业务，线上进行绝大部分常见的 Online DDL ，大家平时遇到最多的就是加链、加索引、加分区等等，这些操作都不依赖于外部工具，直接可以从 SQL 层面执行，以不阻塞业务的方式非常好地帮助用户把 DDL 完成。
如上述所说，这些是独立存储分离，独立扩缩容以后肯定会伴随着数据的搬迁，而在 TDSQL 内部，所有数据搬迁包括哪些部分需要分列，哪些部分需要合并，迁移到哪个节点，这些数据分片应该如何分布，全部操作均可由 TDSQL 内部非常自洽地完成，用户是完全感知不到底下有扩缩容的进程。
MySQL 高度兼容，因为我们的分布式存储层是基于 LSM-Tree 实现的存储引擎，对比传统的 InnoDB 存储引擎有非常高的压缩比的效果。
从目前我们已经迁移到新敏态引擎架构下的业务来看，普遍能够比 InnoDB 引擎的实例节省，耗费的空间是原本的 10% 甚至 5% ，也即可以实现 10~20 倍的压缩率。
原生 DDL 的支持，除了上述讲到的不但能够原生支持不阻塞业务， Online DDL 在多个不同计算节点的执行是完全一模一样的，因为计算节点之间共享一份数据对象，以确保不同表的 DDL 在不同引擎不会被并行执行。
TDSQL 敏态引擎架构演进 [1]
阐述完总体的产品特点，再进一步分享下架构演进相关的内容，看看从技术的角度看下总体架构上 到底进行了哪些操作等等。如下图所示。
TDSQL 敏态引擎之计算层——SQLEngine
计算层是做了一个非常重要的理念，即无状态的设计，意味着每个计算节点都可以随时根据业务的需求，比如若活动期间业务洪峰流量上来，非常需要更多的计算节点承受读写请求，我们则可以以秒级速度拉起新的计算节点，马上加入实例，便能够即刻响应用户的请求。
每个节点拉起来以后与管控节点的交互，就会从管控节点获取全局时间戳和路由信息，路由信息会缓存在自己的缓存中，接下来就是与存储层发生交互。
TDSQL 敏态引擎之存储层——TDStore
TDStore 作为分布式存储层，不但负责保存用户的数据，其设计中还是两阶段事务协调者的这一层，不同的数据是根据 Raft 协议分布在不同的节点，都是由 Raft Leader 进行数据请求。
TDSQL 敏态引擎之管控层——TDMetaCluster
管控层负责的工作与数据面、管控面均有交互，我们叫做 MC ，负责分配全局唯一而且递增的事务 ID ，并且需要管理所有的这些数据分片的原数据、管理路由。从管控层面的能力来说，还管理这些数据分片如何分裂、合并、迁移、切除，监测所有不同的数据分片的存活状态，确保整个存储集群运行时刻需要达到负载和访问上的均衡。
基于这些架构，我们在线网上确实跑了很长一段时间，也是从用户实际的诉求以及内部总结的技术上具有非常大的可改进空间的点，做了进一步的思考，也即我们这套架构还能否往前继续演进和优化。
TDSQL 敏态引擎架构演进[2]
TDSQL 产品特性及发展方向
2022 年上半年开始，腾讯内部基于已上线的这套存算分离架构 做了进一步调研、分析，以及诸多架构上的优化设计，今年 11 月底正式将这套架构做了一些更大的升级改造， 在 新版本 当中 推出 了 更进一步的一体化存算分离的架构，整套架构也是呈现对等节点的模式，非常好地支持单机和分布式版本 “ 原地无缝 ” 切换的效果。
就像我之前提到的，上一代的 版本叫做 “ 分离版 ” 的存算分离架构， 那么最新 版本 的敏态引擎 为何叫做一体化的合并版本存算分离架构 呢 ？
TDSQL 敏态引擎演进：一体化的存算分离对等架构
从 架构示意图中 我们 可以看到， T DSQL 中 每个节点完全是能力对等的，其中把计算引擎和存储引擎的能力合并到每个节点中，就叫 TDSQL HyperNode ，代表具有超 集 能力的节点。
结合下图所示，每个节点会开放两个端口： SQL 端口；底层负责 TDStore 功能的 KV RPC 接口。其中 第三个节点 实则并未连接到接入层，这种接入方式根据用户的需求来讲就是。
现在用户可能是需要更大的存储空间，计算能力并不需要那么多，此时我们就可以根据用户的实际需求，要有更大的存储容量、更便宜的机械硬盘，组成一个新的节点，这个实例中就是承担能够存储非常多的冷数据，主要是以存储节点身份运作的对象。这里没有存放任何数据，此时也是通过管控的能力知道这个节点上线以后，所有数据还是存放在其它节点。
大家可以清晰看到第三个节点形式的加入，相当于我们依然具备可以独立扩展存储能力的方式，第四个节点就是体现依然可以像前面一样独立扩展计算能力的方式。
数据的组织和管理也有实现基于复制组和 Region 两个层级的日志流数据管理模式，原本在第一个版本的敏态引擎架构，我们数据分片 粒度 只有 Region 。这一版本可以实现将多个数据分片，以任意的 粒度 进行划分，通过分裂、迁移、合并的方式组织这些数据分片，从而达到数据访问亲和性的数据，数据分片归并到同一个日志流，从而极大地减少两阶段事务的比例。
TDSQL 敏态引擎架构演进：一体化对等架构
为何我们会做这样一个演进？
其中实则有一些关键的思考要点。做这个事情当时第一个非常大的动力就是通过这样做可以让计算引擎和存储引擎合并到一个进程，存储引擎非常天然地具备完整的 SQL 优化性和执行性，新增的功能不再需要不断地以 Lib 库的形式，由计算引擎提供给存储引擎使用，计算下推动的时限就会变得非常友好，能够快速新上很多计算下推的功能，达到资源复用的效果。
因为上一个版本的架构中，大家可以看到计算引擎和存储引擎刚好一个是计算密集型，一个是 IO 密集型，合并成一个对等架构以后就能够更好地利用整机资源。
更明显地出于性能的考虑，通过这种架构，可以极大地降低网络的损耗。因为有些请求，如果我们发现可以在本地数据访问，就会直接以本地接口访问本地数据，不是每个请求都需要 走一遍网络 。
因为之前的架构 下 S QLE ngine 就是没有状态，不存数据，所以那个架构体系下 SQL Engine 和计算引擎、存储引擎必然存在网络上的开销，对等架构的演进体系下可以从网络延时方面极大地优化。数据可感知、可管理的提升，新的架构体系下，管控层是能够知道每个物理数据分片，用户库表逻辑层具体映射到什么，从而可以根据数据亲和性规则、可用性规则、分布式策略实现非常多的策略规则的配置能力，也会给用户提供高阶精细化的数据调度能力。
做了这套架构体系的演进之后，还有一个非常重要的提升就是在新敏态引擎架构下，我们可以非常无缝地从一个单机版本，即一个对等节点加上一个 MC ，无缝地 通过提升副本的方式，即单机切换到分布式，而且是原地的，并不需要去新开一个实例。
用户如果有此需求，可以通过缩容，无论是多大节点，几百个节点的规模，同样可以无缝切回至单机的数据库，所以真正实现了如果一个业务从一开始只有一定的小数据量，想要测试，导入一部分的测试数据甚至生产数据进行初期的试用和灰度的使用。当整个使用稳定之后，可能业务量也开始增大，业务可能也会开始考虑要从单机慢慢进入实例作为正式生产实例， TDSQL 无缝的切换和弹性的扩增能力就能够很好地满足业务在不同阶段对数据库实例体量差异化的要求。
这一点曾有所提及，升级成为一体化，将计算引擎和存储引擎合并到一个节点以后， TDSQL 并没有放弃存算分离这种优秀的架构设计。
如上述所说，因为我们是可以通过数据感知以及很强的管控调度能力，让不同的引擎在一个实例中以不同的身份运作，承担不同的功能。
TDSQL 敏态引擎架构演进：弹性独立伸缩
默认的模式下，每个对等节点都是混合角色，既有计算能力也有存储能力，我们也可以根据客户的需求购买不同资源配置的。比如硬盘很小，只需要扩展计算能力，或者存储空间可以很大，计算层并不挂在 VIP 接入层，所以维持了计算和存储的资源均可独立弹性地扩缩容在上一个架构版本中已有的一个好的特性。
TDSQL 敏态引擎架构演进：基于数据感知的调度
最后一点也是目前已经在腾讯内部研发和使用的基于数据感知的调度，前文中已有些例子，我们可以根据很多业务以时间作为分区，每个月一个分区 的这种形态 ， 让用户指定一年之前按照时间分区的分区表的子分区，并且就在一个实例调度到一些节点，即存储容量非常大，压缩率非常高，能够帮助业务节省成本。
如上图中的右下角所示，我们可以根据用户对业务的隔离性有一定要求的业务，符合两个数据在北京，一个数据在上海。从分布来讲，希望北京的业务 对应的数据分片 Lead er 固定在北京满足访问延迟性的要求，但有一个副本需要放在上海，满足数据跨域容灾的要求。类似于这些能力场景，我们可以根据敏态引擎的架构下，依靠数据感知强大的管控调度能力给业务实现。
TDSQL 敏态引擎架构演进：HTAP混合负载
未来一年，腾讯会在这一套架构体系下做一个更高阶的能力体现，即同一套产品体系下做一个 OLTP 和 OLAP 混合负载的能力实现。
每个对等节点底层的数据同步和通讯，都是有一个统一的 Log Service 实现，因为计算引擎和存储引擎分离的特性，整个架构能够具有非常天然的优势，即加入列存的引擎把日志解析出来，从而在一套实例中同时有行存引擎和列存引擎混合存在的能力。整个计算层接受到请求以后，根据自己的优化器决定把这些计算推给行存执行器还是列存执行器，这一能力目前是在腾讯内部 Beta 研发版本中，相信明年也即 2023 年很快就可以上市与大家见面。
今天围绕 TDSQL 的整套引擎在腾讯中的几个阶段的演进和迭代做了一个简单的分享，非常期待线下或其他场合能够与大家有更多碰面交流的机会。