Bloom filter将集合中的元素映射到位数组中，用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中。Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter，从而支持了元素的删除操作。一旦位扩展成了counter，每一个counter就不仅能表示这一地址有无映射，还能表示映射的个数。这一扩展使得存储的数据包含了更多信息，然而遗憾的是，CBF仅仅利用这个扩展支持了删除操作，并没有将信息中蕴含的潜力完全挖掘出来。毫无疑问，Spectral Bloom Filter（SBF）的提出者就看到了这种潜力。

 

标准的bloom filter和CBF解决的只是集合元素的membership问题，即判断一个元素是否属于某个集合。但有时我们不但想知道集合中是否存在一个元素，我们还想知道这个元素在集合中的出现次数。例如在一些数据流（data stream）应用中，我们关心的也许不是一个数据元素是否属于某个集合，而是它的出现频率。很自然地，我们希望能从counter中得到这些信息。但是，counter反映的只是映射数，如何将其与集合元素的出现次数关联呢？

 

在CBF中加入一个元素时，k个哈希位置的counter都要加1。也就是说，如果不考虑碰撞（collision），出现次数为n的元素对应的k个counter的值都为n。即使考虑到碰撞的因素，只要k个位置不全出现碰撞，k个counter中的最小值仍是n。令元素x对应的k个counter的最小值为m_x，x的出现频率为f_x，从上面的分析我们不难看出，f_x ≠ m_x的概率和标准bloom filter的false positive概率相同，因为二者出现的充要条件都是k个哈希位置同时出现碰撞。

 

上面这个结果其实就是SBF的理论基础。SBF扩展了CBF，使得用户不但可以进行membership query，还可以查询集合元素的出现频率。在查询元素x的出现频率时，SBF返回m_x，出错的概率和false positive rate相同。注意，由于f_x ≤ m_x，所以查询的结果即使不准，也可以得到一个上界，而且这个上界和实际值f_x一般情况下不会相差太远。

 

到现在为止讲的都是概念，我们还没有看到SBF和CBF在构造上有什么不同。当然，如果不改变CBF就可以加入新的feature，那最好不过了，可惜事情没有这么简单。CBF的counter在只支持membership query的时候，4位就够了，如果想要支持元素的出现频率查询，4位就远远不够。由于元素有可能成百上千次重复出现，而且完全没法预测，所以SBF的counter必须能够动态伸缩。下一次我们就来讨论SBF如何实现counter的存储。

发表于 @ 2007年03月19日　22:11:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:Bloom Filter应用之Web Cache Sharing | 新一篇:Spectral Bloom Filter (2)