Skip to main content

Concepts

Wide-column model: tablets, SSTables, and memtable

Intuition

Imagine a secretary who receives messages all day: each message is first copied into a logbook, so it isn't lost, and then placed in the right order on a draft on the desk. When the draft fills up, it is copied clean onto a sorted sheet that goes into the archive and is never scratched out again; a correction or a cancellation becomes just a new message. From time to time, the archived sheets are merged into a few larger sheets, and, to find something, you look at the draft and then at the sheets, from newest to oldest.

How it works

Data is kept sorted by row key, and the row range is partitioned into tablets, the unit of distribution and load balancing; columns are grouped into families, and reads and writes under the same row key are atomic. Every valid write goes first to a commit log, which provides durability and, because it is written sequentially, is cheap to write, and only then is inserted into the memtable, a sorted in-memory buffer. When the memtable reaches a threshold, it is frozen and written to disk as an SSTable, a sorted, immutable file with a key index. A read consults the memtable and the SSTables, from newest to oldest, and a Bloom filter (in Cassandra, one per file; in Bigtable, optional) avoids opening SSTables that do not contain the key. Since each flush creates a new SSTable, background compactions merge files to limit that number, and the major compaction rewrites all of them into one, discarding delete entries and deleted data. Because SSTables are never modified, the memtable is the only mutable structure accessed by reads and writes, which simplifies concurrency control, and, after a failure, the memtable is rebuilt by replaying the log.

In practice

In modeling, the row key is the central decision, since neighboring rows are stored together and define locality and load distribution; the Bigtable paper reverses the URL's hostname so that pages from the same domain are contiguous. Writing only to the sequential log and the memtable makes writes cheap, which suits write-heavy workloads, such as Facebook's Inbox Search, the workload Cassandra was built for and which required billions of writes per day. The price is that a read may need to consult several files, compactions consume background I/O, and atomicity holds within a row, not across different rows.

Use it in a design

Practice the cases that rely on this concept in the System Design school.