教學路線：全球強一致與 TrueTime 成本

Spanner 服務頁的教學目標是把 global strong consistency、TrueTime、Paxos、region layout 與 processing unit 連成一條產品決策線。讀者讀完後要能判斷何時需要全球一致 SQL，並理解這種能力的 latency、成本與雲平台邊界。

定位：TrueTime + Paxos 的全球線性 SQL

Spanner 解決的是跨地理位置同時追求 strong consistency、linear scalability 與 global availability 的 OLTP 問題。

關鍵設計：

• TrueTime API：用 GPS + 原子鐘提供「全球 unambiguous 時間戳」、誤差 < 7ms
• External consistency（線性化）：跨節點交易順序跟 wall clock 一致
• Paxos-based replication：跨 zone / region quorum
• 線性擴展：2 nodes → 45K reads/sec、4 nodes → 90K reads/sec、依此類推

容量特性（引自 9.C10 Spanner 案例）：

• 內部峰值：> 10 億 requests / sec
• 線性擴展（不像 USL 系統會在某點 plateau）
• 跨 region quorum 延遲：50-200ms（視 region 距離）
• 最小容量單位：100 processing units（PU）≈ 1/10 node、適合小負載

適用場景

1. 金融交易、ticketing inventory、payment ledger：

• 需要強一致，避免 double-spend、oversell 或帳務順序錯亂
• 全球用戶但需要原子性
• 對應案例：9.C10 Spanner — Google Ads 計費與 Google Play 訂閱都需要把每次計費事件放進可驗證順序

2. 全球用戶的 OLTP（不只 read replica）：

• 跨 region 寫入、各地用戶寫入本地 region 仍維持全球強一致
• 它承擔的是 multi-region write path，而非 single primary + 跨 region read replica
• 對應案例：Blockchain.com（高頻 crypto 交易、強一致）

3. 想擺脫 sharding 複雜度：

• 傳統大規模 SQL 常走應用層 sharding（管 shard key、跨 shard query、resharding）
• Spanner 自動 partition，application 主要管理 schema、query shape 與 region layout
• 對應案例：9.C10 Spanner 案例 — 「節點數量是容量單位」，shard placement 由 Spanner 管理

4. PostgreSQL 相容路徑：

• 2024 後 Spanner 提供 PostgreSQL dialect interface
• 從 PostgreSQL 應用遷入 Spanner 變得容易
• 跟 CockroachDB / Aurora DSQL 類似的策略

不適用場景

1. 跨洲低延遲（< 50ms）需求：

• 跨洲 quorum 物理上 100ms+ 不可壓縮
• 替代：single-region OLTP（Aurora、Cloud SQL）+ eventual consistency 跨 region 同步

2. 高 throughput 但容忍 eventual consistency：

• Spanner 強一致有溢價，eventual consistency workload 通常有更低成本選項
• 替代：Bigtable（wide-column、eventual）、DynamoDB Global Tables（KV、eventual）

3. 小規模 OLTP：

• 100 PU 起跳、月費約 $65 起、比 Cloud SQL 貴
• 流量 < 1000 RPS 的場景、Cloud SQL 更划算
• Spanner 主要對 中大規模 + 全球 workload

4. 跨雲需求：

• Spanner 是 GCP managed service，cross-cloud / on-prem 需求要看 CockroachDB、TiDB 或其他自管路線
• 替代：CockroachDB、TiDB（自管、可跨雲）

5. 需要 OLAP 分析能力：

• Spanner 定位在 OLTP，analytics workload 交給 BigQuery 或其他 OLAP 系統
• 替代：跟 BigQuery 整合做 ETL、或用 Spanner Graph（2024 推出）

跟其他 vendor 的取捨

vs Aurora DSQL（AWS 2024 推出、概念對標 Spanner）：

• Spanner：用 TrueTime hardware、生產驗證 17 年（Google 內部）+ 7 年（公開）
• Aurora DSQL：新（2024）、PostgreSQL 相容、serverless
• 選 Spanner：GCP 生態、需要極致成熟度
• 選 Aurora DSQL：AWS 生態、需要 PostgreSQL ORM 相容

vs CockroachDB：

• Spanner：managed、TrueTime hardware、GCP 限定
• CockroachDB：自管、HLC + Raft（不靠 TrueTime）、跨雲
• 選 Spanner：想把 operation 交給 GCP managed service，並需要 Google 規模驗證
• 選 CockroachDB：跨雲 / on-prem、PostgreSQL 相容、自管彈性

vs TiDB：

• Spanner：GCP-only、PostgreSQL-like
• TiDB：可自管 + Cloud、MySQL 相容、中國 / 亞洲生態深
• 選 Spanner：英語 / 歐美生態
• 選 TiDB：MySQL 應用、亞洲市場

vs Aurora（traditional single-region scaling）：

• Spanner：全球分散式
• Aurora：single-region scaling
• 選 Spanner：流量明確跨 region + 需要強一致
• 選 Aurora：流量集中一個 region（多數情況）

vs Cosmos DB（multi-region write）：

• Spanner：strong consistency 跨 region
• Cosmos DB：5 個 consistency levels、AP 系統（含 strong 但語義不同）
• 選 Spanner：需要 linearizable（金融、ticketing）
• 選 Cosmos DB：可接受 session / eventual、Azure 生態、需要 multi-model

vs Bigtable：

• Spanner：SQL、強一致、OLTP
• Bigtable：wide-column、eventual replication、時序 / IoT / 大資料
• 兩者互補：Bigtable 承擔大資料 / wide-column，Spanner 承擔強一致 OLTP

vs PostgreSQL（baseline）：

• PostgreSQL：single-primary、跨 region async replication、90% 場景夠用
• Spanner：全球線性化、強一致跨 region、需要 GCP + 接受 latency / 成本
• 從 PostgreSQL 升級 Spanner 的判準：流量明確跨 region，且跨 region 一致性是 product requirement
• 詳見 PostgreSQL vendor page 取捨段 + 1.11 全球分散式 OLTP

