# Trying (and failing?) to build a Scalable CountMin Sketch

(or, What I Did For One Day Of My Summer Vacation.)

tl;dr? I played around with building a CountMin Sketch that is dynamic in size, based on a scalable Bloom Filter approach. I'm not sure it worked. Thoughts, suggestions, help?

## Bloom Filters

In our research, we've made some hay using Bloom filters. They're remarkably easy to implement; I've talked about them a couple of times on my blog -- take a look at my PyCon 2013 talk, for example -- but it's almost easiest to just introduce them with pseudocode.

Bloom filters are data structure that allow presence/absence queries; they implement two functions, add(obj) and query(obj), that respectively let you add an object into the filter and query for the presence of an object. Here's a simple Python implementation of a sliced Bloom filter:

```N = ...           # a number >= 1, and not that big
primes = [ ... ]  # N prime numbers

filters = []
for i in range(N):   # create N arrays of [0], each w/a prime # of entries
filters.append([0] * primes[i])

h = hash(obj)
for i, filter in enumerate(filters):

def query(obj):
h = hash(obj)
for i, filter in enumerate(filters):
return False

return True
```

Essentially you're recording the presence of objects by flipping N bits to 1 for each object, and upon a query, examining the bits that would have been flipped to 1 to see to see if they are all actually 1. If they are, you cry huzzah, and say that the object is there; if they aren't, you know that the object isn't there.

The main thing to understand about Bloom filters is that they are probabilistic. There's some probability that when you query for the presence of a particular object, you return a "True" even when the object isn't there. This happens when all of the bits that correspond to a particular object are set because they belong to other objects that have been inserted. However, this error is one-sided -- you never falsely claim that an object isn't present, just (sometimes) that it is. The error rate depends on the size of the Bloom filter and how many objects you stick in it, and it is fairly straightforward to calculate (see our khmer-counting paper for some references).

Bloom filters are also tricky because they are constant in size. In the construction above, you specify the total size of the Bloom filters as the sum of the prime numbers, and you cannot increase its size without re-creating it and re-adding all of the objects. In some situations this is ideal: Bloom filters never increase in size, so you never run out of memory when inserting elements. However, in situations where you don't know how many elements you have, you may want to be able to increase the size.

Enter... scalable bloom filters!

## Scalable Bloom filters

Scalable Bloom filters are one of a near-infinite set of Bloom filter derivatives and extensions. The main thing that scalable Bloom filters provide is dynamic scaling: they let you make use of the (super efficient) Bloom filter storage without fixing memory usage a priori.

(See Jay Baird's excellent python-bloomfilter project for the implementation of the scalable Bloom filter that made me first understand how they worked.)

They do this in a brilliantly simple way, using Bloom filters as a building block. Essentially you maintain a list of Bloom filters:

```blooms = [ BloomFilter(size0) ]
```

and then the 'add' operation checks to see if the element is already present in one of the Bloom filters already in the list, and if not, adds it to the last one:

```def add(obj):
for b in reversed(blooms):
if b.query(obj):
return

b = blooms[-1]
if b.is_at_capacity():
b = BloomFilter(sizeN)
blooms.append(b)

```

The query then looks for the element in each of the Bloom filters:

```def query(obj):
for b in reversed(blooms):
if b.query(obj):
return True
return False
```

The important bit here is the 'if b.is_at_capacity()' condition. What the scalable Bloom filter does is successively allocate and fill new Bloom filter tables as old ones fill up. This means that the overall memory consumption goes up as new objects arrive.

There are some tricks needed to make this work -- you need to define the progression in table sizes as you load in more elements, and you need to ratchet down the false positive rate of later tables so as to maintain an overall acceptable false positive rate -- but it's very easy to implement a dynamically scaling Bloom filter.

The scalable version is not quite as efficient as the static Bloom filter; if you look at figure 2 in the SBF paper you'll see that depending on the parameters, you can get between 1.5 and 4x loss in memory efficiency over a static filter, depending on the desired performance.

## The CountMin Sketch

Imagine that instead of mere element presence/absence you want to get the frequency distribution of elements -- how many elements show up once, or twice, or 50 times? You can modify the Bloom filter to keep totals, like so:

```N = ...           # a number >= 1, and not that big
primes = [ ... ]  # N prime numbers

filters = []
for i in range(N):   # create N arrays of [0], each w/a prime # of entries
filters.append([0] * primes[i])

h = hash(obj)
for i, filter in enumerate(filters):
filter[address] += 1           # changed to increment @ each location

def query(obj):
h = hash(obj)
count = 0
for i, filter in enumerate(filters):  # changed to take min across all

return min
```

The behavior of this is similar to the Bloom filter: fixed size, some probability that you have an overcount, but very memory efficient for keeping track of counts. (See the khmer counting paper for our exploration of this in relation to sequence analysis.)

## Can we build a scalable CountMin Sketch?

For several Reasons, we'd really like to have a CountMin Sketch that behaved like a scalable Bloom filter: dynamic size, but still memory efficient. (I also like the simplicity of the scalable Bloom filter -- there are other memory-efficient data structures, but they all look difficult to implement, which means I'd have to spend a lot of time debugging them.) Since the scalable Bloom filter is based on, basically, a bunch of Bloom filters -- why not use the same idea with a CountMin Sketch? What happens if we extend the concept of the scalable Bloom filter to build on a CountMin Sketch?

Conveniently, we already have a good-performing implementation of a CountMin Sketch in the khmer project (implemented in counting.cc and counting.hh). And as we saw above, it's pretty easy to implement a scalable Bloom filter. So... voila! I implemented a simple scalable CountMin Sketch data structure.

### Testing it out

