关于shardingsphere:SQL-居然还能在-Apache-ShardingSphere-上实现这些功能

在去年 10 月 5.0.0-alpha 版本公布之后，Apache ShardingSphere 经验了长达 8 个多月的继续开发与优化，终于在 6 月 25 日正式迎来了 5.0.0-beta 版本的公布。
本次 5.0.0-beta 版除了提供 DistSQL 这样的新个性外，对 ShardingSphere 内核也进行了加强，次要体现在 SQL 根底解析能力加强 、SQL 规范路由能力晋升 和 SQL 分布式查问能力加强这三方面。通过这三方面优化，不仅进一步提高了对 MySQL，PostgreSQL，SQLServer 和 Oracle 数据库的根底 SQL 解析能力，而且大幅度提高了对用户 SQL 的反对度，特地针对跨数据库实例的关联 SQL 进行了更有针对性的优化。本文将率领大家一起，探秘 5.0.0-beta 版内核加强个性。

端正强
Apache ShardingSphere Committer，SphereEx Java 高级工程师。酷爱开源，乐于分享，目前专一于 Apache ShardingSphere 数据库中间件开发。

内核原理

在探秘 5.0.0-beta 版内核加强之前，让咱们先来回顾下 ShardingSphere 的内核原理。如下图所示，ShardingSphere 内核次要由解析引擎、路由引擎、改写引擎、Standard 执行引擎、Federate 执行引擎、归并引擎等组成。Federate 执行引擎是本次 5.0.0-beta 版本引入的新性能，用于加强分布式查问能力。

• 解析引擎：解析引擎负责进行 SQL 解析，具体能够分为词法剖析和语法分析。词法剖析负责将 SQL 语句拆分为一个个不可再分的单词，而后语法分析器对 SQL 进行了解，并最终失去解析上下文。解析上下文包含表、选择项、排序项、分组项、聚合函数、分页信息、查问条件以及可能须要批改的占位符标记；
• 路由引擎：路由引擎依据解析上下文，匹配用户配置的分片策略，并生成路由后果，目前反对分片路由和播送路由；
• 改写引擎：改写引擎负责将 SQL 改写为在实在数据库中能够正确执行的语句，SQL 改写能够分为正确性改写和优化改写；
• Standard 执行引擎：Standard 执行引擎负责将路由和改写实现之后的实在 SQL 平安且高效地发送到底层数据源执行；
• Federate 执行引擎：Federate 执行引擎负责解决跨多个数据库实例的分布式查问，底层应用的 Calcite 基于关系代数和 CBO 优化，通过最优执行打算查问出后果；
• 归并引擎：归并引擎负责将从各个数据节点获取的多数据后果集，组合成为一个后果集并正确的返回至申请客户端。

在回顾了 ShardingSphere 内核原理后，上面让咱们来具体看看 5.0.0-beta 版内核加强。

SQL 根底解析能力加强

