前有Atomikos 今有有ShardingsphereJdbc.
简单整理相关信息,关于分库分表的,如下的分库分表,统一改成分片.
参考资料:
相同结构的水平拆分数据库(表)的逻辑名称,是 SQL 中表的逻辑标识。 例:订单数据根据主键尾数拆分为 10 张表,分别是 t_order_0 到 t_order_9,他们的逻辑表名为 t_order
在水平拆分的数据库中真实存在的物理表。 即上个示例中的 t_order_0 到 t_order_9
指所有的分片数据源中都存在的表,表结构及其数据在每个数据库中均完全一致。 适用于数据量不大且需要与海量数据的表进行关联查询的场景,例如:字典表。
指分片规则一致的一组分片表。 使用绑定表进行多表关联查询时,必须使用分片键进行关联,否则会出现笛卡尔积关联或跨库关联,从而影响查询效率。 例如:t_order 表和 t_order_item 表,均按照 order_id 分片,并且使用 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);
在配置绑定表关系,并且使用 order_id 进行关联后,路由的 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 表由于指定了分片条件,ShardingSphere 将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略,那么 t_order_item 表的分片计算将会使用 t_order 的条件。
数据分片的最小单元,由数据源名称和真实表组成。 例:ds_0.t_order_0。 逻辑表与真实表的映射关系,可分为均匀分布和自定义分布两种形式。
用于将数据库(表)水平拆分的数据库字段。 例:将订单表中的订单主键的尾数取模分片,则订单主键为分片字段。 SQL 中如果无分片字段,将执行全路由,性能较差。 除了对单分片字段的支持,Apache ShardingSphere 也支持根据多个字段进行分片。
用于将数据分片的算法,支持 =、>=、<=、>、<、BETWEEN 和 IN 进行分片。 分片算法可由开发者自行实现,也可使用 Apache ShardingSphere 内置的分片算法语法糖,灵活度非常高。
分片算法语法糖,用于便捷的托管所有数据节点,使用者无需关注真实表的物理分布。 包括取模、哈希、范围、时间等常用分片算法的实现。
提供接口让应用开发者自行实现与业务实现紧密相关的分片算法,并允许使用者自行管理真实表的物理分布。 自定义分片算法又分为:
=、IN、BETWEEN AND、>、<、>=、<= 进行分片的场景。Hint 行分片的场景。(即,不是通过表中的字段来进行分片,而是通过请求的上下文来决定如何进行分片cuiyoanan2000@163.com)关于通过请求的上下文来进行分片只需要在执行SQL前使用HintManager注入分片信息就可以了cuiyaonan2000@163.com

分片键+分片算法 = 分片策略

默认的运行模式,用户无需配置 mode。内存模式下用户无需配置任何持久化组件和策略,无论是本地初始化的配置还是通过 SQL/DistSQL 操作造成的元数据变更,仅在当前进程中生效, 服务重启后配置将会被还原。内存模式适用于集成测试环境,方便开发人员在整合功能测试中集成 ShardingSphere 而无需清理运行痕迹。
ShardingSphere 为单机模式默认提供了本地文件的持久化方式,能够将数据源和规则等元数据信息持久化到本地文件中,而在服务重启的时候,依然能够从本地文件中读取配置,保持元数据和重启之前的版本一致。 单机模式适用于开发工程师在本地快速搭建 ShardingSphere 的开发环境,进行功能的联调和验证。
集群模式是 ShardingSphere 建议的真实部署上线的生产环境必须使用的模式,采用 JDBC 和 Proxy 混合部署架构也必须使用集群模式。集群模式提供了分布式治理的功能,通过集成独立部署的第三方注册中心(用于存储元数据信息cuiyaonan2000@163.com),除了能够持久化元数据之外,同时实现了多个实例之间的数据共享 以及分布式场景下的状态协调, 也是 ShardingSphere 通过水平扩展来提高计算能力 以及高可用等核心功能的基础。

常用的分片算法种类入官网所说如下:

通过官网可以看到有如下4中配置.