To evaluate this scalable CMS, I wrote a little bit of test code (at the bottom of the file). The __main__ block of our scalable_cms.py creates a counter, and then adds 10,000 random objects to it (in this case, k-mers -- but it doesn't really matter). Then it outputs the counts of each of the things it added, to check for accuracy. Here's the output:

```Creating new ScalableCounter: growth rate 2, error ratio 0.50, bound 0.100
added new table of size 512/capacity 427 (now 1 tables total)
last table is full! 427 counts, FP rate 0.093
added new table of size 1024/capacity 656 (now 2 tables total)
last table is full! 656 counts, FP rate 0.057
added new table of size 2048/capacity 1066 (now 3 tables total)
last table is full! 1066 counts, FP rate 0.025
added new table of size 4096/capacity 1796 (now 4 tables total)
last table is full! 1796 counts, FP rate 0.016
added new table of size 8192/capacity 3102 (now 5 tables total)
last table is full! 3102 counts, FP rate 0.010
added new table of size 16384/capacity 5458 (now 6 tables total)
TCCTATACATTCGCAGATTG 5
GAAATCTGAGCGCACGTCCA 3
TGCTAGGTTAATGATGTGAA 1
GCGGCGGTACCTCCGATAGC 2
ACATTCTCCTCCACCCTGCT 4
AGTGGAAGAGCCTCCGATTG 3
ATACGCGCGTTGTCATACGT 3
TGGCTAGGCTTTTTCCCACG 1
GGCTTCACCGGGGCGTTACA 4
GGTCGGACTATCCTGTGGAA 1
total memory used: 129.6k
average miscount: 0.4294
```

You can see a couple of things going on here.

First, note that things proceed as expected. As we add more counts, the last table saturates, and then we add a new one that's bigger. Huzzah!

Second, the parameters: the growth rate ('s' in the scalable Bloom filter paper) is the rate at which we grow the size of each additional table, while the tightening ratio ('r' in the paper) is related to the factor by which we clamp down on the allowable error in each successive table. You can see the effects of the growth rate and tightening ratio by looking at the sizes of each successive table (512, then 1024, then 2048...) and the capacity for each table (427 for the first, 656 for the second, 1066 for the third...)

Third, the counts. I output the average miscount and the counts of the first 10 things added to the table. The average miscount (the average number by which we're off from the true count) is 0.0! But... if we're adding each random k-mer once, the counts should all be one. Why do we have so many counts that are higher than one?

### Ruh-roh

It took me a long time to figure this out, but it spells doom for this idea, at least without modification.

First, let me show you the output if I choose objects at random, rather than in the order I added them:

```Creating new ScalableCounter: growth rate 2, error ratio 0.50, bound 0.100
...
shuffling items
TCAGAGCTCAACTTATCCCA 1
GTGGGGCTATAATTCTCGCG 1
AACGCTTGCAAGGTAAGAGT 1
CTAGTAGACTAGACCTGGCA 1
GACTCATCTGACCTTGAAGG 2
AGCCGCTGGGTCACTTTCAG 2
GTATCAGTAGGTCCCCAACA 3
AGGGCGCTCCTATACGTCGA 2
TGCCGACGAGATCACCTCGA 1
CGGCAAGATTAGCATCCGTT 1
total memory used: 129.6k
average miscount: 0.4313
```

Looks a little better, eh? But the total miscount isn't any different... Why?

Basically what's going on is this: the first table is consulted for every new object we add, and it has a certain false positive rate at which it falsely answers "yes, we've seen this before" and increments the associated counts. For the scalable Bloom filter, this doesn't cause any problems: the false positive rate is still the same, but all we're doing is indicating presence and absence. For the CountMin Sketch, however, we're incrementing the counters when there's a false positive -- and since the early tables get consulted a lot more frequently than the later tables, they have a lot more false positive matches, and get incremented a lot more. This results in a systematically higher miscount for the frequency of objects added earlier vs later.

DOOOOOOM. I can imagine situations where this might not matter that much but I think it does matter for our purposes in khmer, where a bias towards higher counts in the early objects added would be Bad.

I played around with a few ideas. One idea is to adjust the counts in the early tables based on the number of total objects added to the counter; this could be done either by tweaking the actual counts, or adding in per-table weights that are adjusted with each increment. Another idea is to decrement counters in the tables at random as we increment new counters. A third idea (that I haven't actually tested yet) was to move heavy hitters from early tables to later tables, by decrementing all their counts in the early table and then adding them in to the later table. Any or all of these might work, but require further research and probably some Math.

You can actually do some good by setting the total error bound to something smaller:

```Creating new ScalableCounter: growth rate 2, error ratio 0.50, bound 0.010
...
total memory used: 260.7k
average miscount: 0.0417
```

but the memory required doubles, and -- of even more concern -- the fundamental problem is still there: if we add an infinite number of objects, the counts in the early tables will be infinitely wrong. So we need an approach that's sustainable in theory, too.

## What's next?

From a skim of this review, I plan to look at decaying Bloom Filters, dynamic Bloom filters, and retouched Bloom filters next.

## Help?

I would, at this point, love some help :).

First, if the problem above has been solved already, then great! I'd love references. If you're working in this area and want to tackle it, please let me know; I'd love to either collaborate or make use of your work.

Second, if there are good implementations of scalable and memory-efficient probabilistic counting data structures, I'd love to know. We're already looking at Google's sparsehash for exact storage, but I think we can probably get 10x or more improved memory usage out of a probabilistic solution (see the diginorm discussion in khmer-counting for reasons why.) Note, it needs to be BSD-license-compatible before we can include it in khmer, which prevents us from using several of the published k-mer counting solutions :(.

--titus

p.s. Note that bitly's dablooms takes a similar approach, and may be subject to the same problem.

p.p.s. Thanks to Sherine Awad, Qingpeng Zhang, and Charles Ofria for pre-posting discussions!