Skip to content
All papers

Bigtable: A Distributed Storage System for Structured Data

Fay Chang, Jeffrey Dean, Sanjay Ghemawat, et al.2006OSDI 2006

Read it on research.google(opens in a new tab)

Why this one

Read this after The Google File System: Bigtable is what happens when you stop treating GFS as a file store and start building a database-shaped service on top of it. The lasting idea is not “NoSQL is schemaless.” It is that the row key, column families, timestamps, locality groups, and compaction policy are the schema, and if you get them wrong no amount of API cleanliness saves you. People remember Bigtable as a giant sparse map, but the useful lesson is more operational: make distribution, locality, and recovery visible enough that application designers can cooperate with the storage system. This is the ancestor you should know before Cassandra, Dynamo, and Spanner, because each keeps or rejects a different part of this bargain. Worth your evening if you have ever designed a key, regretted it in production, and wondered why the database seemed to be obeying rules you never wrote down.

What to take away

  • A Bigtable row key is both an identifier and a placement strategy, so access patterns belong in the key design.
  • Column families are the real physical schema: they control locality, compression, and read amplification.
  • Tablets, memtables, SSTables, and compaction turn a sparse sorted map into an operable distributed store.

Reads with