go語言中布隆過濾器低空間成本判斷元素是否存在方式
簡(jiǎn)介
布隆過濾器(BloomFilter)是一種用于判斷元素是否存在的方式,它的空間成本非常小,速度也很快。
但是由于它是基于概率的,因此它存在一定的誤判率,它的Contains()
操作如果返回true
只是表示元素可能存在集合內(nèi),返回false
則表示元素一定不存在集合內(nèi)。因此適合用于能夠容忍一定誤判元素存在集合內(nèi)的場(chǎng)景,比如緩存。
它一秒能夠進(jìn)行上百萬次操作(主要取決于哈希函數(shù)的速度),并且1億數(shù)據(jù)在誤判率1%的情況下,只需要114MB內(nèi)存。
原理
數(shù)據(jù)結(jié)構(gòu)
布隆過濾器的數(shù)據(jù)結(jié)構(gòu)是一個(gè)位向量,也就是一個(gè)由0、1所組成的向量(下面是一個(gè)初始向量):
添加
每個(gè)元素添加進(jìn)布隆過濾器前,都會(huì)經(jīng)過多個(gè)不同的哈希函數(shù),計(jì)算出不同的哈希值,然后映射到位向量上,也就是對(duì)應(yīng)的位上面置1:
判斷存在
判斷元素是否存在也是如上圖流程,根據(jù)哈希函數(shù)映射的位置,判斷所有映射位置是否都為1,如果是則元素可能存在,否則元素一定不存在。
由于不同的值通過哈希函數(shù)之后可能會(huì)映射到相同的位置,因此如果一個(gè)不存在的元素對(duì)應(yīng)的位位置都被其他元素所設(shè)置位1,則查詢時(shí)就會(huì)誤判:
假設(shè)上圖元素3334并沒有加入集合,但是由于它映射的位置已經(jīng)被其他元素所映射,則查詢時(shí)會(huì)誤判。
哈希函數(shù)
布隆過濾器里面的哈希函數(shù)需要是彼此獨(dú)立且均勻分布(類似于哈希表的哈希函數(shù)),而且需要盡可能的快,比如murmur3就是一個(gè)很好的選擇。
布隆過濾器的性能嚴(yán)重依賴于哈希函數(shù)的性能,而一般哈希函數(shù)的性能則依賴于輸入串(一般為字節(jié)數(shù)組)的長度,因此為了提高布隆過濾器的性能建議減少輸入串的長度。
下面是一個(gè)簡(jiǎn)單的性能測(cè)試,單位是字節(jié),可以看到時(shí)間的消耗隨著元素的增大基本是線性增長的:
cpu: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
BenchmarkAddAndContains/1-8 1805840 659.6 ns/op 1.52 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/2-8 1824064 696.4 ns/op 2.87 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/4-8 1819742 649.5 ns/op 6.16 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/8-8 1828371 653.2 ns/op 12.25 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/16-8 1828426 642.0 ns/op 24.92 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/32-8 2106834 565.7 ns/op 56.57 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/64-8 2063895 579.3 ns/op 110.48 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/128-8 1767673 666.1 ns/op 192.17 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/256-8 1292918 916.9 ns/op 279.21 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/512-8 749666 1590 ns/op 322.11 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/1024-8 388015 2933 ns/op 349.12 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/2048-8 203404 5603 ns/op 365.51 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/4096-8 105134 11303 ns/op 362.38 MB/s 0 B/op 0 allocs/op
BenchmarkAddAndContains/8192-8 52305 22067 ns/op 371.23 MB/s 0 B/op 0 allocs/op
布隆過濾器大小、哈希函數(shù)數(shù)量、誤判率
布隆過濾器的大小、哈希函數(shù)數(shù)量和誤判率之間是互相影響的,如果我們想減少誤判率,則需要更大的布隆過濾器和更多的哈希函數(shù)。但是我們很難直觀的計(jì)算出這些參數(shù),還好有兩個(gè)公式可以幫助我們計(jì)算出準(zhǔn)確的數(shù)值:
在我們可以確定我們的元素?cái)?shù)量和能夠容忍的錯(cuò)誤率的情況下,我們可以根據(jù)下面公式計(jì)算布隆過濾器大小和哈希函數(shù)數(shù)量:
n = 元素?cái)?shù)量
m = 布隆過濾器大?。ㄎ粩?shù))
k = 哈希函數(shù)數(shù)量
fpr = 錯(cuò)誤率(falsePositiveRate,假陽性率)
m = n*(-ln(fpr)/(ln2*ln2))
k = ln2 * m / n
應(yīng)用場(chǎng)景
數(shù)據(jù)庫
布隆過濾器可以提前過濾所查詢數(shù)據(jù)并不存在的請(qǐng)求,避免對(duì)磁盤訪問的耗時(shí)。比如LevelDB就使用了布隆過濾器過濾請(qǐng)求github.com/google/leve… 。
黑名單
假設(shè)有10億個(gè)黑名單URL,每個(gè)URL大小為64字節(jié)。使用Bloom Filter,如果錯(cuò)誤率為0.1%,只需要1.4GB內(nèi)存,如果錯(cuò)誤率為0.0001%,也只需要2.9GB內(nèi)存。
實(shí)現(xiàn)
這里簡(jiǎn)單的介紹一下Golang的實(shí)現(xiàn)方式。
數(shù)據(jù)結(jié)構(gòu)
由于我們沒辦法直接申請(qǐng)一個(gè)bit組成的數(shù)組,因此我們使用uint64表示64個(gè)bit。
type Filter struct { bits []uint64 // bit數(shù)組 bitsCnt uint64 // bit位數(shù) hashs []*hash.Hash // 不同哈希函數(shù) }
初始化
在初始化的時(shí)候,我們需要根據(jù)上面提到的兩個(gè)公式,計(jì)算布隆過濾器的大小和哈希函數(shù)的數(shù)量。
// capacity:容量 // falsePositiveRate:誤判率 func New(capacity uint64, falsePositiveRate float64) *Filter { // bit數(shù)量 ln2 := math.Log(2.0) factor := -math.Log(falsePositiveRate) / (ln2 * ln2) bitsCnt := mmath.Max(1, uint64(float64(capacity)*factor)) // 哈希函數(shù)數(shù)量 hashsCnt := mmath.Max(1, int(ln2*float64(bitsCnt)/float64(capacity))) hashs := make([]*hash.Hash, hashsCnt) for i := 0; i < hashsCnt; i++ { hashs[i] = hash.New() } return &Filter{ bits: make([]uint64, (bitsCnt+63)/64), bitsCnt: bitsCnt, hashs: hashs, } }
添加元素
添加元素的時(shí)候,把每個(gè)哈希函數(shù)映射的位置都設(shè)置為1。這里需要注意,因?yàn)槭怯玫膗int64的數(shù)組,因此需要把按照bit計(jì)算的偏移,轉(zhuǎn)換為按照64位計(jì)算的數(shù)組下標(biāo)和對(duì)應(yīng)下標(biāo)元素里面的偏移。
// 添加元素 func (f *Filter) Add(b []byte) { for _, h := range f.hashs { index, offset := f.pos(h, b) f.bits[index] |= 1 << offset } } // 獲取對(duì)應(yīng)元素下標(biāo)和偏移 func (f *Filter) pos(h *hash.Hash, b []byte) (uint64, uint64) { hashValue := h.Sum64(b) // 按照位計(jì)算的偏移 bitsIndex := hashValue % f.bitsCnt // 因?yàn)橐粋€(gè)元素64位,因此需要轉(zhuǎn)換 index := bitsIndex / uint64Bits // 在一個(gè)元素里面的偏移 offset := bitsIndex % uint64Bits return index, offset }
判斷元素是否存在
同理,只是這里我們?nèi)绻l(fā)現(xiàn)某一位不為1則可以直接返回false。
// 元素是否存在 // true表示可能存在 func (f *Filter) Contains(b []byte) bool { for _, h := range f.hashs { index, offset := f.pos(h, b) mask := uint64(1) << offset // 判斷這一位是否位1 if (f.bits[index] & mask) != mask { return false } } return true }
參考
以上就是go語言中布隆過濾器低空間成本判斷元素是否存在方式的詳細(xì)內(nèi)容,更多關(guān)于go 布隆過濾器判斷元素的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Go語言中配置實(shí)現(xiàn)Logger日志的功能詳解
當(dāng)我們正式開發(fā)go程序的時(shí)候,就會(huì)發(fā)現(xiàn)記錄程序日志已經(jīng)不是fmt.print這么簡(jiǎn)單了,所以我們需要專門的去存儲(chǔ)日志文件,這篇文章主要介紹了在Go語言中配置實(shí)現(xiàn)Logger日志的功能,感興趣的同學(xué)可以參考下文2023-05-05解決golang處理http response碰到的問題和需要注意的點(diǎn)
這篇文章主要介紹了解決golang處理http response碰到的問題和需要注意的點(diǎn),具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2020-12-12CMD下執(zhí)行Go出現(xiàn)中文亂碼的解決方法
需要在Go寫的服務(wù)里面調(diào)用命令行或者批處理,并根據(jù)返回的結(jié)果做處理。但是windows下面用cmd返回中文會(huì)出現(xiàn)亂碼,本文就詳細(xì)的介紹一下解決方法,感興趣的可以了解一下2021-12-12Goland 斷點(diǎn)調(diào)試Debug的操作
這篇文章主要介紹了Goland 斷點(diǎn)調(diào)試Debug的操作方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2021-04-04