容量規劃要點

從 09 案例庫 + Spanner 文件提煉：

1. 節點數量 = 容量單位：

• 節點配置通常用較長週期 review，並在事件高峰前預先調整
• 線性擴展讓 forecast 簡單（2x 流量 → 2x 節點）
• 對應 9.6 容量規劃模型 的「不可水平擴容服務」反向 — Spanner 是 可水平擴容 但需要 提前 provision

2. 跨 region quorum 配置：

• multi-region instance 可選擇哪些 region 是 voting member
• voting region 數量決定 failure domain
• 跨大洲 voting 延遲高、跨大陸內可接受

3. 100 PU 起跳的 granular sizing：

• 早期 Spanner 最小單位 1 node（約 $1000+/month）、中小負載難用
• 後來推出 100 PU（1/10 node、約 $65/month）、讓小負載也能 evaluate

4. 跨環境與新產品能力要查官方文件：

• Spanner 的跨環境、graph、PostgreSQL dialect 與 change streams 能力持續演進
• 實作前要用官方文件確認可用 region、版本、限制與 pricing

5. TrueTime 是 Spanner 價值之一：

• Spanner 還有 schema migration without downtime、change streams、interleaved tables
• 評估 Spanner 要同時看跨 region 強一致與整體 SQL 工程能力

Deep article（已完成）

本批 4 篇 deep article 已完成、覆蓋 Spanner 從 TrueTime 到 Cloud SQL 遷移的核心 production 議題：

DB4 cross-vendor entry：先看 CockroachDB / Aurora DSQL / Spanner 決策樹 識別 driver path、再進本 vendor 深度。

後續擴充（仍待補）

• Spanner Graph 進階查詢 lab（GQL pattern、super node 處理、遍歷效能調校）
• Data Boost 容量規劃與成本模型 deep dive
• Change Streams → Dataflow hands-on lab（建 stream、部署 pipeline、驗證 end-to-end）
• Spanner regional → multi-region topology 升級 playbook

Anti-recommendation 與升級路由

Spanner 的 global strong consistency 是高價值能力，也會把 latency、region layout 與 GCP lock-in 帶進核心架構。這一段先說何時維持 Cloud SQL / Aurora，再說何時升級 Spanner、CockroachDB、Aurora DSQL 或 Bigtable / DynamoDB。

Spanner 的簡單路徑是先證明跨 region 一致性是產品需求。若只是想要全球 read latency，read replica、cache、edge KV 或 eventual consistency pipeline 可能更划算；Spanner 適合把「全球寫入順序正確」視為產品承諾的資料。

Region layout 的升級路徑要先定義 leader、voting replica 與使用者地理分布。跨洲 quorum 會把物理延遲放進 transaction path，因此 latency budget、降級策略與 read staleness policy 要一起寫進設計。

已知 limitation 與後續路由

Spanner overview 目前完成 global SQL 判斷。下一輪 deep article / playbook 應補 TrueTime、external consistency、PostgreSQL dialect、interleaved tables、change streams、Cloud SQL / PostgreSQL → Spanner migration 與 Spanner / BigQuery federation。

案例對照

Spanner case 的讀法是先看一致性需求，再看容量數字。10 億 req/sec 證明它能水平擴展，但讀者真正要回收的是「計費、訂閱、庫存、交易順序」這類需要 global external consistency 的產品壓力。

反向 sibling 路由

Spanner 的反向 sibling 路由用來把 global strong consistency 和雲端代管責任一起判讀。若讀者從 PostgreSQL / MySQL 過來，先確認是否具產品契約等級的 external consistency 需求；若只是 managed SQL 與 replica scaling，回 Aurora vendor；若要 PostgreSQL-like distributed SQL 且需要自管或多雲彈性，對照 CockroachDB vendor；若 access pattern 是固定 KV / document，先看 DynamoDB vendor 或 Cosmos DB vendor。

這條路由的判準是交易順序是否跨 region 影響產品正確性。Spanner 的價值在 external consistency、schema 與 SQL 能力、全球 deployment 與 Google Cloud operation model 的組合；若產品只需要 eventual / session consistency，較輕的 NoSQL 或 managed SQL 常有更低成本。

常見陷阱

• 誤以為跨 region 強一致沒有延遲代價：跨洲 quorum 100-200ms 是物理成本
• 設計 schema 像傳統 PostgreSQL：Spanner 有 interleaved tables、適當用能加速查詢
• 所有讀取都用強一致：read-only transaction 可選 bounded staleness，reporting 類路徑常能用 stale read 換較低成本
• 單 region 用 Spanner：浪費、Cloud SQL / Aurora 更便宜
• 不評估 100 PU 起跳：早年 1 node minimum、現在 100 PU 起、small workload 也可以 POC

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Aurora vendor、DynamoDB vendor、CockroachDB vendor
• 上游：1.11 全球分散式 OLTP
• 跨模組：9.6 容量規劃模型 — 全球 OLTP 的容量規劃特殊性
• Last reviewed：2026-05-22（processing units / PostgreSQL interface / TrueTime 文件屬時間敏感 claim）
• 官方：Cloud Spanner、TrueTime: Time Distributed in Spanner

教學路線：Multi-model API 與全球寫入

Cosmos DB 服務頁的教學目標是把 API model、consistency level、RU/s、logical partition 與 multi-region write 放在同一個 Azure 服務決策中。讀者讀完後要能判斷 Cosmos DB 是遷移相容層、全球 NoSQL 平台，還是特定 Azure workload 的容量抽象。

定位：multi-model + multi-region write

Cosmos DB 跟其他 DB 最大差異是 multi-model。一個服務同時支援 5 種 API、每個 API 對應不同資料模型。應用層選擇用哪個 API、底層是同一個分散式 KV store。

