系列文章目录

文章目录

系列文章目录
前言
一、什么是分库分表
二、分库分表的原因
- 分库
- 分表
三、如何分库分表
- 3.1 垂直拆分
- - 1.垂直分库
  - 2、垂直分表
- 3.2 水平拆分
- - 水平分库
  - 水平分表
  - 水平分库分表的策略
  - - hash取模算法
    - range范围
    - range+hash取模混合
    - 地理位置分片
    - 预定义算法
四、分库分表的问题
- 分页、排序、跨节点联合查询
- 事务一致性
- 全局唯一的主键
- 多数据库高效治理
- 历史数据迁移
参考

前言

想要开发一个基于 HashMap 核心设计原理，使用哈希散列+扰动函数的方式，把数据散列到多个库表中的组件，并验证使用。这里是分库分表的基础知识

一、什么是分库分表

分库：就是一个数据库分成多个数据库，部署到不同机器。
在这里插入图片描述

分表：就是一个数据库表分成多个表。
在这里插入图片描述

二、分库分表的原因

分库

如果业务量剧增，数据库可能会出现性能瓶颈，这时候我们就需要考虑拆分数据库。从这几方面来看：

磁盘存储

业务量剧增，MySQL单机磁盘容量会撑爆，拆成多个数据库，磁盘使用率大大降低。

并发连接支撑

我们知道数据库连接是有限的。在高并发的场景下，大量请求访问数据库，MySQL单机是扛不住的！当前非常火的微服务架构出现，就是为了应对高并发。它把订单、用户、商品等不同模块，拆分成多个应用，并且把单个数据库也拆分成多个不同功能模块的数据库（订单库、用户库、商品库），以分担读写压力。

分表

数据量太大的话，SQL的查询就会变慢。如果一个查询SQL没命中索引，千百万数据量的表可能会拖垮这个数据库。
即使SQL命中了索引，如果表的数据量超过一千万的话，查询也是会明显变慢的。这是因为索引一般是B+树结构，数据千万级别的话，B+树的高度会增高，查询就变慢啦。

一棵高度为2的B+树，能存放1170 * 16=18720条这样的数据记录。同理一棵高度为3的B+树，能存放1170 *1170 *16 =21902400，大概可以存放两千万左右的记录。B+树高度一般为1-3层，如果B+到了4层，查询的时候会多查磁盘的次数，SQL就会变慢。
因此单表数据量超过千万，就需要考虑分表啦。是否分库分表的关键指标是数据量

三、如何分库分表

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

在这里插入图片描述

首先我们要知道为什么要用分库分表，其实就是由于业务体量较大，数据增长较快，所以需要把用户数据拆分到不同的库表中去，减轻数据库压力。

分库分表操作主要有垂直拆分和水平拆分：

垂直拆分：指按照业务将表进行分类，分布到不同的数据库上，这样也就将数据的压力分担到不同的库上面。最终一个数据库由很多表的构成，每个表对应着不同的业务，也就是专库专用。
水平拆分：如果垂直拆分后遇到单机瓶颈，可以使用水平拆分。相对于垂直拆分的区别是：垂直拆分是把不同的表拆到不同的数据库中，而水平拆分是把同一个表拆到不同的数据库中。如：user_001、user_002

3.1 垂直拆分

1.垂直分库

在这里插入图片描述
但是随着业务蒸蒸日上，系统功能逐渐完善。这时候，可以按照系统中的不同业务进行拆分，比如拆分成用户库、订单库、积分库、商品库，把它们部署在不同的数据库服务器，这就是垂直分库。
垂直分库把一个库的压力分摊到多个库，提升了一些数据库性能，但并没有解决由于单表数据量过大导致的性能问题，所以就需要配合后边的分表来解决。

2、垂直分表

如果一个单表包含了几十列甚至上百列，管理起来很混乱，每次都select *的话，还占用IO资源。这时候，我们可以将一些不常用的、数据较大或者长度较长的列拆分到另外一张表。
比如一张用户表，它包含user_id、user_name、mobile_no、age、email、nickname、address、user_desc，如果email、address、user_desc等字段不常用，我们可以把它拆分到另外一张表，命名为用户详细信息表。这就是垂直分表

在这里插入图片描述

3.2 水平拆分

