-
前言
其实分库分表是牵扯到高并发的,因为分库分表无非来说就是为了支撑高并发、数据量大的问题。尤其进入稍微大一点的公司或者互联网公司,这些都是必须掌握!
-
场景
假如一个新兴公司,刚开始时,注册用户就40W,每天活跃1W,每天单表数据量1000,高峰期每秒的并发就10,这种一般的单表单库操作就可以搞定。
但是,当用户不断增加、日活跃用户增加、单表数据量增加、高峰期每秒增加到一定数量时,单表单库性能就存在很大的问题了。
-
解决办法-->分表
前提:当单表数据量太大,会极大的影响sql的执行性能,这时sql会跑的很慢。根据实战经验来说,当单表到几百万的时候,性能就会有所下降
个人理解:白话来说就是把一个表的数据放到多个表中,查就查一个表,可以按照id来分表控制每个表的数据量,比如单表固定在200W以内。
-
解决办法-->分库
个人理解:单库而言,最大的并发可能就2000左右,但是一个健壮的单库来说最好的并发保持在1000左右。单数据库增大或者并发增加的时候,可以将一个库的数据拆分到多个库中。
-
分库分表图表理解
分库分表前 | 分库分表后 | |
并发情况 | Mysql单机,支撑不了高并发 | Mysql集群,并发加倍 |
磁盘情况 | 磁盘容量几乎撑满 | 拆分多个表,磁盘使用率降低 |
SQL性能 | 数据量加大,SQL越来越慢 | 单表数据量少,SQL效率提升明显 |
- 目前常用的分库分表中间件
sharding-jdbc:当当开源,属于client层,SQL语法支持比较多,支持分库分表、读写分离、分布式id生成、柔性事务(最大努力送达型事务、TCC事务),一直在维护,社区也比较活跃
mycat:基于proxy层方案,属于目前非常火且不断更新的数据库中间件,支持功能也非常完善
区别和选择:
sharding-jdbc这种client层优点是不用部署,运维成本低,不需要代理层的二次转发请求,性能很高,但是一旦升级,需要各个系统都重新升级版本在发布,各个系统都需要耦合sharding-jdbc的依赖。
mycat这种proxy层的方案缺点就是自己运维一套中间件,运维成本高,但是好处在于对于各个项目透明,如果升级都是在中间件那里搞定就可以了。
通常来说,小公司小项目建议使用sharding-jdbc,维护成本低,而大公司使用mycat这种proxy方案,大公司系统和项目多,有专人维护。
就是把一个表的数据分到多个库的多个表中,每个库的表结构一样,不过每个库存放的数据不同。水平拆分的意思就是将数据均匀放到更多表里,然后多个库来抗高并发,还有就是用多个库的存储容量来扩容
- 数据库水平拆分
- 数据库垂直拆分
就是把一个很多字段的表拆分给多个表,或者多个库上去。每个库表结构都不一样,每个库表都包含部分字段。一般来说,会将很少访问的字段放到一个表,数据库有缓存,访问频率高的字段越少,可以缓存更多的行,性能更好,这个一般在表层面操作。
- 如何来拆分
其实大家可能都遇到到,比如说把一个订单大表拆开,订单表、订单支付表、订单商品表。
一种是按照range来分,每个库一段连续的数据,比如按时间来,但比较少用,比如大量流量产生大量数据。
一种是按照某个字段hash均匀分散,这个较常用