Sharding-Proxy代理Mysql服务

最新推荐文章于 2024-08-05 15:00:31 发布
最新推荐文章于 2024-08-05 15:00:31 发布
阅读量1k 收藏 2
点赞数
分类专栏： Apache ShardingSphere springboot mysql 文章标签： mysql docker java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/vc33569/article/details/125933346
版权

目录

版本说明，写在前面的话

可视化工具连接配置说明

SQL分库分表概述

逻辑表

真实表

数据节点

绑定表

广播表

分片

分片键

分片算法

分片策略

SQL Hint

配置说明

分片规则

数据源配置

表配置

数据节点配置

分片策略配置

自增主键生成策略

行表达式,适用于单表无限分片，简化分库配置，理论上一个表可以无限向下

语法说明

配置数据节点

配置分片算法

1.单实例分片配置

1.1 单实例，单库，单表分片配置😉

1.2 单实例，单库，多表分片配置😉

1.3 单实例，多库，单表分片配置😉

1.4 单实例，多库，单表分片配置😉

2.多实例分片配置

2.1 多实例，多库，单表分片配置😉

2.2 多实例，多库，多表分片配置😉

测试

版本说明，写在前面的话

👀别像我一样没有注意，一步踩进5.0的坑中哦，这个真心是有点坑的，不能选择官方最新的内测5.0的版本，文档竟然和代码不匹配有想法的请直接看我的第一篇文章：Shardingsphere结合ES、Mysql MHA、Logstash实现全家桶

组件名称版本下载地址备注
ShardingSphere源码4.1.1github:  下载
gitee:    下载 		找不到的去官方找找，一定要下载4.1.1版本
ShardingProxy文档4.x.x文档地址

这篇文章就不写废话了，直接上干货，下载源码后，maven项目首先要做的事情，请自行处理，无法启动服务的话，和前辈请教一下，实在不行，运行官方提供的服务包吧。

服务包下载

源码运行

注意，我下面的代理服务全部基于4.1.1的源码进行，没有用服务包，需要用docker的可以按照官方自己做镜像，4.x版本的容器镜像，我没有在网上找到

可视化工具连接配置说明

      必须按照如下配置进行访问，否则无法正常使用工具连接服务，会一直跳，no database select,请注意，后面不再说明

SQL分库分表概述

逻辑表

水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为10张表，分别是t_order_0到t_order_9，他们的逻辑表名为t_order。

真实表

在分片的数据库中真实存在的物理表。即上个示例中的t_order_0到t_order_9。

数据节点

数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。

绑定表

指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明，如果SQL为：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在不配置绑定表关系时，假设分片键order_id将数值10路由至第0片，将数值11路由至第1片，那么路由后的SQL应该为4条，它们呈现为笛卡尔积：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在配置绑定表关系后，路由的SQL应该为2条：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

其中t_order在FROM的最左侧，ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略，那么t_order_item表的分片计算将会使用t_order的条件。故绑定表之间的分区键要完全相同。

广播表

指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。

分片

分片键

用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。

分片算法

通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

  • 精确分片算法

对应PreciseShardingAlgorithm，用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。

  • 范围分片算法

对应RangeShardingAlgorithm，用于处理使用单一键作为分片键的BETWEEN AND、>、<、>=、<=进行分片的场景。需要配合StandardShardingStrategy使用。

  • 复合分片算法

对应ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。

  • Hint分片算法

对应HintShardingAlgorithm，用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。

分片策略

包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供5种分片策略。

  • 标准分片策略

对应StandardShardingStrategy。提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。StandardShardingStrategy只支持单分片键，提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的，用于处理=和IN的分片。RangeShardingAlgorithm是可选的，用于处理BETWEEN AND, >, <, >=, <=分片，如果不配置RangeShardingAlgorithm，SQL中的BETWEEN AND将按照全库路由处理。

  • 复合分片策略

对应ComplexShardingStrategy。复合分片策略。提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。ComplexShardingStrategy支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。

  • 行表达式分片策略

对应InlineShardingStrategy。使用Groovy的表达式，提供对SQL语句中的=和IN的分片操作支持，只支持单分片键。对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的Java代码开发，如: t_user_$->{u_id % 8} 表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。

  • Hint分片策略

对应HintShardingStrategy。通过Hint指定分片值而非从SQL中提取分片值的方式进行分片的策略。

  • 不分片策略