5 個 API：

• SQL API：document（JSON）+ SQL-like query、Cosmos DB native
• MongoDB API：wire-protocol 相容 MongoDB
• Cassandra API：wire-protocol 相容 Cassandra
• Gremlin API：graph database
• Table API：簡單 KV（Azure Table Storage 升級版）

5 個 consistency levels（從強到弱）：

1. Strong：在支援的 account / region 配置內提供最強一致性，通常帶來最高 latency
2. Bounded staleness：訂版本 / 時間差異上限
3. Session：同 session 內強一致（最常用）
4. Consistent prefix：保證寫入順序
5. Eventual：最便宜、最終一致

容量特性：

• 容量單位：RU/s（Request Unit per second）— 把 read / write / query 統一抽象
• 1 RU = strongly consistent read of 1KB document
• 配置擴容延遲：99 百分位 5 秒內生效
• 每個 logical partition 上限：10,000 RU/s
• 測試最高：1,000,000 RU/s（Minecraft Earth 案例）

適用場景

1. Azure 生態的 multi-model 需求：

• 同一服務多種 use case（document、graph、KV 共存）
• 想把多個 NoSQL 資料模型集中在 Azure 服務邊界內治理
• 對應案例：9.C30 Microsoft 365 — Microsoft 自家用 Cosmos DB 撐分析平台

2. 全球零售 + 季節性高峰：

• multi-region write 讓全球用戶寫入本地 region
• 對應案例：9.C21 ASOS — Black Friday 24 小時 1.67 億請求、3500 RPS 峰值、48ms 平均延遲

3. 全球分散式遊戲後端：

• AR / 即時遊戲跨地區同步
• session consistency 對遊戲足夠、不需 strong
• 對應案例：9.C11 Minecraft Earth — AR 遊戲玩家位置、跨 region 寫入

4. MongoDB 應用想要 managed + 全球分散：

• Cosmos DB MongoDB API wire protocol compatible
• 應用層主要驗證相容差異，底層改成分散式架構
• 對應案例：9.C30 Microsoft 365 — MongoDB → Cosmos DB MongoDB API、planet-scale 分析

5. 想用 multi-region active-active write：

• 不像 Spanner / Aurora DSQL 是 PC 系統、Cosmos DB 是 AP 系統
• 用 LWW（Last-Writer-Wins）或 stored procedure 處理 conflict
• 適合可接受 eventual / session consistency 的 multi-region write workload；需要 global SQL linearizability 時轉 Spanner / Aurora DSQL

不適用場景

1. 跨雲需求：

• Cosmos DB only on Azure
• 替代：MongoDB Atlas（cross-cloud）、CockroachDB（自管）

2. Linearizable 全球 OLTP：

• Cosmos DB Strong consistency 的適用範圍要按 account / region 配置判讀；全球 linearizable SQL 需求通常轉 Spanner / Aurora DSQL
• 替代：Spanner / Aurora DSQL（真正全球 linearizable）

3. 預算極敏感的小 workload：

• 最低 400 RU/s（約 $25/month）
• 小流量場景、Azure SQL Database 更便宜

4. 純 OLAP 分析：

• Cosmos DB 定位在 OLTP / document，analytics workload 交給 Synapse、BigQuery 或 Snowflake
• 替代：Azure Synapse、BigQuery、Snowflake

5. 嚴格 ACID 跨 partition transaction：

• Cosmos DB Transaction 限 same logical partition
• 跨 partition 的 multi-row transaction 要改用 workflow、stored procedure 邊界或 distributed SQL
• 替代：Spanner / Aurora DSQL

跟其他 vendor 的取捨

vs DynamoDB（AWS）：

• Cosmos DB：multi-model（5 API）、5 consistency levels、multi-region write
• DynamoDB：KV 為主、strong / eventual consistency、Global Tables 以 LWW 處理 multi-region conflict
• 選 Cosmos DB：Azure 生態、需要 multi-model、需要 consistency 細粒度控制
• 選 DynamoDB：AWS 生態、純 KV、AWS-native 整合（Lambda、Streams）

vs Spanner（GCP）：

• Cosmos DB：AP 系統、5 consistency levels、multi-model
• Spanner：CP 系統、external consistency、SQL only
• 選 Cosmos DB：可接受 eventual / session、需要 multi-model
• 選 Spanner：需要 linearizability 與 SQL workload

vs MongoDB Atlas：

• Cosmos DB MongoDB API：Azure-only、managed、global 強
• MongoDB Atlas：跨雲（AWS / GCP / Azure）、原生 MongoDB 行為
• 選 Cosmos DB：已在 Azure、想要更好 global distribution
• 選 MongoDB Atlas：跨雲、需要 MongoDB 完整功能（aggregation pipeline 等 native 行為）

vs Cassandra / ScyllaDB：

• Cosmos DB Cassandra API：managed Azure
• Cassandra / ScyllaDB：自管、跨雲
• 選 Cosmos DB：Azure 生態、想把 operation 交給 managed service
• 選 Cassandra：跨雲、自管、極限 throughput tuning

vs Azure SQL Hyperscale：

• Cosmos DB：NoSQL / document、global 分散
• Azure SQL Hyperscale：傳統 SQL OLTP、storage / compute 分離、AWS Aurora 對應
• 選 Cosmos DB：document model、global 分散
• 選 Azure SQL：SQL workload、應用已用 SQL Server
• 對應 9.C32 Clearent Azure SQL Hyperscale — SQL 工作負載選 Hyperscale，document / NoSQL workload 才進 Cosmos DB

vs PostgreSQL（SQL baseline）：

• PostgreSQL：SQL、強一致、single-primary、跨雲可用
• Cosmos DB：NoSQL / multi-model、AP 系統、Azure-only、global 分散
• 選 PostgreSQL：SQL workload、跨雲、需要進階 SQL 特性
• 選 Cosmos DB：Azure 生態、document / KV / multi-model、需要 global distribution