- spring.shardingsphere.datasource.names= # 省略数据源配置,请参考使用手册
-
- # 标准分片表配置
- spring.shardingsphere.rules.sharding.tables.
.actual-data-nodes= # 由数据源名 + 表名组成,以小数点分隔。多个表以逗号分隔,支持 inline 表达式。缺省表示使用已知数据源与逻辑表名称生成数据节点,用于广播表(即每个库中都需要一个同样的表用于关联查询,多为字典表)或只分库不分表且所有库的表结构完全一致的情况 -
- # 分库策略,缺省表示使用默认分库策略,以下的分片策略只能选其一
-
- # 用于单分片键的标准分片场景
- spring.shardingsphere.rules.sharding.tables.
.database-strategy.standard.sharding-column= # 分片列名称 - spring.shardingsphere.rules.sharding.tables.
.database-strategy.standard.sharding-algorithm-name= # 分片算法名称 -
- # 用于多分片键的复合分片场景
- spring.shardingsphere.rules.sharding.tables.
.database-strategy.complex.sharding-columns= # 分片列名称,多个列以逗号分隔 - spring.shardingsphere.rules.sharding.tables.
.database-strategy.complex.sharding-algorithm-name= # 分片算法名称 -
- # 用于 Hint 的分片策略
- spring.shardingsphere.rules.sharding.tables.
.database-strategy.hint.sharding-algorithm-name= # 分片算法名称 -
- # 分表策略,同分库策略
- spring.shardingsphere.rules.sharding.tables.
.table-strategy.xxx= # 省略 -
- # 自动分片表配置
- spring.shardingsphere.rules.sharding.auto-tables.
.actual-data-sources= # 数据源名 -
- spring.shardingsphere.rules.sharding.auto-tables.
.sharding-strategy.standard.sharding-column= # 分片列名称 - spring.shardingsphere.rules.sharding.auto-tables.
.sharding-strategy.standard.sharding-algorithm-name= # 自动分片算法名称 -
- # 分布式序列策略配置
- spring.shardingsphere.rules.sharding.tables.
.key-generate-strategy.column= # 分布式序列列名称 - spring.shardingsphere.rules.sharding.tables.
.key-generate-strategy.key-generator-name= # 分布式序列算法名称 -
- # 分片审计策略配置
- spring.shardingsphere.rules.sharding.tables.
.audit-strategy.auditor-names= # 分片审计算法名称 - spring.shardingsphere.rules.sharding.tables.
.audit-strategy.allow-hint-disable= # 是否禁用分片审计hint -
- spring.shardingsphere.rules.sharding.binding-tables[0]= # 绑定表规则列表
- spring.shardingsphere.rules.sharding.binding-tables[1]= # 绑定表规则列表
- spring.shardingsphere.rules.sharding.binding-tables[x]= # 绑定表规则列表
-
- spring.shardingsphere.rules.sharding.broadcast-tables[0]= # 广播表规则列表
- spring.shardingsphere.rules.sharding.broadcast-tables[1]= # 广播表规则列表
- spring.shardingsphere.rules.sharding.broadcast-tables[x]= # 广播表规则列表
-
- spring.shardingsphere.rules.sharding.default-database-strategy.xxx= # 默认数据库分片策略
- spring.shardingsphere.rules.sharding.default-table-strategy.xxx= # 默认表分片策略
- spring.shardingsphere.rules.sharding.default-key-generate-strategy.xxx= # 默认分布式序列策略
- spring.shardingsphere.rules.sharding.default-sharding-column= # 默认分片列名称
-
- # 分片算法配置
- spring.shardingsphere.rules.sharding.sharding-algorithms.
.type= # 分片算法类型 - spring.shardingsphere.rules.sharding.sharding-algorithms.
.props.xxx= # 分片算法属性配置 -
- # 分布式序列算法配置
- spring.shardingsphere.rules.sharding.key-generators.
.type= # 分布式序列算法类型 - spring.shardingsphere.rules.sharding.key-generators.
.props.xxx= # 分布式序列算法属性配置 -
- # 分片审计算法配置
- spring.shardingsphere.rules.sharding.auditors.
.type= # 分片审计算法类型 - spring.shardingsphere.rules.sharding.auditors.
.props.xxx= # 分片审计算法属性配置