Back to index
Online, asynchronous schema change in F1
Ian Rae, Eric Rollins, Jeff Shute, Sukhdeep Sodhi, and Radek Vingralek.
University of Wisconsin, and Google
Scribe by: Zuyu Zhang
One-line Summary
Overview/Main Points
- Background
- Colossus: the next generation of the Google FS; data replicated within one datacenter
- Spanner: key-value store built upon Colossus; data replicated across multi-datacenters with Paxos for data version consensus
- F1 server built upon Spanner; stateless; fault-tolerant; scalable
- access data on all three levels of the stacks
- Schema change
- Goal: async schema changes without data corruption
- F1 uses a schema to interpret key-value pairs as rows and to translate relational operations into key-value operations.
- Every F1 server has a local cached copy of the schema.
- a series of intermediate states (pair-wise compatible)
- Start
- Delete-only
- Insert-and-Delete-only
- End (enabling reads)
- Schema elements: any part of schema, e.g., tables, columns, constraints, etc.
- Structured elements
- no support of DDL
- CC: change lock coverage
- Constraints changes
- Column type
- Column unique / non-unique
- Foreign key changes
- Adding index may not be treated as a “ physical ” schema changes, but Oracle does.
- three-phase commit
- Goal: avoid blocking introduced in 2pc
- Protocol
- prepare
- pre-commit
- commit
Relevance
Flaws
The graph of three-phase commit credits to Trevor Johns, under the Creative Commons Attribution 3.0 License.