Redis-Redis 高级数据结构 HyperLogLog与事务

本文介绍了Redis中的高级数据结构HyperLogLog,包括pfadd、pfcount、pfmerge等操作命令,并探讨了其原理和实例应用。此外,还涉及Redis 7.0的前瞻及复制缓存区的问题分析。
摘要由CSDN通过智能技术生成

Redis 高级数据结构 HyperLogLog

        HyperLogLog(Hyper [ˈhaɪpə(r)] ) 并不是一种新的数据结构 ( 实际类型为字符串类 型) ,而是一种基数算法 , 通过 HyperLogLog 可以利用极小的内存空间完成独立总数的统计,数据集可以是 IP Email ID 等。
        如果你负责开发维护一个大型的网站,有一天产品经理要网站每个网页每天 的 UV 数据,然后让你来开发这个统计模块,你会如何实现?
        如果统计 PV 那非常好办,给每个网页一个独立的 Redis 计数器就可以了, 这个计数器的 key 后缀加上当天的日期。这样来一个请求, incrby 一次,最终 就可以统计出所有的 PV 数据。
        但是 UV 不一样,它要去重,同一个用户一天之内的多次访问请求只能计 数一次。这就要求每一个网页请求都需要带上用户的 ID ,无论是登陆用户还是 未登陆用户都需要一个唯一 ID 来标识。
        一个简单的方案,那就是为每一个页面一个独立的 set 集合来存储所有当 天访问过此页面的用户 ID 。当一个请求过来时,我们使用 sadd 将用户 ID 塞 进去就可以了。通过 scard 可以取出这个集合的大小,这个数字就是这个页面 的 UV 数据。
        但是,如果你的页面访问量非常大,比如一个爆款页面几千万的 UV ,你需 要一个很大的 set 集合来统计,这就非常浪费空间。如果这样的页面很多,那 所需要的存储空间是惊人的。为这样一个去重功能就耗费这样多的存储空间,值 得么?其实需要的数据又不需要太精确,1050w 1060w 这两个数字对于老板 们来说并没有多大区别,So ,有没有更好的解决方案呢?
        这就是 HyperLogLog 的用武之地, Redis 提供了 HyperLogLog 数据结构就是 用来解决这种统计问题的。HyperLogLog 提供不精确的去重计数方案,虽然不精 确但是也不是非常不精确, Redis 官方给出标准误差是 0.81% ,这样的精确度已经 可以满足上面的 UV 统计需求了。

操作命令

HyperLogLog 提供了 3 个命令 : pfadd pfcount pfmerge
例如 08-15 的访问用户是 u1 u2 u3 u4 08-16 的访问用户是 u-4 u-5 、 u-6、 u-7

pfadd

pfadd key element [element …]
pfadd 用于向 HyperLogLog 添加元素 , 如果添加成功返回 1:
pfadd 08-15:u:id "u1" "u2" "u3" "u4"

pfcount

pfcount key [key …]
pfcount 用于计算一个或多个 HyperLogLog 的独立总数,例如 08-15:u:id 的独
立总数为 4:
pfcount 08-15:u:id
如果此时向插入 u1 u2 u3 u90 ,结果是 5:
pfadd 08-15:u:id "u1" "u2" "u3" "u90"
pfcount 08-15:u:id
如果我们继续往里面插入数据,比如插入 100 万条用户记录。内存增加非常少,但是 pfcount 的统计结果会出现误差。
        以使用集合类型和 HperLogLog 统计百万级用户访问次数的占用空间对比:
        数据类型 1 天         1 个月         1 年
        集合类型 80M        2.4G         28G
        HyperLogLog 15k         450k         5M
        可以看到,HyperLogLog 内存占用量小得惊人,但是用如此小空间来估算如
此巨大的数据,必然不是 100% 的正确,其中一定存在误差率。前面说过, Redis
官方给出的数字是 0.81% 的失误率。

pfmerge

pfmerge destkey sourcekey [sourcekey ... ]
pfmerge 可以求出多个 HyperLogLog 的并集并赋值给 destkey ,请自行测试。

原理概述

数学原理
        HyperLogLog 基于概率论中伯努利试验并结合了极大似然估算方法,并做了分桶优化。
        实际上目前还没有发现更好的在大数据场景中准确计算基数的高效算法,因 此在不追求绝对准确的情况下,使用概率算法算是一个不错的解决方案。概率算 法不直接存储数据集合本身,通过一定的概率统计方法预估值,这种方法可以大 大节省内存,同时保证误差控制在一定范围内。目前用于基数计数的概率算法包括:
         Linear Counting(LC):早期的基数估计算法,LC 在空间复杂度方面并不算优 秀;
        LogLog Counting(LLC):LogLog Counting 相比于 LC 更加节省内存,空间复杂度更低;
        HyperLogLog Counting(HLL):HyperLogLog Counting 是基于 LLC 的优化和改进, 在同样空间复杂度情况下,能够比 LLC 的基数估计误差更小。
        举个例子来理解 HyperLogLog 算法,有一天 Fox 老师和 Mark 老师玩抛硬币 的游戏,规则是 Mark 老师负责抛硬币,每次抛的硬币可能正面,可能反面,每 当抛到正面为一回合,Mark 老师可以自己决定进行几个回合。最后需要告诉 Fox 老师最长的那个回合抛了多少次以后出现了正面,再由 Fox 老师来猜 Mark 老师
一共进行了几个回合。
进行了 n 次,比如上图:
第一次 : 抛了 3 次才出现正面,此时 k=3 n=1
第二次试验 : 抛了 2 次才出现正面,此时 k=2 n=2
第三次试验 : 抛了 4 次才出现正面,此时 k=4 n=3
…………
n 次试验:抛了 7 次才出现正面,此时我们估算, k=7 n=n
k 是每回合抛到 1 (硬币的正面)所用的次数,我们已知的是最大的 k
  • 20
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

长情知热爱

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

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

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

打赏作者

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

抵扣说明:

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

余额充值