分库分表基本概念

我就是我 2024-02-21 07:14 53阅读 0赞

### 什么是分库分表 ###

分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。

分库分表是由`分库`和`分表`这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。

![图片][0ef2e4845eb274fc6f9c1730d058a636.png]

通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。

### 为什么分库分表 ###

单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。

一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行分库分表。

#### 为什么需要分库？ ####

##### 容量 #####

我们给数据库实例分配的磁盘容量是固定的，数据量持续的大幅增长，用不了多久单机的容量就会承载不了这么多数据，解决办法简单粗暴，加容量！

##### 连接数 #####

单机的容量可以随意扩展，但数据库的连接数却是有限的，在高并发场景下多个业务同时对一个数据库操作，很容易将连接数耗尽导致`too many connections`报错，导致后续数据库无法正常访问。

可以通过`max_connections`查看MySQL最大连接数。

show variables like '%max_connections%'

![图片][7a54b5f4b40b488f725501b854a6e975.png]

将原本单数据库按不同业务拆分成订单库、物流库、积分库等不仅可以有效分摊数据库读写压力，也提高了系统容错性。

#### 为什么需要分表？ ####

做过报表业务的同学应该都体验过，一条SQL执行时间超过几十秒的场景。

导致数据库查询慢的原因有很多，SQL没命中索引、like扫全表、用了函数计算，这些都可以通过优化手段解决，可唯独数据量大是MySQL无法通过自身优化解决的。慢的根本原因是`InnoDB`存储引擎，聚簇索引结构的 B+tree 层级变高，磁盘IO变多查询性能变慢，详细原理自行查找一下，这里不用过多篇幅说明。

阿里的开发手册中有条建议，单表行数超500万行或者单表容量超过2GB，就推荐分库分表，然而理想和实现总是有差距的，阿里这种体量的公司不差钱当然可以这么用，实际上很多公司单表数据几千万、亿级别仍然不选择分库分表。

![图片][9ada640df5c6647aaad77c9bdd2c7692.png]

### 什么时候分库分表 ###

> 到底什么情况下会用分库分表呢？

分库分表要解决的是`现存海量数据`访问的性能瓶颈，对`持续激增`的数据量所做出的架构预见性。

**是否分库分表的关键指标是数据量**，我们以`fire100.top`这个网站的资源表 `t_resource`为例，系统在运行初始的时候，每天只有可怜的几十个资源上传，这时使用单库、单表的方式足以支持系统的存储，数据量小几乎没什么数据库性能瓶颈。

但某天开始一股神秘的流量进入，系统每日产生的资源数据量暴增至十万甚至上百万级别，这时资源表数据量到达千万级，查询响应变得缓慢，数据库的性能瓶颈逐渐显现。

以MySQL数据库为例，单表的数据量在达到亿条级别，通过加索引、SQL调优等传统优化策略，性能提升依旧微乎其微时，就可以考虑做分库分表了。

既然MySQL存储海量数据时会出现性能瓶颈，那么我们是不是可以考虑用其他方案替代它？比如高性能的非关系型数据库`MongoDB`？

可以，但要看存储的数据类型！

现在互联网上大部分公司的核心数据几乎是存储在关系型数据库（MySQL、Oracle等），因为它们有着`NoSQL`无法比拟的稳定性和可靠性，产品成熟、生态系统完善，还有核心的事务功能特性，也是其他存储工具不具备的，而评论、点赞这些非核心数据还是可以考虑用`MongoDB`的。

### 如何分库分表 ###

> 分库分表的核心就是对数据的分片（`Sharding`）并相对均匀的路由在不同的库、表中，以及分片后对数据的快速定位与检索结果的整合。

分库与分表可以从：\*\*垂直（纵向）\*\*和 **水平（横向）两种纬度进行拆分。下边我们以经典的订单业务**举例，看看如何拆分。

![图片][0e9c91b53382ba97cc9b512dc92ffbcf.png]

#### 垂直拆分 ####

##### 1、垂直分库 #####

垂直分库一般来说按照业务和功能的维度进行拆分，将不同业务数据分别放到不同的数据库中，核心理念 `专库专用`。

按业务类型对数据分离，剥离为多个数据库，像订单、支付、会员、积分等相关表放在对应的订单库、支付库、会员库、积分库。不同业务禁止跨库直连，获取对方业务数据一律通过`API`接口交互，这也是微服务拆分的一个重要依据。

![图片][147d20f9293e984c82f0ccf63861dae9.png]垂直分库

