Bloomer: Bloom filters with elastic

Build Status

Bloom filters are great for quickly checking to see if a given string has been seen before--in constant time, and using a fixed amount of RAM, as long as you know the expected number of elements up front. If you add more than capacity elements to the filter, accuracy for include? will drop below false_positive_probability.

Scalable Bloom Filters maintain a maximal false_positive_probability by using additional RAM as needed.

Bloomer is a Bloom Filter. Bloomer::Scalable is a Scalable Bloom Filter.

Keep in mind that false positives with Bloom filters are expected, with a specified probability rate. False negatives, however, are not. In other words,

  • if include? returns false, that string has certainly not been added
  • if include? returns true, it might mean that string was added (depending on the false_positive_probability parameter provided to the constructor).

This implementation is unique in that Bloomer

  • supports scalable bloom filters (SBF)
  • uses triple hash chains (see the paper)
  • can marshal state quickly
  • has rigorous tests
  • is pure ruby
  • does not require EM or Redis or something else unrelated to simply implementing a bloom filter

Usage

expected_size = 10_000
false_positive_probability = 0.01
b = Bloomer.new(expected_size, false_positive_probability)
b.add "cat"
b.include? "cat"
#=> true
bf.include? "dog"
#=> false

Scalable Bloom filters uses the same API:

b = Bloomer::Scalable.new
b.add "boom"
b.include? "boom"
#=> true
bf.include? "badda"
#=> false

Serialization is through Marshal:

b = Bloomer.new(10)
b.add("a")
s = Marshal.dump(b)
new_b = Marshal.load(s)
new_b.include? "a"
#=> true

Changelog

0.0.5

  • Switched from rspec to minitest

0.0.4

  • Fixed gem packaging

0.0.3

  • Added support for scalable bloom filters (SBF)

0.0.2

  • Switch to triple-hash chaining (simpler, faster, and better false-positive rate)

0.0.1

  • Bloom, there it is.