vs Aurora（AWS managed SQL）：

• Aurora：AWS、SQL（PostgreSQL / MySQL）、single-region scaling
• Cosmos DB：Azure、NoSQL / multi-model、global write
• 兩者分別站在 cloud provider 與 data model 兩個維度；同需求下通常先看既有雲平台（AWS → Aurora、Azure → Cosmos / Azure SQL）

vs CockroachDB（cross-cloud distributed SQL）：

• CockroachDB：跨雲、PostgreSQL wire、distributed SQL、強一致
• Cosmos DB：Azure-only、multi-model、5 consistency levels、AP 系統
• 選 CockroachDB：要 SQL + 跨雲 + 強一致
• 選 Cosmos DB：要 NoSQL + Azure 生態 + 細粒度 consistency 選擇

容量規劃要點

1. RU/s 抽象化把 read / write / query 統一：

• 不像 DynamoDB 拆 RCU / WCU、Cosmos DB 用單一 RU
• 簡化容量規劃、但要算「不同操作各吃多少 RU」
• 1 RU = 1 KB strong read、寫 ~5 RU、複雜 query 數百 RU

2. partition key 設計跟 DynamoDB 一樣關鍵：

• 每個 logical partition 上限 10,000 RU/s
• partition key 不均 → hot partition
• 對應 9.C11 Minecraft Earth — synthetic partition key 強制分散
• 詳見 Hot Partition 卡片

3. multi-region 配置：

• 開啟跨 region 後、容量在每個 region 都 mirror、成本乘以 region 數
• 對應 9.C24 Genesys — 跟 DynamoDB Global Tables 同類思維、各 region 獨立容量

4. Consistency level 影響成本：

• Strong consistency：跨 region quorum、單個 read 約 2x RU
• Session：cost 跟 eventual 接近、但提供同 session 一致
• Eventual：最便宜

5. Autoscale provisioned throughput：

• 訂 max RU/s、實際用多少算多少（10% min）
• 適合：流量 unpredictable、想降低 on-demand 成本治理負擔

6. Serverless mode：

• 按 request 計費，適合稀疏與小流量 workload
• 適合：dev / test、小流量、稀疏 workload

Deep article（已完成）

本批 5 篇 deep article 已完成、覆蓋 Cosmos DB 從 consistency level 選擇到 multi-region write conflict 的核心 production 議題：

第二批 deep article 把 Cosmos DB 從核心容量 / 一致性議題推進到 server-side 邏輯、CDC、不同產品釐清與 OLTP / OLAP federation：

Migration playbook：

跨 vendor entry：先看 DB3 vendor selection（MongoDB / DynamoDB / Cosmos DB 三方選型 + workload shape 前置判讀），再進本 vendor 的 deep article。

後續擴充（仍待補）

• Hierarchical partition key 與 partition split / merge 運維
• Autoscale vs serverless 的成本切換決策樹
• Hands-on lab 入口（對齊 PostgreSQL / MySQL / SQLite hands-on 形態）
• Backup / PITR 與 continuous backup tier 選擇
• Gremlin / Table API 的適用邊界與遷入

Anti-recommendation 與升級路由

Cosmos DB 的 multi-model 能把遷移阻力降到很低，也會讓 API compatibility、RU/s、partition key 與 consistency level 同時變成設計責任。這一段先說何時維持單一 API model，再說何時升級 multi-region write、Synapse Link、MongoDB Atlas、Spanner 或 Azure SQL。

Cosmos DB 的簡單路徑是先固定 API model 與 consistency level。每個 API 的相容範圍、index 行為與 query cost 都不同；單純因為「同一服務支援多模型」而混用 API，後續 migration、debug 與容量估算會變複雜。

RU/s 的升級路徑要把 partition key 與 query shape 放在同一張圖。單純提高 RU/s 只能提高名義容量；logical partition 熱點、跨 partition query、index policy 與 payload size 仍會決定真實成本。

已知 limitation 與後續路由

Cosmos DB overview 目前完成 Azure global NoSQL 判斷。下一輪 deep article / playbook 應補 consistency level 選擇、RU/s cost model、partition key design、multi-region conflict、Change Feed、MongoDB API migration、Cassandra API migration 與 Synapse Link。

案例對照

Cosmos DB case 的讀法是分開看三種壓力：Minecraft Earth 提供 global partition 與 RU/s 訊號，ASOS 提供季節性零售尖峰訊號，Microsoft 365 提供 MongoDB API 相容遷移與 Azure dogfood 訊號。

反向 sibling 路由

Cosmos DB 的反向 sibling 路由用來把 Azure global NoSQL、DynamoDB 與 document migration 分開。若讀者從 DynamoDB 過來，先比較 RU/s、partition key、multi-region conflict 與 API model；若讀者從 MongoDB 過來，先把 API compatibility 當 migration hypothesis，再用 aggregation、index、change stream / Change Feed 行為驗證；若需求其實是 SQL strong consistency，轉到 Spanner vendor 或 CockroachDB vendor。

這條路由的判準是 API model 是否已固定。Cosmos DB 的 multi-model 是產品入口，不代表同一套資料可以在多個 API 之間自由切換；partition key、index policy、RU/s 與 consistency level 一旦進 production，就會成為 migration 與成本邊界。

常見陷阱

• Strong consistency 用太多：多數互動式業務用 session consistency 就能滿足讀寫體驗
• partition key 只用 user_id：某些業務 user 集中（VIP、bot）會 hot
• 忽略 Change Feed：寫入後通知、投影與同步流程適合先評估 Change Feed
• MongoDB API behavior 假設：API compat 仍要驗證 aggregation pipeline / index 行為
• 忽略 multi-region 成本乘數：開 3 region active-active = 3 倍 RU 成本

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：DynamoDB vendor、Spanner vendor、MongoDB vendor
• 上游：1.10 KV / Document DB 容量規劃 / 1.11 全球分散式 OLTP
• 下游：1.12 大規模 DB 遷移實戰（MongoDB → Cosmos 範例）
• 跨模組：9.6 容量規劃模型、9.4 Saturation Discovery
• Last reviewed：2026-05-22（API compatibility / consistency / RU model 屬時間敏感 claim）
• 官方：Azure Cosmos DB、Cosmos DB consistency levels

