Dynamic Count Filter

Spectral bloom filterSBF)在counting bloom filterCBF)的基础上提出了元素出现频率查询的概念,将CBF的应用扩展到了multi-set的领域。但是,SBF为解决动态counter的存储问题,引入了复杂的索引结构,这让每个counter的访问变得复杂而耗时。有没有一种解决方案既支持元素出现频率查询,结构又相对比较简单呢?Dynamic count filterDCF)尝试回答了这个问题。

 

要支持元素出现频率查询,就需要解决变化范围可能很大的counter的存储问题。DCFSBF的不同之处,也就是counter的存储结构。DCF使用两个数组来存储所有的counter,它们的长度都为m(即bloom filter的位数组长度)。第一个数组是一个基本的CBF(即下图中的CBFVcounting bloom filter vector),counter的长度固定,为x = log(M/n),其中M是集合中所有元素的个数,n为集合中不同元素的个数。第二个数组用来处理counter的溢出(即下图中的OFVoverflow vector),数组每一项的长度并不固定,根据counter的溢出情况动态调整。假设OFjOFV中某一项的值,那么OFV中每一项的长度y = floor(log(max(OFj))) + 1,即最大值决定了每项长度。

 Dynamic Count Filter_第1张图片

上图中最右一列是counter的值,从图中我们可以清楚地看出OFVCBFV的作用。比如第5counter的值是1026,二进制为10000000010。我们把这个二进制位串分成两段10000000010,分别就对应着OFVCBFV中的值。图中我们也可以看出x + y就等于counter的最大值的二进制位数。

 

在查询一个counter时,DCF要求两次内存访问。假设想查询位置为jcounter的值,我们先读出CBFVOFV的值,分别为CjOFj,那么counter的值就可以表示为Vj = (2x ×OFj Cj)

 

在集合增加元素时,如果OFV的最大值从2x – 1增加到2xOFV就需要给每一项增加1位,否则就会溢出。每次OFV大小改变的时候都需要重建。重建是一件开销很大的工作,必须重新创建一个OFV数组,然后把旧OFV数组的值拷贝到新建的OFV数组中,最后把旧OFV数组的空间释放掉。如果说增加时的overflow必须重建的话,那么集合元素减少时的underflow则有更多选择。当OFV的最大值从2x减少到2x – 1时,我们可以选择马上重建OFV,也可以采用一些策略延迟OFV的重建,以避免一些临时性的减少导致OFV反复重建。

 

从上面的介绍可以看出,DCF中最大的那个counter决定了整个结构所占的空间。因此,在counter的值普遍不大的情况下,DCF由于不用维护复杂的索引结构,所以占用空间比SBF要少。如果将counter的值逐渐增大,SBF在空间占用上的优势就会越来越明显。在counter存取时间上,DCF占有绝对的优势,只比CBF多访问了一次内存。在不同的实际应用场合中对比SBFDCF,论文作者发现DCF整体占用的空间以及执行时间都比SBF少了一半还多。最后,我们给出一个将CBFSBFDCF定性比较的表格:

参考论文:http://www.sigmod.org/sigmod/record/issues/0603/p26-article-pey.pdf

你可能感兴趣的:(c,工作,vector,filter,存储,扩展)