对应NoneShardingStrategy。不分片的策略。

SQL Hint

对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录主键分库，而数据库中并无此字段。SQL Hint支持通过Java API和SQL注释(待实现)两种方式使用。

配置说明

分片规则

分片规则配置的总入口。包含数据源配置、表配置、绑定表配置以及读写分离配置等。

数据源配置

真实数据源列表。

表配置

逻辑表名称、数据节点与分表规则的配置。

数据节点配置

用于配置逻辑表与真实表的映射关系。可分为均匀分布和自定义分布两种形式。

  • 均匀分布

指数据表在每个数据源内呈现均匀分布的态势，例如：

db0
  ├── t_order0 
  └── t_order1 
db1
  ├── t_order0 
  └── t_order1

那么数据节点的配置如下：

db0.t_order0, db0.t_order1, db1.t_order0, db1.t_order1
  • 自定义分布

指数据表呈现有特定规则的分布，例如：

db0
  ├── t_order0 
  └── t_order1 
db1
  ├── t_order2
  ├── t_order3
  └── t_order4

那么数据节点的配置如下：

db0.t_order0, db0.t_order1, db1.t_order2, db1.t_order3, db1.t_order4

分片策略配置

对于分片策略存有数据源分片策略和表分片策略两种维度。

  • 数据源分片策略

对应于DatabaseShardingStrategy。用于配置数据被分配的目标数据源。

  • 表分片策略

对应于TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在与该数据的目标数据源内。故表分片策略是依赖与数据源分片策略的结果的。

两种策略的API完全相同。

自增主键生成策略

通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。

行表达式,适用于单表无限分片，简化分库配置，理论上一个表可以无限向下

语法说明

行表达式的使用非常直观，只需要在配置中使用${ expression }或$->{ expression }标识行表达式即可。 目前支持数据节点和分片算法这两个部分的配置。行表达式的内容使用的是Groovy的语法，Groovy能够支持的所有操作，行表达式均能够支持。例如：

${begin..end}表示范围区间

${[unit1, unit2, unit_x]}表示枚举值

行表达式中如果出现连续多个${ expression }或$->{ expression }表达式，整个表达式最终的结果将会根据每个子表达式的结果进行笛卡尔组合。

例如，以下行表达式：

${['online', 'offline']}_table${1..3}

最终会解析为：

online_table1, online_table2, online_table3, offline_table1, offline_table2, offline_table3

配置数据节点

对于均匀分布的数据节点，如果数据结构如下：

db0
  ├── t_order0 
  └── t_order1 
db1
  ├── t_order0 
  └── t_order1

用行表达式可以简化为：

db${0..1}.t_order${0..1}

或者

db$->{0..1}.t_order$->{0..1}

对于自定义的数据节点，如果数据结构如下：

db0
  ├── t_order0 
  └── t_order1 
db1
  ├── t_order2
  ├── t_order3
  └── t_order4

用行表达式可以简化为：

db0.t_order${0..1},db1.t_order${2..4}

或者

db0.t_order$->{0..1},db1.t_order$->{2..4}

对于有前缀的数据节点，也可以通过行表达式灵活配置，如果数据结构如下：

db0
  ├── t_order_00
  ├── t_order_01
  ├── t_order_02
  ├── t_order_03
  ├── t_order_04
  ├── t_order_05
  ├── t_order_06
  ├── t_order_07
  ├── t_order_08
  ├── t_order_09
  ├── t_order_10
  ├── t_order_11
  ├── t_order_12
  ├── t_order_13
  ├── t_order_14
  ├── t_order_15
  ├── t_order_16
  ├── t_order_17
  ├── t_order_18
  ├── t_order_19
  └── t_order_20
db1
  ├── t_order_00
  ├── t_order_01
  ├── t_order_02
  ├── t_order_03
  ├── t_order_04
  ├── t_order_05
  ├── t_order_06
  ├── t_order_07
  ├── t_order_08
  ├── t_order_09
  ├── t_order_10
  ├── t_order_11
  ├── t_order_12
  ├── t_order_13
  ├── t_order_14
  ├── t_order_15
  ├── t_order_16
  ├── t_order_17
  ├── t_order_18
  ├── t_order_19
  └── t_order_20

可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式笛卡尔积的特性，自动组合即可。 上面的示例，用行表达式可以简化为：

