Redis：HyperLogLog使用与应用场景

最新推荐文章于 2024-03-01 09:30:00 发布

小明同学YYDS

最新推荐文章于 2024-03-01 09:30:00 发布

阅读量1.9w

点赞数 7

分类专栏： Redis 文章标签： redis HyperLogLog pfcount 大数据统计基数统计

本文链接：https://blog.csdn.net/maoyuanming0806/article/details/81814610

版权

Redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

本文介绍redis的HyperLogLogde 命令使用和其他统计方式以及应用场景。
本文最后记录了HyperLogLog算法相关参考链接

简介
基数计数的演进
使用一般集合或数据结构来处理如HashSet或B+树
bitmap
概率算法
算法白话说明

redis中HLL的使用
pfadd 添加
pfcount 获得基数值
pfmerge 合并多个key

应用场景
参考链接

简介

Redis 在 2.8.9 版本添加了 HyperLogLog 结构。
Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。
但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 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(Nmax)))；
- HyperLogLog Counting(HLL)：HyperLogLog Counting是基于LLC的优化和改进，在同样空间复杂度情况下，能够比LLC的基数估计误差更小。

三者的演进参考文章：神奇的HyperLogLog算法

算法白话说明

通俗点说明：假设我们为一个数据集合生成一个8位的哈希串，那么我们得到00000111的概率是很低的，也就是说，我们生成大量连续的0的概率是很低的。生成连续5个0的概率是1/32，那么我们得到这个串时，可以估算，这个数据集的基数是32。

再深入的那就是数学公式，可参考本文最后的参考链接前往研究

额，更多原理和实现这里就不复制粘贴了，个人也没有很完整的理解，实现也没有测试，故本文下方会记录相关参考文章

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 数
统计在线用户数
统计用户每天搜索不同词条的个数

参考链接

小明同学YYDS

关注

7
点赞
踩
39

收藏

觉得还不错? 一键收藏
10
评论
Redis：HyperLogLog使用与应用场景

本文介绍redis的HyperLogLogde 命令使用和其他统计方式以及应用场景。本文最后记录了HyperLogLog算法相关参考链接简介基数计数的演进使用一般集合或数据结构来处理如HashSet或B+树bitmap概率算法算法白话说明redis中HLL的使用pfadd 添加pfcount 获得基数值pfmerge 合并多个key...
复制链接

扫一扫