Redis实战系列(3) 使用hashtable和hash-max-zipmap-entries优化内存使用

在我的系统中大约有50000个用户,每个用户有nickname1、nickname2、nickname3、nickname4、profile_id。对于上面几个属性来说,每个用户都是唯一的,而用户信息大概有70个字段。我用user:info:$profile_id作为一个hashtable的key来存储一个用户的所有信息。而系统要求能用nickname1、nickname2、nickname3、nickname4来获取到用户信息。

最先考虑的是每个字段对应一个hashtable:user:nickname1:profile_id:map作为一个key,$email作为hashkey, $profile_id作为hashkey的值。对四个字段都做如是的处理,这样处理的内存占用量大概是15M,总共有4个hashtable,每个hashtable中有50000个元素,总共有200000个元素。

        下面先解释一下hash-max-zipmap-entries和hash-max-zipmap-value,然后再介绍第二种方案。

hash-max-zipmap-entries是只hashtable中元素的总个数不超过设定数量时,就用zipmap的方式来存储hashtable以节省内存

hash-max-zipmap-value是hashtable中的key以及value的长度小于设定的值时,就用zipmap的方式来存储hashtable以节省内存
一旦hashtable的元素个数超过了设定的值,或者任意一个元素的key或者value超过了hash-max-zipmap-value的值,则使用hashtable来存储。
这两个配置主要是减少了元数据。
    因为每个人的nickname1、nickname2、nickname3、nickname4都是全局唯一的,所以对每个人的nickname1、nickname2、nickname3、nickname4做md5,然后取前两位作为hashtable的可以,这样会有256个hashtable,然后hashtable中的key是nickname1、nickname2、nickname3、nickname4 值是profile_id,将200000个元素分布到256个槽中,每个槽平均有781.25个元素。把hash-max-zipmap-entries的数量设置为1000。而nickname1、nickname2、nickname3、nickname4和profile_id的长度是不会超过64个字节的,所以,经过这样处理之后,内存的使用量仅仅是4.7M左右。
     
    这样做的坏处是会多消耗一些cpu的时间,因为要遍历将近1000个元素的数量,不过这个代价是值得的。

发布了17 篇原创文章 · 获赞 1 · 访问量 5万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览