db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20}

或者

db->${0..1}.t_order_0$->{0..9}, db$->{0..1}.t_order_$->{10..20}

配置分片算法

对于只有一个分片键的使用=和IN进行分片的SQL，可以使用行表达式代替编码方式配置。

行表达式内部的表达式本质上是一段Groovy代码，可以根据分片键进行计算的方式，返回相应的真实数据源或真实表名称。

例如：分为10个库，尾数为0的路由到后缀为0的数据源， 尾数为1的路由到后缀为1的数据源，以此类推。用于表示分片算法的行表达式为：

ds${id % 10}

或者

ds$->{id % 10}

       

其他概念请自行阅览官方文档，这里只把上面的概念摘录一下，因为下面的配置要用到一些概念，方便阅览。下图的内容，标题3相关的内容，建议还是仔细阅读一下。

1.单实例分片配置

server.yaml 这个都一样，直接把配置贴在这里了，下面不写了，改其他配置文件就行
#governance:
#  name: governance_ds
#  registryCenter:
#    type: ZooKeeper
#    serverLists: localhost:2181
#    props:
#      retryIntervalMilliseconds: 500
#      timeToLiveSeconds: 60
#      maxRetries: 3
#      operationTimeoutMilliseconds: 500
#  overwrite: false

authentication:
  users:
    root:
      password: 12345678
    sharding:
      password: 12345678
      authorizedSchemas: sharding_db

props:
  max-connections-size-per-query: 1
  acceptor-size: 16  # The default value is available processors count * 2.
  executor-size: 16  # Infinite by default.
  proxy-frontend-flush-threshold: 128  # The default value is 128.
    # LOCAL: Proxy will run with LOCAL transaction.
    # XA: Proxy will run with XA transaction.
  # BASE: Proxy will run with B.A.S.E transaction.
  proxy-transaction-type: LOCAL
  proxy-opentracing-enabled: false
  proxy-hint-enabled: false
  query-with-cipher-column: true
  sql-show: true
  check-table-metadata-enabled: false

1.1 单实例，单库，单表分片配置😉

建表
       我就直接在第一篇文章中建立的mysql docker容器中新建了，建议还是用docker快速实现，把坑都踩一踩，别上了生成就尴尬了，使用mysql节点4，33083来建立单表示例，注意这是基于真实容器mysql的连接中新建数据表。
DROP SCHEMA IF EXISTS demo_singleton;
CREATE SCHEMA IF NOT EXISTS demo_singleton;
ShardingProxy代理配置
config-sharding.yaml
schemaName: sharding_db

# 数据源配置
dataSources:
  ds_0:
    url: jdbc:mysql://192.168.32.132:33083/demo_singleton
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
#分片规则配置
shardingRule:
#表分片规则
  tables:
    t_order:
      actualDataNodes: ds_${0}.t_order_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_id
  bindingTables:
    - t_order
启动服务，连接代理
创建表
CREATE TABLE IF NOT EXISTS ds_0.t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));

结果如下,配置成功

1.2 单实例，单库，多表分片配置😉

修改config-sharding.yaml
# 逻辑库,也可以说是虚拟表空间,实际上并不存在
schemaName: sharding_db

# 数据源配置
dataSources:
  ds_0:
    url: jdbc:mysql://192.168.32.132:33083/demo_singleton
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
#分片规则配置
shardingRule:
#表分片规则
  tables:
    t_order:
      actualDataNodes: ds_${0}.t_order_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_id
    t_order_item:
      actualDataNodes: ds_${0}.t_order_item_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_item_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_item_id
  bindingTables:
    - t_order
重启服务，建表
CREATE TABLE IF NOT EXISTS ds_0.t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));
CREATE TABLE IF NOT EXISTS ds_0.t_order_item (order_item_id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_item_id));

1.3 单实例，多库，单表分片配置😉

建库33080mysql容器服务中
DROP SCHEMA IF EXISTS demo_singleton_ds_a;
CREATE SCHEMA IF NOT EXISTS demo_singleton_ds_a;
DROP SCHEMA IF EXISTS demo_singleton_ds_b;
CREATE SCHEMA IF NOT EXISTS demo_singleton_ds_b;
修改config-sharding.yaml，重启服务
schemaName: sharding_db

