分库分表介绍

1.什么是分库分表

很多情况下，分库分表并不是从系统设计开始就存在的，而是系统运行过程中，出现数据量庞大或者查询性能慢等问题延伸而来。

分库有两种模式：

• 垂直拆库：电商库 MallDB，业务拆分后就是 UserDB、OrderDB、PayDB...

• 分片拆库：用户库 UserDB，分片库后就是 UserDB_0、UserDB_1、UserDB_xx

分表也有两种模式：

• 垂直拆分：订单表 OrderTable，拆分后就是 OrderTable 以及 OrderExtTable。

• 水平拆分：订单表 OrderTable，拆分后就是 OrderTable_0、 OrderTable_xxx。

2. 什么场景下进行分库分表

什么时候进行分表?

数据量极大,查询很慢

什么时候进行分库?

当数据库的连接不够客户端使用时，可以考虑分库或读写分离。

如果说当数据库的 QPS 越来越高以及数据量越来越大的时候，就需要考虑分库分表。

什么时候既分库又分表?

• 高并发写入场景：当应用面临高并发的写入请求时，单一数据库可能无法满足写入压力，此时可以将数据按照一定规则拆分到多个数据库中，每个数据库处理部分数据的写入请求，从而提高写入性能。

• 数据量巨大场景：随着数据量的不断增加，单一数据库的存储和查询性能可能逐渐下降。此时，可以将数据按照一定的规则拆分到多个表中，每个表存储部分数据，从而分散数据的存储压力，提高查询性能。

分库分表组件

1. ShardingSphere-JDBC

定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

2. ShardingSphere-Proxy

定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。 目前提供 MySQL 和 PostgreSQL 协议，透明化数据库操作，对 DBA 更加友好。

优缺点

JDBC

• 优点：性能较高，通过 JDBC 直接向 MySQL 发起请求调用。

• 优点：使用较为简单，理论上无需修改代码，仅需使用 ShardingSphere 的配置即可。

• 缺点：需要修改项目配置以及引入 Jar 包。

• 缺点：对应用的内存有一定影响。

Proxy

• 优点：无需对现有项目做任何配置或代码变更，将数据库的地址改为 Proxy 的地址即可。

• 优点：Proxy 对 Java 应用内存没有任何影响。

• 优点：分片后无法知道一条数据记录到底在那张表，Proxy 是屏蔽了分片逻辑，可直接操作逻辑表。

• 缺点：JDBC 操作 MySQL 是点对点的，但是 Proxy 多了一层链路。

为什么选择 ShardingSphere？

• 拥有活跃的社区，能够提供及时的技术支持和更新；

• 代码质量极高，经过严格测试和验证，稳定可靠；

• 提供丰富的功能，满足多样化的业务需求。

如何选择分片键?

1. 访问频率：选择分片键应考虑数据的访问频率。将经常访问的数据放在同一个分片上，可以提高查询性能和降低跨分片查询的开销。

2. 数据均匀性：分片键应该保证数据的均匀分布在各个分片上，避免出现热点数据集中在某个分片上的情况。

3. 业务关联性：分片键应该与业务关联紧密，这样可以避免跨分片查询和跨库事务的复杂性。

4. 数据不可变：一旦选择了分片键，它应该是不可变的，不能随着业务的变化而频繁修改。