【数据结构】布隆过滤器-编程知识

布隆过滤器的提出

在注册账号设置昵称的时候，为了保证每个用户昵称的唯一性，系统必须检测你输入的昵称是否被使用过，这本质就是一个key的模型，我们只需要判断这个昵称被用过，还是没被用过。

方法一：用红黑树或哈希表将所有使用过的昵称存储起来，当需要判断一个昵称是否被用过时，直接判断该昵称是否在红黑树或哈希表中即可。但红黑树和哈希表最大的问题就是浪费空间，当昵称数量非常多的时候内存当中根本无法存储这些昵称
方法二：用位图将所有使用过的昵称存储起来，虽然位图只能存储整型数据，但我们可以通过一些哈希算法将字符串转换成整型，比如BKDR哈希算法。当需要判断一个昵称是否被用过时，直接判断位图中该昵称对应的比特位是否被设置即可。

位图虽然能够大大节省内存空间，但由于字符串的组合形式太多了，一个字符的取值有256种，而一个数字的取值只有10种，因此无论通过何种哈希算法将字符串转换成整型都不可避免会存在哈希冲突。

这里的哈希冲突就是不同的昵称最终被转换成了相同的整型，此时就可能会引发误判，即某个昵称明明没有被使用过，却被系统判定为已经使用过了，于是就出现了布隆过滤器。

布隆过滤器的概念

布隆过滤器是由布隆（Burton Howard Bloom）在1970年提出的一种紧凑型的、比较巧妙的概率型数据结构，特点是高效地插入和查询。

布隆过滤器其实就是位图的一个变形和延申，虽然无法避免存在哈希冲突，但我们可以想办法降低误判的概率。
当一个数据映射到位图中时，布隆过滤器会用多个哈希函数将其映射到多个比特位，当判断一个数据是否在位图当中时，需要分别根据这些哈希函数计算出对应的比特位，如果这些比特位都被设置为1则判定为该数据存在，否则则判定为该数据不存在。
布隆过滤器使用多个哈希函数进行映射，目的就在于降低哈希冲突的概率，一个哈希函数产生冲突的概率可能比较大，但多个哈希函数同时产生冲突的概率可就没那么大了。

假设布隆过滤器使用三个哈希函数进行映射，那么“张三”这个昵称被使用后位图中会有三个比特位会被置1，当有人要使用“李四”这个昵称时，就算前两个哈希函数计算出来的位置都产生了冲突，但由于第三个哈希函数计算出的比特位的值为0，此时系统就会判定“李四”这个昵称没有被使用过。

在这里插入图片描述

但随着位图中添加的数据不断增多，位图中1的个数也在不断增多，此时就会导致误判的概率增加。

比如“张三”和“李四”都添加到位图中后，当有人要使用“王五”这个昵称时，虽然“王五”计算出来的三个位置既不和“张三”完全一样，也不和“李四”完全一样，但“王五”计算出来的三个位置分别被“张三”和“李四”占用了，此时系统也会误判为“王五”这个昵称已经被使用过了。

在这里插入图片描述

布隆过滤器的特点

布隆过滤器判断一个数据存在可能是不准确的，因为这个数据对应的比特位可能被其他一个数据或多个数据占用了。
布隆过滤器判断一个数据不存在是准确的，因为如果该数据存在那么该数据对应的比特位都应该已经被设置为1了。

如何控制误判率？

很显然，过小的布隆过滤器很快所有的比特位都会被设置为1，此时布隆过滤器的误判率就会变得很高，因此布隆过滤器的长度会直接影响误判率，布隆过滤器的长度越长其误判率越小。
此外，哈希函数的个数也需要权衡，哈希函数的个数越多布隆过滤器中比特位被设置为1的速度越快，并且布隆过滤器的效率越低，但如果哈希函数的个数太少，也会导致误判率变高。

那应该如何选择哈希函数的个数和布隆过滤器的长度呢，有人通过计算后得出了以下关系式：

在这里插入图片描述

其中k为哈希函数个数，m为布隆过滤器长度，n为插入的元素个数，p为误判率。

我们这里可以大概估算一下，如果使用3个哈希函数，即k的值为3， ln2的值我们取0.7，那么m和n的关系大概是m = 4 * n，也就是布隆过滤器的长度应该是插入元素个数的4倍。

布隆过滤器的实现

首先，布隆过滤器可以实现为一个模板类，因为插入布隆过滤器的元素不仅仅是字符串，也可以是其他类型的数据，只有调用者能够提供对应的哈希函数将该类型的数据转换成整型即可，但一般情况下布隆过滤器都是用来处理字符串的，所以这里可以将模板参数K的缺省类型设置为string。

