Janker

V1

2023/01/08阅读:19主题:橙心

分库分表,真的有必要吗?

分库分表,真的有必要吗?

哈喽,大家好,我是janker。

关于数据库分库分表的面试题已经是烂大街了,面经小册各路神仙的经验分享也是不绝于耳。当然现有的技术解决方案已经是很成熟了。

但是想要使用的得心应手,首先应该搞清楚三个问题?

  • 为什么使用分库分表?
  • 何时使用分库分表?
  • 如何分库分表?

为什么使用分库分表?

​ 答案很简单:当数据库出现性能瓶颈。顾名思义就是数据库扛不住了。

数据库出现瓶颈,对外表现有以下几个方面?

  1. 高并发场景下,大量请求阻塞,大量请求都需要操作数据库,导致连接数不够了,请求处于阻塞状态。
  2. SQL操作变慢(慢SQL增多)如果数据库中存在一张上亿数据量的表,一条 SQL 没有命中索引会全表扫描,这个查询耗时会非常久。
  3. 随着业务流量变大存储出现问题,单库数据量越来越大,给存储造成巨大压力。

​ 从机器角度,性能瓶颈不外乎就是CPU、磁盘、内存、网络这些,要解决性能瓶颈最简单粗暴的方式就是提升机器性能,但是通过这种方式投入产出比往往不高,也不划算,所以重点还是要从软件层面去解决问题。

​ 数据库相关优化方案

数据库优化方案很多,主要分为两大类:软件层面、硬件层面。

软件层面包括:SQL 调优、表结构优化、读写分离、数据库集群、分库分表等;

硬件层面主要是增加机器性能。

分库分表其实不是数据库优化方案的最终解决办法,一般来说说能用优化SQL、表结构优化、读写分离等手段解决问题,就不要分库分表,因为分库分表会带来更多需要解决的问题,比如说分布式事务,查询难度增大等。

何时使用分库分表?

什么时候我们才会选择分库分表?前面已经说了,除了分库分表以外那些软件手段搞不定的时候,我们才会选择分库分表。

我们心中可能会有这些疑问?

  1. 使用分库分表,我们的评判依据是什么?
  2. 一张表存储了多少数据的时候,才需要考虑分库分表?
  3. 数据增长速度很快,每天产生多少数据,才需要考虑做分库分表?

阿里巴巴开发手册有推荐的思路:单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。

注意:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。

如何分库分表?

当前针对分库分表有很多解决方案。这里分两个方面来展开说说:分库 和 分表。

分库

很多项目前期为了快速迭代,多个应用公用一套数据库,随着业务量增加,系统访问压力增大,系统拆分就势在必行。

为了保证业务平滑,系统架构重构也是分了几个阶段进行。

多应用单数据库

第一个阶段将商城系统单体架构按照功能模块拆分为子服务,比如:Portal 服务、用户服务、订单服务、库存服务等。

image-20230107232802486

多应用单数据库如上图,多个服务共享一个数据库,这样做的目的是底层数据库访问逻辑可以不用动,将影响降到最低。

多应用多数据库

随着业务推广力度加大,数据库终于成为了瓶颈,这个时候多个服务共享一个数据库基本不可行了。我们需要将每个服务相关的表拆出来单独建立一个数据库,这其实就是“分库”了。

单数据库的能够支撑的并发量是有限的,拆成多个库可以使服务间不用竞争,提升服务的性能。

image-20230107233441875
image-20230107233441875

从一个大的数据中分出多个小的数据库,每个服务都对应一个数据库,这就是系统发展到一定阶段必要要做的“分库”操作。

分表

说完了分库,那什么时候才会分表呢?

如果系统处于高速发展阶段,拿商城系统来说,一天下单量可能几十万,那数据库中的订单表增长就特别快,增长到一定阶段数据库查询效率就会出现明显下降。

因此当表数据增长过快,根据阿里巴巴开发规范中超过500w的数据就要考虑分表了,当然这只是一个经验值,具体要不要分表还要看业务考虑未来三年的一个业务增量。

如何分表?

分表有几个维度,一是水平切分和垂直切分,二是单库内分表和多库内分表。

水平拆分和垂直拆分

拿商品表来说,表中分为几类属性:一类是基础属性,例如:商品名称、通用名,商品编码等信息。二类是规格属性:尺寸、型号等信息。三类是拓展属性:描述商品特征的一些属性。我们可以将其拆分为基础信息表、拓展属性表、属性信息表等。这几张表结构不同并且相互独立。但是从这个角度没有解决因为数据量过大而带来的性能问题,因此我们还需要继续做水平拆分。

image-20230108161956743

水平拆分表的方法很多种,比如说1w条数据,我们拆分为两个表,id 为基数的放在user1,id为偶数的放在user2中,这样的拆分方式就是水平拆分。

