关于shardingsphere:DistSQL-深度解析打造动态化的分布式数据库

35次阅读

共计 10958 个字符，预计需要花费 28 分钟才能阅读完成。

一、背景

自 ShardingSphere 5.0.0 版本公布以来，DistSQL 为 ShardingSphere 生态带来了弱小的动静治理能力，通过 DistSQL，用户能够：

  • 在线创立逻辑库；
  • 动静配置规定（包含分片、数据加密、读写拆散、数据库发现、影子库、全局规定等）；
  • 实时调整存储资源；
  • 即时切换事务类型；
  • 随时开关 SQL 日志；
  • 预览 SQL 路由后果；

  • …
    同时，随着应用场景的深刻，越来越多的 DistSQL 个性被发掘出来，泛滥宝藏语法也受到了用户的青睐。

    二、内容提要

    本文将以数据分片为例，深度解析 Sharding 相干 DistSQL 的利用场景和应用技巧。同时，通过实际案例将一系列 DistSQL 语句进行串联，为读者展示一套残缺实用的 DistSQL 分片治理计划。

本文案例中将用到以下 DistSQL：

三、实战演练

3.1 场景需要

  • 创立两张分片表 t_order 和 t_order_item；
  • 两张表均以 user_id 字段分库，以 order_id 字段分表；
  • 分片数量为 2 库 x 3 表；

如图：

3.2 环境筹备

  1. 筹备可供拜访的 MySQL 数据库实例，创立两个新库 demo_ds_0、demo_ds_1；

    以 MySQL 为例，也可应用 PostgreSQL 或 openGauss 数据库。

2. 部署 Apache ShardingSphere-Proxy 5.1.2 和 Apache ZooKeeper，其中 ZooKeeper 将作为治理核心，存储 ShardingSphere 元数据信息；

3. 配置 Proxy conf 目录下的 server.yaml，内容如下；

mode:
type: Cluster
  repository:
    type: ZooKeeper
    props:
      namespace: governance_ds
      server-lists: localhost:2181  # ZooKeeper 地址
      retryIntervalMilliseconds: 500
      timeToLiveSeconds: 60
      maxRetries: 3
      operationTimeoutMilliseconds: 500
  overwrite: false

rules:
  - !AUTHORITY
    users:
      - root@%:root
  1. 启动 ShardingSphere-Proxy，并应用客户端连贯到 Proxy，例如
mysql -h 127.0.0.1 -P 3307 -u root -p

3.3 增加存储资源

  1. 创立逻辑数据库

    CREATE DATABASE sharding_db;USE sharding_db;

  2. 增加存储资源，对应之前筹备的 MySQL 数据库

    ADD RESOURCE ds_0 (
HOST=127.0.0.1,
 PORT=3306,
 DB=demo_ds_0,
 USER=root,
 PASSWORD=123456
), ds_1(
 HOST=127.0.0.1,
 PORT=3306,
 DB=demo_ds_1,
 USER=root,
 PASSWORD=123456
);

  3. 查看存储资源

    mysql> SHOW DATABASE RESOURCES\\G;
*************************** 1. row ***************************
                        name: ds_1
                        type: MySQL
                        host: 127.0.0.1
                        port: 3306
                          db: demo_ds_1
                         -- 省略局部属性
*************************** 2. row ***************************
                        name: ds_0
                        type: MySQL
                        host: 127.0.0.1
                        port: 3306
                          db: demo_ds_0
                         -- 省略局部属性

    查问语句加了 \G 是为了让输入格局更易读，非必须。

    3.4 创立分片规定

    ShardingSphere 分片规定反对“惯例分片”和“主动分片”两种配置形式，它们的分片成果是等价的，区别在于“主动分片”的配置定义更加简洁，而“惯例分片”配置形式更加灵便自主。
    还不理解“主动分片”的同学能够参考：
    《DistSQL：像数据库一样应用 Apache ShardingSphere》
    《分片利器 AutoTable：为用户带来「管家式」分片配置体验》
    接下来，咱们将采纳“惯例分片”的形式，应用 INLINE 表达式算法实现需求形容的分片场景。

    3.4.1 主键生成器

  4. 创立主键生成器

    CREATE SHARDING KEY GENERATOR snowflake\_key\_generator \(TYPE(NAME=SNOWFLAKE)
);

  5. 查问主键生成器

    mysql> SHOW SHARDING KEY GENERATORS;
