简介

当前微服务架构非常流行，很多都会采用微服务架构对其系统进行拆分。 而虽然产生了多个微服务，但因为其用户量和数据量的问题，很有可能仍然使用的是同一个数据库。但是随着用户量和数据量增加，就会出现很多影响数据库性能的因素，如：数据存储量、IO 瓶颈、访问量瓶颈等。此时就需要将数据进行拆分，从一个库拆分成多个库。

水平切分

为了解决垂直拆分出现的问题，可以使用水平拆分继续横向扩展，首先，可以如果当前数据库的容量没有问题的话，可以对读写极其频繁且数据量超大的表进行分表操作。由一张表拆分出多张表。

在一个库中，拆分出多张表，每张表存储不同的数据，这样对于其操作效率会有明显的提升。而且因为处于同一个库中，也不会出现分布式事务的问题。

而拆分出多张表后，如果当前数据库的容量已经不够了，但是还要继续拆分的话，就可以进行分库操作，产生多个数据库，然后在扩展出的数据库中继续扩展表。

优点：

  • 尽量的避免了跨库 join 操作
  • 不会存在超大型表的性能瓶颈问题
  • 事务处理相对简单
  • 只要拆分规则定义好，很难出现扩展性的限制

缺点：

  • 拆分规则不好明确，规则一定会和业务挂钩，如根据 id、根据时间等
  • 不好明确数据位置，难以进行维护
  • 多数据源管理难度加大，代码复杂度增加
  • 也会存在分布式事务问题
  • 数据库维护成本增加

垂直切分

垂直拆分是按照业务将表进行分类并分布到不同的数据节点上。在初始进行数据拆分时，使用垂直拆分是非常直观的一种方式。

优点：

  • 拆分规格明确，按照不同的功能模块或服务分配不同的数据库
  • 数据维护与定位简单

缺点：

  • 对于读写极其频繁且数据量超大的表，仍然存在存储与性能瓶颈。简单的索引此时已经无法解决问题
  • 会出现跨库 join
  • 需要对代码进行重构，修改原有的事务操作
  • 某个表数据量达到一定程度后扩展起来较为困难

存在的问题

数据切分带来的问题:

  • 产生引入分布式事务的问题
  • 跨节点 Join 的问题
  • 跨节点合并排序分页问题

例如:

  • 按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中
  • 按照日期，将不同月甚至日的数据分散到不同的库中
  • 按照某个特定的字段求模，或者根据特定范围段分散到不同的库中