PFCOUNT

PFCOUNT key [key ...]

Available since:

2.8.9

Time complexity:

O(1) with a very small average constant time when called with a single key. O(N) with N being the number of keys, and much bigger constant times, when called with multiple keys.

ACL categories:

@read, @hyperloglog, @slow,

当使用单个键调用时，返回存储在指定变量中的HyperLogLog数据结构计算的近似基数，如果变量不存在，则返回0。

当使用多个键调用时，通过内部将存储在提供的键中的HyperLogLogs合并到一个临时的HyperLogLog中，返回传递的HyperLogLogs并集的近似基数。

HyperLogLog数据结构可以用来计算集合中的唯一元素，仅使用少量的恒定内存，具体来说，每个HyperLogLog使用12k字节（加上键本身的几个字节）。

返回的观测集合的基数不准确，但具有0.81%的标准误差。

例如，为了计算一天内执行的所有唯一搜索查询的数量，程序需要在每次处理查询时调用PFADD。可以在任何时候使用PFCOUNT检索唯一查询的估计数量。

注意：调用此函数的副作用是，HyperLogLog 可能会被修改，因为最后8个字节编码了最新计算的基数用于缓存目的。因此，PFCOUNT 在技术上是一个写命令。

示例

性能

当使用单个键调用PFCOUNT时，性能非常出色，即使在理论上处理密集的HyperLogLog所需的时间是恒定的。这是可能的，因为PFCOUNT使用缓存来记住之前计算的基数，这个基数很少变化，因为大多数PFADD操作不会更新任何寄存器。每秒可以进行数百次操作。

当使用多个键调用PFCOUNT时，会即时合并HyperLogLogs，这个过程较慢，而且并集的基数无法缓存，因此当与多个键一起使用时，PFCOUNT可能需要毫秒级的时间，不应滥用。

用户应注意，此命令的单键和多键执行在语义上是不同的，并且具有不同的性能。

HyperLogLog 表示法

Redis HyperLogLogs 使用双重表示法：稀疏表示法适用于计数少量元素的 HLLs（导致少量寄存器设置为非零值），以及适用于更高基数的密集表示法。Redis 在需要时会自动从稀疏表示法切换到密集表示法。

稀疏表示使用了一种优化的游程编码，以高效存储大量设置为零的寄存器。密集表示是一个12288字节的Redis字符串，用于存储16384个6位计数器。需要双重表示的原因是，对于较小的基数，使用12k（这是密集表示的内存需求）来编码仅几个寄存器是极其不理想的。

两种表示形式都以16字节的头部为前缀，其中包括一个魔数、一个编码/版本字段，以及以小端格式存储的缓存基数估计（如果自计算基数以来HyperLogLog已更新，则最高有效位为1，表示估计无效）。

HyperLogLog 作为 Redis 字符串，可以使用 GET 获取，并使用 SET 恢复。使用损坏的 HyperLogLog 调用 PFADD、PFCOUNT 或 PFMERGE 命令通常不会出现问题，它可能会返回随机值，但不会影响服务器的稳定性。大多数情况下，当损坏稀疏表示时，服务器会识别出损坏并返回错误。

从处理器字长和字节序的角度来看，表示是中立的，因此32位和64位处理器、大端序或小端序都使用相同的表示。

有关Redis HyperLogLog实现的更多详细信息可以在这篇博客文章中找到。在hyperloglog.c文件中的实现源代码也易于阅读和理解，并包含了用于稀疏和密集表示的确切编码的完整规范。

RESP2 回复

RESP3 回复