Why architecture matters here
SSTable architecture matters because Cassandra reads depend on it directly. Bloom filters eliminate most SSTable lookups; summary + index skip to relevant offsets; compression keeps disk footprint down. Each file plays a specific role; missing one degrades reads.
Cost is real. Compression saves 3-10x storage. Bloom filter false positive rate affects read amp. Right sizing per column family matters.
Reliability depends on integrity. Digest files catch corruption. Missing summary or filter files degrade to slow paths, not corruption — but you should know when it happens.
The architecture: every file explained
Walk the diagram top to bottom.
MemTable flush. When a MemTable exceeds threshold, it's serialized to disk as a new SSTable. All files below are written together.
SSTable Writer. Iterates the sorted MemTable; writes data + accompanying files in one pass.
Immutable Files. Once written, SSTables never change. Deletes are tombstones inside newer SSTables; updates are newer versions in newer SSTables.
Data.db. The row-oriented sorted data. Compressed in chunks (typically 64KB). Partition contents grouped together.
Index.db. Maps partition key to byte offset in Data.db. Sorted; binary-searchable.
Summary.db. Sparse in-memory index of Index.db (every Nth entry). Lets you binary-search a small in-memory structure then linear-search a small Index.db window.
Filter.db. Bloom filter over partition keys. Says "definitely not here" or "possibly here." Skips SSTables that don't contain the key.
Statistics.db. Min/max cluster keys, cardinality, TTL info. Used by compaction and query planner.
CompressionInfo.db. Offsets of compressed chunks so you can decompress only what you need.
TOC.txt / Digest.crc32. Manifest listing all files in this SSTable; digest for integrity check.
End-to-end read flow
Trace a read. Client asks for partition key "user-42."
Read path scans SSTables on the region. For each SSTable:
1. Bloom filter check: Filter.db says "possibly here" — else skip this SSTable.
2. Summary.db binary search: finds the range in Index.db containing partitions near "user-42."
3. Index.db linear scan within that range: finds exact offset in Data.db.
4. Read Data.db chunk containing that offset. Use CompressionInfo.db to identify which compressed chunk. Decompress.
5. Extract the row data. If tombstoned in a newer SSTable, mark deleted.
Repeat for each SSTable that passed bloom. Merge results across SSTables + MemTable, applying most-recent-wins semantics.
Return.
Well-tuned bloom filter means only 1-3 SSTables actually read data. Well-tuned summary keeps index-search fast. Compression keeps disk IO down.