全球分散式 OLTP 解決一個傳統 DB 做不到的問題：跨地理位置 同時 維持強一致性、低延遲、高可用性。CAP 定理過往把這視為「三選二」，但近 15 年的工程進展（Google Spanner、AWS Aurora DSQL、CockroachDB、Microsoft Cosmos DB 等）顯示「在投入 專屬硬體 或 特殊演算法 的條件下、可以同時拿到 strong consistency + global distribution + 可接受 latency」。

本章整理這類系統的工程設計、容量取捨、跟傳統 single-region OLTP 的差異。讀完後讀者能回答：什麼業務需求需要 global OLTP、跨 region quorum 的延遲代價、選 Spanner vs Aurora DSQL vs Cosmos DB 的決策依據。

跟 1.3 Transaction Boundary 的關係：1.3 處理 single-region OLTP 的 transaction 設計、本章處理 multi-region OLTP 的特殊取捨。

跟 1.10 KV / Document DB 容量規劃 的關係：1.10 KV 通常 eventual consistency 全球分散容易、本章處理 強一致 全球分散的工程挑戰。

CAP 跟 PACELC：理論工具

選擇全球 DB 前要先理解兩個理論框架。

CAP 定理：分散式系統 發生分區（network partition） 時、必須在 Consistency 跟 Availability 二選一。

• CP 系統：強一致、partition 時拒絕服務（Spanner、Cosmos DB strong）
• AP 系統：高可用、partition 時可能回舊資料（Cassandra、DynamoDB Global Tables）

PACELC（Daniel Abadi 提出）：擴充 CAP、加上「沒 partition 時」的取捨。

• 沒 partition 時：Latency vs Consistency 二選一
• 結合表示：PA/EL（partition 時選 Availability、平時選 Latency）vs PC/EC（partition 時選 Consistency、平時選 Consistency）

工程含義：

• Spanner、Aurora DSQL、Cosmos DB strong：PC/EC — 永遠選一致、付出 latency
• Cassandra、DynamoDB Global Tables：PA/EL — 永遠選快、付出可能不一致
• Cosmos DB session：PA/EL 但對同一 session 內保持 EC — 妥協方案

選 global DB 不是「哪個最好」、是「業務需要哪一邊」。金融交易、ticketing inventory、payment ledger 通常需要 EC；社群 feed、推薦、analytics 通常 EL 夠用。

Spanner / TrueTime 模型

Google Cloud Spanner 是目前最成熟的 global strong-consistency OLTP。

TrueTime API：用 GPS + 原子鐘提供「全球 unambiguous 時間戳」、解決分散式系統最難的問題之一 — 跨節點時序排序。

External consistency（線性化）：用 TrueTime 保證「全球任何節點看到的交易順序、跟 wall clock 一致」。比 CAP 的 strong consistency 更強。

容量特性（引自 9.C10 Spanner 案例）：

• 內部峰值 > 10 億 requests / 秒
• 線性擴展：2 nodes → 45K reads/sec、4 nodes → 90K reads/sec
• 跨地區交易延遲 100-200ms（quorum round-trip 不可壓縮）
• multi-region instance 可設定 quorum location（影響哪幾個 region 必須同意）

線性擴展為什麼是 OLTP 設計的最高目標

「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」這個線性對應在傳統 OLTP（PostgreSQL、MySQL）做不到。原因是 跨節點交易需要 coordinator 確認順序、coordinator 本身是 bottleneck。加更多節點不會線性加吞吐、因為 coordinator 處理速度跟不上、其他節點得排隊等。

Spanner 用 Paxos + TrueTime 把 coordinator 變成「拓樸感知的多 leader」、每個 leader 只管自己 partition、不需要全域 coordinator。這層演算法 + 硬體（GPS + 原子鐘）配合、才達成線性擴展。

為什麼這個 frame 對選型重要：讀「Spanner 撐 10 億 req/sec」不該理解成「能力差距」、而是「設計差距」— 傳統 OLTP 不是「沒它快」、是「結構上做不到線性」。如果業務未來會跨 region 擴展、必須在最初就選 distributed SQL、不是先用 PostgreSQL 再「之後加 sharding」。

對等技術跟取捨：

• AWS Aurora DSQL：用其他協議（OCC + 分散式時鐘）達成跨 region strong consistency、不用 TrueTime 硬體。
• CockroachDB：用 HLC（Hybrid Logical Clock）+ Raft、可在通用硬體上跑、但 cross-region linearizability 需要 OCC retry。
• TiDB：用 TSO（Timestamp Oracle）服務發 global timestamp、TSO 本身是 single point、可用性要靠 TSO failover 設計。

TrueTime 是 專屬硬體投資、其他方案是 軟體 only、兩者一致性保證等級類似、但運維成本跟認證難度差很大。可複製性低的 TrueTime 是 Google 的競爭優勢、不是普遍 best practice。

容量規劃：

• 節點數量 = 容量單位（每年 review）
• 跨 region quorum 配置決定 latency baseline
• 不能像 single-region OLTP 那樣短期擴容、需要提前 ramp

適用場景：

• 金融交易、ticketing inventory
• 全球客戶但需要強一致
• 不能容忍跨地區 stale read 的業務

不適用：

• 跨洲低延遲（沒辦法、TrueTime 也壓不下 100ms 跨洲）
• 高 throughput 但容忍 eventual consistency（Bigtable / Cassandra 更便宜）

