System Design Cases
Google Spanner
Google Spanner concept page. Globally-distributed SQL database with external consistency via TrueTime API (GPS+atomic clocks). 3 regions (us-central1 leader, europe-west1 replica, asia-northeast1 replica), each with TrueTime time service. Per-shard Paxos groups (Shard A, Shard B), 2PC across shards. Clients hit shard leaders. 4 scenarios: single-shard RW txn with Paxos+commit-wait, cross-shard 2PC, lock-free read-only at snapshot, TrueTime uncertainty spike (GPS antenna fail). 2 ADRs: (1) TrueTime as foundation for external consistency vs HLC alternative, (2) when Spanner is justified vs cheaper alternatives.
Google Cloud Spanner: transactions, TrueTime, and replicated splits
Spanner is a synchronously replicated, multi-version distributed relational database. Read-write transactions at the default serializable isolation are externally consistent. Read-only transactions read one consistent timestamp without locks or a commit operation; they are not read-write commits with a hidden commit-wait.
Write latency depends on client placement, leader placement, replica configuration, contention, TrueTime uncertainty, and the number of participating splits. A multi-region topology cannot honestly promise a fixed 10–15 ms intercontinental write latency.
Модель и предпосылки
- A split has a leader and voting replicas; read-write work is routed to leaders and must satisfy the configured replication quorum.
- A transaction spanning splits needs distributed coordination; a single-split transaction avoids that extra communication.
- TrueTime exposes an uncertainty interval. Commit-wait is part of externally consistent read-write commit; read-only transactions select a timestamp and do not commit.
Проверяемые утверждения
- C1. Default serializable read-write transactions are externally consistent and may abort; applications must retry the transaction body.
- C2. Read-only transactions perform all reads at one timestamp, hold no locks, and have no commit operation.
- C3. Multi-region writes communicate with a quorum across regions; leader and client placement materially affect write latency.
- C4. Monotonically increasing leading primary-key parts can hotspot a split; key choice and measured load distribution matter.
- C5. Read-write work across multiple splits costs more communication than equivalent single-split work.
Исполняемые сценарии
Single-split read-write transaction. A short read-write transaction reaches one leader, a replication quorum, and commit-wait before success.
Cross-split distributed transaction. The coordinator involves every participant and retries the whole transaction after an abort.
Lock-free read-only snapshot. Several reads use one chosen timestamp; there is no commit request and no read-write commit-wait.
Leader distance and key hotspot. Remote routing and a monotonic key can add latency or concentrate load; neither is a fixed service constant.
Ошибки проектирования
- Не переносите regional latency в multi-region и не обещайте одинаковую latency из любой точки мира.
- Не называйте read-only transaction commit: она выбирает timestamp, выполняет reads и завершается без commit.
- Не смешивайте TrueTime с perfect clock; API показывает ограниченную, но ненулевую неопределённость.
- Не используйте монотонный первый key component для интенсивной вставки без проверки hotspot и schema alternatives.
Границы гарантии
- External consistency относится к committed database transactions, а не к exactly-once внешних API или очередей.
- Spanner transaction ограничена одной database; внешние системы не становятся её участниками автоматически.
- Текущие сервисные edition, configuration и performance guidance меняются; выбирать их нужно по официальной документации и нагрузочному тесту.