All the time - [1]/[2] When you are going to fetch data from a remote location, you don't want to make a trip in vain. So you end up storing them as a fixed s

All the time - [1]/[2] When you are going to fetch data from a remote location, you don't want to make a trip in vain. So you end up storing them as a fixed size metadata chunk that lets you guess whether to go fetch it or not. The neat trick is that the bloom filters have no false-negatives - the data might not exist (false positives), but it will never say "no" if it does exist. But unfortunately, it doesn't really support deletion neatly - so it's really useful for scenarios where it's a first point of lookup before overloading a central source-of-truth. The best use case I've seen for it is in Chrome, where the "Safe browsing" list is actually a huge bloom filter, which is used to decide whether to ask Google if this domain is safe. So the list of banned URLs might be in the millions, but the bloom filter is a few megabytes and when it has a false positive, it goes & checks upstream whether it is indeed still banned/problematic. [1] - http://www.slideshare.net/Hadoop_Summit/orc-2015-faster-better-smaller/22 http://www.slideshare.net/Hadoop_Summit/orc-2015-faster-bett... [2] - https://issues.apache.org/jira/browse/HIVE-11306 https://issues.apache.org/jira/browse/HIVE-11306