Apache Cassandra

Performance Tuning: Bloom Filters, Key Cache & Row Cache

Understand the caching and probabilistic data structures Cassandra uses to accelerate reads, and how to tune them.

Cassandra employs several layers of caching and probabilistic data structures to minimize disk I/O on the read path, since a naive implementation would need to check every SSTable for every read.

The bloom filter is like a quick 'definitely not here' checklist you glance at before searching a filing cabinet, saving you from opening cabinets that certainly don't have what you need. The key cache is like remembering exactly which drawer and folder a frequently requested document lives in. The row cache is like keeping photocopies of your most-requested documents right on your desk so you never need to visit the cabinet at all — until someone updates that document, at which point your desk copy becomes stale and must be discarded.

Key Concepts

1
Bloom filters are a space-efficient probabilistic data structure maintained per SSTable that can definitively say "this partition is NOT in this SSTable" (no false negatives) but may occasionally produce false positives (saying a partition might be present when it isn't). This lets reads skip SSTables that certainly don't contain the requested data, dramatically reducing unnecessary disk reads at a very low memory cost. The bloom_filter_fp_chance table setting controls the trade-off between bloom filter memory usage and false-positive rate.
Bloom filtersbloom_filter_fp_chance
2
The key cache stores the location (offset) of frequently accessed partition keys within their SSTable files, avoiding the need to consult the partition index on disk repeatedly for hot partitions — a relatively small, high-value cache since it stores only offsets, not actual data.
key cache
3
The row cache goes further, caching entire hot rows in memory, which can dramatically speed up reads for a small set of very frequently accessed rows, but consumes significantly more memory per cached item and can be counterproductive for workloads with large rows or low cache hit rates, since it's invalidated on any write to a cached row.
row cache
4
Tuning these layers appropriately based on workload characteristics (read/write ratio, hot key skew, row sizes) is a key advanced performance topic in Cassandra operations.