Redis系列10:HyperLogLog实现海量数据基数统计

redis,系列,hyperloglog,实现,海量,数据,基数,统计 · 浏览次数 : 719

小编点评

**Redis系列1:深刻理解高性能Redis的本质** **1. 基本数据结构** * **Redis_STRING**:用于存储字符串类型数据。 * **Redis_INT**:用于存储整数类型数据。 * **Redis_RAW**:用于存储原始数据类型。 * **Redis_LINKEDLIST**:用于存储有序列表数据。 * **Redis_ZIPLIST**:用于存储压缩列表数据。 * **Redis_HASH**:用于存储哈希表数据。 * **Redis_INTSET**:用于存储整数集合数据。 **2. HyperLogLog** HyperLogLog 是 Redis 中用于统计数据的专用数据结构。它是一种基于基数的算法,可以极大地降低存储空间和计算成本。 **3. 高效和海量特性** * HyperLogLog 的数据结构非常简洁,每个键只存储一个唯一的元素。 * 在添加元素时,使用 PFADD 命令可以合并多个元素。 * 在统计时,可以使用 PFCOUNT 命令快速获取基数。 **4. PFADD 命令** PFADD 命令用于添加多个元素到 HyperLogLog 中。 **5. PFCOUNT 命令** PFCOUNT 命令用于返回给定 HyperLogLog 的基数的值。 **6. PFMERGE 命令** PFMERGE 命令用于将多个 HyperLogLog 合并为一个新的 HyperLogLog。 **7. 使用案例** * 统计单日一个页面的访问量 (PV)。 * 统计单日一个页面的用户访问量 (UV)。 * 合并多个key的页面访问量。

正文

Redis系列1:深刻理解高性能Redis的本质
Redis系列2:数据持久化提高可用性
Redis系列3:高可用之主从架构
Redis系列4:高可用之Sentinel(哨兵模式)
Redis系列5:深入分析Cluster 集群模式
追求性能极致:Redis6.0的多线程模型
追求性能极致:客户端缓存带来的革命
Redis系列8:Bitmap实现亿万级数据计算
Redis系列9:Geo 类型赋能亿级地图位置计算

1 前言

我们来回顾下在这个系列的第一篇 深刻理解高性能Redis的本质 中介绍过Redis的几种基本数据结构,
它服务于各种不同的业务场景而设计的,比如:

  • 动态字符串(REDIS_STRING):整数(REDIS_ENCODING_INT)、字符串(REDIS_ENCODING_RAW)
  • 双端列表(REDIS_ENCODING_LINKEDLIST)
  • 压缩列表(REDIS_ENCODING_ZIPLIST)
  • 跳跃表(REDIS_ENCODING_SKIPLIST)
  • 哈希表(REDIS_HASH)
  • 整数集合(REDIS_ENCODING_INTSET)

除了这些常见数据类型,还有一些不常用的数据类型,如 BitMap、Geo、HyperLogLog 等等,他们在各自的方向为不同的类型的数据统计给出解决方案。

  • 位图(BitMap)计算:可以应用于任何大数据场景下的二值计算,比如 是否登录、是否在线、是否签到、用户性别状态、IP黑名单、是否VIP用户统计 等等场景。
  • Geo类型:记录地理空间信息,如 地理坐标存储、位置计算、距离计算等能力,普遍运用在地图业务中的各种场景。

这一篇我们来介绍下HyperLogLog,HyperLogLog 主要用于Redis基数的统计,比如IP统计,用户访问量,页面访问量。

2 关于HyperLogLog

HyperLogLog 主要用于Redis 的基数统计,它的数据结构专门设计用来做数据合并和计算,并能节省大量的空间。
基数计数( cardinality counting) 通常用来统计一个集合中不重复的元素个数 , 例如统计某个网站的UV、PV或者网站搜索的的关键词数量。
在各种应用领域基数统计被广泛应用,如数据分析、网络监控指标、存储性能优化等。
简单来说,基数计数就是记录集合中所有不重复的元素Su ,当新增元素Xa时,判断Su中是否包含,不包含则将其加入Su,包含则不加入,计数值就是Su 的元素数量总和。
当然这种做法也存在两个问题:

  1. 当统计的数据量变大时,相应的存储内存也会线性增长
  2. 当集合Su 变大,判断其是否包含新加入元素的成本变大

2.1 实际应用场景