dataSources:
  ds_0:
    url: jdbc:mysql://192.168.32.132:33083/demo_singleton_ds_a
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  ds_1:
    url: jdbc:mysql://192.168.32.132:33083/demo_singleton_ds_b
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50

shardingRule:
  tables:
    t_order:
      actualDataNodes: ds_${0..1}.t_order_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_id
  bindingTables:
    - t_order
  defaultDatabaseStrategy:
    inline:
      shardingColumn: user_id
      algorithmExpression: ds_${user_id % 2}
  defaultTableStrategy:
    none:
建表，连接代理服务
CREATE TABLE IF NOT EXISTS ds_0.t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));
CREATE TABLE IF NOT EXISTS ds_1.t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));

1.4 单实例，多库，单表分片配置😉

修改config-sharding.yaml，重启服务
schemaName: sharding_db

dataSources:
  ds_0:
    url: jdbc:mysql://192.168.32.132:33083/demo_singleton_ds_a
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  ds_1:
    url: jdbc:mysql://192.168.32.132:33083/demo_singleton_ds_b
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50

shardingRule:
  tables:
    t_order:
      actualDataNodes: ds_${0..1}.t_order_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_id
    t_order_item:
      actualDataNodes: ds_${0..1}.t_order_item_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_item_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_item_id
  bindingTables:
    - t_order,t_order_item
  defaultDatabaseStrategy:
    inline:
      shardingColumn: user_id
      algorithmExpression: ds_${user_id % 2}
  defaultTableStrategy:
    none:
在代理服务中建表
CREATE TABLE IF NOT EXISTS ds_0.t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));
CREATE TABLE IF NOT EXISTS ds_1.t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));
CREATE TABLE IF NOT EXISTS ds_0.t_order_item (order_item_id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_item_id));
CREATE TABLE IF NOT EXISTS ds_1.t_order_item (order_item_id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_item_id));

2.多实例分片配置

分为以下二种，与单实例类似，只不过，修改了数据源配置，贴下配置，大家做下对比，建表还是和之前的一样，就不贴了

建库，先在具体对应的数据源把库建好

33080实例
DROP SCHEMA IF EXISTS demo_many_ds_a;
CREATE SCHEMA IF NOT EXISTS demo_many_ds_a;
33081实例
DROP SCHEMA IF EXISTS demo_many_ds_b;
CREATE SCHEMA IF NOT EXISTS demo_many_ds_b;

2.1 多实例，多库，单表分片配置😉

schemaName: sharding_db

dataSources:
  ds_0:
    url: jdbc:mysql://192.168.32.132:33080/demo_many_ds_a
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  ds_1:
    url: jdbc:mysql://192.168.32.132:33081/demo_many_ds_b
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50

shardingRule:
  tables:
    t_order:
      actualDataNodes: ds_${0..1}.t_order_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_id   
  bindingTables:
    - t_order
  defaultDatabaseStrategy:
    inline:
      shardingColumn: user_id
      algorithmExpression: ds_${user_id % 2}
  defaultTableStrategy:
    none:

2.2 多实例，多库，多表分片配置😉

schemaName: sharding_db

dataSources:
  ds_0:
    url: jdbc:mysql://192.168.32.132:33080/demo_many_ds_a
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  ds_1:
    url: jdbc:mysql://192.168.32.132:33081/demo_many_ds_b
    username: root
    password: 12345678
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50

shardingRule:
  tables:
    t_order:
      actualDataNodes: ds_${0..1}.t_order_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_id
    t_order_item:
      actualDataNodes: ds_${0..1}.t_order_item_${0..1}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: t_order_item_${order_id % 2}
      keyGenerator:
        type: SNOWFLAKE
        column: order_item_id
  bindingTables:
    - t_order,t_order_item
  defaultDatabaseStrategy:
    inline:
      shardingColumn: user_id
      algorithmExpression: ds_${user_id % 2}
  defaultTableStrategy:
    none:

测试

INSERT INTO t_order (user_id, status) VALUES (1, 'init');
INSERT INTO t_order (user_id, status) VALUES (1, 'init');
INSERT INTO t_order (user_id, status) VALUES (2, 'init');

select * from t_order;

查看实际实例中的数据，按照分片规则，user_id为1的数据，应该在ds1

条件虚拟库名称真实库实例
user_id=1ds_133081
user_id=2ds_033080