分散式 SQL 的 over-provision 屬結構性成本

分散式 SQL（TiDB、CockroachDB、Spanner）要求恆常 over-provision、是結構性成本、不是 capacity planning 失誤。三個原因都來自跨節點協調的物理需求：

• 跨節點 transaction 需要 coordinator 角色、leader election 在尖峰當下不能發生、否則整個 cluster 卡住。
• 預留 buffer 讓 leader / follower lag 在尖峰時仍能收斂、否則 replication lag 爆增、讀走 replica 的 query 拿到太舊資料。
• 跨 region quorum 在某個 region 暫時不可用時、剩下 region 要能繼續 quorum、所以每 region 的容量都要 >= quorum 所需。

對應 9.C20 Zomato — Zomato 從 TiDB 遷出是業務需求側的判斷：該 workload 本身就能接受 eventually consistent、為 strong consistency 付的 over-provision 屬於浪費。判讀重點：strong consistency 是業務需求時、distributed SQL 的常態 over-provision 是合理代價；業務需求不到這個層級時、KV / 傳統 OLTP 是更划算的選項。

選型公式：先問業務需求要什麼一致性層級、再選 DB 類型、避免倒過來「先選 DB 再硬塞需求」。

Aurora DSQL：AWS 的全球 strong consistency 答案

AWS 在 2024 re:Invent 推出 Aurora DSQL、是 AWS 對 Spanner 的回應。

設計特點（引自 Aurora DSQL announcement）：

• 跨 region active-active write
• 強一致性（線性化）
• PostgreSQL wire protocol compatible（應用層改動小）
• Serverless（不必管 instance）

跟 Spanner 的差異：

• Spanner 用 TrueTime 硬體、Aurora DSQL 用其他協議
• Aurora DSQL 跟 PostgreSQL 相容（容易遷移）、Spanner 是專屬 SQL dialect
• Aurora DSQL 較新（2024）、生態還在成長
• Spanner 服務時間長（內部 2007、外部 2017）、production 案例多

適用場景：

• AWS 生態用戶想要 global strong consistency
• 已用 Aurora / PostgreSQL、想擴展到 multi-region
• 應用層想保留 PostgreSQL ORM

CockroachDB 跟 TiDB：自管選項

如果不想 vendor lock-in、或需要 on-prem 部署、選擇是 self-managed distributed SQL。

CockroachDB：

• 開源、可自管或用 Cockroach Cloud
• 跟 PostgreSQL wire protocol compatible
• 線性擴展、跨 region 部署、強一致
• 設計理念近 Spanner、但不用 TrueTime（用 HLC + Raft）

TiDB：

• 開源（PingCAP）、可自管或用 TiDB Cloud
• 跟 MySQL wire protocol compatible
• TiKV + TiDB 分層架構
• 中國市場大量使用、亞洲生態成熟

選擇取捨：

• vendor lock-in 風險 → 選 CockroachDB / TiDB
• 想 managed → 選 Spanner / Aurora DSQL
• 已用 PostgreSQL → 選 CockroachDB / Aurora DSQL（migration 容易）
• 已用 MySQL → 選 TiDB

對應案例：9.C20 Zomato 從 TiDB 遷出（理由不是 TiDB 不好、是 NewSQL 必須 over-provision、KV NoSQL 對該 workload 更划算）。

Cosmos DB multi-region write 模式

Azure Cosmos DB 提供 五個一致性層級、是 multi-region OLTP 最有彈性的選擇之一。

五個 consistency level（從強到弱）：

1. Strong：linearizable、跨 region quorum
2. Bounded staleness：訂版本 / 時間上限
3. Session consistency：同 session 內強一致
4. Consistent prefix：保證寫入順序
5. Eventual：最便宜、最終一致

Multi-region write 特色：

• 每個 region 都能寫、不必所有寫入回主 region
• conflict resolution 用 LWW（Last-Writer-Wins）或自訂 stored procedure
• 跟 Spanner 的 strong consistency 不同 — 是 AP 系統、不保證 linearizability

適用場景：

• 全球用戶分布、想 寫入本地 region 減延遲
• 容忍 eventual consistency（電商商品評論、社群動態）
• 不能容忍跨 region failover 中斷

對應案例：

• 9.C11 Minecraft Earth — AR 玩家位置用 session consistency、跨 region 寫入
• 9.C21 ASOS — Black Friday 全球用戶、Cosmos DB 跨 region 複製
• 9.C30 Microsoft 365 — 分析 platform 用 weakest acceptable consistency、最大 throughput

跨地理合規：法規限制下的 global OLTP

部分產業（金融、醫療、政府）有 資料駐留 要求 — 特定國家的資料不能離境。這跟全球分散式 OLTP 的設計有 conflict。

典型法規：

• 歐盟 GDPR：歐洲用戶資料應留歐
• 中國《網路安全法》、《資料安全法》：中國用戶資料留中國
• 印度資料保護法：印度金融資料留印度
• 美國各州 healthcare（HIPAA）：醫療資料規範
• 金融業：各國央行通常規定本地交易資料留本地

設計策略：

• 多個獨立 cluster、每個合規區一個。不是 single global cluster。
• meta-data 可以 global（用戶 profile 摘要）、transaction 必須 local
• 跨區查詢通過 federated query 或 ETL、不是直接 join

對應案例：

• 9.C14 Standard Chartered — 7 個受監管市場、各自獨立 Aurora cluster、不能合併
• 9.C24 Genesys — 15 主 region + 5 衛星、按合規區分布
• 9.C32 Clearent — 美國支付業務、Azure SQL Hyperscale + 美國 region

延遲代價：跨 region quorum 不可壓縮

全球 strong consistency 必須付的延遲代價來自物理。光速跑跨大西洋（紐約 ↔ 倫敦 5500 km）大約 27ms one-way、實際網路延遲 70-90ms（含路由 / 處理）。任何 strong consistency 系統都不能比這個快。

