分库分表
2022-06-11 21:34:31 0 举报AI智能生成
mysql分库分表
作者其他创作
大纲/内容
什么时候拆分
数据量较大，影响正常的业务访问
随着业务的发展，需要对某些字段垂直拆分
数据量快速增长
安全性和可用性
拆分方向
水平拆分
优点
不存在单库数据量过大、高并发的性能瓶颈。
提升系统的稳定性和负载能力
应用端改造小，不需要拆分业务模块
缺点
跨分片的事务一致性难以保证
跨库的join关联查询性能较差
数据多次扩展难度和维护量极大
拆分方向
按数值范围range来分
每个库一段连续的数据
容易产生热点问题
扩容迁移的时候方便
数值hash取模
扩容麻烦
垂直拆分
优点
避免一条记录占用空间过大导致跨页，造成额外的性能开销
数据库以行为单位将数据加载到内存中，表中字段的长度比较短且访问效率较高，内存能加载更多的数据，命中率更高了，减少了磁盘IO，从而提升数据库性能
解决业务系统层面的耦合，业务清晰
对不同的业务的数据进行分级管理、维护、监控和扩展
高并发场景下，垂直切分能一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点
部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
仍然存在单表数据量过大的问题（需要水平拆分）
拆分模式
代理模式
优点
扩展性强
无侵入
缺点
架构复杂
运维成本高
mycat
性能降低30%
不适合链表查询
不适合大数据导入导出
业务入侵小
代理本身需要做高可用
atlas
性能降低30%
响应时间比直连慢
实现了读写分离
支持动态DB上下线，方便扩展
sharing-sphere
客户端直连模式
优点
直连数据库，降低外围系统依赖所带来的宕机风险
集成成本低，无需额外运维的组件
缺点
扩展性一般
业务入侵高
将分片逻辑的压力放在应用服务器上，造成额外风险
分库分表切换方案
双写
同时写新库和老库
数据做同步
可能产生脏数据
切换追加
从库摘除
主库binlog记录
从库导入新库
数据校验
binlog追加
canal框架
开启写新库
常见问题及处理方案
基本路由问题
表路由
库路由
全局ID避免重复
UUID
不太建议
不同表使用不同步长
扩展分片表得时候会有问题
分布式ID
比较主流的方案
跨库join
字段冗余
将需要跨库join查询的字段冗余到本表
全局表
每个库里面都储存一份
业务层组装数据
多次查询然后组装行数据
es分片
将存在join关系的表尽量分片在同一个库中
0 条评论
下一页