垂直分库很大程度上取决于业务的划分，但有时候业务间的划分并不是那么清晰，比如：电商中订单数据的拆分，其他很多业务都依赖于订单数据，有时候界线不是很好划分。

垂直分库把一个库的压力分摊到多个库，提升了一些数据库性能，但并没有解决由于单表数据量过大导致的性能问题，所以就需要配合后边的分表来解决。

##### 2、垂直分表 #####

垂直分表针对业务上字段比较多的大表进行的，一般是把业务宽表中比较独立的字段，或者不常用的字段拆分到单独的数据表中，是一种大表拆小表的模式。

例如：一张`t_order`订单表上有几十个字段，其中订单金额相关字段计算频繁，为了不影响订单表`t_order`的性能，就可以把订单金额相关字段拆出来单独维护一个`t_order_price_expansion`扩展表，这样每张表只存储原表的一部分字段，通过订单号`order_no`做关联，再将拆分出来的表路由到不同的库中。

![图片][e7b1dcaa87efb06bcf08ca9343861656.png]

数据库它是以行为单位将数据加载到内存中，这样拆分以后核心表大多是访问频率较高的字段，而且字段长度也都较短，因而可以加载更多数据到内存中，减少磁盘IO，增加索引查询的命中率，进一步提升数据库性能。

#### 水平拆分 ####

上边垂直分库、垂直分表后还是会存在单库、表数据量过大的问题，当我们的应用已经无法在细粒度的垂直切分时，依旧存在单库读写、存储性能瓶颈，这时就要配合水平分库、水平分表一起了。

##### 1、水平分库 #####

水平分库是把同一个表按一定规则拆分到不同的数据库中，每个库可以位于不同的服务器上，以此实现水平扩展，是一种常见的提升数据库性能的方式。

![图片][cfbbb8e9c9389a30894761566d8be781.png]

例如：`db_orde_1`、`db_order_2`两个数据库内有完全相同的`t_order`表，我们在访问某一笔订单时可以通过对订单的订单编号取模的方式 `订单编号 mod 2 （数据库实例数）` ，指定该订单应该在哪个数据库中操作。

这种方案往往能解决单库存储量及性能瓶颈问题，但由于同一个表被分配在不同的数据库中，数据的访问需要额外的路由工作，因此系统的复杂度也被提升了。

##### 2、水平分表 #####

水平分表是在**同一个数据库内**，把一张大数据量的表按一定规则，切分成多个结构完全相同表，而每个表只存原表的一部分数据。

例如：一张`t_order`订单表有900万数据，经过水平拆分出来三个表，`t_order_1`、`t_order_2`、`t_order_3`，每张表存有数据300万，以此类推。

![图片][c20756089794398a9fce268bb9b845b9.png]

水平分表尽管拆分了表，但子表都还是在同一个数据库实例中，只是解决了单一表数据量过大的问题，并没有将拆分后的表分散到不同的机器上，还在竞争同一个物理机的CPU、内存、网络IO等。要想进一步提升性能，就需要将拆分后的表分散到不同的数据库中，达到分布式的效果。

![图片][4ea0f66f3c183631b993ee55fae271cc.png]

### 数据存在哪个库的表 ###

分库分表以后会出现一个问题，一张表会出现在多个数据库里，到底该往哪个库的哪个表里存呢？

上边我们多次提到过`一定规则` ，其实这个规则它是一种路由算法，决定了一条数据具体应该存在哪个数据库的哪张表里。

常见的有 `取模算法` 、`范围限定算法`、`范围+取模算法` 、`预定义算法`

#### 1、取模算法 ####

关键字段取模（对hash结果取余数 hash(XXX) mod N)，N为数据库实例数或子表数量）是最为常见的一种路由方式。

以`t_order`订单表为例，先给数据库从 0 到 N-1进行编号，对 `t_order`订单表中`order_no`订单编号字段进行取模`hash(order_no) mod N`，得到余数`i`。`i=0`存第一个库，`i=1`存第二个库，`i=2`存第三个库，以此类推。

![图片][9bfea8094f7d7f149007a0ced4b372d4.png]

同一笔订单数据会落在同一个库、表里，查询时用相同的规则，用`t_order`订单编号作为查询条件，就能快速的定位到数据。

##### 优点 #####

实现简单，数据分布相对比较均匀，不易出现请求都打到一个库上的情况。

##### 缺点 #####

取模算法对集群的伸缩支持不太友好，集群中有N个数据库实`·hash(user_id) mod N`，当某一台机器宕机，本应该落在该数据库的请求就无法得到处理，这时宕掉的实例会被踢出集群。

