为何布隆过滤器（Bloom Filter）不采用Count-Min Sketch的实现方式？

二者的设计目标差异从根源上决定了实现方案的取舍，核心原因有几个：

• 设计目标对误差的要求不同
  计数布隆过滤器的核心能力是成员存在性判定，仅需要输出「一定不存在」/「可能存在」的二元结果，碰撞带来的影响只有假阳性率的小幅上升，只要调整哈希函数数量、总数组长度，完全可以把假阳性控制在业务可接受的范围。而Count-Min Sketch的核心目标是做元素频率统计，需要输出具体的计数值，哈希碰撞会直接导致统计结果偏大，精度受碰撞影响远大于计数布隆过滤器，所以才需要用独立数组降低碰撞的影响。
• 空间效率的性价比不足
  计数布隆过滤器的每个计数桶通常只需要4~8位就可以覆盖绝大多数场景的计数需求（毕竟它不需要记录高精度的高频值，只需要记录桶被命中的次数，常规场景下很少出现单桶计数溢出的情况）。如果给每个哈希函数分配独立数组，总空间占用会和哈希函数数量成正比上升，对于工业级场景下动辄需要数千万、数亿桶的计数布隆过滤器来说，额外的空间开销完全没有必要，性价比极低。
• 操作逻辑的收益为负
  计数布隆过滤器的增删逻辑都是对所有哈希函数命中的桶统一做加减1操作，共用数组的实现逻辑非常简洁。如果拆分为独立数组，增删逻辑复杂度没有下降，反而会因为不同数组的桶溢出概率不同提升维护成本，没有额外收益。

当然也有少数特殊场景下会出现拆分独立数组的计数布隆过滤器变种，但绝大多数通用实现都会选择共用数组的方案。

内容的提问来源于stack exchange，提问作者aa8y