Google Bigtable
The original wide-column store: tablets on a distributed lattice, the paper behind HBase and Cassandra.
Bigtable is Google wide-column storage system: rows sorted by key, split into tablets served by a single tablet server each, persisted into the SSTable file format, and coordinated through Chubby. Its 2006 paper defined the wide-column family — HBase and Cassandra are direct descendants of this design.
Tablets, one server each
Rows are lexicographically sorted and split into tablets; each tablet is served by exactly one tablet server at a time — simple single-writer ordering per tablet.
Column families
Columns group into families with one SSTable per family per tablet — access control and storage tuning happen at family granularity.
Timestamped cells
Every cell stores multiple versions keyed by timestamp; collection policies garbage-collect old versions automatically — the birthplace of "everything has a timestamp" storage.
SSTable + memtable
Writes log to a tablet log then land in a memtable; flushes produce immutable SSTables; merges compact them — the LSM shape, named here first.
The paper that defined wide-column
The 2006 Bigtable paper introduced the vocabulary the whole NoSQL family inherited: row keys sorted lexicographically, column families as storage and access units, timestamped cells, tablets as distribution units, SSTables as the file format, and a memtable in front.
Rows sharing a key prefix live contiguously — locality groups let you group hot families together. The data model is deliberately sparse: rows with no data for a family store nothing for it.
Row key: "com.cnn.www"
Families: contents: , anchor: (sparse)
cells: contents:html @ t3, anchor:CNN.com @ t9, ...
From paper to products
HBase replicated the design on Hadoop; Cassandra recombined Bigtable data model with Dynamo replication; Google Cloud Bigtable is the managed version of the original. Reading this exhibit explains all three.
Single-tablet-single-server keeps ordering simple: cross-tablet transactions do not exist in the base design. The commit path per tablet is the classic LSM loop — log, memtable, flush, merge.
Diagrams
[caption] The original LSM write loop — named in this paper.
Each tablet server keeps a commit log and memtable per tablet; flushes write SSTables per column family; MergingCompaction folds them.
Tablets migrate between servers for load balance; the metadata layer (originally in Chubby) tracks placement.
[caption] Illustrative tablet counts for a mid-size cluster — placement is metadata, data is SSTables.
Tablets migrate between servers for load balance; the metadata layer (originally in Chubby) tracks placement.