HyperLogLog实现uv统计

目录

特点

操作

pfadd添加

pfcount计算

pfmerge合并

应用场景

统计uv案例

统计日活、月活案例

小结

---

特点

1、HyperLogLog是一种算法，并非redis独有。

2、在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

3、HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

4、核心是基数估算算法，最终数值存在一定误差。基数估计的结果是一个带有 0.81% 标准错误（standard error）的近似值。

5、存储时并不会直接占用12k空间，它的存储空间采用稀疏矩阵存储，空间占用很小，仅仅在计数慢慢变大，稀疏矩阵占用空间渐渐超过了阈值时才会一次性转变成稠密矩阵，才会占用 12k 的空间。

在不追求绝对准确的情况下，使用概率算法算是一个不错的解决方案。概率算法不直接存储数据集合本身，通过一定的概率统计方法预估基数值，这种方法可以大大节省内存，同时保证误差控制在一定范围内。

操作

Redis 为 HyperLogLog提供了三个命令：

pfadd添加

pfadd key element [element ...]

 pfadd一个已存在的元素时，元素估计数量不发生变化。比如我上边添加过xiaoming，再添加小明时，class:4的key内部存储不发生变化。

pfcount计算

pfcount key [key ...]

当它作用于多个key时，返回所有给定 HyperLogLog 的并集的近似基数，这个近似基数是通过将所有给定 HyperLogLog 合并至一个临时 HyperLogLog 来计算得出的。

pfmerge合并

pfmerge destkey sourcekey [sourcekey ...]

合并后的 HyperLogLog 的基数接近于所有输入 HyperLogLog 的可见集合（observed set）的并集。

然后计算可得

应用场景

统计uv案例

把每天访问的ip放入HyperLogLog结构中

如果统计某天uv，直接使用pfcount 日期即可

如果统计某几天uv，先合并，在计算即可

统计日活、月活案例

略

小结

了解熟悉HyperLogLog，对它有一个基本认知