#bloom-filter #filter #bloom

b100m-filter

The fastest bloom filter in Rust. No accuracy compromises. Use any hasher.

5 unstable releases

0.4.0 Mar 5, 2024
0.2.0 Nov 12, 2023
0.1.2 Oct 30, 2023
0.1.1 Oct 30, 2023
0.1.0 Oct 29, 2023

#1216 in Data structures

MIT/Apache

42KB
604 lines

b100m-filter

Crates.io docs.rs License: MIT License: APACHE

This project has been moved to https://crates.io/crates/fastbloom

The fastest bloom filter in Rust. No accuracy compromises. Use any hasher.

Usage

# Cargo.toml
[dependencies]
b100m-filter = "0.4.0"
use b100m_filter::BloomFilter;

let num_blocks = 4; // by default, each block is 512 bits
let values = vec!["42", "🦀"];

let filter = BloomFilter::builder(num_blocks).items(values.iter());
assert!(filter.contains("42"));
assert!(filter.contains("🦀"));
use b100m_filter::BloomFilter;
use ahash::RandomState;

let num_blocks = 4; // by default, each block is 512 bits

let filter = BloomFilter::builder(num_blocks)
    .hasher(RandomState::default())
    .items(["42", "🦀"].iter());

Background

Bloom filters are a space efficient approximate membership set data structure. False positives from contains are possible, but false negatives are not, i.e. contains for all items in the set is guaranteed to return true, while contains for all items not in the set probably return false.

Blocked bloom filters are supported by an underlying bit vector, chunked into 512, 256, 128, or 64 bit "blocks", to track item membership. To insert, a number of bits, based on the item's hash, are set in the underlying bit vector. To check membership, a number of bits, based on the item's hash, are checked in the underlying bit vector.

Once constructed, neither the bloom filter's underlying memory usage nor number of bits per item change.

Implementation

b100m-filter is blazingly fast because it uses L1 cache friendly blocks and efficiently derives many index bits from only one hash per value. Compared to traditional implementations, b100m-filter is 2-5 times faster for small sets of items, and hundreds of times faster for larger item sets. In all cases, b100m-filter maintains competitive false positive rates.

Runtime Performance

Runtime comparison to other bloom filter crates:

  • Bloom memory size = 16Kb
  • 1000 contained items
  • 364 hashes per item
Check Non-Existing (ns) Check Existing (ns)
b100m-filter 16.900 139.62
*fastbloom-rs 35.358 485.81
bloom 66.136 749.27
bloomfilter 68.912 996.56
probabilistic-collections 83.385 974.67

*fastbloom-rs uses XXHash, which is faster than SipHash.

False Positive Performance

b100m-filter does not compromise accuracy. Below is a comparison false positive rate with other bloom filter crates:

bloom-crate-fp

Scaling

b100m-filter scales very well.

As the number of bits and set size increase, traditional bloom filters need to perform more hashes per item to optimize false positive rates. However, b100m-filter's optimal number of hashes is bounded while keeping near zero rates even for many items:

bloom_perf

Bloom filter speed is directly proportional to number of hashes.

References

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Dependencies

~365KB