当我们的应用已经无法在细粒度的垂直切分时，依旧存在单库读写、存储性能瓶颈，这时就要配合水平分库、水平分表一起了。

水平分库

水平分库是指，将表的数据量切分到不同的数据库服务器上，每个服务器具有相同的库和表，只是表中的数据集合不一样。它可以有效的缓解单机单库的性能瓶颈和压力。
在这里插入图片描述
例如：db_orde_1、db_order_2两个数据库内有完全相同的t_order表，我们在访问某一笔订单时可以通过对订单的订单编号取模的方式订单编号 mod 2 （数据库实例数），指定该订单应该在哪个数据库中操作。
这种方案往往能解决单库存储量及性能瓶颈问题，但由于同一个表被分配在不同的数据库中，数据的访问需要额外的路由工作，因此系统的复杂度也被提升了。

水平分表

水平分表是在同一个数据库内，把一张大数据量的表按一定规则，切分成多个结构完全相同表，而每个表只存原表的一部分数据。
例如：一张t_order订单表有900万数据，经过水平拆分出来三个表，t_order_1、t_order_2、t_order_3，每张表存有数据300万，以此类推。

在这里插入图片描述

水平分库分表的策略

如果一个表的数据量太大，可以按照某种规则（如hash取模、range），把数据切分到多张表去。

其实这个规则它是一种路由算法，决定了一条数据具体应该存在哪个数据库的哪张表里。

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

hash取模算法

hash取模策略：指定的路由key（一般是user_id、订单id作为key）对分表总数进行取模，把数据分散到各个表中。
在这里插入图片描述

比如id=1，对4取模，就会得到1，就把它放到第1张表，即t_order_0;
id=3，对4取模，就会得到3，就把它放到第3张表，即t_order_2;

这种方案的优点：

hash取模的方式，不会存在明显的热点问题。

缺点：

如果一开始按照hash取模分成4个表了，未来某个时候，表数据量又到瓶颈了，需要扩容，这就比较棘手了。比如你从4张表，又扩容成8张表，那之前id=5的数据是在（5%4=1，即第一张表），现在应该放到（5%8=5，即第5张表），也就是说历史数据要做迁移了。

range范围

range，即范围策略划分表。比如我们可以将表的主键，按照从0_{1000万的划分为一个表，1000}2000万划分到另外一个表。如下图：在这里插入图片描述
这种方案的优点：

这种方案有利于扩容，不需要数据迁移。假设数据量增加到5千万，我们只需要水平增加一张表就好啦，之前0~4000万的数据，不需要迁移。

缺点：

这种方案会有热点问题，因为订单id是一直在增大的，也就是说最近一段时间都是汇聚在一张表里面的。比如最近一个月的订单都在1000万~2000万之间，平时用户一般都查最近一个月的订单比较多，请求都打到order_1表啦，这就导致表的数据热点问题。

range+hash取模混合

既然range存在热点数据问题，hash取模扩容迁移数据比较困难，我们可以综合两种方案一起嘛，取之之长，弃之之短。
比较简单的做法就是，在拆分库的时候，我们可以先用range范围方案，比如订单id在04000万的区间，划分为订单库1，id在4000万8000万的数据，划分到订单库2,将来要扩容时，id在8000万~1.2亿的数据，划分到订单库3。然后订单库内，再用hash取模的策略，把不同订单划分到不同的表。
在这里插入图片描述

地理位置分片

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

预定义算法

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

四、分库分表的问题

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

分页、排序、联合查询，这些看似普通，开发中使用频率较高的操作，在分库分表后却是让人非常头疼的问题。把分散在不同库中表的数据查询出来，再将所有结果进行汇总合并整理后提供给用户。
比如：我们要查询11、12月的订单数据，如果两个月的数据是分散到了不同的数据库实例，则要查询两个数据库相关的数据，在对数据合并排序、分页，过程繁琐复杂。

方案1：在个节点查到对应结果后，在代码端汇聚再分页。
方案2：把分页交给前端，前端传来pageSize和pageNo，在各个数据库节点都执行分页，然后汇聚总数量前端。这样缺点就是会造成空查，如果分页需要排序，也不好搞。
排序问题：
跨节点的count,order by,group by以及聚合函数等问题：可以分别在各个节点上得到结果后在应用程序端进行合并。