+-------------------------+-----------+-------+
| name                    | type      | props |
+-------------------------+-----------+-------+
| snowflake_key_generator | snowflake | {}    |

  6. row in set (0.01 sec)

  7. 创立一个分库算法，由 t_order 和 t_order_item 共用

    -- 分库时按 user_id 对 2 取模
CREATE SHARDING ALGORITHM database_inline (TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="ds_${user_id % 2}"))
);

  8. 为 t_order 和 t_order_item 创立不同的分表算法

    -- 分表时按 order_id 对 3 取模
CREATE SHARDING ALGORITHM t_order_inline (TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="t_order_${order_id % 3}"))
);
CREATE SHARDING ALGORITHM t_order_item_inline (TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="t_order_item_${order_id % 3}"))
);

  9. 查问分片算法

    mysql> SHOW SHARDING ALGORITHMS;
+---------------------+--------+---------------------------------------------------+
| name                | type   | props                                             |
+---------------------+--------+---------------------------------------------------+
| database_inline     | inline | algorithm-expression=ds_${user_id % 2}            |
| t_order_inline      | inline | algorithm-expression=t_order_${order_id % 3}      |
| t_order_item_inline | inline | algorithm-expression=t_order_item_${order_id % 3} |

  10. rows in set (0.00 sec)

    #### 3.4.3 默认分片策略
分片策略由分片键和分片算法组成，其概念可参考[《分片策略》](https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/sharding/)
分片策略蕴含分库策略（databaseStrategy）和分表策略（tableStrategy）。

  11. 创立默认分库策略

    CREATE DEFAULT SHARDING DATABASE STRATEGY (TYPE=STANDARD,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM=database_inline);

  12. 查问默认策略

    mysql> SHOW DEFAULT SHARDING STRATEGY\G;
*************************** 1. row ***************************
                 name: TABLE
                 type: NONE
      sharding_column:
 sharding_algorithm_name:
 sharding_algorithm_type:
sharding_algorithm_props:
*************************** 2. row ***************************
                 name: DATABASE
                 type: STANDARD
      sharding_column: user_id
 sharding_algorithm_name: database_inline
 sharding_algorithm_type: inline

  13. rows in set (0.00 sec)

    > 未配置默认分表策略，因而 TABLE 类型的默认策略是 NONE。#### 3.4.4 分片规定

  14. t_order

    CREATE SHARDING TABLE RULE t_order (DATANODES("ds_${0..1}.t_order_${0..2}"),
TABLE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_inline),
KEY_GENERATE_STRATEGY(COLUMN=order_id,KEY_GENERATOR=snowflake_key_generator)
);
  15. DATANODES 指定了分片表的数据节点；
  • TABLE_STRATEGY 指定了分表策略，其中 SHARDING_ALGORITHM 应用了已创立好的分片算法 t_order_inline；
  • KEY_GENERATE_STRATEGY 指定该表的主键生成策略，若不须要主键生成，可省略该配置。

  • t_order_item

    CREATE SHARDING TABLE RULE t_order_item (DATANODES("ds_${0..1}.t_order_item_${0..2}"),
TABLE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_item_inline),
KEY_GENERATE_STRATEGY(COLUMN=order_item_id,KEY_GENERATOR=snowflake_key_generator)
);

  • 查问分片规定

    mysql> SHOW SHARDING TABLE RULES\G;
*************************** 1. row ***************************
                          table: t_order
              actual_data_nodes: ds_${0..1}.t_order_${0..2}
            actual_data_sources:
         database_strategy_type: STANDARD
       database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
            table_strategy_type: STANDARD
          table_sharding_column: order_id
  table_sharding_algorithm_type: inline
 table_sharding_algorithm_props: algorithm-expression=t_order_${order_id % 3}
            key_generate_column: order_id
             key_generator_type: snowflake
            key_generator_props:
