bugu

Cuckoo Filter: Practically Better Than Bloom

1 unstable release

0.5.0 Jun 17, 2024

#835 in Algorithms

Download history 31/week @ 2024-08-05 23/week @ 2024-08-12 23/week @ 2024-08-19 29/week @ 2024-08-26 31/week @ 2024-09-02 10/week @ 2024-09-09 29/week @ 2024-09-16 40/week @ 2024-09-23 39/week @ 2024-09-30 34/week @ 2024-10-07

142 downloads per month

MIT license

21KB
337 lines

bugu

Cargo Documentation

An implementation of Cuckoo filter in Rust.

Cuckoo filter is a Bloom filter replacement for approximated set-membership queries. While Bloom filters are well-known space-efficient data structures to serve queries like "if item x is in a set?", they do not support deletion. Their variances to enable deletion (like counting Bloom filters) usually require much more space.

Cuckoo filters provide the flexibility to add and remove items dynamically. A cuckoo filter is based on cuckoo hashing (and therefore named as cuckoo filter). It is essentially a cuckoo hash table storing each key's fingerprint. Cuckoo hash tables can be highly compact, thus a cuckoo filter could use less space than conventional Bloom filters, for applications that require low false positive rates (< 3%).

For details about the algorithm and citations please use this article for now

"Cuckoo Filter: Better Than Bloom" by Bin Fan, Dave Andersen and Michael Kaminsky

Example usage

use bugu::CuckooFilter;

let value: &str = "hello world";

// Create cuckoo filter with default max capacity of 1000000 items
let mut cf = CuckooFilter::new();

// Add data to the filter
let success = cf.add(value).unwrap();
// success ==> Ok(())

// Lookup if data is in the filter
let success = cf.contains(value);
// success ==> true

// Test and add to the filter (if data does not exists then add)
let success = cf.test_and_add(value).unwrap();
// success ==> Ok(false)

// Remove data from the filter.
let success = cf.delete(value);
// success ==> true

Notes & TODOs

  • This implementation uses a a static bucket size of 4 fingerprints and a fingerprint size of 1 byte based on my understanding of an optimal bucket/fingerprint/size ratio from the aforementioned paper.
  • When the filter returns NotEnoughSpace, the element given is actually added to the filter, but some random other element gets removed. This could be improved by implementing a single-item eviction cache for that removed item.

Dependencies

~0.3–1MB
~12K SLoC