ShardingSphere 5.3.0 升级解读：DistSQL 对象体系首次揭秘！

前言

DistSQL（Distributed SQL）是 Apache ShardingSphere 特有的操作语言，它自从 5.0.0-Beta 版本面世以来，始终保持着高速的迭代，并逐步为用户提供了规则管理、集群管理、元数据管理等诸多特性，越发迈向『成熟』。

与此同时，DistSQL 又仍然十分『年轻』。ShardingSphere 社区时常会收到关于 DistSQL 的想法和建议，它们为 DistSQL 的成长注入活力，也带来更大的想象空间。经过不断总结与碰撞，在 5.3.0 版本来临之际，社区为 DistSQL 完成了一次系统性重构，对众多语法进行了优化升级。由于调整内容较多，本文将为读者一一解读。

名词解释

为了便于理解和交流，也方便 DistSQL 的语法设计，我们对 DistSQL 管理的对象进行了梳理，根据对象的特点和其作用范围，作出分类。

节点

参考下图，这是一个经典的 ShardingSphere 混合架构。相应的名词解释如下：

计算节点

ShardingSphere-JDBC ShardingSphere-Proxy 实例均负责提供「计算能力」它们被称为计算节点（Compute Node）

存储节点

物理数据库 ds_0，ds_1 和 ds_2 提供数据存储能力，对应的被称为存储节点（Storage Node）。根据存储节点的形态不同，我们将实例级节点称为 Storage Node（如一个 MySQL instance），库级节点称为 Storage Unit（如一个 MySQL database）。一个 Storage Node 可以提供多个 Storage Units。

实例级对象

实例级对象（Instance Object）的作用域是整个计算节点实例，它们的能力影响所有逻辑库中的操作。

全局规则

全局规则（Global Rules）包含 Authority、Transaction、SQL Parser、SQL Translator 等在 ShardingSphere 全局范围内生效的规则配置，它们分别控制了认证和授权、分布式事务、SQL 解析、SQL 翻译等功能引擎，是计算节点运行时的基础配置。值得一提的是，在 ShardingSphere 中全局规则均有默认值，用户如无特殊需要，保持默认即可。

分布式变量

分布式变量（Dist Variables）是 ShardingSphere 中存在的一组系统级变量，它们的配置同样影响到整个计算节点。取名 Dist Variables，是为了方便用户在使用时与存储节点自身的 Variables 作区分，避免混淆。同时，对分布式变量值的修改会同步到整个计算节点集群，是真正的分布式配置。分布式变量包含：

• SQL_SHOW
• MAX_CONNECTIONS_SIZE_PER_QUERY
• SQL_FEDERATION_TYPE 

等常用的计算节点属性，完整覆盖 YAML 中的 props 配置。

作业

作业（Job）特指 Proxy 计算节点提供的异步作业的能力，例如为用户提供数据迁移的 Migration Job，未来还可能提供更丰富的异步作业功能。

库级对象

库级对象（Database Object）主要用于对逻辑库级别的元数据进行管理，提供 REFRESH DATABASE METADATA、EXPORT DATABASE CONFIGURATION 等元数据的操作。

表级对象

表级对象（Table Object）是指其作用域为特定逻辑表的对象，可以简单的理解为表级别的规则配置。表级对象包含常用的 Broadcast（广播表）、Encrypt（数据加密）、Sharding（数据分片）、Single（单表）等规则，这些规则的名称往往与逻辑表名相同。

关系型对象

关系型对象（Relation Object）不是用于管理某个特定的库或表，它们用于描述某一组对象之间的关联关系。当前关系型对象包含两类：描述存储节点关系的 DB_Discovery Rule 和描述分片表关系的 Sharding Table Reference Rule。

流量型对象

流量型对象（Traffic Object）用于管理 ShardingSphere 中的数据流量，包含 Readwrite-splitting Rule 和 Shadow Rule 这类的流量规则。

小结

将以上概念整理汇总，就形成了 DistSQL 管理对象的体系结构图，如下所示：

有了这张图，我们就可以更好对 DistSQL 进行系统性的分类和语法设计了！

语法变更

随着本次 5.3.0 版本的发布，DistSQL 的升级也已初步完成。根据 ShardingSphere 社区的长期规划，我们对 DistSQL 语句进行了细致的梳理和重构，使每一个语句都具有更明确的定位和更好的向前兼容性。现在，是时候为您呈现了！本节将以前后对比的方式展现变更的具体内容。

节点

计算节点

解读：关键字 INSATNCE 更新为 COMPUTE NODE。

存储节点

解读：关键字 RESOURCE 更新为 STORAGE NODE / STORAGE UNIT，分别对应实例级存储和库级存储。

其中 STORAGE NODE 为预留暂未使用。

实例级对象

全局规则

全局规则相关语法本次未有调整。

分布式变量

解读：VARIABLE 前加 DIST 关键字，表示分布式变量。

MIGRATION 作业

解读：

• PROCESS CONFIGURATION 关键字调整为 RULE；
• 因 MIGRATION RULE 具有默认值，移除 CREATE 和 DROP 操作；
• 其他语法未调整。