*************************** 2. row ***************************
                          table: t_order_item
              actual_data_nodes: ds_${0..1}.t_order_item_${0..2}
            actual_data_sources:
         database_strategy_type: STANDARD
       database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
            table_strategy_type: STANDARD
          table_sharding_column: order_id
  table_sharding_algorithm_type: inline
 table_sharding_algorithm_props: algorithm-expression=t_order_item_${order_id % 3}
            key_generate_column: order_item_id
             key_generator_type: snowflake

  • rows in set (0.00 sec)

    💡至此，`t_order` 和 ` t_order_item ` 的分片规定已配置实现。什么？有点简单？好吧，其实也能够疏忽独自创立主键生成器、分片算法、默认策略的步骤，一步实现分片规定，让咱们来加点糖。### 3.5 语法糖
当初，需要中要减少一张分片表 ` t_order_detail`，咱们能够这样一步实现分片规定的创立：

    CREATE SHARDING TABLE RULE t_order_detail (
    DATANODES(“ds_${0..1}.t_order_detail_${0..1}”),
    DATABASE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM(TYPE(NAME=INLINE,PROPERTIES(“algorithm-expression”=”ds_${user_id % 2}”)))),
    TABLE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM(TYPE(NAME=INLINE,PROPERTIES(“algorithm-expression”=”t_order_detail_${order_id % 3}”)))),
    KEY_GENERATE_STRATEGY(COLUMN=detail_id,TYPE(NAME=snowflake))
    );

    ** 阐明 **：上述语句中指定了分库策略、分表策略、主键生成策略，但都没有援用曾经存在的算法，因而 DistSQL 引擎会主动用输出的表达式创立相应的算法，供 `t_order_detail ` 分片规定应用。

  • 主键生成器

    mysql> SHOW SHARDING KEY GENERATORS;
+--------------------------+-----------+-------+
| name                     | type      | props |
+--------------------------+-----------+-------+
| snowflake_key_generator  | snowflake | {}    |
| t_order_detail_snowflake | snowflake | {}    |

  • rows in set (0.00 sec)

  • 分片算法

    mysql> SHOW SHARDING ALGORITHMS;
+--------------------------------+--------+-----------------------------------------------------+
| name                           | type   | props                                               |
+--------------------------------+--------+-----------------------------------------------------+
| database_inline                | inline | algorithm-expression=ds_${user_id % 2}              |
| t_order_inline                 | inline | algorithm-expression=t_order_${order_id % 3}        |
| t_order_item_inline            | inline | algorithm-expression=t_order_item_${order_id % 3}   |
| t_order_detail_database_inline | inline | algorithm-expression=ds_${user_id % 2}              |
| t_order_detail_table_inline    | inline | algorithm-expression=t_order_detail_${order_id % 3} |

  • rows in set (0.00 sec)

  • 分片规定

    mysql> SHOW SHARDING TABLE RULES\G;
*************************** 1. row ***************************
                          table: t_order
              actual_data_nodes: ds_${0..1}.t_order_${0..2}
            actual_data_sources:
         database_strategy_type: STANDARD
       database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
            table_strategy_type: STANDARD
          table_sharding_column: order_id
  table_sharding_algorithm_type: inline
 table_sharding_algorithm_props: algorithm-expression=t_order_${order_id % 3}
            key_generate_column: order_id
             key_generator_type: snowflake
            key_generator_props:
*************************** 2. row ***************************
                          table: t_order_item
              actual_data_nodes: ds_${0..1}.t_order_item_${0..2}
            actual_data_sources:
         database_strategy_type: STANDARD
       database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
            table_strategy_type: STANDARD
          table_sharding_column: order_id
  table_sharding_algorithm_type: inline
 table_sharding_algorithm_props: algorithm-expression=t_order_item_${order_id % 3}
            key_generate_column: order_item_id
             key_generator_type: snowflake
            key_generator_props:
*************************** 3. row ***************************
                          table: t_order_detail
              actual_data_nodes: ds_${0..1}.t_order_detail_${0..1}
            actual_data_sources:
         database_strategy_type: STANDARD
       database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
            table_strategy_type: STANDARD
          table_sharding_column: order_id
  table_sharding_algorithm_type: inline
 table_sharding_algorithm_props: algorithm-expression=t_order_detail_${order_id % 3}
            key_generate_column: detail_id
             key_generator_type: snowflake

  • rows in set (0.01 sec)

    ** 阐明 **：`CREATE SHARDING TABLE RULE ` 语句中，DATABASE_STRATEGY、TABLE_STRATEGY 和 KEY_GENERATE_STRATEGY 均能够援用已有算法，达到复用的目标，也能够通过语法糖疾速定义，差别是会创立额定的算法对象。用户可依据场景灵便搭配应用。### 3.6 配置验证
