引言
分布式 TDSQL for MySQL 数据库是标准的 Share Nothing 架构数据库，支持数据水平拆分与线性扩展，具备高性能、数据高可用、数据高可靠等特性。本文主要介绍的是，我们在“分布式 TDSQL for MySQL”数据库新计算引擎架构上，分布式计算下推所做的主要工作。
关键字
在介绍后续内容之前，我们首先描述一些专业术语，以便大家有所了解。1、1、CN：TDSQL 的计算节点，全称是 Compute Node。包含 DDL 组件，计算下推组件，分布式 XA 事务组件等计算层核心功能。
2. 2、DN：TDSQL 的数据节点，全称是 Data Node。我们把每个存储数据分片的节点叫做 DN，每个 DN 都是一个独立的TXSQL引擎。
3. 3、SET：一个主 DN 节点与若干备 DN 节点所组成的数据节点集合，我们叫做一个SET。
4. 4、FQS：SQL 分布式快速下推框架，全称是 Fast Query Shipping。
5. 5、PQ：SQL 分布式并行执行框架，全称是 Parallel Query。
6. 6、Sharding表：按照指定分布键（Sharding Key）进行数据分布的表。TDSQL 支持 Range（按范围分区）、List（按列表分区）、Hash（按哈希分区）三种分片表类型。
7. 7、Distribution表：按照指定的数据节点（DN）进行数据重复分布的表。可以选择将数据仅分布在单个DN 上，也可以以数据重复的方式分布在多个 DN 上。
架构简介
我们对目前腾讯云官网售卖的“分布式 TDSQL MySQL InnoDB 引擎”版本的计算引擎，进行了架构重构与升级。新的计算引擎整体兼容 MySQL 8.0.26 内核，支持了CTE、存储过程等更为丰富的 SQL 特性与部分 Oracle 兼容语法，同时，我们也在计算下推框架上做了很多工作，来提升整体的性能 QPS。
在 TDSQL 中，为了满足不同业务场景的计算下推需求，以减少数据传输和处理的开销，实现卓越的下推性能，在新的计算引擎下推框架中，我们提供了两种机制 ，分别是：1. 快速下推（Fast Query Shipping，FQS）；2. 并行执行（Parallel Query，PQ)。从业务模型来说，前者主要针对基础的高并发 TP 型业务，提供 SQL 快速下推执行的能力，后者主要针对复杂的 SQL（复杂子查询，查询物化，多表 Repartition 的Join 等），提供并行执行的能力。此外，我们通过多存储引擎接口 Secondary Engine集成了LibraDB AP 计算引擎，来提供一站式的 HTAP 计算能力
本文主要介绍 FQS 快速下推计算框架，关于 PQ 并行框架的介绍，可以关注后续我们的推文。
总体说来，FQS 是一套分布式的 RBO 下推框架，它会根据集群提供的元数据信息，计算当前表的分布情况，并构建下推计划。
执行框架
整个分布式计算下推框架的作用对象为 DML 语句，计算引擎对 DML 语句的处理逻辑，可以被分为两个阶段：1. 1、Prepare 阶段：这个阶段会进行基本的开表操作，并完成代价优化之前的所有准备工作，包含：
● 1）解析表和列信息。
● 2）解析所有表达式，包括 WHERE 子句、连接条件、GROUP BY 子句HAVING 子句、ORDER BY 子句、LIMIT 子句、递归地准备所有子查询。
● 3）对抽象语法树应用永久变换，包括半连接变换、派生表变换、消除常量值和冗余子句。
2、Execute 阶段：这个阶段会对 Query_block 进行基于代价的物理优化，产生物理执行计划，并进入到执行器迭代执行。
FQS 下推框架，实现了新的 Prepare 与 Execute 处理逻辑来接管原本单机的处理。
Prepare阶段
预检查
FQS 的 Prepare 阶段，会首先进行下推策略的预检查，对于目前不被支持或是下推后存在语义歧义的 SQL ，需要被禁止下推。
例如，TDSQL 实现了中心化的 Sequence 对象，Sequence 的生成在不同的 CN 节点上需要保证唯一性，所以一条带 Sequence 对象的查询语句，是不能被下推执行的，否则可能破坏 Sequence 值的唯一性规则。此外，还有一些对系统表和系统视图的操作，也是明确被限制下推的。
当然，绝大多数的业务 SQL 语句是不会受到预检查限制下推的，这些 SQL 将会进入到 FQS 的基于规则的优化阶段，计算分布方式与多表 Join 下推优化。
（一）阶段优化
需要承认的是，生产环境中，绝大多数的数据库业务为读多写少的场景。复杂的数仓查询受益于高级查询优化，而简单的读请求则受益于更小的查询优化开销，FQS 下推框架，针对“单 Sharding 表 + 分布键的点查”场景，进行了一阶段优化，来极致化降低查询优化的开销。
FQS 的优化器将会直接从 Filter 条件中提取分布键值，并计算与该值匹配的分片，完成查询优化的过程。这使得 FQS 可以用最小的 CPU 开销，来支撑这类业务场景的高吞吐工作负载。
FQS 一阶段优化的整体算法思想，借鉴了 PostgreSQL 数据库中的分布式扩展插件 Citus，论文《Citus: Distributed PostgreSQL for Data-Intensive Applications》。
（二）阶段优化
对于非“单 Sharding 表 + 分布键的点查”的场景，比如绝大多数的 JOIN SELECT 与 INSERT DELETE / UPDATE 语句，都需要进行二阶段优化，来得到明确的 DN 分布方式。
JOIN条件优化
多表 JOIN 的场景下，判断 FQS 是否可下推的条件，主要有两个：
1）JOIN的表是否满足下推兼容性规则。 2）JOIN的表是否满足Sharding Key的等值或推导后 Sharding Key 的等值。
JOIN 下推兼容性规则
FQS 与 PQ 在对 JOIN 下推规则的判断上是相同的，需要成对的枚举所有的 JOIN TABLE，并判断外表与内表的 JOIN 规则，需要额外注意的是，包含子查询的Query_block，需要递归地进行检查，并将整个子查询的 Query_block 视为一个 JOIN TABLE 组，来判断 JOIN 规则。整体来说规则如下:● SingleShard:分区裁剪之后为单 DN 分布的表。例如：
● ReplicatedAllSets:数据重复分布所有 DN 的 Distribution 表。一般叫做广播表。例如：
● ReplicatedSets:数据重复分布部分 DN 的 Distribution 表。一般叫做复制表。例如：
● Shard:分区裁剪之后的 Sharding 表。例如：
上述 5×5 的表格中，第一列为外表类型，第一行为内表类型，对于表格中的内容，描述了完整的 JOIN 的兼容性判断规则，例如:
条件优化上拉与等值推导
MySQL 优化器对 Filter 条件的优化，发生在物理优化阶段，而 FQS 的查询优化发生在物理优化之前。为了能够从条件“”推导出条件“”，我们做了一些工作，将 Filter 的条件优化逻辑，上拉到物理优化阶段之前完成。这个特性的支持，可以解决掉 TPC-C 基准测试模型中的下推问题。
此外，FQS 设计了一个条件等值推导传递算法，来实现从条件“”推导出“”，这个也是我们相较于现有计算引擎新增加的特性。
分布裁剪
与大部分的数据库计算引擎类似，分布式 TDSQL 数据库的优化器本身会提供完善的分区表剪枝策略，来得到数据的分布情况，这为我们的开发工作带来了很多便利。总体来说，二阶段优化会判断所有的 Sharding 表与 Distribution 表，来计算是否满足相同的 DN 分布，“所有表拥有相同的 DN 分布”是 FQS 可以下推的必要非充分条件。例如:
t1 与 t2 表都是基于分布键的相同 Hash 分布 Sharding 表。Q1 过滤条件为“WHERE t1.a = 1 AND t2.a = 1”时，两表可以被裁剪到相同 DN ，且满足 JOIN 下推条件，可以产生出 FQS 的执行计划。Q2 过滤条件为“WHERE t1.a = 1 AND t2.a = 2”时，两表在优化阶段实际被裁剪到了不同的 DN，无法产生出 FQS 的执行计划。Q3 无任何过滤条件时，两表同样被裁剪到相同 DN（命中全部 DN ），但不满足JOIN 下推条件，无法产生出 FQS 的执行计划。
Execute阶段
FQS 查询优化结果，会输出对应的 AccessPath 与执行层 Iterator 算子，进入到执行器阶段。虽然 FQS 和 PQ 是针对不同业务场景实现计算下推的两套机制，但我们在执行引擎层面进行了收敛，两者共用了一套分布式执行框架，来完成并行下推执行与异步数据收发的工作，并处理分布式XA事务的相关逻辑。唯一不同的是，FQS 定义了单独的 Query_result 来直接转发 DN 节点的执行结果，避免了物化执行结果所带来的额外性能开销。
FQS 下推框架，可以解决 CN 节点不需要进行二次分布式计算的业务SQL场景，对于上述分布式计算的(A), (B), (C)场景，可以带来极致的性能。
其他应用场景
除了典型的诸如 sysbench/TPC-C 这样的 TP 型业务场景以外，我们还为 FQS 下推框架支持了更多有用的特性。
SQL Hint 路由
为了降低用户的学习成本和提升 TDSQL 对于 MySQL 的兼容性，我们在 FQS 下推框架中集成了“SQL Hint 路由”功能 ，通过标准化的MySQL Hint语法规则，来干预FQS 的下推策略，并根据 Hint 所指定的路由节点来进行下推。例如，用户可以通过 /+SETS(ROUTER)/的 Hint 规则，来手动指定下推的路由节点，这个功能可以结合“Statement Outline”功能进行自动化配置与使用。
FQS下推框架除了支持TDSQL分布式计算的下推，也可以结合“SQL Hint路由”功能，来提供了对 LibraDB 引擎的转发。
并行数据导入（Parallel DML）
无需结果集物化的 INSERT INTO SELECT 与 INSERT MANY VALUES，是 FQS 可以支持的批量导数据场景，对于 INSERT MANY VALUES ，我们会根据每条插入数据的分布，来构建各自的下推执行计划。例如，FQS 会合并属于相同 DN 分布的VALUE，最终并行下推到各个 DN 节点执行:
未来展望
目前的 FQS 分布式计算下推框架，具备了基本的并行下推执行与路由转发能力，当前主要是补齐新计算引擎架构正式上线前的各项能力，提升性能。对于未来工作展望，可以包含：
1. 1、CN 与 DN 之间通信协议支持BINARY协议。在 TDSQL 的计算引擎中，对于 Group Shard 部署模式，CN 与 DN 之间的通信协议均采用了普通的 TEXT 协议。而在TEXT协议下，对于 DN 节点的计算负载会有损耗，通过在 CN 的执行层增加BINARY 协议的通信接口，可以提升并发下的吞吐，降低 DN 节点的 CPU 消耗。
2. 2、目前的执行计划中，如果 FQS 无法进行下推处理，则会流转到 PQ 的下推框架中执行，后续可以考虑单条执行计划中融合 FQS 与 PQ 的下推执行，进一步的，LibraDB 的 AP 执行算子也可以在代价估计时被考虑，从而让单条执行计划包含行列混合计划，实现真正意义上的 HTAP。
﹀
﹀
﹀
-- 更多精彩 --
入选国际数据库顶级会议ICDE，腾讯云数据库技术创新获权威认可
↓↓点击阅读原文，了解更多优惠