库级对象

解读：

• CONFIG 统一为 CONFIGURATION，更加精确；
• 新增 REFRESH DATABASE METADATA 语句，从治理中心拉取配置。强制刷新本地元数据。

表级对象

广播表

解读：广播表移除 SHARDING 关键字。

数据加密

数据加密相关语法本次未有调整，请参考官方文档 [1] 即可。

分片表

解读：

• 移除独立创建分片算法和分布式 ID 生成器的语法，集成在 CREATE SHARDING TABLE RULE 的规则定义中；
• 其他语法未调整。

单表

解读：默认单表路由只能有一个，无法重复创建，由 CREATE 更新为 SET 方式。

关系型对象

数据库发现

解读：

• 移除独立创建 DB_DISCOVERY TYPE 和 HEARTBEAT 的语法，集成在 CREATE DB_DISCOVERY RULE 的规则定义中；
• 其他语法未调整。

绑定表

解读：调整关键字，增加 ruleName，方便用户管理操作。

流量型对象

读写分离

解读：读写分离相关语法本次没有重大调整，仅根据存储节点的关键字变化，将语句中的 RESOURCE 替换为 STORAGE_UNIT。例如：

CREATE READWRITE_SPLITTING RULE ms_group_0 (
WRITE_STORAGE_UNIT=write_ds,
READ_STORAGE_UNITS(read_ds_0,read_ds_1),
TYPE(NAME="random")
);

影子库

解读：

• 移除独立创建影子算法的语法，集成在 CREATE SHADOW RULE 的规则定义中；
• 新增 ALTER 和 SHOW 默认影子算法的语句，与 CREATE DEFAULT SHADOW ALGORITHM 对应。

参数规范优化

除了语法的重大升级，本次调整的另一个亮点，是进一步简化了用户使用 DistSQL 的复杂度。主要内容有：

• 引用内置策略类型、内置算法类型时，可省略引号；
• PROPERTIES 中的 value 类型从 string（字符串）调整为 literal（字面量），literal 可支持字符串、整形及布尔值。

示例

举例来说，此前用户创建分片规则时，算法部分需要满足以下描述规则：

TYPE(NAME="MOD",PROPERTIES("sharding-count"="4"))

• 其中 "MOD" 是算法类型名称，属于字符串，需要引号；
• PROPERTIES 的 value 虽然是 "4"，也属于字符串，需要引号。

在本次优化后，引用内置算法类型可省略引号，PROPERTIES value 若非字符串，也可省略引号。因此，以下写法也是合法等效的：

TYPE(NAME=MOD,PROPERTIES("sharding-count"=4))。

实例演示

除了『主要变更』中列举的内容，还有一些语法也受到影响，但调整较小。

如使用 CREATE SHARDING TABLE RULE 语句创建自动分片规则时，此前须使用 RESOURCES(ds_0, ds_1) 的方式引用存储资源，今后则对应的调整为 STORAGE_UNITS(ds_0, ds_1)。

下面让我们通过一个分片场景的实例来展示全新 DistSQL 的应用：

创建逻辑库

CREATE DATABASE sharding_db;
USE sharding_db;

注册存储资源

REGISTER STORAGE UNIT ds_0 (
    HOST="127.0.0.1",
    PORT=3306,
    DB="ds_0",
    USER="root",
    PASSWORD="root"
),ds_1 (
    HOST="127.0.0.1",
    PORT=3306,
    DB="ds_1",
    USER="root",
    PASSWORD="root"
);

创建分片规则

CREATE SHARDING TABLE RULE t_order(
STORAGE_UNITS(ds_0,ds_1),
SHARDING_COLUMN=order_id,
TYPE(NAME=MOD,PROPERTIES("sharding-count"=4)),
KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME=SNOWFLAKE))
);

创建分片表

CREATE TABLE t_order (
  `order_id` int NOT NULL,
  `user_id` int NOT NULL,
  `status` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`order_id`)
);

数据读写

INSERT INTO t_order (order_id, user_id, status) VALUES 
(1,1,'OK'),
(2,2,'OK'),
(3,3,'OK');

SELECT * FROM t_order;

删除表

DROP TABLE IF EXISTS t_order;

删除分片规则

DROP SHARDING TABLE RULE t_order;

移除存储节点

UNREGISTER STORAGE UNIT ds_0, ds_1;

删除逻辑库

DROP DATABASE sharding_db;

总结

以上就是本次分享的全部内容，关于 DistSQL 语法的更多信息，请参考官网文档 [1]。

如果读者对 Apache ShardingSphere 有任何疑问或建议，欢迎在 GitHub issue 列表 [2] 提出.

🔗

[1] DistSQL 语法文档：

​​https://shardingsphere.apache.org/document/5.3.0/cn/user-manual/shardingsphere-proxy/distsql/syntax/​​

[2] GitHub issue 列表：

​​https://github.com/apache/shardingsphere/issues​​

文章转载自公众号：  ShardingSphere官微