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 меняются; выбирать их нужно по официальной документации и нагрузочному тесту.

Связанные материалы

Официальные и первичные источники

1. Google Cloud Spanner: Transactions overview
2. Google Cloud Spanner: TrueTime and external consistency
3. Google Cloud Spanner: Instance configurations
4. Google Cloud Spanner: Schema design best practices
5. Corbett et al., Spanner: Google’s Globally-Distributed Database