【干货】分库分表最佳实践

何时分库分表

MySQL单表(innoDB)可以存储10亿级数据,只是这时候性能比较差,业界公认MySQL单表容量在1KW以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。

参考阿里开发手册建议:

1.单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表;如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。

2.实际情况受mysql机器配置等多方面影响,可能数据量很大但性能依旧不错,但考虑后续发展一定要进行分库分表考虑。

如何分库分表

设置合适的分片数量

根据实际的业务场景选择合适的分片数据,参考如下:

  • 满足当前数据平均后的数据量在一个合理的范围(<=100w)
  • 预估未来5年的数据量发展情况,数据量在一个合理的范围(500w左右,有合理的归档备份机制)

选择合适的分片字段

根据实际的业务场景选择适当的分片字段,要达到如下要求:

  • 字段类型常规
  • 字段不易过多
  • 字段应该是业务场景大多数都会被使用的

设计合理的分片规则

分表数量和分表字段确定后,要设计一个合理的分表规则,良好的分表规则要达到如下条件:

  • 规则计算高效,逻辑清晰
  • 规则计算后,分片数据均匀
  • 方便后续扩容分片

如何保证分片数据均匀,参考:

  • 分片字段本身就是随机均匀的,可以直接使用
  • 分片字段随机,但不均匀,如对总分片取模后,会导致数据不均匀,建议先对分片字段进行2次随机处理(如:zebra提供的:md5/crc32 方法)

如何保证方便后续分片扩容,参考:

  • 如果是按照时间或数值范围进行分片,只需要创建分片库表,修改分片规则,立即生效
  • 如果是hash分片,条件允许可考虑停服迁移,停止服务,将数据按新分片规则进行迁移,修改分片规则,启动服务
  • 某些情况下可考虑升级从库,如2分库扩容为4分库,可将从库升级为主库并修改分片规则,后续可将冗余的数据进行清除并补上缺失的从库。
  • 数据库双写,同时按新老分片规则写入两套物理表,并逐渐下线老数据模型,可参考-新老迁移参考

SQL使用注意

如何高效的使用分库分表,核心是做到尽量的路由到最少的表,最好是只路由到一个表里面

核心规则如下:

  • 能带分片字段的就尽量把其带上
  • 尽量不使用范围查询
  • 无分片使用limit时不要查询太靠后的数据
  • 尽量不要使用复杂的sql
  • sql写法尽量规范

新老迁移方案参考

阶段一

  • 数据库双写(事务成功以老模型为准),查询走老模型。
  • 每日job数据对账,并将差异补平。
  • 通过job导历史数据。

阶段二

  • 历史数据导入完毕并且数据对账无误。
  • 依然是数据库双写,但是事务成功与否以新模型为准,在线查询切新模型。
  • 每日job数据对账,将差异补平。

阶段三

  • 老模型不再同步写入,异步补齐(同步数据终态)。
  • 此阶段只有离线数据依然依赖老的模型,并且下游的依赖非常多,待改造完就可以完全废除老模型了。

【干货】分库分表最佳实践

上一篇:[LeetCode] 1894. Find the Student that Will Replace the Chalk


下一篇:VS Code中小程序与Vue常用插件合集(前端合集)