Reading path

Before detailing the cache working, we have to dig in reading path :
First, two drawing (from datastax website) to represent it :








Cassandra read path 1
Cassandra read path (with row cache enabled)
Cassandra read path 2
Cassandra read path

So what I understand :
  1. Checks if the in-memory memtable cache still contain the data (if it is not yet flushed to SSTable)
  2. If enabled, row cache
  3. BloomFilter (for each SSTable)
  4. Key cache
  5. Partition Summary
  6. SSTables
A generic diagram that (I hope) summarize !








Cassandra read path diagram
Cassandra read path diagram

A little vocabulary

SSTable

SSTables are immutable, not written to again after the memtable is flushed. Thus, a partition is typically stored across multiple SSTable files.
For each SSTables, cassandra create one Partition Index, Partition Summary and BloomFilter

Memtable

When a write occurs, Cassandra stores the data in a structure in memory, the memtable, and also appends writes to the commit log on disk. The memtable stores writes until reaching a limit, and then is flushed.
Cassandra flushes memtables to disk, creating SSTables when the commit log space threshold has been exceeded

Partition Index :

A list of primary keys and the start position of data

Partition summary

A subset of the partition index (in memory). By default, 1 partition key out of every 128 is sampled.

Caches

Row cache :

The row cache is similar to a traditional cache like memcached. When a row is accessed, the entire row is pulled into memory, merging from multiple SSTables if necessary, and cached, so that further reads against that row can be satisfied without hitting disk at all.
While storing the row cache off-heap, Cassandra has to deserialize a partition into heap to read from it, so we have to take care about partition size.
The row cache is not write-through. If a write comes in for the row, the cache for it is invalidated and is not be cached again until it is read again.