布隆過濾器 Bloom Filter
布隆過濾器，用來判斷一個元素是否在集合中。
它的特點是節省空間，但是有誤判。有可能誤判某個不存在的元素在集合中（false positive），但是不會誤判存在的元素不再集合中（false negative）。RocksDB可能也正是因為這個特性，才選擇布隆過濾器來作為默認filter的數據結構。
簡單地說，布隆過濾器提供了這樣的語義:
- 某個元素可能在集合中
- 某個元素一定不在集合中
一個布隆過濾器由兩部分組成
- 一個長度為m的位數組，各個為初始值都是0
- k個不同的hash函數
當有一個新的元素x需要插入到集合中，并記錄在布隆過濾器中時
- 通過k個hash函數，計算k個hash值
- 在位數組中，將計算得到的k個hash值對應的位置為1
查詢時
- 通過k個hash函數，計算k各hash值
- 在位數組中，查看k個hash值對應的位是否都是1，如果都是1，則說明被查詢的數在集合中
上面所說的false negative就是因為有一定的概率，會發生兩個不同的元素x和y，通過k各hash函數得到的k個值是相同的。
下圖簡單說明了布隆過濾器的原理。
An example of a Bloom filter, representing the set {x, y, z}. The colored arrows show the positions in the bit array that each set element is mapped to. The element w is not in the set {x, y, z}, because it hashes to one bit-array position containing 0. For this figure, m = 18 and k = 3.
更詳細的說明請參考 Wikipedia article.
RocksDB中Bloom Filter的用法
- 每一個SST文件對應一個Bloom Filter。
- 當SST文件寫入到磁盤中時，創建一個Bloom Filter， 并作為SST文件的一部分寫到磁盤上。
- Bloom Filter只能通過key集合創建，而沒有合并的操作。所以，當合并兩個SST文件時，新文件的Bloom Filter是創建出來的，而不是合并得到的。
- 當打開一個SST文件時，會將對應的Bloom Filter load到內存中。當關閉SST文件時，將對應的Bloom Filter從內存中刪除。
Bloom Filter類圖
職責說明
- BlockBasedTableBuilder
用于構建一個SST文件的數據結構, 持有一個Rep對象來保存各種選項和成員變量. 詳見<RocksDB. BlockBasedTable源碼分析> - Rep
用于持有各種選項和成員變量, 其中filter_builder成員用于構建bloom filter. - FilterBlockBuilder
接口類, 定義了構建filter的接口, 包括IsBlockBased, StartBlock, Add, Finish等接口. - BlockBasedFilterBlockBuilder
實現了FilterBlockBuilder的接口, 用于構造BlockBasedFilterBlock. 持有一個FilterPolicy* 類型的成員policy_, 用于對一組key創建filter block. - FilterPolicy
接口類, 定義創建filter的接口, 包括CreateFilter, KeyMayMatch等接口. - BloomFilterPolicy
實現了接口類FilterPolicy, 用于對一組key創建filter block.
Bloom FIlter創建流程分析
filter_policy作為BlockBasedTableOption的一個選項，在打開數據庫對的時候指定
BlockBasedTableOptions table_options;
table_options.format_version = first_table_version;
table_options.filter_policy.reset(NewBloomFilterPolicy(10));
Options options = CurrentOptions();
options.table_factory.reset(NewBlockBasedTableFactory(table_options));
options.create_if_missing = true;
options.compression = comp;
// DestroyAndReopen(options);
NewBloomFilterPolicy函數返回Bloom Filter的實現對象
const FilterPolicy* NewBloomFilterPolicy(int bits_per_key,
bool use_block_based_builder) {
return new BloomFilterPolicy(bits_per_key, use_block_based_builder);
}
參數說明
- bits_per_key：位數組的長度。推薦的長度是10，約有%1的誤判率。
- use_block_based_builder ：是否使用block based filter，和block based filter對應的是full filter。默認值是true，即使用block based filter。
如第二節所說，Bloom Filter是在生成SST文件的時候創建的，而SST文件使用的是TableBuilder。以BlockBasedTableBuilder為例，來看Bloom Filter是如何被創建，并寫入到SST文件中。
BlockBasedTableBuilder并沒有直接使用filter_policy來創建filter，而是通過Rep的成員變量filter_builder。
std::unique_ptr<FilterBlockBuilder> filter_builder;
// 在BlockBasedTableBuilder::Rep的構造函數里，創建一個filter block builder
if (skip_filters) {
filter_builder = nullptr;
} else {
filter_builder.reset(
CreateFilterBlockBuilder(_ioptions, table_options, p_index_builder));
}
// CreateFilterBlockBuilder的實現
FilterBlockBuilder* CreateFilterBlockBuilder(
const ImmutableCFOptions& opt, const BlockBasedTableOptions& table_opt,
PartitionedIndexBuilder* const p_index_builder) {
if (table_opt.filter_policy == nullptr) return nullptr;
FilterBitsBuilder* filter_bits_builder =
table_opt.filter_policy->GetFilterBitsBuilder();
if (filter_bits_builder == nullptr) {
return new BlockBasedFilterBlockBuilder(opt.prefix_extractor, table_opt);
} else {
...
}
}
創建filter block builder的時候，將table_options傳了進去，讓BlockBasedFilterBlockBuilder可以獲取打開數據庫時創建的filter policy指針。
BlockBasedFilterBlockBuilder::BlockBasedFilterBlockBuilder(
const SliceTransform* prefix_extractor,
const BlockBasedTableOptions& table_opt)
: policy_(table_opt.filter_policy.get()),
prefix_extractor_(prefix_extractor),
whole_key_filtering_(table_opt.whole_key_filtering),
prev_prefix_start_(0),
prev_prefix_size_(0) {
assert(policy_);
}
filter builder通過該指針為一組key集合創建bloom filter。
filter builder的使用分為三個步驟。
- StartBlock：為下一個block創建一個新的bloom filter。filter builder并不是只為整個table創建一個bloom filter。而是創建一組bloom filter，每個block有一個bloom filter。實際上，在計算filter數量的時候，是按照每2KB data創建一個filter。所以在實現上，一個block對應兩個filter，一個filter對應4KB data，一個filter是空的。在后面貼的源碼中可以看到這一點，之所這樣實現，可能是其它類型的filter對這樣的行為有依賴。這樣就可以在TableBuilder調用Flush接口時觸發filter builder的創建filter動作，而Flush接口是4KB調用一次。
創建一個新的bloom filter前，檢查之前是否有沒有生成filter的數據。判斷標準是比較上一個block filter的序號和已有 的filter數量。
void BlockBasedFilterBlockBuilder::StartBlock(uint64_t block_offset) {
uint64_t filter_index = (block_offset / kFilterBase);
assert(filter_index >= filter_offsets_.size());
while (filter_index > filter_offsets_.size()) {
GenerateFilter();
}
}
正常情況下，兩者應該相差2。即新來一個data block，一個data block是4KB，除以默認的2KB，即新增2個filter。但是在調用GenerateFilter接口時，并沒有將新的key set分為兩部分，而是在第一次創建filter時為所有新增的key創建了filter，filter_offsets size + 1，這時filter_index比filter_offsets size少1，但是start_和entries_成員已經空了，GenerateFilter再被調用一次，filter_offsets增加一個和前一個一樣的offset值，其他什么都不做。
void BlockBasedFilterBlockBuilder::GenerateFilter() {
const size_t num_entries = start_.size();
if (num_entries == 0) {
// Fast path if there are no keys for this filter
filter_offsets_.push_back(static_cast<uint32_t>(result_.size()));
return;
}
// Make list of keys from flattened key structure
start_.push_back(entries_.size()); // Simplify length computation
tmp_entries_.resize(num_entries);
for (size_t i = 0; i < num_entries; i++) {
const char* base = entries_.data() + start_[i];
size_t length = start_[i + 1] - start_[i];
// 這里只拷貝指針，沒有做字符串的拷貝
tmp_entries_[i] = Slice(base, length);
}
// Generate filter for current set of keys and append to result_.
filter_offsets_.push_back(static_cast<uint32_t>(result_.size()));
policy_->CreateFilter(&tmp_entries_[0], static_cast<int>(num_entries),
&result_);
tmp_entries_.clear();
entries_.clear();
start_.clear();
prev_prefix_start_ = 0;
prev_prefix_size_ = 0;
}
在后面會詳細分析policy_->CreateFilter(&tmp_entries_[0], static_cast<int>(num_entries), &result_);的實現。
- Add
在TableBuilder中，每插入一個key value對，就會將key插入到filter builder中。
然后在Flush時為之前插入的所有key創建filter。
void BlockBasedTableBuilder::Add(const Slice& key, const Slice& value) {
...
// Note: PartitionedFilterBlockBuilder requires key being added to filter
// builder after being added to index builder.
if (r->filter_builder != nullptr) {
r->filter_builder->Add(ExtractUserKey(key));
}
...
}
對于PartitionedFilterBlockBuilder（即我們現在分析的filter builder策略），Add會調用AddPrefix接口來插入key的前綴。
因為entries_是一個字符串類型，所有key插入時都是直接append到字符串末尾，同時用一個vector<int>型的成員變量start_來記錄每個key在entries_中的offset。所以在取下一個key時，要先通過兩個成員變量prev_prefix_start_和prev_prefix_size_來確定下一個key的偏移量。
只有在key的prefix不存在時，才會插入。
inline void BlockBasedFilterBlockBuilder::AddPrefix(const Slice& key) {
// get slice for most recently added entry
Slice prev;
if (prev_prefix_size_ > 0) {
prev = Slice(entries_.data() + prev_prefix_start_, prev_prefix_size_);
}
Slice prefix = prefix_extractor_->Transform(key);
// insert prefix only when it's different from the previous prefix.
if (prev.size() == 0 || prefix != prev) {
start_.push_back(entries_.size());
prev_prefix_start_ = entries_.size();
prev_prefix_size_ = prefix.size();
entries_.append(prefix.data(), prefix.size());
}
}
- Finish
當TableBuilder創建完成后，在TableBuilder的Finish接口中會調用filter builder的Finish接口來將offset數組append到創建的filter結果所存的result_字符串中，然后調用WriteRawBlock寫入到SST文件中。
// 調用的地方
Status BlockBasedTableBuilder::Finish() {
...
// Write filter block
if (ok() && r->filter_builder != nullptr) {
Status s = Status::Incomplete();
while (s.IsIncomplete()) {
Slice filter_content = r->filter_builder->Finish(filter_block_handle, &s);
assert(s.ok() || s.IsIncomplete());
r->props.filter_size += filter_content.size();
WriteRawBlock(filter_content, kNoCompression, &filter_block_handle);
}
}
...
}
用于拼接的Finish方法實現
Slice BlockBasedFilterBlockBuilder::Finish(const BlockHandle& tmp,
Status* status) {
// In this impl we ignore BlockHandle
*status = Status::OK();
if (!start_.empty()) {
GenerateFilter();
}
// Append array of per-filter offsets
const uint32_t array_offset = static_cast<uint32_t>(result_.size());
for (size_t i = 0; i < filter_offsets_.size(); i++) {
PutFixed32(&result_, filter_offsets_[i]);
}
PutFixed32(&result_, array_offset);
result_.push_back(kFilterBaseLg); // Save encoding parameter in result
return Slice(result_);
}
到這里我們看到filter block展開之后的結構如下
[filter 0]
[filter 1]
[filter 2]
...
[filter N-1]
[offset of filter 0] : 4 bytes
[offset of filter 1] : 4 bytes
[offset of filter 2] : 4 bytes
...
[offset of filter N-1] : 4 bytes
[offset of beginning of offset array] : 4 bytes
lg(base) : 1 byte
filter builder通過調用BloomFilterPolicy的CreateFilter接口來創建filter。
CreateFilter的實現包括一下幾步：
- 計算下一個filter占用的位數。為了保證準確率，最小值是64位。
- 確定下一個filter在dst中的起始偏移位置。resize之后，起始偏移位置到dst的末尾，就是一個長度至少為64bit的bit數組。
- 對每一個key，計算得到num_probes_個hash值，對bits取余，然后將對應bit位至1.
這樣就完成了一個filter的創建。
virtual void CreateFilter(const Slice* keys, int n,
std::string* dst) const override {
// Compute bloom filter size (in both bits and bytes)
size_t bits = n * bits_per_key_;
// For small n, we can see a very high false positive rate. Fix it
// by enforcing a minimum bloom filter length.
if (bits < 64) bits = 64;
size_t bytes = (bits + 7) / 8;
bits = bytes * 8;
const size_t init_size = dst->size();
dst->resize(init_size + bytes, 0);
dst->push_back(static_cast<char>(num_probes_)); // Remember # of probes
char* array = &(*dst)[init_size];
for (size_t i = 0; i < (size_t)n; i++) {
// Use double-hashing to generate a sequence of hash values.
// See analysis in [Kirsch,Mitzenmacher 2006].
uint32_t h = hash_func_(keys[i]); // 計算hash 值
const uint32_t delta = (h >> 17) | (h << 15); // Rotate right 17 bits
for (size_t j = 0; j < num_probes_; j++) {
const uint32_t bitpos = h % bits;
array[bitpos/8] |= (1 << (bitpos % 8)); // 將對應bit位標1
h += delta; // 相當于更換hash函數
}
}
}
至此是BloomFilter創建相關流程分析。可以用類似的思路來分析讀流程中，BloomFilter是如何生效的。
小結
BloomFilter標識了某個key是否可能存在對應的SST文件中。BloomFilter對于讀請求的優化效果明顯, 不需要掃描整個SST文件, 因為在打開SST文件時, 會將Bloom Filter加載到內存中, 通過掃描filter即可判斷某個key是否可能存在該SST文件中。
參考資料
https://github.com/facebook/rocksdb/wiki/RocksDB-Bloom-Filter
https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format
