mysql的分库分表简述
mysql的分库分表简述
切分策略
- 哈希\取余\取模
- 优点 均匀存放数据，缺点 扩容非常麻烦
- 常见的有哈希取余分片、一致性哈希分片、虚拟槽分片等
- 按照范围分片（区域、数据）
- 比较好扩容， 数据分布不够均匀
- 一般较少用，因为很容易发生数据倾斜，大量的流量都打在最新的数据上
- 按照时间分片
- 按照枚举值分片
- 按照目标字段前缀指定进行分区
- 映射表，使用单独的一个数据库来存储映射关系
分片方案
- 水平分片
- 从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案
- 垂直分片
- 在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案
- 若数据量极大，且持续增长，再考虑水平分库水平分表方案
- 在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案
问题场景
- 事务一致性问题
- 需要将关联查询拆分成多次查询，然后将获得的结果进行拼装
- 跨节点分页、排序函数
- 需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。这时非常容易出现内存崩溃的问题
- 主键避重问题
- 需要单独设计全局主键，以避免跨库主键重复问题，如雪花算法
- 公共表处理
- 实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。这一类表一般就需要在每个数据库中都保存一份，并且所有对公共表的操作都要分发到所有的分库去执行
- 运维工作量
分库分表建议
- MySQL单表记录如果达到500W这个级别，或者单表容量达到2GB，一般就建议进行分库分表
- 对于数据增长比较缓慢的数据，一般可以按照三年左右的业务量来预估使用人数，按照标准预设好分库分表的方案
- 对于数据增长快速且稳定的数据，一般则需要按照预估量的两倍左右预设分库分表方案
- 分库分表的后期扩容是非常麻烦的，所以在进行分库分表时，尽量根据情况，多分一些表
- 设计分库分表方案时，要尽量兼顾业务场景和数据分布。在支持业务场景的前提下，尽量保证数据能够分得更均匀
常用分库分表中间件
Sharding-JDBC
MyCAT
DBLE