此时机器数减少算法发生变化`hash(user_id) mod N-1`，同一用户数据落在了在不同数据库中，等这台机器恢复，用`user_id`作为条件查询用户数据就会少一部分。

#### 2、范围限定算法 ####

范围限定算法以某些范围字段，如`时间`或`ID区`拆分。

用户表`t_user`被拆分成`t_user_1`、`t_user_2`、`t_user_3`三张表，后续将`user_id`范围为1 ~ 1000w的用户数据放入`t_user_1`，1000~ 2000w放入`t_user_2`，2000~3000w放入`t_user_3`，以此类推。按日期范围划分同理。

![图片][7b85b23c90a5b1107de80847a1536e80.png]

##### 优点 #####

*  单表数据量是可控的
 *  水平扩展简单只需增加节点即可，无需对其他分片的数据进行迁移

##### 缺点 #####

*  由于连续分片可能存在`数据热点`，比如按时间字段分片时，如果某一段时间（双11等大促）订单骤增，存11月数据的表可能会被频繁的读写，其他分片表存储的历史数据则很少被查询，导致数据倾斜，数据库压力分摊不均匀。

#### 3、范围 + 取模算法 ####

为了避免热点数据的问题，我们可以对上范围算法优化一下

这次我们先通过范围算法定义每个库的用户表`t_user`只存1000w数据，第一个`db_order_1`库存放`userId`从1 ~ 1000w，第二个库10002000w，第三个库20003000w，以此类推。

![图片][b52f1b5e69a93cd9fbe1b4987dadbd9e.png]

每个库里再把用户表`t_user`拆分成`t_user_1`、`t_user_2`、`t_user_3`等，对`userd`进行取模路由到对应的表中。

有效的避免数据分布不均匀的问题，数据库水平扩展也简单，直接添加实例无需迁移历史数据。

#### 4、地理位置分片 ####

地理位置分片其实是一个更大的范围，按城市或者地域划分，比如华东、华北数据放在不同的分片库、表。

#### 5、预定义算法 ####

预定义算法是事先已经明确知道分库和分表的数量，可以直接将某类数据路由到指定库或表中，查询的时候亦是如此。

### 分库分表出来的问题 ###

了解了上边分库分表的拆分方式不难发现，相比于拆分前的单库单表，系统的数据存储架构演变到现在已经变得非常复杂。看几个具有代表性的问题，比如：

#### 分页、排序、跨节点联合查询 ####

分页、排序、联合查询，这些看似普通，开发中使用频率较高的操作，在分库分表后却是让人非常头疼的问题。把分散在不同库中表的数据查询出来，再将所有结果进行汇总合并整理后提供给用户。

比如：我们要查询11、12月的订单数据，如果两个月的数据是分散到了不同的数据库实例，则要查询两个数据库相关的数据，在对数据合并排序、分页，过程繁琐复杂。

![图片][3e6eff4a4f33fc56b148844192cd3ba9.png]

#### 事务一致性 ####

分库分表后由于表分布在不同库中，不可避免会带来跨库事务问题。可以用阿里的`Seata或`MySQL的`XA`协议实现分布式事务，二者有各自的优势与不足。

#### 全局唯一的主键 ####

分库分表后数据库表的主键ID业务意义就不大了，因为无法在标识唯一一条记录，例如：多张表`t_order_1`、`t_order_2`的主键ID全部从1开始会重复，此时我们需要主动为一条记录分配一个ID，这个全局唯一的ID就叫`分布式ID`，发放这个ID的系统通常被叫发号器。

#### 多数据库高效治理 ####

对多个数据库以及库内大量分片表的高效治理，是非常有必要，因为像某宝这种大厂一次大促下来，订单表可能会被拆分成成千上万个`t_order_n`表，如果没有高效的管理方案，手动建表、排查问题是一件很恐怖的事。

#### 历史数据迁移 ####

分库分表架构落地以后，首要的问题就是如何平滑的迁移历史数据，增量数据和全量数据迁移，这又是一个比较麻烦的事情，之后有机会再分享。

### 分库分表架构模式 ###

分库分表架构主要有两种模式：`client`客户端模式和`proxy`代理模式

#### 客户模式 ####

`client`模式指分库分表的逻辑都在你的系统应用内部进行控制，应用会将拆分后的 SQL 直连多个数据库进行操作，然后本地进行数据的合并汇总等操作。

