数据库 常用分片算法分析

分片算法

【范围法】

以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实例上去:

在这里插入图片描述

db1:存储0到1千万的uid数据

db2:存储1到2千万的uid数据

范围法的优点是:

切分策略简单,根据id,按照范围,业务很快能够定位到数据在哪个库上

扩容简单,如果容量不够,只要增加db3即可

范围法的不足是:

id必须要满足递增的特性

数据量不均,新增的db3,在初期的数据会比较少

请求量不均,一般来说,新注册的用户活跃度会比较高,故db2往往会比db1负载要高,导致服务器利用率不平衡

【哈希法】

也是以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实例上去:
在这里插入图片描述

db1:存储id取模得1的id数据

db0:存储id取模得0的id数据

哈希法的优点是:

切分策略简单,根据uid,按照hash,业务很快能够定位到数据在哪个库上

数据量均衡,只要uid是均匀的,数据在各个库上的分布一定是均衡的

请求量均衡,只要uid是均匀的,负载在各个库上的分布一定是均衡的

哈希法的不足是:

扩容麻烦,如果容量不够,要增加一个库,重新hash可能会导致数据迁移,如何平滑的进行数据迁移,是一个需要解决的问题

【索引表法】

思路:id能直接定位到库,数据不能直接定位到库,如果通过id能查询到db,问题解决

解决方案:

建立一个索引表记录id ->db的映射关系

用id来访问时,先通过索引表查询到id,再定位相应的库

索引表属性较少,可以容纳非常多数据,一般不需要分库

如果数据量过大,可以通过id来分库

优点:节点扩容无影响

潜在不足:多一次数据库查询,性能下降一倍

【缓存映射法】

思路:访问索引表性能较低,把映射关系放在缓存里性能更佳

解决方案:

查询先到cache中查询id,再根据id定位数据库

假设cache miss,采用扫全库法获取对应的id,放入cache

id到db的映射关系不会变化,映射关系一旦放入缓存,不会更改,无需淘汰,缓存命中率超高

如果数据量过大,可以通过id进行cache水平切分

潜在不足:多一次cache查询

【基因法】

【 业务标识 基因融入 id 】

思路:可以从业务标识抽取“基因”,融入id中

假设分8库,采用id%8路由,潜台词是,id的最后3个bit决定这条数据落在哪个库上,这3个bit就是所谓的“基因”。

在这里插入图片描述

解决方案:

在插入数据时,设计函数业务标识生成3bit基因,sign_gene=f(k),如上图粉色部分

同时,生成61bit的全局唯一id,作为用户的标识,如上图绿色部分

接着把3bit的lsign_gene也作为uid的一部分,如上图屎黄色部分

生成64bit的uid,由id和sign_gene拼装而成,并按照uid分库插入数据

用k来访问时,先通过函数由k再次复原3bit基因,sign_gene=f(k),通过sign_gene%8直接定位到库

【动态扩容解决方案 之 hash环迁移法】

一致性哈希算法将整个哈希值空间映射成一个虚拟的圆环,整个哈希空间的取值范围为0— 2 32 2^{32} 232-1。整个空间按顺时针方向组织。0— 2 32 2^{32} 232-1在零点中方向重合。接下来使用Hash算法对服务请求进行映射,将服务请求使用哈希算法算出对应的hash值,然后根据hash值的位置沿圆环顺时针查找,第一台遇到的服务器就是所对应的处理请求服务器。当增加一台新的服务器,受影响的数据仅仅是新添加的服务器到其环空间中前一台的服务器(也就是顺着逆时针方向遇到的第一台服务器)之间的数据,其他都不会受到影响。综上所述,一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性;
在这里插入图片描述

  • 2
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值