典型跨 region quorum latency：

• 同 region 跨 AZ：1-3ms
• 同 continent 跨 region（us-east-1 ↔ us-west-2）：50-80ms
• 跨 continent（us ↔ eu）：80-120ms
• 跨地球（us ↔ asia）：150-250ms

工程含義：

• SLO 訂 p99 < 50ms 跨 continent strong consistency → 不可能達成
• 必須在 SLO 設計時就接受跨 region 的物理 floor
• 業務不需要 strong consistency 的話、用 session / eventual 換 latency

對應案例：

• 9.C3 Coinbase — sub-ms 需求、無法跨 region、用 single-AZ cluster placement
• 9.C12 Riot Games — 35ms VALORANT 延遲門檻、靠 region cluster 滿足、不靠 global DB

詳見 Latency Budget 卡片。

業務的不同延遲代價曲線

讀「100-200ms 跨洲延遲」這種數字、不能只看絕對值、要看 業務代價怎麼隨延遲變化。不同業務型態的延遲代價曲線不同、決定能不能用 strong consistency 全球分散。

B2B agent 操作介面（客服平台、CRM）：延遲代價的特性是 累積。agent 一通客戶電話內連續操作數十次、每次卡 1 秒、累積 30 秒讓 agent 在用戶面前沉默 — 客服效率直接掉一半、客戶等不及掛電話、agent 績效跟 NPS 同時下降。專屬訊號是「單次 latency 看似可接受、agent 體感卻變慢」。對應 9.C24 Genesys 用 15 個 region 把任一 agent 的 DB 延遲壓到 < 50ms — 客服 SaaS 對單次延遲的容忍區間遠窄於一般網路服務。

B2C 終端用戶（社群、電商）：延遲代價是 一次性跳離。用戶等 1 秒會抱怨、等 3 秒會跳離；但完成一個操作就走、不會像 B2B 累積多次。容忍區間在 200ms-500ms、超過就掉 conversion。專屬訊號是「session bounce rate 跟 latency p99 高度相關」、不是看平均。

金融交易（payment、trading）：延遲代價有兩面、是其他業務型態少見的結構。一面是用戶體驗（付款卡 = 結帳放棄）、另一面是 系統正確性（交易順序錯 = 對帳異常、稽核失敗）。後者讓金融業願意付 100-200ms 換 strong consistency、因為對帳成本遠高於延遲成本。專屬訊號是「願意接受比 B2C 更高的 latency budget、但拒絕任何 consistency 妥協」。對應 9.C14 Standard Chartered 7 個受監管市場的設計。

IoT / Telemetry：延遲幾乎無業務代價（資料晚 10 秒進來、報表還是準）、但 throughput 才是主導指標。原因是這類業務的價值來自 大量裝置的聚合趨勢、不是 單一裝置即時回應；只要事件最終到達且順序合理、晚一點不影響決策。專屬訊號是「百萬裝置同時上報、寫入吞吐才是 SLO、latency 不在 alert 條件裡」。選型上 KV 或時序 DB 比 strong-consistency OLTP 更划算。

判讀重點：選 global OLTP 前先畫業務的延遲代價曲線、再決定能付多少 latency budget 給 strong consistency。「100ms 跨洲太慢」這個直覺反射只在沒有對帳 / 累積 / 趨勢這些業務代價時成立。

容量規劃：跟 single-region OLTP 完全不同

全球分散式 OLTP 的容量規劃有獨特挑戰。

容量單位：

• Spanner：節點數
• Aurora DSQL：serverless 自動（按 ACU 計費）
• Cosmos DB：RU/s（每個 region 獨立配置）
• CockroachDB / TiDB：節點數 + storage

規劃要點：

• 每個 region 獨立規劃（跨 region 不能 amortize）
• quorum 配置決定哪些 region 必須同意（影響 failure domain）
• 跨 region replication lag 是 SLO 一部分
• 不能像 single-region 那樣 reactive 擴容、必須 predictive

對應 9.6 容量規劃模型：全球 OLTP 是「不可水平擴容服務」的延伸 — 不只「單機極限」、是「跨 region 協調的物理極限」。

可用性目標的成本曲線

「我們要 99.99% 還是 99.999%」這個問題不該用直覺答、要先看每多一個 9 帶來的成本是多少。可用性是非線性、不是線性。

九的數學意義：

為什麼 99.99 → 99.999 是指數成本而非線性：每多一個 9、要求 每一層基礎設施 都要對等冗餘。

• 99.9 → 99.99：加 multi-AZ active-active、~2-3x 成本
• 99.99 → 99.999：加 multi-region active-active、+ DR 演練、+ failover 自動化、+ 監控覆蓋率拉滿、~5-10x 成本
• 99.999 → 99.9999：加多 cloud、+ 異地災備、+ 全自動 failover、+ 全鏈路演練、~20-50x 成本

適用場景的業務理由：

• 99.99%（受監管產業、付款）：合約 SLA 通常落在這層。受監管金融在中央銀行 / 金融監管機關的書面要求下、年度書面合規會審查 downtime 紀錄、超過 52 分鐘 / 年要解釋；付款 gateway 對商家 SLA 通常承諾 99.99%、低於這個值會被合作夥伴扣保證金。
• 99.999%（客服 SaaS / telco）：5x9 是 B2B 客服 SaaS 跟電信業的 合約義務、不是行銷話術。對應 9.C24 Genesys — 客服平台用 15 主 region + 5 衛星 region 達 99.999%、架構成本約是 single-region 的 15 倍、但 B2B 客服合約要 5x9、這是合理投資。對應 9.C5 Amazon Ads — 廣告計費 1 分鐘斷線可能損失幾百萬美金廣告收入、5x9 對應真實營收邊界。電信業 911 緊急通話必須 5x9 是更嚴格的法規層級。
• 99.9999%（核電、航空管制）：6x9 不只是工程目標、是 公共安全法規。核電廠 SCADA 系統、空管雷達、軌道交通信號這類業務 30 秒 / 年的中斷會威脅生命、所以付得起跨多 cloud / 異地災備 / 全鏈路演練的成本。一般網路服務談 6x9 通常是過度設計。

