系列文章目录
- 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。⽤于配置数据被分配的⽬标表,该⽬标表存在与该数据的⽬标数据源内。故表分⽚策略是依赖与数据源分⽚策略的结果的。