saas应用分库分表
2024-06-23 11:35:48 0 举报
AI智能生成
Saas应用分库分表是一种在Saas应用中广泛使用的技术,用于解决大规模数据处理和数据存储问题。通过将数据分散到多个数据库和数据表中,可以有效提高查询性能和数据处理的速度。同时,分库分表还可以提高系统的可用性和容错性,因为即使某个数据库或数据表出现故障,其他数据库或数据表仍然可以正常运行。分库分表技术通常与分布式数据库管理系统、云存储等技术结合使用,以满足现代企业对数据处理和数据存储的高要求。
作者其他创作
大纲/内容
mysql分库分表
一、数据库瓶颈
不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,
进而逼近甚至达到数据库可承载活跃连接数的阈值。
在业务Service来看就是,可用数据库连接少甚至无连接可用。
接下来就可以想象了吧(并发量、吞吐量、崩溃)
进而逼近甚至达到数据库可承载活跃连接数的阈值。
在业务Service来看就是,可用数据库连接少甚至无连接可用。
接下来就可以想象了吧(并发量、吞吐量、崩溃)
IO瓶颈
第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,
每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表
每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表
第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库
CPU瓶颈
第一种:SQL问题,如SQL中包含join,group by,order by,
非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,
在业务Service层进行业务计算
非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,
在业务Service层进行业务计算
第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,
CPU率先出现瓶颈 -> 水平分表
CPU率先出现瓶颈 -> 水平分表
二、分库分表
1、水平分库
概念
以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中
以医院组织为分库依据
结果
每个库的结构都一样
每个库的数据都不一样,没有交集
所有库的并集是全量数据
场景
系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库
分析
库多了,io和cpu的压力成倍缓解
2、水平分表
概念
以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中
以医院组织跟用户为分表依据
结果
每个表的结构都一样
每个表的数据都不一样,没有交集
所有表的并集是全量数据
场景
系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,
加重了CPU负担,以至于成为瓶颈。推荐:一次SQL查询优化原理分析
加重了CPU负担,以至于成为瓶颈。推荐:一次SQL查询优化原理分析
分析
表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担
3、垂直分库
概念
以表为依据,按照业务归属不同,将不同的表拆分到不同的库中
按照各个微服务实现数据跟业务隔离,但是不垂直分库
结果
每个库的结构都不一样
每个库的数据也不一样,没有交集
所有库的并集是全量数据
场景
系统绝对并发量上来了,可以抽象出单独的业务模块
分析
到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,
这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,
这时可以将相关的表拆到单独的库中,甚至可以服务化
这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,
这时可以将相关的表拆到单独的库中,甚至可以服务化
4、垂直分表
概念
以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中
结果
每个表的结构都不一样
每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据
所有表的并集是全量数据
场景
系统绝对并发量并没有上来,表的记录并不多,
但是字段多,并且热点数据和非热点数据在一起,
单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,
查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈
但是字段多,并且热点数据和非热点数据在一起,
单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,
查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈
分析
可以用列表页和详情页来帮助理解。
垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,
非热点数据放在一起作为扩展表。
这样更多的热点数据就能被缓存下来,进而减少了随机读IO。
拆了之后,要想获得全部数据就需要关联两个表来取数据。
但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。
关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据
垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,
非热点数据放在一起作为扩展表。
这样更多的热点数据就能被缓存下来,进而减少了随机读IO。
拆了之后,要想获得全部数据就需要关联两个表来取数据。
但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。
关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据
三、分库分表工具
ShardingJDBC
sharding-sphere:jar,前身是sharding-jdbc
TDDL:jar,Taobao Distribute Data Layer
Mycat:中间件
四、分库分表方案设计
分库分表的策略
垂直拆分
按照各个微服务实现数据跟业务隔离,但是不垂直分库
水平拆分
以组织跟用户为分表依据
分库分表的规则
按数据量拆分
按业务类型拆分
按数据访问频率拆分
分库分表的实现
分库分表的工具
分库分表的框架
ShardingJDBC+mycat
五、分库分表带来的问题
跨库关联查询
患者端涉及,通过用户病历关联索引表里的库跟表去获取详细信息
分布式事务
不涉及
排序分页,函数计算问题
不涉及
全局主键避重问题
uuid不涉及
六、分库分表的流程
数据统计以及分组策略
统计数据量前十的医院水平分到10个库(租户)上/最不活跃的10家医院划分到同一个库(租户)上
应用程序调整
修改数据存储模型,医生端跟用户端的数据访问模型
数据存入,详细数据按照医院对应存入对应数据库跟表;然后更新公共库的用户病历索引表
医生端按照所属医院库,表去读取数据信息
患者端在用户病历关联表获取数据索引,详细信息根据关联表的库表信息去相应数据库获取详细数据
历史数据迁移
迁移医院数据
试运行
试运行是不是双机并行更新
结果处理
成功历史数据处理
备份数据库并清理原库下的用户数据
失败,查找原因更新方案,重新走分库流程
0 条评论
下一页