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