同样是分库分表, 你为何如此优秀

随着公司业务快速发展,数据量的猛增,数据库就会变成系统的瓶颈.随之而来的就会有运维成本高,数据热点等诸多问题.

为解决瓶颈, 除了优化数据库本身外, 最常用的方式就是分库分表了. 尤其是当我们发现某个表数据量达到1千万或者2千万时, 就认为可以进行分库分表了. 但这种判断方式是错的.

正确方式是判断出当前数据库瓶颈是什么, 根据瓶颈的不同调整方案也是不同的. 如果一个表的行长度很多, 即使是数据量达到2千万也不需要进行调整, 这是因为mysql的磁盘数据读取方式是按页读写的. 在行数据长度不长时, 每页是可以存储很多数据的.

数据库瓶颈一般有磁盘IO,网络IO等瓶颈, 以及SQL计算等引起的CPU瓶颈.

为解决上述数据库问题, 通常有三种方式, 按优先考虑使用顺序分别是: 分库, 垂直分表, 水平分表(分库分表), 选择合理的解决方法才会达到最优效果.

分库

选择合适的表拆分到多个数据库实例中, 可以直接缓解IO问题和CPU问题. 这里合适的表主要是指业务相关性不高的表.

例如, 一个电商库可以拆分为用户库,订单库,产品库等.

在做分库操作时, 需要注意避免引入分布式事务问题; 另外, 在设计不合理的系统中, 各表关联性较高, 做分库的同时, 业务代码可能也需要做兼容改动. 总体来说, 是一种性价比较高的优化方案.

垂直分表

针对某一个表IO较多, 同时表的列宽度较大时,一般会有如下问题: (1)表的行宽度较大时,检索表的时候需要执行大量的IO，严重降低了性能; (2)在数据更新时不仅会增加数据文件的IO负担, 也增加系统重做日志(redo log),回滚日志(undo log),二进制日志(binlog)的IO负担; (3)表的宽度过大,还会引起行溢出问题, 浪费更多磁盘空间;

这时可以优先做垂直拆分, 也就是垂直分表是将表的大字段或者多个字段分离到其他表中.

垂直分表会减少每个表的行宽度, 增加每个数据库页的数据行数量, 提高IO效率. 这里拆表时, 可以根据以下拆分大表原则: (1)把不常用的字段或者不经常更新的字段拆分到一张表, 经常变更的字段拆分到另一个表中; (2)把text，blob等大字段拆分出来放在附表中,可以有效减少行溢出问题, 提高IO效率; (3)经常组合查询的列拆分到一张表中;

例如, 如下用户表:

用户表:{'用户ID', '昵称', '生日', 'email', '登录时间'}

先分析下表结构, 除了'登录时间'字段外, 其他字段基本都不会变动了, 首先可以将'登录时间'时间.

用户表:{'用户ID', '昵称', '生日', 'email'}
用户登录表:{'用户ID', '登录时间'}

当然实际项目中表结构会更复杂, 需要具体分析下.

水平分表(分库分表)

水平分表是针对数据量特别大的表常用的优化手段, 准确的说应该是分库分表. 主要的优化手段就是分库分表, 这里的提到的分表就是水平分表. 并不是所有情况都需要进行分库,如果是数据量并不是特别大时, 可以只使用分表, 这样可以减少多数据源带来的额外开发, 事务, 中间件等问题.

在做分库分表之前, 首先我们需要先分析数据特点.

例如, 订单数据, 大多数业务场景是只关心最近一段时间的数据,这时再将所有数据都存储到一起, 就很浪费了. 这时最好的分库分表方法是将数据按时间分为热点数据和历史数据, 更久远的数据甚至可以做归档处理.

再举个例子, 如果针对有 1 亿数据的用户表, 这时比较好的处理方式是根据hash(userID)算法, 将数据平均分配到多个表中.

综上, 根据数据特点的不同, 需要选择不同的分表方式.

在代码的多数据源兼容方面可以使用 Spring 动态数据源,也可以使用 mycat,ShardingSphere这样的分库中间件.

总结

在解决数据库瓶颈时, 一定要想清楚瓶颈是什么, 根据业务情况, 选择合适的解决方式。