SQL 解析引擎是 ShardingSphere 我的项目的基石，也是我的项目中最稳固的基础设施。在 5.0.0-alpha 版中，咱们将 SQL 解析引擎与主我的项目齐全剥离，为开发者提供了一套独立的 SQL 解析引擎组件，相比其余老牌 SQL 解析引擎，ShardingSphere SQL 解析引擎具备易于扩大和更欠缺的 SQL 方言反对等个性。目前，用户可将 ShardingSphere SQL 解析引擎作为独立解析器，进行 SQL 解析，详见官网链接(https://shardingsphere.apache…。

在本次公布的 5.0.0-beta 中，咱们更加关注 SQL 解析引擎最重要的两个掂量指标——性能和 SQL 反对度。对于性能问题，ShardingSphere 已通过缓存将 SQL 解析的性能损耗降至最低。对于社区始终关注的 SQL 反对度问题，ShardingSphere 联合多个不同反馈渠道，在本次公布的 5.0.0-beta 版中进行了大量的 SQL 解析优化和反对度晋升。

首先是 ShardingSphere 社区通过协定层反推过来的 SQL 优化，在 SQL 反对度晋升的同时，Proxy 接入端也越来越稳固，特地是 ShardingSphere-Proxy PostgreSQL 5.0.0-beta 版，在各个方面都有较大晋升，欢送大家下载应用。此外，针对 MySQL，PostgreSQL，openGauss 数据库的 Proxy 接入端介绍，也会在后续为大家带来技术分享。

其次是 SphereEx 性能测试团队，在应用 sysbench 和 tpcc 进行压测过程中，反馈了很多测试用例中不反对的 SQL。针对 SphereEx 性能测试团队反馈的 SQL 不反对项，咱们在 5.0.0-beta 版进行了针对性优化，目前曾经全副反对。

针对社区反馈问题较多的 PostgreSQL，SQLServer 和 Oracle 等数据库中的 SQL 反对度问题，ShardingSphere 社区通过外围团队成员领导反对、社区同学大规模参加的形式进行晋升。特地是在本次作为 Apache 优良社区加入的 Google Summer Code 中，海内同学做出了较大奉献。

在泛滥社区贡献者的致力之下，ShardingSphere 5.0.0-beta 版的 SQL 反对度获得了大幅度晋升。为了打造更好的我的项目基石，咱们会继续晋升优化 SQL 反对度，期待有更多的贡献者能够参加到这项工作中来，一起晋升 SQL 反对度。

SQL 规范路由能力晋升

在 SQL 反对度晋升的根底上，ShardingSphere 5.0.0-beta 版也对 SQL 路由逻辑进行了加强，重点优化了 DDL 语句 和 DQL 语句的路由逻辑。
在 5.0.0-beta 版优化 DDL 语句路由逻辑前，路由引擎只能解决 DDL 语句中单表的路由，对于蕴含多表的场景，路由解决并不是很欠缺。
以 ALTER TABLE 语句为例，假如 t_order 和 t_order_item 为分片表，并且未设置为绑定表关系。在优化前执行如下 SQL 会抛出 Table t_order_item does not exist. 异样，路由逻辑只会针对 t_order 表进行路由，漠视了 t_order_item 表的数据分布状况。

ALTER TABLE t_order ADD CONSTRAINT t_order_fk FOREIGN KEY (order_id) REFERENCES t_order_item (order_id);
想要反对 DDL 语句多表组合路由，须要思考许多简单的组合场景。依照 ShardingSphere 中对于表的分类，咱们能够将表划分为分片表（sharding table）、播送表（broadcast table）和单表（single table），分片表又能够组成绑定表（binding table）。对于表的具体概念能够参考上面的阐明。

• 分片表（sharding table）：又叫逻辑表，程度拆分的数据库（表）的雷同逻辑和数据结构表的总称。例：订单数据依据主键尾数拆分为 10 张表，别离是 t_order_0 到 t_order_9，他们的逻辑表名为 t_order；
• 绑定表（binding table）：指分片规定统一的主表和子表。例如：t_order 表和 t_order_item 表，均依照 order_id 分片，则此两张表互为绑定表关系；
• 播送表（broadcast table）：指所有的分片数据源中都存在的表，表构造和表中的数据在每个数据库中均完全一致。实用于数据量不大且须要与海量数据的表进行关联查问的场景，例如：字典表；
• 单表（single table）：指所有的分片数据源中只存在惟一一张的表。实用于数据量不大且不须要做任何分片操作的场景。

对于以上三种次要类型的表进行排列组合，能够失去如下 9 种组合场景：

针对这 9 种表的组合场景，ShardingSphere 5.0.0-beta 版对 ShardingTableBroadcastRoutingEngine 路由引擎进行了加强，齐全反对分片表 / 播送表和其余类型表的组合路由。当 SQL 语句中蕴含的表都为分片表，并且都是绑定表关系时，会依照原有主表驱动路由的形式进行解决。当 SQL 语句中蕴含的表都为分片表，但不是绑定表关系时，或者 SQL 语句中的局部表为分片表时，路由引擎会依照表所属的数据源先取交加，而后再对同数据源的物理表计算笛卡尔积，失去最终的路由后果。

因为表的组合关系简单，路由后果也存在多种状况。当分片表只配置了单个数据节点，并且散布在同一数据源时，DDL 语句多表组合的笛卡尔积路由后果是非法的，而当分片表配置了多个数据节点时，笛卡尔积路由后果往往是非法的。路由引擎须要可能判断出非法路由后果和非法路由后果，对于非法的路由后果，路由引擎须要抛出适合的异样信息。

为了保障用户应用 ShardingSphere 的安全性，针对不反对的 SQL 或非法 SQL，ShardingSphere 引入了前置校验（pre validate）和后置校验（post validate）。前置校验次要用于校验 SQL 语句的根本信息是否非法，如：表是否存在、索引是否存在、多个单表是否存在于同一个数据源中。后置校验次要用于校验路由的后果是否非法，如：在 ALTER TABLE 语句中增加外键束缚时，咱们认为所有的主表（primary table）都胜利增加外键束缚为非法路由后果，否则将抛出异样信息。

对于 DQL 语句路由逻辑的优化，次要是针对跨数据库实例 JOIN 及子查问进行的。路由引擎在解决 DQL 语句时，如果以后语句中的表跨多个数据库实例，则会应用 ShardingTableBroadcastRoutingEngine 路由引擎来解决。在上面一个局部，将会对 SQL 分布式查问能力加强进行介绍。

SQL 分布式查问能力加强

在 ShardingSphere 5.0.0-beta 版前，跨数据库实例进行 JOIN 及子查问始终是令用户头疼的问题。在同时应用多个数据库实例时，业务研发人员须要时刻留神查问 SQL 的应用领域，尽量避免跨数据库实例进行 JOIN 及子查问，这使得业务层面的性能受到了数据库限度。

在 ShardingSphere 5.0.0-beta 版中，借助于 Apache Calcite 和 ShardingSphere 本身的解析、路由和执行能力，通过路由引擎进行判断，将跨数据实例的分布式查问 SQL，交由 Federate 执行引擎解决，完满反对了跨数据库实例的 JOIN 及子查问。

同时，针对 ShardingSphere 尚不反对的一些简单查问语句，咱们也在最新的 master 分支进行了尝试，应用 Federate 执行引擎进行解决，目前曾经获得了良好的成果。例如：查问语句应用 Having 过滤，子查问应用聚合函数，多聚合函数组合查问等语句，曾经失去了反对，反对的 SQL 样例如下。

SELECT user_id, SUM(order_id) FROM t_order GROUP BY user_id HAVING SUM(order_id) > 10;
SELECT (SELECT MAX(user_id) FROM t_order) a, order_id FROM t_order;
SELECT COUNT(DISTINCT user_id), SUM(order_id) FROM t_order;

ShardingSphere 最新 SQL 语句反对状况能够参考官网文档（https://shardingsphere.apache…）。5.0.0-beta 版对于分布式查问能力的加强是一个良好的开始，将来 ShardingSphere 将继续优化，一直加强分布式查问能力。

结语

Apache ShardingSphere 我的项目依然在疾速倒退中，在后续的版本中，咱们将继续晋升各种数据库的 SQL 反对度，不断完善内核性能，致力为社区提供更多弱小的性能，欢送继续关注并积极参与社区工作，也欢送点击“链接”下载应用。