在大数据时代,随着业务数据量的不断增长,单一的数据库往往难以承载大规模的数据处理需求。数据库分片(Sharding)是一种有效的数据库扩展技术,通过将数据分布到多个数据库实例上,提高系统的性能和可扩展性。
ShardingSphere
是一款开源的分布式数据库中间件,可以帮助我们轻松实现数据库分片。
本文的目的是介绍如何快速上手使用 ShardingSphere
来实现 MySQL
数据库分片。
一、ShardingSphere 简介
ShardingSphere
是 Apache
基金会下的一个开源项目,提供分布式数据库中间件解决方案。ShardingSphere
已经在2020年4月16日从 Apache
孵化器毕业,成为 Apache 顶级项目。其主要功能包括数据分片(Sharding)、读写分离、分布式事务以及数据加密等。ShardingSphere
主要由三个核心组件组成:
- Sharding-JDBC:轻量级的 Java 框架,直接集成在应用程序中,提供数据库分片、读写分离等功能。需要在
spring boot
中集成,编写相关的配置。如果分片策略用默认的4种,那可以只改配置就好了。如果分片策略很特殊,可以通过实现抽象类,写自定义的方法进行分片分库。 - Sharding-Proxy:独立部署的数据库代理,支持所有兼容
MySQL
、PostgreSQL
协议的客户端。原来程序连接到这个代理就可以实现分片和分库。程序不需要任何改变。 - Sharding-Sidecar(Plan):云原生环境下的数据库代理,与
Kubernetes
等平台集成。
1.1 对比
Sharding-JDBC | Sharding-Proxy | Sharding-Sidecar | |
---|---|---|---|
数据库 | 任意 | MySQL/PostgreSQL | MySQL/PostgreSQL |
连接消耗数 | 高 | 低 | 高 |
异构语言 | 仅Java | 任意 | 任意 |
性能 | 损耗低 | 损耗略高 | 损耗低 |
无中心化 | 是 | 否 | 是 |
静态入口 | 无 | 有 | 无 |
1.2 核心概念
分库分表中最重要的核心概念有两个,即路由键和分片算法,这两个将决定数据分片的位置,先稍微解释一下这两个概念:
-
路由键:也被称为分片键,也就是作为数据分片的基准字段,可以是一个或多个字段组成。
-
分片算法:基于路由键做一定逻辑处理,从而计算出一个最终节点位置的算法。
举个例子来感受一下,好比按 user_id 将用户表数据分片,每八百万条数据划分一张表,那在这里,user_id 就是路由键,而按user_id做范围判断则属于分片算法,一张表中的所有数据都会依据这两个基础,后续对所有的读写SQL进行改写,从而定位到具体的库、表位置。
在Sharding-Sphere这套技术中,无论是JDBC还是Proxy产品,工作的流程都遵循上述这个原则,里面除开上面介绍的路由键和分片算法的概念外,还有逻辑表、真实表、数据节点这三个概念:
-
逻辑表:提供给应用程序操作的表名,程序可以像操作原本的单表一样,灵活的操作逻辑表。
-
真实表:在各个数据库节点上真实存在的物理表,但表名一般都会和逻辑表存在偏差。
-
数据节点:主要是用于定位具体真实表的库表名称,如DB1.tb_user1、DB2.tb_user2…
-
均匀分布:指一张表的数量在每个数据源中都是一致的。
-
自定义分布:指一张表在每个数据源中,具体的数量由自己来定义,上图就是一种自定义分布。
以 Java 程序为例,编写业务代码时写的 SQL 语句,会直接基于逻辑表进行操作,逻辑表并不是一种真实存在的表结构,而是提供给 Sharding-Sphere 使用的,当 Sharding-Sphere 接收到一条操作某张逻辑表的 SQL语句时,它会根据已配置好的路由键和分片算法,对相应的 SQL语句进行解析,然后计算出 SQL要落入的数据节点,最后再将语句发给具体的真实表上处理即可。
1.3 Sharding-Sphere中的表概念
除开上述的一些核心概念外,在Sharding-Sphere中为了解决某些问题,同时还有一些表概念,如广播表、绑定表、单表、动态表等,接着简单介绍一下这些概念。
1.3.1 绑定表
一般的项目基本上都会存在主外键,虽然不会在表上添加主外键约束,但也会从逻辑上保障主外键关系,但经过水平分库后,所有的读写操作会基于路由键去分片。
那此时以订单表、订单详情表为例,假设用户选择了三个购物车的商品提交订单,此时会产生
- 一条订单记录
- 以及对应的三条订单详情记录。
假设商品库有两个水平节点,两个商品库都具备订单表、订单详情表,而订单表的路由键是 order_id
,订单详情表的路由键是 order_info_id
,数据分片的路由算法为取模,那此时数据的落库情况为:
- 订单详情2数据落入 DB0 商品库中。
- 订单详情1、详情3数据落入 DB1 商品库中。
但此时订单表和订单详情表的数据是存在外键关系的,如果按照上述的路由方式去对数据做分片,最终就会导致通过 order_id=1 的订单 ID 查询订单详情时,只能在 DB1 中查询到两条订单详情数据,这个问题显然是业务上无法接受的。通常我们会将这两张表配置为绑定表,以确保它们在同一个分片中,从而优化订单相关的联表查询操作。
1.3.2 广播表
广播表是指在所有分片数据源中都存在的一张表,且数据内容完全相同。这种表通常用于存储一些公共的、全局性的数据,比如系统配置、国家代码等。由于广播表的数据是全局一致的,当有更新操作时,需要将变更同步到所有的分片数据源中。
- 在不同的库需要数据的表中冗余字段,把常用的字段放到需要要数据的表中,避免跨库连表。
- 选择同步数据,通过广播表/网络表/全局表将对应的表数据直接完全同步一份到相应库中。
- 在设计库表拆分时创建 ER 绑定表,具备主外键的表放在一个库,保证数据落到同一数据库
- Java 系统中组装数据,通过调用对方服务接口的形式获取数据,然后在程序中组装后返回
这四种方案都能够解决需要跨库 Join 的问题,但第二种方案提到了广播表/网络表/全局表似乎之前没听说过对嘛,这其实是分库分表中的名词。场景:假设有一个 t_country 表,存储国家和地区的信息,这些信息在整个系统中是统一的,因此可以将 t_country 作为广播表,在所有数据库实例中都保存一份副本。
但往往垂直分库的场景中,第四种方案是最常用的,因为分库分表的项目中,Java 业务系统那边也绝对采用了分布式架构,因此通过调用对端 API 接口来获取数据,是分布式系统最为常见的一种现象。
1.3.3 单表
单表的含义比较简单,并非所有的表都需要做分库分表操作,所以当一张表的数据无需分片到多个数据源中时,就可将其配置为单表,这样所有的读写操作最终都会落入这一张单表中处理。
二、ShardingSphere-JDBC
Sharding-JDBC
是 ShardingSphere
的第一个产品,也是 ShardingSphere
的前身。 它定位为轻量级 Java
框架,在 Java
的 JDBC
层提供的额外服务。它使用客户端直连数据库,以 jar
包形式提供服务,无需额外部署和依赖,可理解为增强版的 JDBC
驱动,完全兼容 JDBC
和各种 ORM
框架。
Apache ShardingSphere-JDBC 可以通过Java 和 YAML 这 2 种方式进行配置,开发者可根据场景选择适合的配置方式。
2.2 原理
Sharding-JDBC 中的路由结果是通过分片字段和分片方法来确定的,如果查询条件中有 id 字段的情况还好,查询将会落到某个具体的分片
如果查询没有分片的字段,会向所有的db或者是表都会查询一遍,让后封装结果集给客户端。
接下来会搭建一个简单的SpringBoot+MyBatis项目,结合Sharding-Sphere-JDBC实现水平分库~
spring boot整合
<!-- 分表分库依赖 -->
<dependency><groupId>org.apache.shardingsphere</groupId><artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId><version>5.2.1</version>
</dependency>
数据库
接着先在数据库中创建db_sharding_01、db_sharding_02两个库,我这里用伪集群的方式搭建水平库,毕竟线上只需要把数据库地址改为不同的机器IP即可
接着分别再在两个水平库中,创建用户表、订单表、订单详情表、商品表(两张),这四张表是接下来用于测试的表,SQL如下:
drop table if exists `user_info`;
create table `user_info` (`user_id` bigint not null comment '用戶id',`user_name` varchar(255) comment '用戶姓名',`user_sex` varchar(255) comment '用戶性別',`user_age` int(8) not null comment '用戶年齡',primary key (`user_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci
row_format = compact;drop table if exists `shoping_00`;
create table `shoping_00` (`shoping_id` bigint not null comment '商品id',`shoping_name` varchar(255) comment '商品名称',`shoping_price` int(8) not null comment '商品价格',primary key (`shoping_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci
row_format = compact;drop table if exists `shoping_01`;
create table `shoping_01` (`shoping_id` bigint not null comment '商品id',`shoping_name` varchar(255) comment '商品名称',`shoping_price` int(8) not null comment '商品价格',primary key (`shoping_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci
row_format = compact;drop table if exists `order`;
create table `order` (`order_id` bigint not null comment '订单号',`order_price` int(8) not null comment '订单总金额',`user_id` bigint not null comment '用戶id',primary key (`order_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci
row_format = compact;drop table if exists `order_info`;
create table `order_info` (`order_info_id` bigint not null comment '订单详情号',`order_id` bigint not null comment '订单号',`shoping_name` varchar(255) comment '商品名称',`shoping_price` int(8) not null comment '商品价格',primary key (`order_info_id`) using btree,index `key_order_id`(`order_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci
row_format = compact;
分库分表的核心配置
Sharding-Sphere的所有产品对业务代码都是零侵入的,无论是Sharding-JDBC也好,Sharding-Proxy也罢,都不需要更改业务代码,这也就意味着大家在分库分表环境下做业务开发时,可以像传统的单库开发一样轻松,Sharding-Sphere中最主要的是对配置文件的更改,Sharding-JDBC主要修改application.properties/yml文件,Sharding-Proxy主要修改自身的配置文件。
多数据源配置
spring:shardingsphere:mode:type: Standalonerepository:type: JDBCdatasource:names: ds0,ds1ds0:type: com.alibaba.druid.pool.DruidDataSourcedriver-class-name: com.mysql.jdbc.Driverurl: 「数据库节点1的地址」username: 「数据库节点1的账号」password: 「数据库节点1的密码」ds1:type: com.alibaba.druid.pool.DruidDataSourcedriver-class-name: com.mysql.jdbc.Driverurl: 「数据库节点2的地址」username: 「数据库节点1的账号」password: 「数据库节点1的密码」
上述这组配置中,需要通过names配置多个数据源的别名,接着需要为每个别名配置对应的数据源信息,按照上述方式编写好配置文件后,则表示完成了多数据源的配置。
多数据源可用性测试
为了确保多数据源的可用性,接着先简单配置一张表:
spring:shardingsphere:props:sql-show: truerules:sharding:tables:shoping:actual-data-nodes: ds0.shoping_00