Tune bloom filters

To get the observed bloom filters false positive rate and the number of SSTables consulted per read, run nodetool tablestats. For example, the line Bloom filter false positive rate in the output is the bloom filter size in bytes.

A high number of SSTables per read isn’t inherently a problem; some compaction strategies naturally produce many SSTables and can involve many SSTables per read. The problem occurs when bloom filters are producing too many false positives and wasting disk I/O on SSTables that otherwise wouldn’t be read.

The primary way to tune bloom filters is to adjust the rate of false positives with bloom_filter_fp_chance. This value is a decimal from 0 to 1.0 (disabled). Higher values (closer to 1.0) use less memory but produce more false positives, resulting in more disk I/O, especially if SSTables are fragmented. Lower values (closer to 0) use more memory but produce fewer false positives, resulting in less disk I/O overall. Memory savings are nonlinear. For example, increasing the value from 0.01 to 0.1 saves about one third of the memory, not half.

The default value of bloom_filter_fp_chance depends on the compaction strategy. For example, the LeveledCompactionStrategy (LCS) uses a higher default value (0.1) than the SizeTieredCompactionStrategy (STCS) (0.01). This is by design because LCS is meant for fast reads. Although LCS has non-overlapping row key ranges at L1 and higher, which would perform better than STCS even in the absence of bloom filters, tuning the bloom filter false positive rate still helps LCS, particularly when there are many levels.

The ideal value depends on a table’s workloads and compaction strategy. For example, for applications that perform full table scans where bloom filters don’t effectively reduce disk I/O, you might increase the bloom filter false positive chance to save memory. Conversely, workloads that are extremely sensitive to read latency benefit from a lower false positive chance to reduce the number of SSTables that must be consulted during a read.

If you don’t want to use the default value set by a table’s compaction strategy, you can set bloom_filter_fp_chance explicitly when creating or altering a table:

You don’t need to restart DSE after changing bloom filters and rewriting SSTables.

The -Dcassandra.max_bf_memory_mb system property limits the amount of memory used by bloom filters. The default is unlimited. DataStax strongly recommends that you don’t change this parameter because it can be extremely detrimental to read performance.