分库分表的一些思考

分库分表的一些思考,第1张

分库分表的一些思考

链接: 数据库分库分表Java实战经验总结.

为什么要分库分表?

在高并发场景下,大量请求都需要 *** 作数据库,导致连接数不够了,请求处于阻塞状态。

如果数据库中存在一张上亿数据量的表,一条 SQL 没有命中索引会全表扫描,这个查询耗时会非常久。

业务量剧增,单库数据量越来越大,给存储造成巨大压力

IO瓶颈
第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询会产生大量的IO,降低查询速度 -> 分库和垂直分表
第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库

CPU瓶颈
第一种:SQl问题:如SQL中包含join,group by, order by,非索引字段条件查询等,增加CPU运算的 *** 作->SQL优化,建立合适的索引,在业务Service层进行业务计算。
第二种:单表数据量太大,查询时扫描的行太多,SQl效率低,增加CPU运算的 *** 作。
-> 水平分表。

当系统并发量上来了,不分库 只分表是难以根本上解决问题。

那什么时候考虑分库分表

能不分就不分,并不是所有表都需要切分,主要还是看数据的增长速度,分库分表是业务发展到一定阶段,数据积累到一定量级而衍生出来的解决方案。

分库分表会提升系统的复杂度,不到万不得已不要轻易使用分库分表这个“大招”,避免“过度设计”和“过早优化”。就像我们搭建项目,从快速实现的角度来说,肯定是从单体项目起步的,在业务丰富完善之前,也用不到微服务架构。

分库分表对于DBA来说意味着工作量的成倍增加,原来只需要管理一个DB,现在却要管理N个DB,而且每个DB都需要备份,监控,甚至做高可用,扩展等工作。

分库分表之前,先尽力做力所能及的优化:升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后,在考虑分库分表。

阿里巴巴《Java 开发手册》数据库设计规范中提出单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。

数据库相关优化方案

数据库优化方案很多,主要分为两大类:软件层面、硬件层面。
软件层面包括:SQL 调优、表结构优化、读写分离、数据库集群、分库分表等。
硬件层面主要是增加机器性能。

分库分表工具

sharding-jdbc(当当)
TSharding(蘑菇街)
Atlas(奇虎360)
Cobar(阿里巴巴)
MyCAT(基于Cobar)
Oceanus(58同城)
Vitess(谷歌)

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5716556.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-18
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存