布隆过滤器中的成员一般也就是一个位图，我们可以在布隆过滤器这里设置一个非类型模板参数N，用于让调用者指定位图的长度。

//布隆过滤器
template<size_t N, class K = string, class Hash1 = BKDRHash, class Hash2 = APHash, class Hash3 = DJBHash>
class BloomFilter {
public://...
private:bitset<N> _bs;
};

实例化布隆过滤器时需要调用者提供三个哈希函数，由于布隆过滤器一般处理的是字符串类型的数据，因此这里我们可以默认提供几个将字符串转换成整型的哈希函数。

这里选取将字符串转换成整型的哈希函数，是经过测试后综合评分最高的BKDRHash、APHash和DJBHash，这三种哈希算法在多种场景下产生哈希冲突的概率是最小的。
此时本来这三种哈希函数单独使用时产生冲突的概率就比较小，现在要让它们同时产生冲突概率就更小了。

代码如下：

struct BKDRHash {size_t operator()(const string &s) {size_t value = 0;for (auto ch: s) {value = value * 131 + ch;}return value;}
};struct APHash {size_t operator()(const string &s) {size_t value = 0;for (size_t i = 0; i < s.size(); i++) {if ((i & 1) == 0) {value ^= ((value << 7) ^ s[i] ^ (value >> 3));} else {value ^= (~((value << 11) ^ s[i] ^ (value >> 5)));}}return value;}
};struct DJBHash {size_t operator()(const string &s) {if (s.empty())return 0;size_t value = 5381;for (auto ch: s) {value += (value << 5) + ch;}return value;}
};

布隆过滤器的插入

布隆过滤器当中需要提供一个Set接口，用于插入元素到布隆过滤器当中。插入元素时，需要通过三个哈希函数分别计算出该元素对应的三个比特位，然后将位图中的这三个比特位设置为1即可。

代码如下：

void Set(const K &key) {//计算出key对应的三个位size_t i1 = Hash1()(key) % N;size_t i2 = Hash2()(key) % N;size_t i3 = Hash3()(key) % N;//设置位图中的这三个位_bs.set(i1);_bs.set(i2);_bs.set(i3);
}

布隆过滤器的查找

布隆过滤器当中还需要提供一个Test接口，用于检测某个元素是否在布隆过滤器当中。检测时，需要通过三个哈希函数分别计算出该元素对应的三个比特位，然后判断位图中的这三个比特位是否被设置为1。

只要这三个比特位当中有一个比特位未被设置则说明该元素一定不存在。
如果这三个比特位全部被设置，则返回true表示该元素存在（可能存在误判）。

代码如下：

bool Test(const K &key) {//依次判断key对应的三个位是否被设置size_t i1 = Hash1()(key) % N;if (_bs.test(i1) == false) {return false;//key一定不存在}size_t i2 = Hash2()(key) % N;if (_bs.test(i2) == false) {return false;//key一定不存在}size_t i3 = Hash3()(key) % N;if (_bs.test(i3) == false) {return false;//key一定不存在}return true;//key对应的三个位都被设置，key存在（可能误判）
}

布隆过滤器的删除

布隆过滤器一般不支持删除操作，原因如下：

因为布隆过滤器判断一个元素存在时可能存在误判，因此无法保证要删除的元素确实在布隆过滤器当中，此时将位图中对应的比特位清0会影响其他元素。
此外，就算要删除的元素确实在布隆过滤器当中，也可能该元素映射的多个比特位当中有些比特位是与其他元素共用的，此时将这些比特位清0也会影响其他元素。

如何让布隆过滤器支持删除？

要让布隆过滤器支持删除，必须要做到以下两点：

保证要删除的元素在布隆过滤器当中。比如刚才的呢称例子当中，如果通过调用Test函数得知要删除的昵称可能存在布隆过滤器当中后，可以进一步遍历存储昵称的文件，确认该昵称是否真正存在。
保证删除后不会影响到其他元素。可以为位图中的每一个比特位设置一个对应的计数值，当插入元素映射到该比特位时将该比特位的计数值++，当删除元素时将该元素对应比特位的计数值–即可。

可是布隆过滤器最终还是没有提供删除的接口，因为使用布隆过滤器本来就是要节省空间和提高效率的。在删除时需要遍历文件或磁盘中确认待删除元素确实存在，而文件IO和磁盘IO的速度相对内存来说是很慢的，并且为位图中的每个比特位额外设置一个计数器，就需要多用原位图几倍的存储空间，这个代价也是不小的。