布隆過濾器速度 一文講透「布隆過濾器」

布隆過濾器本質上就是一種資料結構，比較巧妙的概率型資料結構(probabilistic data structure)，特點是高效地插入和查詢，可以用來告訴你 「某樣東西一定不存在或者可能存在」。

相比於傳統的 list、set、map 等資料結構，它更高效、占用空間更少，但是缺點是其返回的結果是概率性的，而不是確切的。

我們經常會把一部分資料放在redis中快取，比如文章詳情。

這樣有查詢請求進來，我們可以根據文章id直接去快取中取資料，而不用讀取資料庫，這是提公升效能最簡單，最普遍，也是最有效的做法。

一般的查詢請求流程是這樣的：先查快取(有快取的話直接返回)-> 如果快取中沒有，再去資料庫查詢(把資料庫取出來的資料放入快取)-> 返回資料。

既然文章id都不存在，那麼肯定沒有對應的快取資訊，沒有快取，那麼大量的請求都堆積到資料庫，資料庫的壓力一下子就上來了，甚至可能把資料庫打滿跑死。

查詢近1億使用者手機號系統中是否存在其交易資訊，如何做到判斷的準確快速？

方案一：通過資料庫查詢

查詢壓力好像有點大，做不到高效而且還存在資料庫服務被壓垮的風險。

方案二：通過redis快取(存在交易單的使用者手機號放入set)

可能會產生大key造成慢查詢，同時記憶體資源會造成浪費。

以上例子有乙個共同的特點：如何判斷乙個元素是否存在乙個集合中。這些問題用其他方式可能都會解決，但「布隆過濾器」就能夠有效的解決。

雜湊函式的概念：將任意大小的資料轉換成特定大小的資料的函式，轉換後的資料稱為雜湊值或雜湊編碼。示意圖如下所示：

可以明顯的看到，原始資料經過雜湊函式的對映後成為了乙個個的雜湊編碼，資料得到壓縮。雜湊函式是實現雜湊表和布隆過濾器的基礎。

布隆過濾器是乙個 bit 向量或者說 bit 陣列，示意圖如下所示：

布隆過濾器(bloom filter)的核心實現是乙個超大的位陣列和幾個雜湊函式。

假設我們要將x、y、z三元素放入布隆過濾器再去檢索w，示意圖如下所示：

具體的操作流程如下：

假設集合裡面有3個元素，雜湊函式的個數為3。將位陣列進行初始化，將裡面每個位都設定為0。

注意：此處不能判斷該元素是否一定存在集合中，可能存在一定的誤判率。

假設某個元素通過對映對應下標為4，5，6 這3個點。雖然這3個點都為1，但是很明顯這3個點是不同元素經過雜湊得到的位置，因此這種情況說明元素雖然不在集合中，也可能對應的都是1，由此推斷出誤判率存在的可能性。

//語法：[bf.add  key  options]127.0.0.1:6379> bf.add users 15012345678(integer) 1

//語法：[bf.exists  key  options]127.0.0.1:6379> bf.exists users 15012345678(integer) 1127.0.0.1:6379> bf.exists users 15012345679(integer) 0

但是名為counting bloom filter的變種可以用來測試元素計數個數是否絕對小於某個閾值，它支援元素刪除。大家感興趣可自行檢索了解~

既然我們使用布隆過濾器來加速查詢和判斷是否存在，那麼效能很低的雜湊函式不是個好選擇，推薦 murmurhash、fnv 這些。

雜湊函式的個數也需要權衡，個數越多則布隆過濾器 bit 位置為 1 的速度越快，且布隆過濾器的效率越低；但是如果太少的話，那我們的誤報率會變高。

布隆過濾器

布隆過濾器 bloom filter 是1970年由布隆提出的。它實際上是乙個很長的二進位制向量和一系列隨機對映函式。布隆過濾器可以用於檢索乙個元素是否在乙個集合中。它的優點是空間效率和查詢時間都遠遠超過一般的演算法，缺點是有一定的誤識別率和刪除困難。如果想要判斷乙個元素是不是在乙個集合裡，一般想到...

布隆過濾器

布隆過濾器的概念 如果想要判斷乙個元素是不是在乙個集合裡，一般想到的是將所有元素儲存起來，然後通過比較確定。鍊錶，樹等等資料結構都是這種思路.但是隨著集合中元素的增加，我們需要的儲存空間越來越大，檢索速度也越來越慢 o n o logn 不過世界上還有一種叫作雜湊表 又叫 雜湊表，hash tabl...

布隆過濾器

如果想判斷乙個元素是不是在乙個集合裡，一般想到的是將集合中所有元素儲存起來，然後通過比較確定。鍊錶 樹 雜湊表 又叫雜湊表，hash table 等等資料結構都是這種思路。但是隨著集合中元素的增加，我們需要的儲存空間越來越大。同時檢索速度也越來越慢。bloom filter 是一種空間效率很高的隨機...