其他水平拆分的方式也很多,除了上面按照 id 来拆分,还可以按照时间维度拆分,比如订单表,可以按照每日、每月等进行拆分。

  • 每日表:只存储当天你的数据。
  • 每月表:可以起一个定时任务将前一天的数据全部迁移到当月表。
  • 历史表:同样可以用定时任务把时间超过 30 天的数据迁移到 history表。

总结一下水平拆分和垂直拆分的特点:

  • 垂直切分:基于表或者字段划分,表结构不同。
  • 水平拆分:基于数据划分,表结构相同,数据不同。根据表中字段的某一列特性,分而治之。

水平拆分也分两种拆分方式。单库内拆分和多库内拆分

单库内拆分和多库内拆分

拿针对用户表的拆分来举例,之前的单个用户表按照某种规则拆分为多个子表,多个子表存在于同一数据库中。比如下面用户表拆分为用户1表、用户2表。

image-20230108203705147

单库内拆分是在一个数据库中,将一张表拆分为多个子表,一定程度上可以解决单表查询的性能问题,但是也会遇到另外一个问题:但数据库的数据瓶颈。

所以在行业内更多的将子表拆分到多个数据库中,如下图,用户表拆分为4个子表,4个子表分两批存在两个不同的数据库中,根据一定的规则进行路由。

image-20230108204316330

多库拆分用一句话概括:主要是为了减少单张表数据量大小,解决单表数据量过大带来的性能问题。

但是分库分表也带来许多问题。

分库分表带来的问题

既然分库分表方案那么好,那我们是不是在项目初期就应该采用这种方案呢?莫慌,虽然分库分表解决了很多性能问题,但是同时也给系统带来了很多复杂性。下面我展开说说

1. 跨库关联查询

之前单体项目,我们想查询一些数据,无脑join就好了,只要数据模型设计没啥问题,关联查询起来其实还是很简单的。现在不一样了,分库分表后的数据可能不在一个数据库,那我们如何关联查询呢?

下面推荐几种方式去解决这个问题:

  1. 字段冗余:把需要关联的字段放到主表中,避免join操作,但是关联字段更新,也会引发冗余字段的更新;
  2. 数据抽象:通过ETL 等将数据汇总聚合,生成新的表;
  3. 全局表:一般是一些基础表可以在每个数据库都放一份;
  4. 应用层组装:将基础数据查出来,通过应用程序计算组装;
  5. 同特征的数据在一张表:举个例子:同一个用户的数据在同一个库中,比如说我们对订单按照用户id进行分表,订单主表、订单拓展信息表、跟订单有关联查询的表都按照用户id 进行分表,那么同一个用户的订单数据肯定在同一个数据库中,订单维度的关联查询就不存在跨库的问题了。

2. 分布式事务

单数据库我们可以用本地事务搞定,使用多数据库就只能通过分布式事务解决了。

常用的解决方案有:基于可靠消息(MQ)的最终一致性方案、二段式提交(XA)、柔性事务。

当然分布式事务相关开源项目推荐两个:SeataTX-LCN

比较推荐 Seata,阿里出品、大厂加持、如果需要企业级版本支持也是有的。

3. 排序、分表、函数计算问题

使用SQL 时,order bylimit 等关键字需要特殊处理,一般都是采用数据分片的思路:现在每个分片路由上执行函数、然后将每个分片路由的结果汇总再计算,然后得出最终结果。

开源的解决方案当然也有不少,比较推荐shardingsphere,无论是基于client 或者 基于数据库proxy的都有支持。

4. 分布式ID

既然分库分表了,主键id已经不能唯一确定我们的业务数据了,随之而来的就是分布式id,顾名思义就是在多个数据库多张表中唯一确定的ID。

常见的分布式Id 解决方案有:

  1. UUID
  2. 基于全局数据库自增的ID表
  3. 基于Redis缓存生成全局ID
  4. 雪花算法(Snowflake
  5. 百度uid-generator(雪花算法的变种)
  6. 美团Leaf(雪花算法的变种)
  7. 滴滴Tinyid

这些解决方案后面有专门的文章去介绍,这里不过多展开。

5. 多数据源

分库分表之后可能面临从多个数据库中获取数据,一般的解决方案有,基于 client 适配 和 基于 proxy 适配。

比较成熟并且常用的中间件有:

  • shardingsphere(apache顶级项目相当成熟,文档完善)
  • MyCat (社区不太活跃、不推荐)

总结

如果遇到数据库问题,建议不要着急分库分表。原则是:能不分库分表就不要做。先看下能否通过常规优化手段解决问题。

如上所述,引入分库分表虽然可以解决数据库瓶颈问题,但是也给系统带来巨大的复杂性,不是非必须不要使用。设计系统我们一向要本着高可拓展去设计,但是不要过度设计和超前设计。适合当前系统的设计才是最好的。

分类:

后端

标签:

Java

作者介绍

Janker
V1