很多计数类场景,比如 每日注册 IP 数、每日访问 IP 数、页面实时访问数 PV、访问用户数 UV等。
因为主要的目标高效、巨量地进行计数,所以对存储的数据的内容并不关系。也就是说它只能用于统计数量,没办法知道具体的统计对象的内容。

  • 统计单日一个页面的访问量(PV),单次访问就算一次。
  • 统计单日一个页面的用户访问量(UV),即按照用户为维度计算,单个用户一天内多次访问也只算一次。
  • 多个key的合并统计,某个门户网站的所有模块的PV聚合统计就是整个网站的总PV。

2.2 高效和海量特性

如果我们使用普通集合,也能够实现对巨量数据的存储和统计么,但是存储量会大很多,性能也比较差。
以百度搜索为例,如果要做百度指数的计算,针对来访IP进行统计。那么如果每天 有 1000 万 IP,一个 IP 占位 15 字节,那么 1000 万个 IP 就是 143M。

10,000,000 * 15 /(1024 * 1024)  = 143.05 M

如果使用 HyperLogLog ,那么在 Redis 中每个键占用的内容都是 12K,理论上能够存储 264 个值,即18446744073709551616,这个数是巨量,Java中long类型也只能计算到 262
无论存储何值,它一个基于基数估算的算法HyperLogLog Counting(简称HLLC),使用少量固定的内存去存储并识别集合中的唯一元素。
HLLC采用了分桶平均的思想来消减误差,在Redis中, 有16384个桶 。而HyperLogLog的标准偏差公式是1.04 / sqrt(m),m 为桶的个数。所以

1.04 / sqrt(16384) = 1.04 / 128 = 0.008125 

所以这个计数的估算,是一个带有 0.81% 标准偏差的近似值。

HyperLogLog 算法原理参考这两篇,写的很清晰:
https://zhuanlan.zhihu.com/p/77289303
http://www.javashuo.com/article/p-mmwxrmjm-ga.html

3 HyperLogLog所支持的能力

HyperLogLog数据结构的命令有三个:PFADD、PFCOUNT、PFMERGE

3.1 PFADD 添加计数

Redis Pfadd 命令将所有元素添加到 HyperLogLog 数据结构中。

语法如下:

redis > PFADD key element [element ...]

下面举例了网站统计模块添加IP的两种情况

/* 对访问百度网站(key=baidu:ip_address)的IP进行添加 */
redis> PFADD baidu:ip_address "192.168.0.1" "192.168.0.2" "192.168.0.3"
(integer) 1
 
/* 如果IP已经存在,则进行忽略,不对估计数量进行更新 */
redis> PFADD baidu:ip_address "192.168.0.3"  
(integer) 0  # IP已经存在

3.2 PFCOUNT 统计数量

Redis Pfcount 命令返回给定 HyperLogLog 的基数的估算值。
语法如下:

redis > PFCOUNT key [key ...]

下面估算了访问IP的基数的值,返回 1034546 。

redis> PFCOUNT baidu:ip_address
 
(integer) 1034546

3.3 PFMERGE 合并统计

Redis PFMERGE 命令将多个 HyperLogLog 合并为一个 HyperLogLog ,合并后的 HyperLogLog 的基数估算值是对给定 HyperLogLog 进行并集计算得出的。
所以有重复的会被统计成一条数据。
合并得出的 HyperLogLog 会被储存在 destkey 键里面, 如果该键并不存在,那么命令在执行之前, 会先为该键创建一个空的 HyperLogLog 。
语法如下:

redis > PFMERGE destkey sourcekey [sourcekey ...]

下面演示了合并和统计的过程:

/* 统计百度 baidu:ip_address 访问IP */
redis> PFADD baidu:ip_address "192.168.0.1" "192.168.0.2" "192.168.0.3"
(integer) 1
 
 /* 统计淘宝 taobao:ip_address 访问IP */
redis> PFADD taobao:ip_address "192.168.0.3" "192.168.0.4" "192.168.0.5"
(integer) 1
 
/* 合并且去重之后放在 total:ip_address  */
redis> PFMERGE total:ip_address baidu:ip_address taobao:ip_address
OK
 
/* 结果为5 */
redis> PFCOUNT total:ip_address
(integer) 5

4 总结

基数计数是用于统计一个集合中不重复的元素个数,好比平常需求场景有,统计页面的UV或者统计在线的用户数、注册IP数等。HyperLogLog 主要基于Redis能力下的基数统计。HyperLogLog的主要使用场景包括:

  • 统计单日一个页面的访问量(PV),单次访问就算一次。
  • 统计单日一个页面的用户访问量(UV),即按照用户为维度计算,单个用户一天内多次访问也只算一次。
  • 多个key的合并统计,某个门户网站的所有模块的PV聚合统计就是整个网站的总PV。