SLO 木桶效應：99.999% 是 系統整體 數字、不是 DB 單獨。DNS、load balancer、application、DB、storage 任何一層 single-region 就破壞整體 SLO。傳統工程師常以為「DB 多 region 就好」、忽略 application 跑在 single-region 的話、application down = 整體 down。

要達成 5x9、要 每一層 都 multi-region active-active、且 failover 流程能自動執行（人類在事故當下做不到 5 分鐘內完成切換）。對應 05 部署平台模組 的跨 region 部署、跟 06 可靠性驗證模組 的 DR 演練。

Region 成本曲線：N 個 region 的成本約是 1 個 region 的 N 倍（DB + compute + storage 都要複製）、但業務收益不是線性。

• 1 region：覆蓋本國用戶
• 3 region（同 continent）：覆蓋整 continent、延遲 < 50ms
• 6 region（跨 continent）：覆蓋全球、延遲 100-200ms
• 15 region：每個用戶 < 50ms 接入（如 Genesys 模式）

從 6 region → 15 region 的成本是 2.5x、但用戶體驗改善（50ms 延遲）對 B2B 客服很關鍵、對 B2C 推薦系統幾乎無感。region 數量選擇要看 業務模型對延遲的敏感度、不是工程「越多越好」。

Sharding 粒度跟業務一致性需求

distributed SQL 跟 single-cluster SQL 之間還有一層：多個獨立 cluster + 應用層 sharding。選哪個跟業務的一致性需求有關。

Hyperscale / Aurora 同類設計（storage / compute 分離）：

• AWS Aurora、Azure SQL Hyperscale、GCP AlloyDB、Spanner 都採類似工程哲學 — log-structured 分散式 storage + 獨立 compute scale
• storage 最高通常 100 TB（Hyperscale）、超過要 sharding
• compute 上限是 instance type（80 vCore 等）、超過要 sharding 或換 distributed SQL

對應 9.C32 Clearent — 5 億筆/年支付交易、用 Hyperscale 撐單一 cluster、沒拆 sharding 是因為支付業需要 跨 merchant 對帳一致性、共用 OLTP 比拆 cluster 划算。

選 vendor 看生態、不看技術：Hyperscale 跟 Aurora 工程哲學一致、選哪家取決於 application 已在哪個 cloud。AWS 客戶選 Aurora、Azure 客戶選 Hyperscale、GCP 客戶選 AlloyDB / Spanner。技術差異小、生態差異大（IAM 整合、observability tooling、計費綁定）。

業務一致性需求決定 sharding 粒度：

• 微服務各自 OLTP（Netflix Aurora consolidation）：每個微服務有自己的 Aurora cluster、跨服務一致性靠 application 層 saga / outbox。適合服務間業務 天然解耦（用戶服務、訂單服務、商品服務各自 owned data）。Query path 上、跨服務查詢必須走 API 而非 SQL JOIN、要接受查多個服務多次往返；一致性 path 上、跨服務 transaction 用 saga + compensation、容忍中間態。
• 微服務共用 OLTP（Clearent Hyperscale）：所有微服務共用一個大 cluster、跨服務一致性靠 DB transaction。適合業務 天然耦合（payment 跟 refund 跟 chargeback 必須在同一 transaction）。Query path 上、可以用 SQL JOIN 直接查跨服務資料、簡單；一致性 path 上、所有微服務共享一個 schema 演進邊界、schema migration 影響所有服務、要協調。
• Sharding by tenant（B2B SaaS）：每個 enterprise tenant 自己 cluster、適合 tenant 之間完全隔離、大客戶可能要求專屬 cluster。Query path 上、跨 tenant 查詢（例如平台級報表）要走 federated query 或 ETL 聚合、不能直接 join；運維 path 上、每個 tenant cluster 的容量規劃、backup、upgrade 都獨立、運維工時隨 tenant 數量線性成長。
• Sharding by region（受監管產業）：每個合規市場自己 cluster、合規驅動、不是性能驅動。對應 9.C14 Standard Chartered 7 個市場各自獨立。

判讀重點：sharding 不是「擴容到不夠才做」、是「業務模型決定的初始設計」。等到 single cluster 撐不住才開始 shard、會踩進「跨 shard 一致性」的工程地雷區、修改成本遠高於初期設計成本。Managed DB（Aurora、Hyperscale）的容量上限是 已知 的、設計時就該知道未來何時觸發 sharding。對應 1.1 高併發資料存取 的 storage 層 replication 段 — Hyperscale / Aurora / Spanner 同類設計的容量上限同樣是 sharding 觸發點。

案例對照

下一步路由

• 上游：1.3 Transaction Boundary（single-region OLTP）
• 平行：1.10 KV / Document DB 容量規劃（KV 全球分散）
• 下游：1.12 大規模 DB 遷移實戰（含「預設 DB 治理 pattern」— 平台規模化階段的 OLTP 選型治理）
• 跨模組：9.6 容量規劃模型、9.12 SLO 與 Performance Budget、0.2 State Storage Selection、7.11 Data Residency
• Spanner 深入：TrueTime API 深入、一致性模型對照、interleaved table schema migration
• CockroachDB / Aurora DSQL 深入：Aurora DSQL / Spanner / CockroachDB 決策樹、CockroachDB transaction retry pattern、survival goals、locality-aware schema
• Aurora 多 region 深入：global database multi-region、跨 AZ failover RTO
• Cosmos DB 多 region 深入：一致性層次工程、多 region write 衝突

既建知識卡片

• Transaction Boundary
• Latency Budget
• Universal Scalability Law
• Saturation Point