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)
    1. Start
    2. Delete-only
    3. Insert-and-Delete-only
    4. End (enabling reads)
  • Schema elements: any part of schema, e.g., tables, columns, constraints, etc.
  • Structured elements
    • Table
    • Column
    • Index
    • Lock
  • 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
    
    1. prepare
    2. pre-commit
    3. commit

Relevance

Flaws

The graph of three-phase commit credits to Trevor Johns, under the Creative Commons Attribution 3.0 License.