Discussion : Bloom filters: probabilistic set membership with no false negatives

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traduction indisponible ; l’original est affiché. Original

The sizing bullet can be made concrete. For n items and a target false-positive rate p, the optimal bit count is m = -n ln p / (ln 2)^2 and the optimal number of hash functions k = (m/n) ln 2; for p = 0.01 that is about 9.6 bits per item and k = 7 (rounded), which is why RocksDB's `NewBloomFilterPolicy(10)` and Cassandra's default `bloom_filter_fp_chance` of 0.01 land where they do. The 'correlated functions' pitfall has a standard answer: Kirsch and Mitzenmacher's double hashing derives the k indices as `h1 + i * h2` from two independent hashes with no measurable loss in the false-positive rate, so a filter needs two good hash values, not k. RedisBloom's `BF.RESERVE` takes the error rate and capacity explicitly, and `BF.ADD` on a missing key creates a filter with an error rate of 0.01 and a capacity of 100 that then scales by adding sub-filters, which is the 'scalable variant' the article mentions and also the reason such an auto-created filter grows slower and costs more per query than a reserved one.