说说分库分表?

随着用户量的激增和时间的堆砌,存在数据库里面的数据越来越多,此时的数据库就会产生瓶颈,出现资源报警、查询慢等场景。

首先单机数据库所能承载的连接数、I/O及网络的吞吐等都是有限的,所以当并发量上来了之后,数据库就渐渐顶不住了。

再则,如果单表的数据量过大,查询的性能也会下降。因为数据越多 B+ 树就越高,树越高则查询 I/O 的次数就越多,那么性能也就越差。

因为上述的原因,不得已就得上分库分表了。

把以前存在一个数据库实例里的数据拆分成多个数据库实例,部署在不同的服务器中,这是分库

把以前存在一张表里面的数据拆分成多张表,这是分表

一般而言:

  • 分表:是为了解决由于单张表数据量多大,而导致查询慢的问题。大致三、四千万行数据就得拆分,不过具体还是得看每一行的数据量大小,有些字段都很小的可能支持更多行数,有些字段大的可能一千万就顶不住了。
  • 分库:是为了解决服务器资源受单机限制,顶不住高并发访问的问题,把请求分配到多台服务器上,降低服务器压力。

你们一般怎么分库的?

一般分库都是按照业务划分的,比如订单库、用户库等等。

有时候会针对一些特殊的库再作切分,比如一些活动相关的库都做了拆分。

因为做活动的时候并发可能会比较高,怕影响现有的核心业务,所以即使有关联,也会单独做拆分。

那你觉得分库会带来什么问题呢?

首先是事务的问题。

我们使用关系型数据库,有很大一点在于它保证事务完整性。

而分库之后单机事务就用不上了,必须使用分布式事务来解决,而分布式事务基本的都是残缺的(我之前文章把分布式事务汇总了一波,后台搜索分布式事务就有了)。

这是很重要的一点需要考虑。

连表 JOIN 问题

在一个库中的时候我们还可以利用 JOIN 来连表查询,而跨库了之后就无法使用 JOIN 了。

此时的解决方案就是在业务代码中进行关联,也就是先把一个表的数据查出来,然后通过得到的结果再去查另一张表,然后利用代码来关联得到最终的结果。

这种方式实现起来稍微比较复杂,不过也是可以接受的。

还有可以适当的冗余一些字段。比如以前的表就存储一个关联 ID,但是业务时常要求返回对应的 Name 或者其他字段。这时候就可以把这些字段冗余到当前表中,来去除需要关联的操作。

那你们怎么分表的?

分表其实有两种:

  • 垂直分表
  • 水平分表

垂直分表,来看个图,很直观:

垂直分表就是把一些不常用的大字段剥离出去。

像上面的例子:用户名是很常见的搜索结果,性别和年龄占用的空间又不大,而地址和个人简介占用的空间相对而言就较大,我们都知道一个数据页的空间是有限的,把一些无用的数据拆分出去,一页就能存放更多行的数据。

内存存放更多有用的数据,就减少了磁盘的访问次数,性能就得到提升。

水平分表,则是因为一张表内的数据太多了,上文也提到了数据越多 B+ 树就越高,访问的性能就差,所以进行水平拆分。

其实不管这些,浅显的理解下,在一百个数据里面找一个数据快,还是在一万个数据里面找一个数据快?

即使有索引,那厚的书目录多,翻目录也慢~

那分表会有什么问题?

垂直分表还好,就是需要关联一下,而水平分表就有点麻烦了。

排序、count、分页问题

如果一个用户的数据被拆分到多个表中,那查询结果分页就不像以前单张表那样直接就能查出来了,像 count 操作也是一样的。

只能由业务代码来实现或者用中间件将各表中的数据汇总、排序、分页然后返回。

像 count 操作的结果其实可以缓存下来,然后每次数据增删都更新计数。

路由问题

分表的路由可以分:

  • Hash 路由
  • 范围路由
  • 路由表

Hash 路由,其实就是选择表中的某一列,然后进行 Hash 运算,将 Hash 运算得到的结果再对子表数进行取模,这样就能均匀的将数据分到不同的子表上。

这跟 HashMap 选哪个桶是一样的原理。

优点就是数据分布均匀。

缺点就是增加子表的时候麻烦,想想 HashMap的扩容,是不是得搬迁数据?这个分表也是一样的,我们可都知道,数据迁移一件麻烦事!

范围路由,其实很简单,可以是时间,也可以是地址,表示一定的范围的即可。

比如本来一张 User 表,我可以分 User_HZ、User_BJ、User_SH,按照地名来划分 User。

再比如 log 表,我可以将表分为 log_202103、 log_202104,把日志按照年月来划分。

优点就是相对而言比较容易扩展,比如现在来个 GZ,那就加个 User_GZ。如果到了 5 月,那就建个 log_202105。

缺点就是数据可能分布不均匀,例如 BJ 的用户特别多或者某个月搞了促销,日志量特别大,等等。

路由表,就是专门搞个表来记录路由信息,来看个图就很清楚了。

从图中我们就能得知,UserID 为 2 的用户数据在要去 User_3 这个用户表查询。

优点就是灵活咯,如果要迁移数据,直接迁移然后路由表一改就完事儿了~

缺点就是得多查一次,每次查询都需要访问路由表,不过这个一般会做缓存的。

全局主键问题

以前单表的时候很简单,就是主键自增,现在分表了之后就有点尴尬了。

所以需要一些手段来保证全局主键唯一。

  1. 还是自增,只不过自增步长设置一下。比如现在有三张表,步长设置为3,三张表 ID 初始值分别是1、2、3。这样第一张表的 ID 增长是 1、4、7。第二张表是2、5、8。第三张表是3、6、9,这样就不会重复了。
  2. UUID,这种最简单,但是不连续的主键插入会导致严重的页分裂,性能比较差。
  3. 分布式 ID,比较出名的就是 Twitter 开源的 sonwflake 雪花算法,具体就不展开了,不然就又是一篇文章了,简单点利用 redis 来递增也行。

那上面说的路由问题的 Sharding-Key 如何设计呢?

我们分表是按照某个列来拆分的,那个列就是 Sharding-Key,查询的时候必须带上这个列才行。

例如上面提到的  log_202103,那表明查询条件一定得带上日期,这样才能找到正确的表。

所以设计上得考虑查询的条件来作为 Sharding-Key。

举个常常会被问的订单表 Sharding-Key 例子。

你想着查找订单的时候会通过订单号去找,所以应该利用订单 ID 来作为 Sharding-Key。

但是你想想,你打开外卖软件想查找你的历史订单的时候,你是没有订单 ID 的,你只有你的 UserID,那此时只能把所有子表都通过 UserID 遍历一遍,这样效率就很低了!

所以你想着那用 UserID 来作为 Sharding-Key 吧!

但是,商家呢?商家肯定关心自己今天卖了多少单,所以他也要查找订单,但他只有自己的商家 ID,所以如果要查询订单,只能把所有子表都通过商家 ID 遍历一遍,这样效率就很低了!

所以 Sharding-Key 是满足不了所有查询需求的,只能曲线救国。

一般做法就是冗余数据

将订单同步到另一张表中给商家使用,这个表按商家 ID 来作为 Sharding-Key,也可以将数据同步到 ES 中。一般而言这里的数据同步都是异步处理,不会影响正常流程。

最后

今天的面试题主要是分库分表相关的,基本上常问的都涵盖了。

MySQL 面试题未完,持续更新~

因为分库分表会带来很多复杂性,所以能不分库分表,就不要分库分表。


0 条评论

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注