Redis中位图和HyperLogLog的应用

5 篇文章 0 订阅
5 篇文章 0 订阅

      在我们日常开发中,会遇到一些布尔类型数据存储的需求,说的直白一些,就是是与不是、做与没做的一些需求,像用户的签到并记录这些签到,和办公系统里面打卡是一样的,下面两张图就是我的支付宝与我的移动的签到应用。

 

 

当接到这样的需求时,第一时间我想到的就是使用Redis来应对这样的需求,用户一年的签到记录, 签了是 1,没签是 0,要记录 365 天。如果使用普通的 key/value,每个用户要记录 365 个,当用户上亿的时候,需要的存储空间是惊人的。而这时Redis的位图数据结构就派上用场了,这样每天的签到记录只占据一个位, 365 天就是 365 个位,一个字节是8位,也就是一个用户签到一年,差不多46 个字节就可以完全容纳下,这就大大节约了存储空间。

位图不是特殊的数据结构,它的内容其实就是普通的字符串,也就是 byte 数组。我们可以使用普通的 get/set 直接获取和设置整个位图的内容,也可以使用位图操作 getbit/setbit 等将 byte 数组看成「位数组」来处理。

操作:设置(setbit)和获取(getbit):

操作:统计(bitcount)和查找(bitpos):

以上就是Redis提供给我们位图的数据结构,当然还是其他操作,这里就不再赘述,下面来讲一下另外一个需求,那就是统计网站的UV数据,当接到这样一个需求时,相信大部分程序员都会漏出自信的微笑,我用一个Redis的计数器就可以实现了,其实不然,如果统计 PV 那非常好办,给每个网页一个独立的 Redis 计数器就可以了,这个计数器 的 key 后缀加上当天的日期。这样来一个请求,incrby 一次,最终就可以统计出所有的 PV 数据。但是 UV 不一样,它要去重,同一个用户一天之内的多次访问请求只能计数一次。这就 要求每一个网页请求都需要带上用户的 ID,无论是登陆用户还是未登陆用户都需要一个唯一 ID 来标识。可能你会想到另外一个简单的方案,那就是为每一个页面一个独立的 set 集合来存储所有当天访问过此页面的用户 ID。当一个请求过来时,我们使用 sadd 将用户 ID 塞进去就可 以了。通过 scard 可以取出这个集合的大小,这个数字就是这个页面的 UV 数据。不错,这也是一个实现方案,但这个方案也有缺点,那就是数据量比较大时,如果你的页面访问量非常大,比如一个爆款页面几千万的 UV,你需要一个很大 的 set 集合来统计,这就非常浪费空间。

铺垫了那么久,其实就是为了引出这个解决方案的主角,那就是HyperLogLog,Redis 提供了 HyperLogLog 数据结构就是用来解决 这种统计问题的。HyperLogLog 提供不精确的去重计数方案,虽然不精确但是也不是非常不精确,标准误差是不到1%,这样的精确度已经可以满足上面的 UV 统计需求了。

操作:增加(pfadd)和统计(pfcount):

大家看了会说,这部挺准确的,添加了3个,统计出来的就是3个,量大了就不行了,下面我们就用python脚步跑一个,验证一下,打开我们心爱的ipython:

误差是有一点的,但是可以满足相应的需求了,加入产品对统计精度要求特别的苛刻,那么我们就要损失存储空间和性能来实现它的需求了,兵来将挡,水来土掩,利用好Redis提供的强大功能,来开发应对不同的需求,不要只是会添加、获取和删除缓存这样简单的功能,要物尽其用!

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

猿人小郑

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

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

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

打赏作者

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

抵扣说明:

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

余额充值