如下所示，分片规则，达到预期，分片配置成功

八方来财添好运
关注
专栏目录
Sharding-Proxy自定义分片策略（按年分库，按月、日、小时、分表）
vc33569的专栏
07-22 4009
你会发现如下的说明不能帮你什么🤣当用户需要使用自定义的分片算法类时，无法再通过简单的inline表达式在yaml文件进行配置。可通过以下方式配置使用自定义分片算法。实现ShardingAlgorithm接口定义的算法实现类。将上述java文件打包成jar包。将上述jar包拷贝至ShardingProxy解压后的conf/lib目录下。将上述自定义算法实现类的java文件引用配置在yaml文件里tableRule的属性上，具体可参考配置规则。......
ShardingSphere-Sharding-Proxy
qq_39093474的博客
05-14 584
Sharding-Proxy是ShardingSphere的第二个产品，定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前先提供MySQL版本，它可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench等操作数据，对DBA更加友好。向应用程序完全透明，可直接当做MySQL使用适用于任何兼容MySQL协议的客户端。
Apache Sharding-Proxy分库分表生产实践
vc33569的专栏
07-04 749
目录版本说明，写在前面的话可视化工具连接配置说明SQL分库分表概述逻辑表真实表数据节点绑定表广播表分片分片键分片算法分片策略SQL Hint配置说明分片规则数据源配置表配置数据节点配置分片策略配置自增主键生成策略行表达式,适用于单表无限分片，简化分库配置，理论上一个表可以无限向下语法说明配置数据节点配置分片算法1.单实例分片配置1.1 单实例，单库，单表分片配置😉1.2 单实例，单库，多表分片配置😉1.3 单实例，多库，单表分片配置😉1.4 单实例，多库，单表分片配置😉2.多实例分片配置2.1 多实...
ShardingSphere之ShardingProxy实战操作、分布式事务
最新发布
qq_44027353的博客
08-05 1206
ShardingSphere的两个核心产品分别为ShardingJDBC和ShardingProxy。前文已经详细介绍了ShardingJDBC的具体使用，接下来介绍服务端的分库分表ShardingProxy。定位为一个透明化的数据库代理，目前提供MySQL和PostgreSQL协议，透明化数据库操作。简单理解就是，他会部署成一个MySQL或者PostgreSQL的数据库服务，应用程序只需要像操作单个数据库一样去访问ShardingSphere-proxy，由ShardingProxy去完成分库分表功能。
sharding-proxy
weixin_35997672的博客
12-09 3201
对使用该组件的一个感受描述。 1：sharding-proxy的使用方式大致是，你安装sharding-proxy提供的执行文件，然后修改里面的分库分表，db等配置，然后你就像连接db一样的协议去连接 sharding-proxy。 2：sharding-ui非常不错，，他能直接的管理sharding-proxy，在上面动态修改配置等信息。达到自己本次一些升级的效果。 3:1-2都是说的使用sharding体系的sharding-proxy与sharding-ui比较好的地方，接下来说一些，不好的地方。
利用ShardingSphere（sharding-proxy）实现分库分表，通过整合ZooKeeper，进行简单配置文件修改轻松实现跨库跨表相关操作，轻量级零侵入整合项目开发
代码讲故事
10-09 5403
分布式主键 传统数据库软件开发中，主键自动生成技术是基本需求。而各个数据库对于该需求也提供了相应的支持，比如MySQL的自增键，Oracle的自增序列等。 数据分片后，不同数据节点生成全局唯一主键是非常棘手的问题。同一个逻辑表内的不同实际表之间的自增键由于无法互相感知而产生重复主键。 虽然可通过约束自增主键初始值和步长的方式避免碰撞，但需引入额外的运维规则，使解决...
sharding-proxy实现分表
04-18
在完成所有配置后，可以通过命令行启动 Sharding-Proxy 服务，例如：`bin/start.sh`。 ### 6. 使用注意事项 - 确保 Sharding-Proxy 的版本与 MySQL 的版本兼容。 - 分片策略设计需考虑数据分布、查询效率以及未来...
Sharding-Proxy
02-23
Sharding-Proxy 作为数据库的代理层，部署在应用与数据库之间，承担了数据分片、读写分离、分布式事务等核心功能，极大地提升了数据库的处理能力和系统的可扩展性。 **1. 数据分片** 数据分片是 Sharding-Proxy 的...
mysql代理 分库_sharding-proxy代理分库分表配置
weixin_34462016的博客
02-02 701
sharding proxy代理mysql实现分库的步骤：下载解压tar xvf apache-shardingsphere-4.1.0-sharding-proxy-bin.tar.gz使用mysql数据库时需要自己导入运行工具：(1)下载(2)解压：tar xvf mysql-connector-java-5.1.47(3)把运行 jar复制到sharding proxy的lib/下cd...
sharding-sphere4.1.1
01-28
标签"sharding-proxy"指向了ShardingSphere的一个组件——Sharding-Proxy，它是一个透明化的数据库代理层，允许应用程序以原生的JDBC或ODBC方式访问分布式数据库，无需任何代码修改。Sharding-Proxy支持MySQL和...
利用sharding-proxy实现分库分表
hefrankeleyn的博客
01-23 1621
利用sharding-proxy实现分库分表 文章目录利用sharding-proxy实现分库分表一、启动一个mysql二、在sharding-proxy上面配置分库、分表的规则三、启动sharding-proxy，并测试四、将用户表拆成2个库，每个库16张表4.1 表结构4.2 sharding-sphere-prox的配置：五、利用sharding-sphere-ui 可以动态的修改配置 一、启动一个mysql 在上面创建两个库：ds_shop_1和 ds_shop_2，真实的环境中，应当使用两个my
shardingsphere-sharding-proxy-4.0.0-RC1
05-10
shardingsphere-sharding-proxy，代理数据库，提供分库分表，读写分离功能，对mysql客户端与DBA友好
sharding-proxy-3.0.0.zip
08-17
Sharding-Proxy是ShardingSphere的第二个产品。 它定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前先提供MySQL版本，它可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench等)操作数据，对DBA更加友好。
sharding-proxy-4.1.1.zip
08-28
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。 ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 它与NoSQL和NewSQL是并存而非互斥的关系。NoSQL和NewSQL作为新技术探索的前沿，放眼未来
MYSQLg高级-------分库分表之核心Sharding-Proxy 简介
热门推荐
沉淀、分享、成长，让自己和他人都能有所收获！
08-17 1万+
1 、定位为透明的数据库代理端官网地址是 Apache ShardingSphere 的第二个产品。它定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。目前提供 MySQL 和 PostgreSQL 协议，透明化数据库操作，对 DBA 更加友好。ShardingSphere-Proxy 的优势在于对异构语言的支持，以及为 DBA 提供可操作入口。产品定位构建异构数据库上层生态和标准。.........
Sharding-Proxy简单应用
Kiven_ch的博客
07-28 693
Sharding-Proxy简介 Sharding-Proxy是ShardingSphere的第二个产品，定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前先提供MySQL版本，它可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench等操作数据，对DBA更加友好。 向应用程序完全透明，可直接当做MySQL使用 适用于任何兼容MySQL协议的客户端 Sharding-Proxy的优势
Sharding-Proxy 简介
实践求真知
11-10 1654
一 点睛 1 定位为透明的数据库代理端。 2 Sharding-Proxy为独立应用，需要安装服务，进行分库分表或者读写分离配置，然后启动使用。 二安装 1在官网下载下面文件 apache-shardingsphere-incubating-4.0.1-sharding-proxy-bin.zip 2解压该文件 3lib目录下的 jar 包补充后缀 .jar 4拷贝mysql的驱动到lib中 mysql-connector-java-8.0.13.jar 三...
ShardingSphere-Proxy数据库代理入门使用
关注我！带你一路 "狂飙" 到底！
08-04 1847
Sharding-Proxy是一个分布式数据库中间件，定位为透明化的数据库代理端。作为开发人员可以完全把它当成数据库，而它具体的分片规则在Sharding-Proxy中配置。目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 更加友好。
分库分表利器sharding-proxy
qq_44306975的博客
12-14 4848
sharding-proxy的使用
MySQL5.7结合Sharding-Proxy实现分表策略
Sharding-Proxy是Apache ShardingSphere项目的一部分，它是一个透明化的数据库代理层，提供SQL路由、分布式事务和数据分片等功能，使得应用程序可以像操作单个数据库一样操作分布式数据库集群。 1. **总体说明** ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

八方来财添好运

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值