使用hashmap优化压缩Redis内存使用

原创
2017/05/11 17:50
阅读数 4.8K

使用hashmap优化压缩Redis内存使用


背景

近来公司内部dsp架构升级,需要能够根据请求中的设备id实时的获取到该设备的用户画像相关信息,于是选用每天使用离线任务把用户数据灌入redis里面,供线上服务实时查询。

需求评估

需求是筛选出最近一个月活跃的设备,将其用户画像属性灌入redis中。于是筛选出30天的活跃设备总量有24亿。这么大的量如果直接使用设备id作为key直接写入redis,按value占用16字节来算,大概要用230G内存的redis集群,这成本还是比较可观的。

内存使用评估方法

为了评估我们设计的方法具体将占用多大的内存,上网查了写资料,发现跟redis内存容量使用和优化相关的只有这一篇文章《REDIS内存容量的预估和优化》,其他都是相互转载的,虽然不知道作者是谁,但是向作者致敬。

方案设计

大家知道Hash表空间大小和Key的个数决定了冲突率(或者用负载因子衡量),再合理的范围内,key越多自然hash表空间越大,消耗的内存自然也会很大。再加上大量指针本身是长整型,所以内存存储的膨胀十分可观。所以主要优化思路是考虑如何把key的个数减少。

在网上搜了下相关的博客,发现了这篇文章《Redis百亿级Key存储方案》,同样也是相互转载的特别多,已不知出处,里面bucket的思路启发了我,这里深深感谢作者。

原文的意思是设计一个映射函数,将设备id经过变换,映射到一个桶id上,桶的数量比原始数据的数量小2-3个数量级,而映射函数的作用是能够尽可能平均的将key映射到桶id上,使用桶id作为redis中的key,value使用hashmap结构,原始数据中的key和value作为hashmap中的subkey和value。这样能够大幅减少redis中全局key的数量。所以这里这个映射函数是一个比较核心的东西,要设计一个好的映射函数是很困难的。这里我经过多次尝试,方案如下:

选用CRC32算法对设备id做映射,再将结果对$2^{26}$取模作为桶id。这样能够将桶的数量控制在$2^{26}$ 这个数量上,同时使桶内的subkey分布尽可能均匀,减少数据倾斜的情况出现。同时使用BKDRHash算法对作为subkey的device id进行变换和压缩,从36字节变为4字节。

但是我们使用引用的第一篇文章中的公式来算一下: 首先我们有24亿条数据,这里桶的个数定为$2^{26}$个,平均每个桶里有35个子key。为了存储这$2^{26}$个key,我们需要key的长度为4个字节。 key字节数为4 + 9 ~ 16字节 subkey字节数为4字节 value字节数为16字节 则单个hashmap的大小为

35 × (4 + 16 + 3) + 2 = 807 字节 ~ 1024

总内存大小为

2 ^ 26 × (16 + 16 + 16 + 1024) + 2 ^ 26 × 4 = 67 G

可以看到总内存只使用了67G

总结

1.经过了上面的优化,从230G的内存占用到67G,内存使用减少了3.5倍,满满的成就感啊。 2.利用redis的hashmap可以极大的减少key的数量,和减少内存使用。

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部