Redis之HyperLogLog详解与优缺点

简介:

  • HyperLogLog是一种算法,并非redis独有
  • 目的是做基数统计,故不是集合,不会保存元数据,只记录数量而不是数值。
  • 耗空间极小,支持输入非常体积的数据量
  • 核心是基数估算算法,主要表现为计算时内存的使用和数据合并的处理。最终数值存在一定误差
  • redis中每个hyperloglog key占用了12K的内存用于标记基数(官方文档)
  • pfadd命令并不会一次性分配12k内存,而是随着基数的增加而逐渐增加内存分配;而pfmerge操作则会将sourcekey合并后存储在12k大小的key中,这由hyperloglog合并操作的原理(两个hyperloglog合并时需要单独比较每个桶的值)可以很容易理解。
  • 误差说明:基数估计的结果是一个带有 0.81% 标准错误(standard error)的近似值。是可接受的范围
  • Redis 对 HyperLogLog 的存储进行了优化,在计数比较小时,它的存储空间采用稀疏矩阵存储,空间占用很小,仅仅在计数慢慢变大,稀疏矩阵占用空间渐渐超过了阈值时才会一次性转变成稠密矩阵,才会占用 12k 的空间

基数计数的演进

使用一般集合或数据结构来处理如HashSet或B+树

数据量一大就崩了

bitmap

  • 用位数组来表示各元素是否出现,每个元素对应一位,所需的总内存为n bit。能大大减少内存占用且位操作迅速。

  • 如果要统计1亿个数据的基数值,大约需要内存100000000/8/1024/1024 ≈ 12M,内存减少占用的效果显著。然而统计一个对象的基数值需要12M,如果统计10000个对象,就需要将近120G,同样不能广泛用于大数据场景。

概率算法

  • 目前还没有发现更好的在大数据场景中准确计算基数的高效算法,因此在不追求绝对准确的情况下,使用概率算法算是一个不错的解决方案。概率算法不直接存储数据集合本身,通过一定的概率统计方法预估基数值,这种方法可以大大节省内存,同时保证误差控制在一定范围内。
  • 目前用于基数计数的概率算法包括:
    • Linear Counting(LC):早期的基数估计算法,LC在空间复杂度方面并不算优秀,实际上LC的空间复杂度与上文中简单bitmap方法是一样的(但是有个常数项级别的降低),都是O(Nmax);
    • LogLog Counting(LLC):LogLog Counting相比于LC更加节省内存,空间复杂度只有O(log2(log2(N​max)));
    • HyperLogLog Counting(HLL):HyperLogLog Counting是基于LLC的优化和改进,在同样空间复杂度情况下,能够比LLC的基数估计误差更小。

redis中HLL的使用

这里给出官方文档(中文翻译版)连接,里面关于时间复杂度、返回值、命令方式、使用案例等等都有详细说明

本文对每个命令都简介总结并个人案例展示

pfadd 添加

影响基数估值则返回1否则返回0.若key不存在则创建
时间复杂度O(1)

127.0.0.1:6379> pfadd m1 1 2 3 4 1 2 3 2 2 2 2
(integer) 1

pfcount 获得基数值

  • 得到基数值,白话就叫做去重值(1,1,2,2,3)的插入pfcount得到的是3
  • 可一次统计多个key
  • 时间复杂度为O(N),N为key的个数
  • 返回值是一个带有 0.81% 标准错误(standard error)的近似值(取决于你需不需要单个的记录, 如需要, 请放弃这个).
127.0.0.1:6379> pfadd m1 1 2 3 4 1 2 3 2 2 2 2
(integer) 1
127.0.0.1:6379> pfcount m1
(integer) 4

pfmerge 合并多个key

  • 取多个key的并集
  • 命令只会返回 OK.
  • 时间复杂度为O(N)
127.0.0.1:6379> pfadd m1 1 2 3 4 1 2 3 2 2 2 2
(integer) 1
127.0.0.1:6379> pfcount m1
(integer) 4
127.0.0.1:6379> pfadd m2 3 3 3 4 4 4 5 5 5 6 6 6 1
(integer) 1
127.0.0.1:6379> pfcount m2
(integer) 5
127.0.0.1:6379> pfmerge mergeDes m1 m2
OK
127.0.0.1:6379> pfcount mergeDes
(integer) 6

应用场景

说明:

  • 基数不大,数据量不大就用不上,会有点大材小用浪费空间, 还有错误概率
  • 有局限性,就是只能统计基数数量,而没办法去知道具体的内容是什么
  • 和bitmap相比,属于两种特定统计情况,简单来说,HyperLogLog 去重比 bitmap 方便很多
  • 一般可以bitmap和hyperloglog配合使用,bitmap标识哪些用户活跃,hyperloglog计数

一般使用:

  • 统计注册 IP 数
  • 统计每日访问 IP 数
  • 统计页面实时 UV 数
  • 统计在线用户数
  • 统计用户每天搜索不同词条的个数

这难道不就是布隆过滤器吗?

参考链接:

  • https://blog.csdn.net/maoyuanming0806/article/details/81814610
  • http://www.rainybowe.com/blog/2017/07/13/%E7%A5%9E%E5%A5%87%E7%9A%84HyperLogLog%E7%AE%97%E6%B3%95/index.html?utm_source=tuicool&utm_medium=referral
原创文章 280 获赞 464 访问量 10万+

猜你喜欢

转载自blog.csdn.net/qq_33709508/article/details/105804547
今日推荐