与Redis系列10:HyperLogLog实现海量数据基数统计相似的内容:

Redis系列10:HyperLogLog实现海量数据基数统计

Redis系列1:深刻理解高性能Redis的本质 Redis系列2:数据持久化提高可用性 Redis系列3:高可用之主从架构 Redis系列4:高可用之Sentinel(哨兵模式) Redis系列5:深入分析Cluster 集群模式 追求性能极致:Redis6.0的多线程模型 追求性能极致:客户端缓

一次系统延迟性优化案例

一次系统延迟性优化案例 服务监控系列文章 服务监控系列视频 延迟的本质 本质是cpu没有及时的运行程序代码。 进程内部 网络io,磁盘io,cpu调度 达到瓶颈 第三方系统 调用的第三方系统慢,mysql,redis等基础组件调度慢, 第三方应用系统调用慢 问题背景 线上隔三差五晚上10点左右总会有

[转帖]Redis的高并发及高可用,到底该如何保证?

https://zhuanlan.zhihu.com/p/404481762 一、redis如何通过读写分享来承载读请求QPS超过10万+ 1、redis高并发跟整个系统的高并发之间的关系 redis,你要搞高并发的话,不可避免,要把底层的缓存搞得很好 mysql,高并发,做到了,那么也是通过一系列

redis系列02---缓存过期、穿透、击穿、雪崩

一、缓存过期 问题产生的原由: 内存空间有限,给缓存设置过期时间,但有些键值运气比较好,每次都没有被我的随机算法选中,每次都能幸免于难,这可不行,这些长时间过期的数据一直霸占着不少的内存空间! 解决方案: redis提供8种策略供应用程序选择,用于我遇到内存不足时该如何决策: * noevictio

[转帖]Redis系列(十五)、Redis6新特性之集群代理(Cluster Proxy)

在之前的文章中介绍了Redis6的集群搭建和原理,我们可以使用dummy和smart客户端连接集群,本篇介绍Redis6新增的一个功能:集群代理。客户端不需要知道集群中的具体节点个数和主从身份,可以直接通过代理访问集群,对于客户端来说通过集群代理访问的集群就和单机的Redis一样,因此也能解决很多集

[转帖]Redis系列(十六)、Redis6新特性之IO多线程

https://blog.csdn.net/wsdc0521/article/details/106766587 终于,Redis的多线程版本横空出世,大大提高了并发,本篇就带大家来看看什么是IO多线程,和我们理解的多线程有什么区别,与Memcached的多线程又有什么区别。 目录 介绍 为什么Re

[转帖]Redis系列(十七)、Redis中的内存淘汰策略和过期删除策略

我们知道Redis是分布式内存数据库,基于内存运行,可是有没有想过比较好的服务器内存也不过几百G,能存多少数据呢,当内存占用满了之后该怎么办呢?Redis的内存是否可以设置限制? 过期的key是怎么从内存中删除的?不要怕,本篇我们一起来看一下Redis的内存淘汰策略是如何释放内存的,以及过期的key

[转帖]Redis系列(十五)、Redis6新特性之集群代理(Cluster Proxy)

在之前的文章中介绍了Redis6的集群搭建和原理,我们可以使用dummy和smart客户端连接集群,本篇介绍Redis6新增的一个功能:集群代理。客户端不需要知道集群中的具体节点个数和主从身份,可以直接通过代理访问集群,对于客户端来说通过集群代理访问的集群就和单机的Redis一样,因此也能解决很多集

[转帖]【Redis系列】Redis发布版本历史及特性

目录 概述Redis2.6Redis2.8Redis3.0Redis3.2Redis4.0Redis5.0Redis6.0Redis7.0 概述 Redis 使用标准版本标记进行版本控制:major.minor.patchlevel。 偶数的版本号表示稳定的版本, 例如 1.2,2.0,2.2,2.

Redis系列8:Bitmap实现亿万级数据计算

Redis系列1:深刻理解高性能Redis的本质 Redis系列2:数据持久化提高可用性 Redis系列3:高可用之主从架构 Redis系列4:高可用之Sentinel(哨兵模式) Redis系列5:深入分析Cluster 集群模式 追求性能极致:Redis6.0的多线程模型 追求性能极致:客户端缓