Don't Give Up on Serializability Just Yet
summary
Argues that full serializability is worth keeping until it proves a bottleneck, showing concrete methods that reduce its cost: Google Spanner uses atomic clocks to bound skew, transaction chopping and commutative locking / escrow let many updates proceed without global coordination, and a research system called Doppel exploits commutativity to do per‑core transactions with no cross‑core communication. Cites real failures — simultaneous withdrawals causing negative balances — to show lost guarantees matter; recommends measuring performance before abandoning strong consistency.
AI-written summary · about
chapters (30)
- 0:00Introduction
- 0:55James Mickens
- 2:36Databases
- 3:06Database scalability
- 3:54Distributed databases
- 4:21Horizontal partitioning
- 6:12Distributed database problems
- 7:03Pros of distributed databases
- 8:36MongoDB
- 9:35Jay Recursive
- 9:59Transactions
- 11:17Bitcoin Exchange Loss
- 12:26Consensus Consistency
- 13:31Acid Transactions
- 15:02Serializability
- 15:22Defining Serializability
- 16:17Serializability Example
- 17:24Benefits
- 18:46Eventually Consistency
- 20:38Sequential Consistency
- 21:39Sequential Consistency Example
- 23:00External Consistency
- 24:14Cap Theorem
- 26:33What does this mean
- 27:54Its impossible to 100
- 28:45Consistency vs Performance
- 29:18Types of Research
- 32:29Transaction Execution
- 33:18spanner
- 33:56conclusion
related talks
41mTransactions: myths, surprises and opportunities
41mConcurrency, Scalability and Transactions -- Myths and Surprises
01h 00mDistributed transactions implementation trade-offs
43mBeing Transactional in 2019 — What Does That Actually Mean?
17mJust-Right Consistency
47mBeing transactional in 2019 - what does this actually mean?
22mOrder And Consistency At Scale
45mTransactions and Concurrency Control Patterns