HyperLogLog is an algorithm for the count-distinct problem, approximating the number of distinct elements in a multiset. Calculating the exact cardinality of a multiset requires an amount of memory proportional to the cardinality, which is impractical for very large data sets. Probabilistic cardinality estimators, such as the HyperLogLog algorithm, use significantly less memory than this, at the cost of obtaining only an approximation of the cardinality. The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical accuracy (standard error) of 2%, using 1.5 kB of memory.
Hyperloglog is part of a class of algorithms known as “sketches”, which use precomputed probabilistic data structures to perform fast but approximate computations on very large data sets.
Supported computations include count distinct, frequency, sampling, and quantiles and histograms.
There’s a project called Apache Datasketches (developed at Yahoo) that implements production versions of these algorithms. They are useful in the implementations of search engines, discussion forum software, etc. that are designed for scale.
Another sketch is the well-known Bloom filter, which can quickly test if an element is part of a set without ever returning a false negative (useful for quickly checking a large database for whether a particular username is still available).
Is there a companion paper somewhere explaining how it works? I tried to read the comments in the source but didn't really understand much. (Might be related to the fact that I never knew much about vanilla HyperLogLog to begin with.)
> Moreover, while accessing the registers, we need to compute the sum of pow(2,-register) which involves floating point math.
> [...]
> * The floating point computation was modified in order to allow for multiple operations to be performed in parallel when possible. This was just a matter of adding parens. Floating point math is not commutative, but in this case there was no loss of precision.
Floating point addition is commutative. It is not associative though.
https://github.com/redis/redis/blob/unstable/src/hyperloglog... seems to be the starting point, given a number of identical comments (complete with typos, e.g. "Estimate cardinality form register histogram"), function names, macros. Copyright isn't preserved, which is troubling in itself. There's a brief mention of Redis's HLL implementation in the README, which is a hint re: the code's origins.
The first divergence I see is in hllSparseToDense, although it seems more like a tweak to the input/output (passing in o->ptr instead of o, returning hdr instead of C_OK / C_ERR), than an algorithmic difference.
Line 550 contains a looser check:
if (span == 0) return -1;
omitting the check that p >= end.
And... the only meaningful algorithmic change I found is in hllAdd, wherein we invalidate the cache if hllDenseAdd() returns 1.
There might be something else, but a lot of the details look to be standard (e.g. impl of murmurhash64a).
Anyways, if anyone else wants to look at it: I've stripped the comments, clang-formatted both implementations, and uploaded the diff (sans newline differences) to pastebin.
Yeah, WangYi only updates via some git gui. Same for his hash and prng. But those two set already the new standards, and the hll should be in the same league. Top of the class.
13 comments
[ 1.9 ms ] story [ 48.2 ms ] threadHyperLogLog is an algorithm for the count-distinct problem, approximating the number of distinct elements in a multiset. Calculating the exact cardinality of a multiset requires an amount of memory proportional to the cardinality, which is impractical for very large data sets. Probabilistic cardinality estimators, such as the HyperLogLog algorithm, use significantly less memory than this, at the cost of obtaining only an approximation of the cardinality. The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical accuracy (standard error) of 2%, using 1.5 kB of memory.
Source: https://en.wikipedia.org/wiki/HyperLogLog
Supported computations include count distinct, frequency, sampling, and quantiles and histograms.
There’s a project called Apache Datasketches (developed at Yahoo) that implements production versions of these algorithms. They are useful in the implementations of search engines, discussion forum software, etc. that are designed for scale.
https://datasketches.apache.org/docs/Background/TheChallenge...
Another sketch is the well-known Bloom filter, which can quickly test if an element is part of a set without ever returning a false negative (useful for quickly checking a large database for whether a particular username is still available).
A multiset is a set where each element can be present multiple times. In other words, it's like an array or list but you don't care about the order.
Just a small nitpick, for the craic:
> Moreover, while accessing the registers, we need to compute the sum of pow(2,-register) which involves floating point math. > [...] > * The floating point computation was modified in order to allow for multiple operations to be performed in parallel when possible. This was just a matter of adding parens. Floating point math is not commutative, but in this case there was no loss of precision.
Floating point addition is commutative. It is not associative though.
That, together with the lack of documentation, makes it much more difficult to figure out what's special about this implementation.
The first divergence I see is in hllSparseToDense, although it seems more like a tweak to the input/output (passing in o->ptr instead of o, returning hdr instead of C_OK / C_ERR), than an algorithmic difference.
Line 550 contains a looser check:
omitting the check that p >= end.And... the only meaningful algorithmic change I found is in hllAdd, wherein we invalidate the cache if hllDenseAdd() returns 1.
There might be something else, but a lot of the details look to be standard (e.g. impl of murmurhash64a).
https://pastebin.com/T520dzWV
It would be nice to have comments pointing out specifically what changes are important / why they were made.