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
- The Google File System
bigtable turns gfs chunks and replication into a database-shaped storage service
- Cassandra: A Decentralized Structured Storage System
cassandra inherits the wide-column model while rejecting bigtable's centralized tablet management
- Spanner: Google's Globally-Distributed Database
spanner adds global transactions and time semantics to the bigtable lineage