规定创立结束后，咱们能够通过如下形式进行验证：##### 3.6.1 查看节点散布
DistSQL 提供 `SHOW SHARDING TABLE NODES ` 的语法用于查看节点散布，帮忙用户疾速总览分片表的散布状况。应用形式如下：

从分片表的节点散布察看，与需要形容的散布统一。

3.6.2 SQL 预览

SQL 预览，也是验证配置的一种快捷的形式，语法是 PREVIEW sql：

  1. 无分片键查问，全路由
  1. 指定 user_id 查问，单库路由

3. 指定 user_id 和 order_id，单表路由

单表路由扫描的分片表起码，效率最高。

3.7 辅助查问 DistSQL

在系统维护过程中，可能会呈现不再应用的算法或存储资源须要开释，或是想要开释的资源被援用了无奈删除，以下 DistSQL 能够为咱们提供帮忙：

3.7.1 查问未应用的资源

  1. 语法：SHOW UNUSED RESOURCES
  2. 示例：

3.7.2 查问未应用的主键生成器

  1. 语法：SHOW UNUSED SHARDING KEY GENERATORS
  2. 示例：

3.7.3 查问未应用的分片算法

1. 语法：SHOW UNUSED SHARDING ALGORITHMS

  1. 示例：

3.7.4 查问应用指标存储资源的规定

  1. 语法：SHOW RULES USED RESOURCE

  2. 示例：

    应用了该资源的所有规定都会查问进去，不限于 Sharding Rule。

3.7.5 查问应用指标主键生成器的分片规定

  1. 语法：SHOW SHARDING TABLE RULES USED KEY GENERATOR

  2. 示例：

    3.7.6 查问应用指标算法的分片规定

  3. 语法：SHOW SHARDING TABLE RULES USED ALGORITHM

  4. 示例：

    4、结语

    本篇以罕用的数据分片场景为例，介绍了 DistSQL 的应用流程和利用技巧。同时，DistSQL 提供了灵便的语法糖以帮忙缩小操作步骤，用户可灵便抉择应用。
    在分片场景下，除了 INLINE 算法，DistSQL 也能完满反对其余的规范分片、复合分片、Hint 分片、自定义类分片算法，更多的利用案例将在后续的文章中为大家解读，敬请期待。
    以上就是本次分享的全部内容，如果读者对 Apache ShardingSphere 有任何疑难或倡议，欢送在 GitHub issue 列表提出，或可返回中文社区交换探讨。

GitHub issue：https://github.com/apache/shardingsphere/issues

奉献指南：https://shardingsphere.apache.org/community/cn/contribute/

中文社区：https://community.sphere-ex.com/

5、参考文献

  1. 概念 DistSQL：https://shardingsphere.apache.org/document/current/cn/concepts/distsql/
  2. 概念 分布式主键：https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/key-generator/
  3. 概念 分片策略：https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/sharding/
  4. 概念 行表达式：https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/inline-expression/
  5. 内置分片算法：https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-jdbc/builtin-algorithm/sharding/
  6. 用户手册：DistSQLhttps://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/distsql/syntax/

作者

江龙滔，SphereEx 中间件研发工程师，Apache ShardingSphere Committer。
次要负责 DistSQL 及平安相干个性的翻新与研发。

欢送点击链接，理解更多内容：
Apache ShardingSphere 官网：https://shardingsphere.apache.org/

Apache ShardingSphere GitHub 地址：https://github.com/apache/shardingsphere

SphereEx 官网：https://www.sphere-ex.com

欢送增加社区经理微信（ss_assistant_1）退出交换群，与泛滥 ShardingSphere 爱好者一起交换。

正文完
shardingsphere
发表至： shardingsphere
2022-07-21
 0
关于shardingsphere:终于可以一行代码也不用改了ShardingSphere-原生驱动问世
关于shardingsphere:『征文精选』ShardingSphereProxyBase-事务基于-Seata-验证
关于shardingsphere:ShardingSphere-荣获一等奖2022-年中国开源创新大赛成绩单公布
关于shardingsphere:Apache-ShardingSphere-企业行｜走进中信云网