1. 什么场景下分表?
数据量过大或者数据库表对应的磁盘文件过大。
Q:多少数据分表?
A:网上有人说1kw,2kw?不准确。
1、一般看字段的数量,有没有包含text类型的字段。我们的主表里面是不允许有text的大字段的。
2、一般看业务增长量,如果业务还在每天很高的数量增长就需要进行分表。
[!abstract] Note
- 一般如果数据中有text类型字段的时候就适合,采用垂直分表的方式
- 如果数据量过大的时候,单个数据库承受不住压力可以采用水平分表
2. 什么情况下分库?
连接不够用。
MySQL Server 假设支持 4000 个数据库连接。一个服务连接池最大 10 个,假设有 40 个节点。已经占用了 400 个数据库连接。
类似于这种服务,有10个,那你这个 MySQL Server 连接就不够了。
[!abstract] Note
连接不够可以进行读写分离,不涉及业务的拆分,只需要进行主从同步,配置多数据源就可以。大多数是读写分离就够了。
3. 又分库又分表?
高并发写入或查询场景。
数据量巨大场景。
3、数据库分库分表框架 ShardingSphere
Sharding-JDBC。
4、分片键
用于将数据库(表)水平拆分的数据库字段。
分库分表中的分片键(Sharding Key)是一个关键决策,它直接影响了分库分表的性能和可扩展性。以下是一些选择分片键的关键因素:
- 访问频率:选择分片键应考虑数据的访问频率。将经常访问的数据放在同一个分片上,可以提高查询性能和降低跨分片查询的开销。
- 数据均匀性:分片键应该保证数据的均匀分布在各个分片上,避免出现热点数据集中在某个分片上的情况。
- 数据不可变:一旦选择了分片键,它应该是不可变的,不能随着业务的变化而频繁修改。
用户名和用户ID选哪个作为分片键?
- 用户名。用户名可以登录。
分表之后如果查询不带分片建,就会向所有的表中查询
5、引入 ShardingSphere-JDBC到项目
1. 引入依赖
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-jdbc-core</artifactId>
<version>5.3.2</version>
</dependency>
2. 定义分片规则
替换
spring:
datasource:
# ShardingSphere 对 Driver 自定义,实现分库分表等隐藏逻辑
driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver
# ShardingSphere 配置文件路径
url: jdbc:shardingsphere:classpath:shardingsphere-config.yaml
shardingsphere-config.yaml
# 数据源集合
dataSources:
ds_0:
dataSourceClassName: com.zaxxer.hikari.HikariDataSource
driverClassName: com.mysql.cj.jdbc.Driver
jdbcUrl: jdbc:mysql://127.0.0.1:3306/link?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
username: root
password: 123456
rules:
- !SHARDING
tables:
sys_user:
# 真实数据节点,比如数据库源以及数据库在数据库中真实存在的
actualDataNodes: ds_0.sys_user_${0..15}
# 分表策略
tableStrategy:
# 用于单分片键的标准分片场景
standard:
# 分片键
shardingColumn: username
# 分片算法,对应 rules[0].shardingAlgorithms
shardingAlgorithmName: user_table_hash_mod
# 分片算法
shardingAlgorithms:
# 数据表分片算法
user_table_hash_mod:
# 根据分片键 Hash 分片
type: HASH_MOD
# 分片数量
props:
sharding-count: 16
# 展现逻辑 SQL & 真实 SQL
props:
sql-show: true
6、ShardingSphere 数据分片核心概念
1. 逻辑表
相同结构的水平拆分数据库(表)的逻辑名称,是 SQL 中表的逻辑标识。
2. 真实表
在水平拆分的数据库中真实存在的物理表。
[!abstract] Note
逻辑表和逻辑sql:在代码层面执行,逻辑表的字段对应的就是我们mybatisplus的配置
真实表和真实sql:经过分片算法计算之后的sql
根据分片键 Hash 分片 type: HASH_MOD。根据hash算法取模后进行分片策略。
1.7、用户信息加密存储
加密配置:shardingsphere-config.yaml
# 配置数据源,底层被 ShardingSphere 进行了代理
dataSources:
ds_0:
dataSourceClassName: com.zaxxer.hikari.HikariDataSource
driverClassName: com.mysql.cj.jdbc.Driver
jdbcUrl: jdbc:mysql://127.0.0.1:3306/link?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
username: root
password: root
rules:
# 数据加密存储规则
- !ENCRYPT
# 需要加密的表集合
tables:
# 用户表
t_user:
# 用户表中哪些字段需要进行加密
columns:
# 手机号字段,逻辑字段,不一定是在数据库中真实存在
phone:
# 手机号字段存储的密文字段,这个是数据库中真实存在的字段
cipherColumn: phone
# 身份证字段加密算法
encryptorName: common_encryptor
mail:
cipherColumn: mail
encryptorName: common_encryptor
# 是否按照密文字段查询
queryWithCipherColumn: true
# 加密算法
encryptors:
# 自定义加密算法名称
common_encryptor:
# 加密算法类型
type: AES
props:
# AES 加密密钥
aes-key-value: d6oadClrrb9A3GWo
props:
sql-show: true
[!abstract] Note
如果是业务中已经有了phone这些需要加密的字段,后续如果想要添加密文字段的时候新添加一个字段就行。然后把queryWithCipherColumn: false,按照明文查询,后续数据清洗为密文之后再改为true。
例如此处:
[!abstract] Note
第一个phone对应的就是逻辑表的字段,第二个phone对应的是真实表的字段。
如果在企业中需要进行无缝的转换,可以改此处配置