分库分表方案

分库分表设计思路

首先分库分表有两种方式,一种是垂直拆分,一种是水平拆分。
垂直拆分
垂直拆分比较简单,也就是本来一个数据库,数据量大之后,从业务角度进行拆分多个库,就是一微服务下边一个库
水平拆分
当然如果用到了水平拆分前提一定是做了垂直拆分,然后如果某个业务表比如说订单表4000W数据了,那就把这订单表4000W数据拆分成四张表或者更多表,比如说1000W数据就拆分为一张表,这就是水平拆分。
分库分表所带来的问题
传统的分库分表方案,假设现在已经是把订单表拆分成4张表了,接下来新的数据假设是id为2W的时候落入哪一张表?超过4千万要做数据扩容了,扩容的方案是什么?怎么知道要分四张表?
业内两种解决方案

hash取模和范围方案

1、hash取模
在这里插入图片描述

hash的方案就是对指定的路由key(如:id)对分表总数进行取模。
在上图中,id=12的订单,对4进行取模,也就是会得到0,那此订单会放到0表中;
id=13的订单,取模得到为1,就会放到1表中。
为什么对4取模,是因为分表总数是4。
优点:
没有热点,订单的数据可以均匀的放入到4张表当中,均衡不会有热点问题
缺点:
难扩容难迁移,订单量很大超出了4000万的量,那就需要增加分表数,取模基数就会被改变,然后以前存的数据有可能因为取模基数变化而查询不到了,然后把之前的4000万数据,重新做一个hash方案,放到新的规划分表中。也就是要做数据迁移。这个是一件很痛苦的事情。
2、范围查找
在这里插入图片描述

意思就是把一定范围内的订单,存放到一个表中;
比如说0到1千万的数据放到0号表,1千万到2千万放到1号表。设计这个方案时就是前期把表的范围设计好。
通过id进行路由存放。
优点:
容易扩容,未来不需要做什么数据迁移
缺点:
就是很可能有热点,因为id的值会一直递增变大,那这段时间的订单是不是会一直在某一张表中,
如id=2000万 ~ id=3000万之间,这段时间产生的订单是不是都会集中到此张表中,这个就导致某表过热,压力过大,而其他的表没有什么压力,空闲着。。。

最终方案采用hash取模和rang范围两者相结合

0、思路
考虑一下数据的扩容代表着路由key(如id)的值变大了,这个是一定的,那我们先保证数据变大的时候,首先用range方案让数据落地到一个范围里面。这样以后id再变大,那以前的数据是不需要迁移的。
但又要考虑到数据均匀,那是不是可以在一定的范围内数据均匀的呢?
因为我们每次的扩容肯定会事先设计好这次扩容的范围大小,会做好约定,我们只要保证这次的范围内的数据均匀是不是就ok?
1、设计+方案
在这里插入图片描述
在这里插入图片描述

根据上两图id=15000在【0,1000万】范围内的,根据上面的流程设计,1000万以内的id都均匀的分配到DB_0,DB_1,DB_2三个数据库中的Table_0表中。
也就是组库表,意思就是先分组,再分库,再分表,比如说1到4000W都在分组1里边存着,分组1里边可以分为多个库,而每个库,比如说第一个库的表1就是1到1000w,第二个表就是1000W到2000W,第三个表存的是2000w到3000w,第四个表存是3000w到4000W,因为有可能库1的服务器配置性能配置比较好,所以可以这么存,而库2和其他几个库都可能服务器性能配置不太高,所以库2的表1就可以是存0到1000w,表2存1000w到2500w,表3存2500w到4000w这种,性能好的服务器配置就可以设计多一张表来存,这样大范围的定下来,然后在组库表里边进行取模定位数据。
2、定位数据如何进行定位?
定位查询id为15000的数据,首先根据范围定位是哪个分组,比如查询id为15000的数据是在分组1里边的,然后利用hash取模取表数最终结果来定位到哪个库,假设结果是到0号库,然后再根据0号库的范围来定位是最终的表。
3、为什么要根据hash取模取表数来定位哪个库呢?
因为要兼顾服务器的性能高低不同,安排服务器时,有些公司有些服务器的性能高,存储高,就可以安排多存放些数据,多劳多得;有些服务器的性能低,就少放点数据。
这样就解决了热点问题以及可以按照服务器指标,设计数据量的分配
因为如果利用取模是按照DB总数3,进行取模,那就代表着【0,4000万】的数据是平均分配到3个DB中的,那就不能够实现按照服务器能力适当分配了。
4、扩容方案:
在这里插入图片描述

如上图所示新增的一个group02组,完全是新增的group组,谈不上什么数据迁移,
而且这个group组照样就防止了热点,也就是【4000万,5500万】的数据,都均匀分配到三个DB的table_0表中,
【5500万~7000万】数据均匀分配到table_1表中。
设计新的分组,然后也是根据服务器性能配置,如果是配置一样,就分表均匀一些,如果配置不一样,就让服务器性能高的承担更多一些
5、如果定位不是以id进行,比如 where条件并不是id,而是其他字段,这个怎么定位呢?
分库分表如果不按id查询的话,以上设定的方案都是根据id来查询的,当然这个业务可能不一样,总的一套系统肯定要按照id查询,先确定哪一张表,那么那一张表是做一个映射的,尤其是做分布式的,那么id是最准确的,如果你确定要查询其他字段,那么就要做一些kv映射,只能是这样。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

思静语

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值