Reviewing LevelDB: Part VII - Filters?

i was all set to finish this series, when i realized that i missed something important, i didn’t covered, and indeed, i don’t currently understand, what filters are, and how are they used.

as usual, once i actually got to the part of the code where this is actually handled (instead of ignoring it), it made a lot more sense:

and that, following with the rest of the code that i read makes a lot more sense.

a sst is a sorted table, essentially. we have the keys and the blocks, etc. and we can find a value very quickly. but what if you could do this even more cheaply?

using a bloom filter is a good way to never get false negative, and it will reduce the amount of work we have to do if we can’t find the key in the sst drastically (only need to read the filter value, don’t even need to do any additional checks). quite elegant, even if i say so myself.

there is one thing to pay attention to and that is that you can define your own comparator, in which case you must also define you own filter policy. if you use a comparator that ignore casing, you also need to provider a filter that ignore casing.