![图片][8c43be5d9faba14346d07a56da1129a8.png]

#### 代理模式 ####

`proxy`代理模式将应用程序与 MySQL 数据库隔离，业务方的应用不再需要直连数据库，而是连接 proxy 代理服务，代理服务实现了 MySQL 的协议，对业务方来说代理服务就是数据库，它会将 SQL 分发到具体的数据库进行执行，并返回结果。该服务内有分库分表的配置，根据配置自动创建分片表。

![图片][94e487980c9a9d1cca323a5bc73b0e74.png]

#### 如何抉择 ####

如何选择`client`模式和`proxy`模式，我们可以从以下几个方面来简单做下比较。

##### 1、性能 #####

性能方面`client`模式表现的稍好一些，它是直接连接 MySQL 执行命令；`proxy`代理服务则将整个执行链路延长了，应用->代理服务->MySQL，可能导致性能有一些损耗，但两者差距并不是非常大。

##### 2、复杂度 #####

`client`模式在开发使用通常引入一个 jar 可以；`proxy`代理模式则需要搭建单独的服务，有一定的维护成本，既然是服务那么就要考虑高可用，毕竟应用的所有 SQL 都要通过它转发至 MySQL。

##### 3、升级 #####

`client`模式分库分表一般是依赖基础架构团队的 jar 包，一旦有版本升级或者 Bug 修改，所有应用到的项目都要跟着升级。小规模的团队服务少升级问题不大，如果是大公司服务规模大，且涉及到跨多部门，那么升级一次成本就比较高；

`proxy`模式在升级方面优势很明显，发布新功能或者修复 Bug，只要重新部署代理服务集群即可，业务方是无感知的，但要保证发布过程中服务的可用性。

##### 4、治理、监控 #####

`client`模式由于是内嵌在应用内，应用集群部署不太方便统一处理；`proxy`模式在对 SQL 限流、读写权限控制、监控、告警等服务治理方面更优雅一些。

### 结束语 ###

所有应用到的项目都要跟着升级。小规模的团队服务少升级问题不大，如果是大公司服务规模大，且涉及到跨多部门，那么升级一次成本就比较高；

`proxy`模式在升级方面优势很明显，发布新功能或者修复 Bug，只要重新部署代理服务集群即可，业务方是无感知的，但要保证发布过程中服务的可用性。

##### 4、治理、监控 #####

`client`模式由于是内嵌在应用内，应用集群部署不太方便统一处理；`proxy`模式在对 SQL 限流、读写权限控制、监控、告警等服务治理方面更优雅一些。

### 结束语 ###

本文主要是分享分库分表的一些基础概念，为大家在进行`ShardingSphere`实践中更好上手理解，大家有什么想法和收获都可以在评论区讨论哈。

[0ef2e4845eb274fc6f9c1730d058a636.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/c3a33b0eece74754833953952606936d.png
[7a54b5f4b40b488f725501b854a6e975.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/91f164d238b449ba86729e72f2b0239d.png
[9ada640df5c6647aaad77c9bdd2c7692.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/822cb1dc055645a1a7861be6e3ee2280.png
[0e9c91b53382ba97cc9b512dc92ffbcf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/4905fbac16de49a28a5a93afbf00cb20.png
[147d20f9293e984c82f0ccf63861dae9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/4925ae89a7074878854af636308851f2.png
[e7b1dcaa87efb06bcf08ca9343861656.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/a1f1f9aa3db746179ea5f1049d445ce2.png
[cfbbb8e9c9389a30894761566d8be781.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/adfaccdec15d403898a497548ad00a89.png
[c20756089794398a9fce268bb9b845b9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/316b9e0e318c43edbec204782c476da8.png
[4ea0f66f3c183631b993ee55fae271cc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/2912213602a8412b831f8b1591c7c52b.png
[9bfea8094f7d7f149007a0ced4b372d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/0da2163b08d149a990650a8f35d0a079.png
[7b85b23c90a5b1107de80847a1536e80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/270492651b474b598de098c18bfd8724.png
[b52f1b5e69a93cd9fbe1b4987dadbd9e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/817b1f6747a4477f987278e85df18e88.png
[3e6eff4a4f33fc56b148844192cd3ba9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/d328ee79af444d6fba183d0faf57fbff.png
[8c43be5d9faba14346d07a56da1129a8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/aafc8566ab0840acb1f35d72e14acb18.png
[94e487980c9a9d1cca323a5bc73b0e74.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/d419ad3247404dab8323321a70d8e732.png