数据库分库分表实战

x33g5p2x  于2021-12-11 转载在 其他  
字(0.8k)|赞(0)|评价(0)|浏览(259)

一 使用场景

当单个数据库实例达到瓶颈,例如连接数过多,处理能力受限、存储容量不足、磁盘IO达到瓶颈、内存不足,都需要对数据库进行分库分表。

二 垂直切分

数据库表按列拆分,拆分后,数据库从一个数据列多的表变成了多个数据列少的表。

数据垂直切分如下图所示。

在拆分过程中,由于可能存在冗余字段,所以按照以下原则进行切分

  • 将不常用的字段放到一个表中
  • 将 blog 等占用空间较多的字段拆分到一个表中
  • 将经常一起被访问的字段放到一个表中

三 水平切分

保持表的结构不变,把数据按照行拆分,每个表的数据量变少。

水平切分示意图。

切分方法:

  • 在规定的范围内,每一百万条数据分一个表,按照主键的值进行划分。
  • 按照 主键 % (表的个数)的结果进行划分,然后拆分到相应的数据表中。

通过将不同的表归属到不同的数据库中,存储在不同的物理节点上 ,达到消除性能瓶颈的目的。

四 影响

无论采用哪种方法进行分库分表,都会影响实际数据库的功能范围。因为原本存储在一个表中的数据库支持的操作,由于分库分表后,由于物理分割,从前一个数据库支持的操作就不适用了。

1 事务失效

解决方案:通过乐观锁或分布式事务来解决。跟不分库分表相比,实现的复杂度和难度增加了。

2 分页、排序、统计最值等函数失效

解决方案:在每个分库中统计结果,汇总结果后,再集中处理,得到最终结果。

3 主键冲突

解决方案:主键ID + 库表ID 来实现全局唯一。

五 切分优点

1 容易维护

服务变小后,每个模块的规模变小了,出问题只会影响某个模块,不会影响全局。

2 方便团队并行开发

切分后,每个模块规模变小了,每个人负责的模块小了,只会修改和自己相关的模块,而不是整个应用,编码时,代码冲突也会变少。

3 容易重构

如果整体都在一起,当修改一处代码,则要整体编译,整体发布。而且为了稳定,需要整体测试。

4 复用组装

细粒度模块像搭积木一起灵活搭配,从而实现新功能。

相关文章