分库分表-ShardingSphere基础

系列文章目录

• MySQL分表分库基础
• 分库分表-ShardingSphere基础
• 分库分表ShardingSphere-ShardingJDBC数据分片实战1
• 分库分表ShardingSphere-ShardingJDBC数据分片实战2
• 分库分表ShardingSphere-ShardingJDBC源码解析

---

前言

上一个章节介绍完了MySQL分表分库基础，随着分库分表越来越流行，分表分库框架也越来越成熟，本来就介绍一款分表分库框架ShardingSphere

---

一、ShardingSphere是什么？

• Apache ShardingSphere 是⼀套开源的分布式数据库中间件解决⽅案组成的⽣态圈
• ShardingSphere 由 JDBC、Proxy和 Sidecar（规划中）这 3 款相互独⽴组成，同时支持混合使用
• 提供了标准化的数据分片、分布式事务以及数据库治理的功能
• 目前支持的功能有数据分⽚、读写分离、数据加密、影⼦库压测，同时支持多种数据库MySQL、PostgreSQL、SQLServer、Oracle
• 目前以及提供出数十种SPI作为系统的扩展点提供给开发者使用
  

二、ShardingJDBC 、ShardingProxy对比

ShardingJDBC

• ShardingJDBC 为Java 的 JDBC 层提供的额外服务
• 它使⽤客⼾端直连数据库，以 jar 包形式提供服务，⽆需额外部署和依赖，可理解为增强版的 JDBC 驱动
• 完全兼容 JDBC 和各种 ORM 框架
• 分表分库逻辑油业务决定，相对灵活
• 采用无中心化架构，适合Java开发的高性能OLTP应用
• 缺点：业务侵入性较大

OLTP（on-line transaction processing）翻译为联机事务处理， OLAP（On-Line Analytical Processing）翻译为联机分析处理，从字面上来看OLTP是做事务处理，OLAP是做分析处理。从对数据库操作来看，OLTP主要是对数据的增删改，OLAP是对数据的查询。

ShardingProxy

• ShardingProxy作为数据库代理端
• 支持异构语⾔/支持客户端多种编程语言
• 支持数据库 MySQL/PostgreSQL
• ShardingProxy单独部署，对业务无侵入，无感知
• 采⽤同⼀注册中⼼统⼀配置分⽚策略，能够灵活的搭建适⽤于各种场景的应用系统
• 缺点：支持数据库较少，性能比ShardingJDBC低

三、数据分片 核心概念

逻辑表

⽔平拆分的数据库（表）的相同逻辑和数据结构表的总称。
例如用户表水平拆分从user_1到user_5，其逻辑表为user

真实表

在分⽚的数据库中真实存在的物理表。
即逻辑表对应的user1到user_5

数据节点

数据分⽚的最小单元。由数据源名称和数据表组成，例：db1.user_1

绑定表

指分⽚规则⼀致的主表和⼦表。例如：user 表和 user_info 表，均按照 user_id 分⽚，则
此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将⼤⼤提升。

SELECT info.* FROM user u JOIN user_info info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

在不配置绑定表关系时，假设分⽚键 user 将数值 1 路由⾄第 1 ⽚，将数值 6 路由⾄第 2 ⽚，那么路由后的 SQL 应该为 4 条，它们呈现为笛卡尔积：

SELECT info.* FROM user_0 u JOIN user_info_0 info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

SELECT info.* FROM user_0 u JOIN user_info_1 info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

SELECT info.* FROM user_1 u JOIN user_info_0 info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

SELECT info.* FROM user_0 u JOIN user_info_1 info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

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

SELECT info.* FROM user_0 u JOIN user_info_0 info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

SELECT info.* FROM user_1 u JOIN user_info_1 info ON u.user_id=info.user WHERE u.
user_id in (1, 6);

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

⼴播表

指所有的分⽚数据源中都存在的表，表结构和表中的数据在每个数据库中均完全⼀致。适⽤于数据量不⼤且需要与海量数据的表进⾏关联查询的场景

分片键

⽤于分⽚的数据库字段，是将数据库（表）⽔平拆分的关键字段

分片算法

通过分⽚算法将数据分⽚，⽀持通过 =、>=、<=、>、<、BETWEEN 和 IN 分⽚。目前提供四种算法

• 标准分⽚算法
  对应 StandardShardingAlgorithm，⽤于处理使⽤单⼀键作为分⽚键的 =、IN、BETWEEN AND、>、<、>=、
  <= 进⾏分⽚的场景。需要配合 StandardShardingStrategy 使⽤
• 复合分⽚算法
  对应 ComplexKeysShardingAlgorithm，⽤于处理使⽤多键作为分⽚键进⾏分⽚的场景，包含多个分⽚键
  的逻辑较复杂，需要应⽤开发者⾃⾏处理其中的复杂度。需要配合 ComplexShardingStrategy 使⽤。
• Hint 分⽚算法
  对应 HintShardingAlgorithm，⽤于处理使⽤ Hint ⾏分⽚的场景。需要配合 HintShardingStrategy 使⽤。

分片策略

真正可⽤于分⽚操作的是分⽚键 + 分⽚算法，也就是分⽚策略。⽬前提供 5 种分⽚策略

分片策略配置

真正可⽤于分⽚操作的是分⽚键 + 分⽚算法，也就是分⽚策略。
对于分⽚策略存有数据源分⽚策略和表分⽚策略两种维度。

• 数据源分⽚策略
  对应于 DatabaseShardingStrategy。⽤于配置数据被分配的⽬标数据源。
• 表分⽚策略
  对应于 TableShardingStrategy。⽤于配置数据被分配的⽬标表，该⽬标表存在与该数据的⽬标数据源内。故表分⽚策略是依赖与数据源分⽚策略的结果的。

---