教學路線：全球強一致與 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

本文是 Cloud Spanner overview 的 implementation-layer deep article。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 TrueTime API — Spanner 用來消滅 single coordinator bottleneck、換到 line-rate scaling 的核心機制。

商業邏輯先行：TrueTime 是手段、line-rate scaling 才是目的

TrueTime 的設計目的是消滅 single coordinator bottleneck、讓 OLTP 拿到 line-rate scaling — external consistency 只是這條路徑上拿到的副產品。讀者若把 TrueTime 當成「一個保證 external consistency 的精巧時間 trick」、會誤把工具當目標、後續所有 commit wait / Paxos / GPS 細節都解錯方向。

傳統 OLTP（PostgreSQL、MySQL、Cloud SQL）跨節點交易要靠一個 coordinator 決定全局順序、coordinator 本身就是 bottleneck。1x node = 1x throughput 的線性擴展在 single-primary 模型撞牆、想 scale 只能往應用層 sharding 走、付管理 shard key / 跨 shard query / resharding 的代價。Spanner 換掉這條路徑：TrueTime 把 wall-clock 變成跨 datacenter 可比較的 interval、Paxos 把 coordinator 變成「拓樸感知的多 leader」（每個 Range Sharding split 自己的 Paxos group 各自前進）、commit timestamp 用 TrueTime 對齊到 real-time 順序、不再需要一個全局 coordinator 串行所有 transaction。

9.C10 Cloud Spanner planetary scale case 揭露的線性擴展證據：「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」是 Spanner 設計目標的直接證據、不只是 marketing 數字。這條揭露 Spanner external consistency 不是「加強版 serializable isolation」、是「coordinator 換拓樸」的 paradigm shift。寫到這裡讀者該意識到一件事：選 Spanner 不是選一個更貴更強的 SQL、是選一條 把 coordinator 拆掉 的 scaling 路徑。

Dogfood 邊界（本文反覆強調）：9.C10 是 Google internal dogfood case、不是 customer-facing capacity 參考。「10 億 req/sec」是 Google 全使用者加總、不是單一 instance 配額；「2 nodes → 45K reads / 4 nodes → 90K reads」是 Google internal benchmark 揭露的線性擴展 模式、不是客戶 SLA 承諾。本文後續所有 9.C10 數字引用都會明示這條邊界、避免讀者誤把 dogfood 當配額。

Fact vs derive 分層警告：本段「coordinator bottleneck → TrueTime + Paxos」frame 是跨 Spanner 2012 OSDI 論文 + 公開文件（2024-2026）+ 9.C10 case 合成的工程 frame、不是 9.C10 case 直接展開實作層細節。9.C10 案例直接揭露的 fact 是線性擴展數字跟 dogfood 邊界；本文 derive 的 frame 是「為什麼傳統 OLTP coordinator 是 bottleneck」。引用時這條分層在每段引用具體數字時都會重申。

問題情境：跨 region OLTP 的順序漏洞

跨 region OLTP 想保證「全球用戶看到的交易順序跟 wall clock 一致」、但 NTP 同步誤差動輒 10-100ms、足夠讓 region A 已 commit 的計費事件被 region B 看到一個更新的 timestamp 卻是舊狀態。讀者徵兆通常從這幾個地方浮現：分散式系統團隊在 Cloud SQL / Aurora 多 region 上做 read replica、發現「跨 region read 順序顛倒」、audit log timestamp 不可靠、reconcile 對帳對不上、業務以為自己用了 transaction 就有「強一致」、實際只有 single-node 的 serializable isolation。

真實壓力場景：Google Ads 計費需要把每筆扣款事件放進可驗證的 外部 順序、不只是 transaction 內部 serializable。讀者若把這套需求帶回自家系統、會發現一條共同訊號 — 「兩個 transaction 都 commit 成功、用戶體感卻違反順序」這種事故、不是 isolation level 的問題、是 external consistency 的問題。

Case anchor：9.C10 Cloud Spanner planetary scale — Google Ads / Play 訂閱 / Search 計費跟 TrueTime 綁定。dogfood 邊界明示：9.C10 是 Google 內部 dogfood case、不是 customer-facing capacity 參考；引用其揭露的線性 scaling 模式時要分清「設計目標證據」vs「客戶可獲得配額」。

核心機制：TrueTime 的 API 跟硬體基礎

TrueTime 對外只有兩個 primitive — TT.now() 回傳一個 interval [earliest, latest]、不是單一時刻；TT.after(t) / TT.before(t) 判斷一個事件是否確定在 t 之後 / 之前。整個 external consistency 演算法都建立在「時間是一個 interval、不是一個點」這個 API 設計上。

硬體基礎：GPS + 原子鐘冗餘

每個 datacenter 部署 GPS 接收器 + 原子鐘（armageddon master、用來防 GPS 全網干擾）、time master 之間互相比對排除離群值、TrueTime daemon 從多個 master 拉時間並算 worst-case bound。GPS 給 absolute time reference、原子鐘給 short-term stability（GPS 短暫失聯時仍能用 drift bound 撐過去）。雙來源是為了把 ε 的失敗模式限制在「絕大多數時間 ε ≤ 7ms、極端事件下 ε spike 但不會無限制漂移」。

不確定性 ε（epsilon）

跨 datacenter 同步 + clock drift 估計、ε 目標維持在 1-7ms 區間。

Fact source 分層警告：1-7ms 是 Google 2012 OSDI 論文 + Spanner 公開文件（2024-2026）引用的範圍、9.C10 dogfood case 未直接揭露 production ε 分布。引用時這組數字明標「來自 Spanner vendor docs / 2012 論文、不是 9.C10 case 直接揭露」、避免讀者把兩種來源混為一談。

Commit wait 機制：external consistency 的核心

read-write transaction 要拿 commit timestamp s 時、Spanner 設 s = TT.now().latest、然後 等待 直到 TT.after(s) 才回 ACK。這段「等」就是 Commit Wait — Spanner 特有的物理延遲、由 TrueTime ε 主導、跟 Cross-Region Quorum 的網路 RTT 是兩個獨立的延遲來源、不能混算。

1T1 開始 commit            T1 確定可回 ACK
2       |                          |
3       v                          v
4TT.now().earliest .... s = TT.now().latest .... TT.after(s)
5       |--------- ε --------|
6                            |---------- commit wait ≈ ε ----------|
7       |---------- total commit wait ≈ 2ε（從拿 s 那刻開始） ---------|

commit wait ≈ 2ε 的數學保證了「下一個 transaction 拿到的 timestamp 一定 > s」、external consistency 的全序性質就由這個 wait 撐住。Fact source 分層：commit wait ≈ 2ε 的推導來自 Spanner 2012 OSDI 論文 + 官方文件、不是 9.C10 case 直接展開實作層數學。引用這條數學要附「來源 vendor docs / paper」、避免讀者誤以為這是 case 揭露。

跟通用 linearizability 卡片的差異

Linearizability 只要求「存在某個全序」、external consistency 進一步要求「全序跟 real-time 順序一致」。TrueTime 是把後者變可實作的關鍵 — 它把跨 datacenter 的「real-time 順序」變成可機械判定的 TT.after(s)、不需要全局 coordinator 來決定誰先誰後。對應的概念卡：external-consistency、linearizability、quorum。

操作流程：怎麼觀測 ε 跟調用 TrueTime

TrueTime 本身不對外暴露給 application 操作、ε / commit wait 由 Spanner 內部執行。團隊能做的是 觀測 ε 跟 選擇 不同強度的 read consistency。

觀測 ε

Cloud Monitoring metric spanner.googleapis.com/instance/clock_skew_ms 是 ε 的對外指標、判讀正常 < 7ms、異常 spike > 50ms 代表 time master 失聯或 GPS 干擾。把這條 metric 跟 commit_latencies p99 配成 evidence pair：ε spike 時 commit latency heatmap 應該整層平移、若 commit latency 動但 ε 沒動、不是 TrueTime 的問題、是 quorum / network 的問題。

跨 region instance 配置時的 TrueTime 影響

voting region 越分散、ε 上限越高、commit wait 越長 → write latency 直接受 ε 影響。multi-region instance config 在做 region layout 決策時要把「voting region 散布範圍」當 latency budget 的固定支出、不是配完才補觀測。

read-only transaction 的 staleness 選項

1strong              → 等 TrueTime 確認可讀最新、付完整 commit wait + quorum cost
2exact_staleness(t)  → 讀 t 秒前快照、避開 commit wait、適合 reporting / analytics
3bounded_staleness(t)→ 容忍 t 秒、可讀最近的本地 replica 副本、不跨 region quorum

stale / bounded staleness 走的是 Spanner 版的 Follower Read — 本地 replica serve 不參與 commit 的 read、避開跨 region quorum 把 read latency 降到 single-region 等級。

三者 trade-off 在 SDK 層顯式設定、不是 isolation level：

1// Spanner Go SDK 範例（time-sensitive、查最新文件確認 API）
2client.Single().
3    WithTimestampBound(spanner.MaxStaleness(10 * time.Second)).
4    Query(ctx, statement)

驗證點跟 rollback boundary

跑 cross-region write + cross-region read benchmark、量 p50 / p99 write latency、確認 ≈ 2ε + quorum RTT 的數量級。TrueTime 配置不由用戶調、commit wait 由 Spanner 自動執行；應用層 rollback boundary 在「改用 stale read / bounded staleness」而不是「關掉 TrueTime」 — TrueTime 是 Spanner 內部不可關的機制、不是 feature flag。

失敗模式：ε 暴衝跟誤用 strong read

ε 暴衝（time master 失聯）

GPS 干擾、datacenter time master 雙故障、ε 從 4ms 跳到 200ms → 所有 write 的 commit wait 暴增、p99 write latency 從 50ms 變 500ms。徵兆是 Cloud Monitoring commit_latencies heatmap 整層平移、clock_skew_ms 同步上升。根因不在 application、在 datacenter 物理層、修法是等 GCP 內部 time master 恢復、應用層只能臨時降到 bounded staleness 救 read path。

把 strong read 用在不需要的路徑

報表、analytics、user profile fetch 全用 strong read、每次 read 都付 TrueTime 對齊代價、p99 read 跟 write 同步退化。徵兆是 commit_latencies 沒動、但 api/request_latencies for ExecuteSql 整體上升。修法是把 read path 分類、reporting / analytics 改 bounded staleness、保留 strong read 給「讀後決策再寫」的 critical path。

在 client 側做「自己的 timestamp」

application 用 time.Now() 當業務 key、跨 region 寫入時 client clock skew 直接破壞順序 — Spanner 內部 external consistency 對、業務層卻錯。徵兆是對帳系統發現 timestamp 順序顛倒、但 Spanner audit log 都 OK。修法是業務層 timestamp 全改用 Spanner PENDING_COMMIT_TIMESTAMP sentinel、commit 時由 Spanner 填、不靠 client clock。

把 Spanner 當 single-region SQL 用、卻配 multi-region instance

每筆 write 都付跨洲 quorum + commit wait、cost 跟 latency 都浪費。徵兆是 instance config 是 multi-region 但實際 read 99% 來自單一 region、write 也是。修法是降到 regional instance、把跨 region 需求改用 read-only replica 或 export 到 BigQuery。

ε 沒監控

團隊直到事故才看 clock_skew metric、被動處理而非主動告警。建議 clock_skew_ms > 20ms warn、> 50ms page、跟 commit_latencies p99 偏離 baseline 2x 一起當 saturation discovery 訊號（回 9.4 Saturation Discovery）。

容量與觀測：TrueTime ε 是 latency budget 的固定支出

必看 metric：

1commit_latencies (p50 / p95 / p99)        → commit wait + quorum RTT 的總和
2api/request_count by method               → strong read vs stale read 的分布
3instance/cpu/utilization_by_priority      → high / low priority 分流
4clock_skew_ms                             → TrueTime ε 的對外指標

用 4.20 Observability Evidence Package 框架把 TrueTime ε 跟 commit latency 配成 evidence pair。Capacity 規劃路由回 9.6 容量規劃模型、把「ε × write rate」當 latency budget 的固定支出 — 寫越多筆、commit wait 累積成本越高、不是 free。

Alert 建議：

Line-rate scaling 驗證（呼應商業邏輯先行段）

擴 node 數時量「read throughput / node」是否維持線性 — 9.C10 揭露的 2 → 4 nodes = 45K → 90K reads/sec 是 Google internal dogfood 的線性模式、不是客戶 SLA 承諾。團隊在自己 instance 上要驗證的不是「能不能達到 90K reads」、是「擴 node 後 throughput / node 有沒有保持線性」。若曲線 sub-linear、檢查是否 hot split / hot range / Paxos group 不均、TrueTime 機制本身不解這層。

邊界與整合：何時不用 TrueTime（或不用 Spanner）

何時改用 stale read

reporting / analytics / dashboard 場景改用 bounded staleness 換 cost、不付 commit wait 的 latency tax。判準：若這個 read path 用 5 秒前的資料不會影響業務決策、改 stale read；若會、保留 strong read。

何時不該升 Spanner

單 region workload 不該為了 external consistency 升 Spanner、Cloud SQL + serializable isolation 已經夠。9.C10 dogfood 揭露的線性 scaling 是「跨 region + 大規模」場景的設計目標、單 region 用戶拿不到對應的 cost / latency benefit。詳見遷移判讀：Cloud SQL → Spanner Migration Playbook 的 no-go condition 段。

Sibling deep articles 路由

• consistency-models-comparison：為什麼 external consistency ≠ serializability ≠ linearizability、line-rate scaling 對照表、cross-region quorum 100-200ms 物理硬限
• schema-migration-interleaved-tables：schema change 也用 TrueTime 保證 version 邊界、parent-child storage layout
• migrate-from-cloud-sql-pg：cutover 階段需要把 application 對 timestamp 的假設審一遍（特別是 client 端 time.Now() 那條失敗模式）

跟 1.x 章節的互引

• 1.11 全球分散式 OLTP：Spanner 是 PC 系統的代表、Cosmos DB AP 系統當對照
• transaction boundary：external consistency 是 transaction boundary 的全球延伸

Anti-recommendation

讀者讀完本文應該能判斷：TrueTime 不是「保證強一致」的功能、是「換 scaling 路徑」的核心；若團隊只想要「強一致」、不需要「跨節點線性擴展」、PostgreSQL serializable + 應用層補上 client-side ordering 就夠、不必為 TrueTime 付 GCP lock-in 的 cost。

本文是 Cloud Spanner overview 的 concept-layer deep article。Overview 已說明 Spanner 在強一致 SQL 譜系的定位、本文聚焦 consistency model — 三個常被混用的概念（external consistency / serializability / linearizability）的精確差異、line-rate scaling 對照、跟 cross-region quorum 的物理硬限。

問題情境：五個詞混用的選型困境

團隊在 Spanner / CockroachDB / Aurora DSQL 之間選型、看文件講 strict serializability、external consistency、linearizable、snapshot isolation、serializable — 五個詞混用、不確定買的是哪一種保證。讀者徵兆通常是「我們需要強一致」但說不出強到哪、把 serializable transaction 跟 linearizable read 當同一件事、debug 對帳時發現「兩個 transaction 都 commit 成功、順序卻違反 user 體感」。

真實壓力場景：金融帳本 — A 在台北轉帳給 B、B 在東京立即收到通知然後查餘額、結果查到「轉帳前」的餘額。serializable 允許這種行為（兩 transaction 可以排成任意順序、不要求跟 wall clock 一致）、external consistency 不允許（必須等 commit 後的順序符合 real-time）。混用兩個詞會讓選型結論在系統實作後才被推翻、那時候改架構成本已經高了。

Case anchor：9.C10 Cloud Spanner planetary scale — Google Ads 計費需要 external consistency；對照 PostgreSQL SSI、CockroachDB HLC、Aurora DSQL。dogfood 邊界明示：9.C10 是 Google 內部 dogfood case、不是 customer-facing capacity 參考；本文引用其 line-rate scaling 數字時要附「Google internal dogfood 揭露的設計目標、不是客戶 SLA」邊界。

三個概念的精確定義

Serializability

transaction 的執行結果等同於 某個 序列順序執行；不要求順序跟 real-time 一致。PostgreSQL SERIALIZABLE isolation level（SSI 實作）給的就是這個保證。它解決的問題是 concurrent transaction 之間互相干擾的 anomaly（dirty read / lost update / write skew / G2-item）、不解決「跨 transaction 的 wall-clock 順序」。

範例：A 在 10:00:00 commit T1（餘額 +100）、B 在 10:00:01 commit T2（查餘額）。serializable 允許系統把 T2 排在 T1 之前、B 看到舊餘額 — 兩 transaction 都成功、isolation 沒被破壞、但用戶體感違反順序。

Linearizability

單一 object 操作有全序、且全序跟 real-time wall-clock 一致。只談 single-object、不談跨 object transaction。DynamoDB strongly consistent read 是 single-item linearizability、Redis INCR 是 single-key linearizability。對應 linearizability 卡。

linearizability 跟 serializability 是 正交 的兩個概念 — linearizability 講「單一 object 的 real-time 順序」、serializability 講「transaction 的 anomaly-free 執行」。一個系統可以是 linearizable 但不 serializable（單 object 強保證、跨 object transaction 沒有）、也可以是 serializable 但不 linearizable（PostgreSQL SSI single-node 在 replica lag 後就不 linearizable）。

External consistency / Strict serializability

transaction 層級的 serializability + 全序跟 real-time 一致 — 等同於把 linearizability 推廣到 multi-object transaction。Spanner 用 TrueTime + commit wait 實作、保證 commit timestamp 順序 = real-time 順序。對應 external-consistency 卡。

回到金融帳本例：external consistency 不允許 T2 排在 T1 之前、因為 T2 的 transaction timestamp 必須大於 T1 的 commit timestamp、用戶查餘額必看到 +100 後的金額。

Line-rate scaling 對照：為什麼 PG serializable 在 multi-node 拿不到 line-rate

這段的核心責任是回答「為什麼 Spanner 不只是『更強的 serializable』、是『coordinator 換拓樸』的 paradigm shift」、扣 truetime-api-depth 的商業邏輯先行 frame。讀者選 consistency 等級時、實際在選「系統的 scaling 路徑」、不只是「應用層 anomaly 哪些被排除」。

9.C10 揭露的線性擴展數字

「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」這條線性 scaling 揭露 Spanner external consistency 不是「加強版 serializable」、是把跨節點 coordinator 從 single-point 換成「拓樸感知的多 leader（每個 split 自己的 Paxos group）」、所以擴 node 數可以線性拿 throughput。

Dogfood 邊界明示：9.C10 數字是 Google internal dogfood、不是 customer-facing capacity 承諾。客戶能拿到的 line-rate 受 instance config、region layout、workload shape 影響、不會自動複製 Google 內部曲線。

對照表：四個系統的 scaling 路徑

每個欄位都要回到具體的 scaling 機制讀。PostgreSQL SSI 跟「single-primary」綁定 — 想 scale write 只能 sharding；CockroachDB 把 range 拆細、coordinator 分布到 range 層、但跨 range conflict 還是會 trigger retry；Spanner 用 Paxos group per split、commit timestamp 用 TrueTime 對齊、不需要全局 coordinator 來決定順序；Aurora DSQL 是新系統、機制細節隨版本演進。

為什麼這個對照寫進 consistency 文章、不是純機制文章

讀者選 consistency 等級時、實際在選「系統的 scaling 路徑」、不只是「應用層 anomaly 哪些被排除」。external consistency 的 cost 包含 commit wait latency、但 benefit 包含 line-rate scaling — 兩者要一起講、不能拆開。把對照表放這裡、讓 consistency 跟 scaling 在同一段被讀者一起判讀、避免「我們需要強一致」這種需求被翻譯成「升級到 Spanner」這種跳號決策。

Cross-region quorum 100-200ms 物理硬限：強一致 + 全球不是免費

Cross-Region Quorum + external consistency + multi-region 不是「免費全球」、是「用 latency 換 consistency」。讀者若沒看到具體數量級、會誤把 Spanner 當作「強一致 + 全球 + 低延遲」的奇蹟、實際 cross-region write 在物理光速硬限下必須付跨洲 round-trip cost。

9.C10 揭露的數量級

「external consistency 必須等多區 quorum、跨洲交易延遲可達 100-200ms」 — 這是 9.C10 case 直接揭露的工程數字、不是本章 derive。Dogfood 邊界明示：9.C10 case 揭露的是 Google internal dogfood 觀察到的數量級、不是 SLA 承諾；實際客戶的 cross-region write latency 隨 voting region 配置、network path 變化。

Latency 拆解模型（cross-region write）

1total write latency ≈ 2ε（[Commit Wait](/backend/knowledge-cards/commit-wait/)、TrueTime ε 兩倍 ≈ 2-14ms）
2                    + quorum RTT across voting regions
3                       跨洲：50-100ms one-way、來回 100-200ms
4                       跨大陸內：10-30ms
5                       跨 zone（同 region）：< 5ms
6                    + Spanner internal processing

跨洲 quorum 在這個模型裡是 dominant term、不是 commit wait — 判讀時要明示「commit wait 跟跨 region quorum 是兩個獨立的物理 cost、不能混用一個 latency 數字解釋兩者」。讀者常見的誤解是把 100-200ms 寫成「Spanner commit wait」、實際 commit wait 只是其中 2-14ms、剩下 100ms+ 是物理光速限定的 quorum RTT。

Scope warning：實際 latency 依 region 配置

100-200ms 是 9.C10 case 揭露的範圍、實際 latency 隨 voting region 配置變化：

引用要附條件「跨洲多 region instance、實際數字依 region 配置」、不能寫成「Spanner cross-region write 一律 100-200ms」。讀者拿這條 latency anchor 做 capacity planning 時、必須先 audit 自家 instance 是哪種 config、不能套用 100-200ms 當基線。

SSoT 對齊：Strong + multi-region 互斥議題不在此處展開

Strong consistency + multi-region 互斥議題（包含 Cosmos DB 5 levels 的 Strong + multi-region 限制）的 SSoT 是 Cosmos DB multi-region-write-conflict。本篇 cross-link 不展開、避免重複展開同議題。

本篇展開的子議題：

• external consistency / serializability / linearizability 的精確定義差異
• Spanner external consistency 的 TrueTime 實作機制（細節在 truetime-api-depth）
• cross-region quorum 的物理 cost 數量級
• line-rate scaling 對照表（為什麼 single-primary 系統拿不到線性）

兩個 SSoT 處理同一個讀者問題（強一致 vs multi-region）的不同切面 — 本篇從 系統 scaling 路徑 切入、Cosmos DB 文章從 consistency level 選擇 切入。讀者讀完本篇後若還在問「為什麼 Cosmos DB strong consistency 不能配 multi-region write」、跳 Cosmos DB SSoT。

操作流程：怎麼驗證 consistency 等級

決策樹

1跨 multi-object transaction 嗎？
2├─ 否 → DynamoDB linearizable read / Redis single-key 足夠
3└─ 是 →
4   跨 region 寫入嗎？
5   ├─ 否 → CockroachDB / PostgreSQL serializable 足夠
6   └─ 是 →
7      real-time 順序是產品契約嗎？
8      ├─ 否 → CockroachDB multi-region 可接受
9      └─ 是 → Spanner / Aurora DSQL

驗證 consistency 等級的方法

跑 Jepsen-style test、寫 read-write workload 跑 anomaly checker、量 dirty write / lost update / write skew / G2 anomaly。production 系統若不能跑完整 Jepsen、至少要在 staging 跑 對應 anomaly 的具體 test case — 例如金融帳本跑「轉帳後立即跨 region 查餘額、能不能看到舊值」這個具體 case、不是只看 isolation level 設定文字。

SDK 層的選擇點

1Spanner          → 預設就是 external consistency、read 可降到 bounded staleness
2CockroachDB      → 預設 serializable、可選 AS OF SYSTEM TIME 換 stale read
3PostgreSQL       → 要顯式 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
4DynamoDB         → 預設 eventually consistent、ConsistentRead=true 換強一致

每個 SDK 的 default 都不同、不能假設「沒設就是強的」。PostgreSQL default 是 READ COMMITTED、write skew 直接漏。

Rollback boundary

若一致性等級從強降到弱、要審計應用層所有讀取點（特別是「讀後決策再寫」的 critical path）。降級不是 config 一行的事、是 audit 一遍應用層假設的事。

失敗模式：把 transaction 當「強一致」的五種誤用

把「我們用 transaction」當「強一致」

transaction 只保證原子性、不保證 isolation level；預設 isolation 可能是 READ COMMITTED、write skew 直接漏。修法是顯式設定 isolation level、跑對應 anomaly test 驗證、不靠「我們用 transaction」這種口頭契約。

假設 single-node serializable = distributed serializable

PostgreSQL SSI 跨 read replica 立刻失效（replica lag）、團隊以為加 replica 還是 serializable。實際 replica 的 read 是 eventually consistent、可能看到舊 snapshot。修法是區分 primary read vs replica read、replica read path 標 bounded staleness、不混用 isolation level 字眼。

跨系統 timestamp 假設

service A 用 Spanner、service B 用 Redis、用各自 timestamp 重組事件順序 — service B 的 clock 沒 TrueTime 保證、跨系統 external consistency 不成立。修法是跨系統事件順序要走 單一系統的 timestamp 或 event sequence number、不靠各系統自己的 wall-clock 拼出順序。

把 linearizability 跟 strong consistency 混用、忽略 multi-object 場景

DynamoDB strongly consistent read 是 single-item linearizability、不等於跨 item transaction 強一致。團隊以為「我用了 strongly consistent read 就 OK」、實際跨 item 的順序保證沒有。修法是區分 single-object vs multi-object、跨 item 邏輯如果有順序需求、要用 DynamoDB transaction API（付 2x WCU 的 cost）或換到 Spanner。

過度承諾 external consistency

dashboard / analytics 強寫 strong read、付不必要的 latency tax。修法是把 read path 分類、analytics / reporting 改 bounded staleness、保留 strong read 給 critical path。回 truetime-api-depth 的「把 strong read 用在不需要的路徑」失敗模式。

容量與觀測：一致性等級的 latency 量化

跨 region 延遲量化（finding F3.15、來源 9.C10）：external consistency + multi-region instance config、跨洲 quorum 把 write latency 推到 100-200ms 數量級；單 region instance 的 commit wait 是 baseline（≈ 2ε ≈ 2-14ms）、跨 region quorum 是額外 dominant cost。

Cloud Monitoring：spanner.googleapis.com/instance/clock_skew_ms 觀察 ε、api/api_request_latencies for Commit 觀察 commit latency 分布；CockroachDB 觀察 sql.txn.restart.serializable 計數（serializable restart 率）。回到 4.20 Observability Evidence Package 把一致性等級當 release gate 的一部分。

Capacity 觀點：external consistency 的 commit wait 是「無法 scale away 的 latency 支出」、capacity planning 要先扣這部分；跨 region instance 的 quorum RTT 也是物理硬限、不能透過加 node 解。

邊界與整合：sibling 路由跟 anti-recommendation

Sibling deep articles

• truetime-api-depth：external consistency 的硬體基礎、TrueTime ε / commit wait 數學、商業邏輯先行 frame
• schema-migration-interleaved-tables：schema change 的版本一致性也用 TrueTime
• migrate-from-cloud-sql-pg：Diff 階段要明確標示一致性等級從 SSI 升到 external consistency 的應用層影響

SSoT cross-link

Strong consistency + multi-region 互斥議題的 SSoT 在 Cosmos DB multi-region-write-conflict、本篇不重複展開。

跟 1.x 章節的互引

• 1.11 全球分散式 OLTP：Spanner 是 PC 系統的代表
• transaction boundary：跨 transaction 順序保證

Knowledge card 雙引用

• linearizability — 本文當這張卡的 vendor 應用範例
• external-consistency — 本文擴展這張卡的實作機制
• isolation-level — 本文澄清 isolation level 跟 consistency model 的差異

Anti-recommendation

讀者讀完本文應該能判斷：「我們需要強一致」不等於「升級到 Spanner」 — 先問是 single-object 還是 multi-object、是 single region 還是 multi region、real-time 順序是否是產品契約。多數 OLTP workload 用 PostgreSQL serializable 已經夠、為 external consistency 付 GCP lock-in + 跨 region quorum cost 的判準很高。

本文是 Cloud Spanner overview 的 implementation-layer deep article。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 schema migration without downtime + interleaved tables — Spanner 兩個跟傳統 SQL 差異最大的 schema 機制。

問題情境：DDL 不停機跟 parent-child 物理 layout 的兩個疑問

傳統 PostgreSQL / MySQL DDL 拿 ACCESS EXCLUSIVE / metadata lock、線上跑 ALTER TABLE 動輒鎖表幾分鐘、大型 schema change 要 pt-osc / gh-ost / pg_repack 等外掛工具。Spanner 宣稱「schema change 不停機」、但團隊不知道實際機制跟邊界。讀者徵兆通常從這幾個地方浮現：「Spanner ALTER 真的不卡寫入嗎」「INDEX backfill 跑了 12 小時是正常嗎」「parent-child 的 INTERLEAVE IN PARENT 是什麼黑魔法」「ON DELETE CASCADE 在 interleaved table 為什麼是 storage-level 而不是 application-level」。

真實壓力：multi-tenant SaaS 要對 100 億 row 的 orders 表加 column + 加 index、不能停機、不能讓 p99 write latency 超過 SLA。團隊以為「Spanner schema change 不停機」等同於「DDL 瞬間完成」、實際 ALTER 是 long-running operation、index backfill 在大表上跑數小時到數天、capacity 規劃要把 backfill 期間的 CPU 升幅算進去。

Case anchor：缺案例。9.C10 是 Google internal dogfood case、未展開 schema migration 細節、且 9.C10 不是 customer-facing capacity reference。本文用通用 pattern + 官方文件 + 反向回 PostgreSQL Online Schema Change 對照、待後續 customer case audit 補強。

核心機制：DDL 是 long-running、TrueTime 對齊 schema version

Schema change 的 lifecycle

Spanner DDL 不是同步 ALTER、是 long-running operation。TrueTime 給每次 schema change 分配一個 version timestamp、所有 read / write 用各自 transaction timestamp 對應「當下看到哪個 schema version」。讀者要理解的核心是：DDL 不是「鎖表→改→解鎖」、是「廣播新 schema version、讓現有 transaction 用舊 schema、新 transaction 用新 schema、背景 backfill 物理資料」。

 1時間軸：
 2
 3T0 (DDL 開始)
 4     |
 5     | ──── 舊 schema 仍可用、新 schema metadata 廣播 ────
 6     |
 7T1 (metadata 完成)
 8     |
 9     | ──── 新 transaction 用新 schema、舊 transaction 完成自己 ────
10     | ──── backfill 開始（背景）────
11     |
12T2 (backfill 完成)
13     |
14     | ──── 新 schema fully serve ────

DDL 本身瞬間完成的部分是 metadata 廣播（毫秒到秒級）、慢的部分是 backfill（依資料量、可能數小時到數天）。讀者常見誤解是把 metadata 完成當「DDL 完成」、實際 query 還沒走新 index 因為 backfill 沒跑完。

不停機的關鍵：不同 DDL 的兩階段行為

讀者要記的是：index backfill 完成前、query 該 index 會 fallback 到 table scan、用 EXPLAIN 確認 query plan 走新 index 才算真正完成。沒做這層驗證、團隊會以為 CREATE INDEX 已經成功、實際 p99 query latency 還在表掃描的數量級。

Interleaved table 的設計

Interleaved Table 把 parent table（如 Customer）跟 child table（如 Order）的 row 在 storage 層 物理上交錯儲存 — child row 跟對應 parent row 在同一個 split。不是純 foreign key、是 storage layout：

 1傳統 PostgreSQL FK 設計（兩張獨立表）：
 2Customer table:  [c1, c2, c3, ...]  → 一張表、一段 storage range
 3Order table:     [o1, o2, o3, ...]  → 另一張表、另一段 storage range
 4FK 由 planner 在 JOIN 時拼接、可能跨 page / 跨 segment
 5
 6Spanner Interleaved 設計（物理交錯）：
 7Storage layout: [c1, c1.o1, c1.o2, c2, c2.o1, c2.o2, c2.o3, c3, ...]
 8                 |____________________|  |________________|
 9                  c1 + 其 child           c2 + 其 child
10                  在同一個 split          在同一個 split

Interleaved 的效果：parent + child JOIN 在同一個 Range Sharding split 完成、不跨 split = 不跨 Paxos group = 低延遲 transaction。這條設計把「FK 是 logical constraint」翻成「parent-child access pattern 是 physical co-location」、對 access pattern 固定的 workload（customer → orders、user → posts、tenant → records）是巨大 latency benefit。

Interleaved 的硬限

最後一條是讀者最容易踩的雷 — 一開始沒設 interleaved、後悔時要 export-import 100 億 row、是大工程、不是 ALTER。Schema 設計階段要先 audit access pattern、決定哪些 parent-child 該 interleave。

跟通用 FK 概念的差異

PostgreSQL FK 是 logical constraint、JOIN 由 planner 處理；Spanner interleaved 是 physical layout、JOIN cost 跟 single-table access 接近。對應 transaction-boundary 卡 — interleaved 讓 transaction boundary 跟 storage boundary 對齊、跨 split transaction 變少、commit wait + Paxos round-trip 也省。

操作流程：DDL 跟 interleaved table 的具體步驟

加 column

1ALTER TABLE Orders ADD COLUMN tax_amount FLOAT64;

執行後拿 long-running operation id、用 gcloud spanner operations list 觀察狀態：

1gcloud spanner operations list --instance=prod --database=app
2gcloud spanner operations describe projects/.../operations/<op-id>

驗證點：operation 顯示 done: true 後、跑 SELECT tax_amount FROM Orders LIMIT 1 確認 column 可查。

加 index

1CREATE INDEX OrdersByCustomer ON Orders(customer_id);

拿 operation id → 用 Monitoring metric spanner.googleapis.com/instance/indexes/backfill_progress（或對應的最新 metric、查官方文件）追蹤進度。Backfill 完成前 query 不會走新 index、要用 EXPLAIN 確認：

1EXPLAIN SELECT * FROM Orders WHERE customer_id = 'c123';
2-- 應看到 plan 用 OrdersByCustomer index、不是 table scan

創建 interleaved table

1CREATE TABLE `Order` (
2    customer_id INT64 NOT NULL,
3    order_id INT64 NOT NULL,
4    amount FLOAT64,
5    created_at TIMESTAMP,
6) PRIMARY KEY (customer_id, order_id),
7  INTERLEAVE IN PARENT Customer ON DELETE CASCADE;

關鍵約束：

• child PK (customer_id, order_id) 第一段是 parent PK
• ON DELETE CASCADE 是 storage-level — 刪 parent row 自動刪 child row、Spanner 內部處理、不是 trigger

從 non-interleaved 改成 interleaved

無法直接 ALTER、要走 export-recreate-import：

1. 用 Dataflow / gcloud spanner databases export 把舊表 export 到 GCS
2. 建新表（interleaved schema）
3. 用 Dataflow / gcloud spanner databases import 把資料倒回
4. 應用層 cutover（feature flag / dual write）

這個流程是 mini-migration、要走完整 migration playbook 的 phase plan。Schema 設計階段就決定好 interleave、避免後悔成本。

Rollback boundary

DDL 完成前可 gcloud spanner operations cancel 取消；完成後加 index 要 DROP、加 column 要 DROP COLUMN（同樣是 long-running）。讀者要先確認自己在 DDL 哪個階段、cancel 跟 reverse DDL 是兩條不同路徑。

失敗模式：5 個 production 踩雷

Backfill 時間沒估、event window 撞牆

100 億 row 加 index、預期 1 小時、實際 12 小時 — 沒先用 cost 估 + 沒監控進度 metric。事故場景：團隊在 black friday 前一週開 CREATE INDEX、以為週末跑完、實際週末仍在 backfill、event 期間 CPU 升、query latency 退化。

修法：

• DDL 前用小表 benchmark backfill 速度（rows/sec）、推估大表時間
• DDL 期間監控 instance/cpu/smoothed_utilization、若 > 80% 暫停或降流量
• 大 DDL 排在 capacity headroom 充足的時段、避開 event window

Interleaved table 一開始沒設、後悔時要 recreate

100 億 row export-import + cutover 是大工程、不是 ALTER。事故場景：團隊一開始把 Customer / Order 設成獨立表、上線一年後發現 customer → orders access pattern 是 99% 的 query、JOIN 跨 split 付 commit wait + Paxos cost、想改 interleaved、發現要 mini-migration。

修法：

• Schema 設計階段就 audit access pattern、決定哪些 parent-child 該 interleave
• 寫 ADR 把 interleave 決策跟業務 access pattern 綁定、避免後悔成本

把 interleaved 跟 FK 混為一談

interleaved 的 ON DELETE CASCADE 是 storage-level、刪 parent 自動刪 child；非 interleaved FK 要 application 或 trigger 處理。事故場景：團隊以為「我加了 FK 就會 CASCADE」、實際非 interleaved table 只是 constraint check、刪 parent 時 child orphan、對帳爆炸。

修法：

• Schema 設計時明確分類：interleaved（storage-level CASCADE）vs FK constraint（只檢查、不 CASCADE）
• 非 interleaved 的 parent-child 刪除邏輯放應用層、寫入對帳測試

加 NOT NULL 一步到位

直接 ALTER ADD COLUMN x INT64 NOT NULL 會失敗、必須兩階段。事故場景：開發環境 schema 是新建空表、ADD COLUMN NOT NULL OK；production 表有資料、ADD 失敗、團隊以為 Spanner 不支援、回退。

修法：

1-- Phase 1: ADD with default
2ALTER TABLE Orders ADD COLUMN tax_amount FLOAT64 DEFAULT 0;
3-- 等 backfill 完成
4
5-- Phase 2: ADD CONSTRAINT
6ALTER TABLE Orders ALTER COLUMN tax_amount SET NOT NULL;

Schema change 期間舊 client 還在用舊 schema

TrueTime 保證 read 看到自己 timestamp 對應的 schema version、但 client SDK cache schema 過期會 retry — 沒處理會看到 transient error。事故場景：DDL 完成後、舊 client session 看到 transient FAILED_PRECONDITION、團隊以為 DDL 失敗、回退。

修法：

• 應用層處理 transient retry（指數退避）
• DDL 完成後重新 deploy app instance、避免長期 stale schema cache

容量與觀測：Backfill 是 CPU + I/O 的額外負載

必看 metric：

1spanner.googleapis.com/instance/cpu/smoothed_utilization
2   → backfill 期間 CPU 升幅、判讀是否撞 headroom
3api/api_request_count for ExecuteSql
4   → application traffic 是否受 backfill 影響
5long-running operation API progress
6   → DDL 自身進度（不是 query 進度）

Backfill 期間的 capacity impact：DDL 跑在 background priority、但仍佔 CPU、需要在 instance 有足夠 headroom（建議 < 65% CPU baseline 才開大 backfill）。capacity 規劃要把 schema migration 列入 buffer、回 9.6 容量規劃模型。

Observability evidence：backfill 開始 timestamp、operation id、predicted duration、實際 duration、CPU peak — 全進 incident decision log、回 4.20 Observability Evidence Package。

監控盲點：DDL operation 失敗 silent fail 在 gcloud operations describe 才能看到、Cloud Monitoring 沒有直接 alert。團隊要寫自己的 polling script、operation 失敗時主動 alert、不靠 Cloud Monitoring default。

邊界與整合：何時不用 interleaved、怎麼跟 PG 對照

何時不用 interleaved

• 小 table（< 1M row、單機可放）：不需要 interleave、用 standard FK 就好
• 過度 interleave 7 層：把 split 變窄、反而 hot、得不償失
• access pattern 不是 parent-child JOIN：interleave 沒 benefit、純粹給 schema 加複雜度

跟 PostgreSQL 的對照

PostgreSQL Online Schema Change 用 pg_repack / pt-osc workflow 模擬「不停機」 — 實際是用 trigger + 影子表 + cutover 把 lock 時間壓到秒級、不是真正瞬間。Spanner 是原生支援 DDL long-running operation、不需要外掛工具、但 backfill 時間在大表上仍長、跟 pg_repack 在大表上的執行時間量級接近。

差異點：

讀者選 Spanner 不是為了「DDL 更快」、是為了「不依賴外掛 + 多版本並存」。實際在大表上的耗時兩邊差不多。

Sibling deep articles

• truetime-api-depth：schema version 也是 TrueTime timestamp、跟 transaction timestamp 同層機制
• migrate-from-cloud-sql-pg：target schema 設計含 interleaved、Phase 1 必讀本文
• consistency-models-comparison：schema change 期間多版本並存的一致性保證

跟 1.x 章節

Schema Design — interleaved 是 schema 設計的物理層決策、不是純 logical design。對照 schema-migration-rollout-evidence 看 schema rollout 的 evidence 收集模式。

Anti-recommendation

讀者讀完本文應該能判斷：interleaved 不是「強制使用」的 feature、是「access pattern 固定時的 latency benefit」。小規模 OLTP、access pattern 不確定的 workload、用 standard PostgreSQL FK 就好、為 interleaved 付 schema 後悔成本的判準很高。

本文是 Cloud Spanner overview 的 migration playbook。走 vendor-article-spec Migration Playbook 規格 + migration-playbook-methodology Type E（paradigm shift）。每階段切換用 migration gate 把關 — Evidence 段列的證據是 gate 通過條件、不是 nice-to-have。

Driver：為什麼遷、什麼條件不該遷

啟動壓力

single-region Cloud SQL PostgreSQL primary 觸到容量上限（connection、write throughput、storage IOPS、region 故障風險）、產品要求跨 region active-active write、external consistency 是契約而非 nice-to-have。讀者要先確認自己面對的是「real 跨 region write residency」、不是「想用更強的技術」 — driver 段的核心責任是排除空泛動機。

主要 driver 候選

• Global write residency：用戶分散全球、各地寫入本地 region、跨 region 一致性是產品要求
• External consistency 對帳契約：跨 region 交易順序錯誤會導致對帳爆炸（金融、計費、ticketing）
• 單 primary 容量天花板：Cloud SQL 最大 instance 仍撐不住、應用層 sharding 是大工程
• 跨 region read latency：read 從各地直接打本地 replica、Cloud SQL read replica 受 single-primary 寫入 throughput 限制

No-go condition（基礎）

流量集中單 region、跨 region 只是 DR 需求 → 維持 Cloud SQL + read replica + cross-region async DR 更便宜。這條 no-go 不複雜、但團隊常被 marketing 推著跳過 — 在自家 traffic dashboard 上 audit 一遍「write 來自哪些 region、各占比多少」、若 90%+ 來自單 region、Spanner 沒有 benefit。

No-go condition（sizing barrier）

小 / 中型 PostgreSQL workload 的成本門檻 — Spanner 早期最小單位 100 processing units（≈ 1 node）對中小負載偏貴、過去是 sizing barrier；2021+ 推出 100 pu 起跳的 granular sizing 後雖然可從小開始、但 100 pu × per-pu monthly cost 加上跨 region replication 仍可能比 Cloud SQL HA 設定貴數倍。

來源 9.C10「判讀」段第 3 點：Spanner 早期 100 pu 起跳是 sizing barrier、後來推出 granular sizing 才讓中小負載可從小開始。Dogfood 邊界明示：9.C10 case 揭露的 sizing 結構是 Google 內部 dogfood 的 capacity 規劃語言、不是 customer-facing pricing 承諾；客戶實際成本要看當期 Spanner pricing + region + replication config。

觸發 sizing no-go 的條件：

觸發任一條 → 強烈建議走 Cloud SQL HA、不升 Spanner。判讀時要把 Cloud SQL HA cost vs Spanner 100 pu cost 對比清楚、避免讀者「想用新技術」而升級。

No-go condition（應用層延遲容忍）

應用層延遲容忍 < 50ms write 的 workload 不該升 Spanner — 跨 region Spanner write 在物理光速硬限下達 100-200ms（consistency-models-comparison 的 cross-region quorum 段）。延遲敏感 workload 升級後會在 p99 直接撞牆、回退時資料已經寫進 Spanner、roll back 成本巨大。

來源 9.C10「判讀」段第 2 點 + 「策略」段第 3 點：「external consistency 必須等多區 quorum、跨洲交易延遲可達 100-200ms」。Dogfood 邊界明示：9.C10 揭露的數量級是 Google internal observation、客戶實際 latency 隨 voting region 配置變化、引用時要附條件。

觸發 latency no-go 的場景：

• 實時報價系統（毫秒級回應）
• 高頻交易（HFT）
• 遊戲 leaderboard 寫入
• 低延遲 OLTP（金融下單、支付路由）

觸發任一條 → 強烈建議走 Cloud SQL 單 region、或考慮把 跨 region 一致性需求 重新審視（是否真的需要強一致、能不能改 event-driven async reconcile）。

替代方案排除

• Aurora DSQL：AWS 生態、若團隊在 GCP、跨雲不合
• CockroachDB：要自管或想 PostgreSQL wire 但不選 GCP 託管時可考慮、本 playbook 不對照
• Citus on Cloud SQL：multi-region write 不是強項、不解 cross-region external consistency 需求

Case anchor + dogfood 邊界

無強 customer case。9.C10 是 Google 內部 dogfood、不是公開遷移 case；本 playbook 用 Spanner overview 的 PostgreSQL dialect 路徑 + 官方 migration guide + 通用 pattern。引用時必須明示「9.C10 揭露的線性 scaling / line-rate 設計目標是 Spanner 設計依據、不等於客戶遷移後可獲得的 capacity」。

對照 case：9.C14 Standard Chartered Aurora 受監管 banking — 雖然是 Aurora、不是 Spanner、但揭露「受監管 OLTP 遷移要算合規 lead time」「資料駐留限制 = 容量規劃 per-市場」這兩條結論在 Spanner 遷移同樣適用。讀者若是受監管產業、跨 region instance config 還要疊上 voting region 是否落在合規市場的 audit。

Diff Audit（6 規格面 + sizing / cost 第 7 面）

Schema diff

PostgreSQL DDL → Spanner PostgreSQL dialect 對照：

interleaved table 設計參考 schema-migration-interleaved-tables。讀者要在 schema audit 階段就決定哪些 parent-child 該 interleave、避免後悔成本。

Operational diff

不再需要的 Cloud SQL 責任：vacuum、autovacuum tuning、connection pool（PgBouncer）、replication lag 監控、Patroni HA。

新增 Spanner 責任：processing unit capacity 預測、TrueTime ε 觀測（truetime-api-depth）、long-running schema operation 跟蹤、IAM 細粒度權限。

Paradigm diff

從 single-primary OLTP → 跨 region distributed SQL：

• transaction commit latency：< 5ms → 50-200ms（跨洲、含 Commit Wait + cross-region quorum）
• external consistency 是 default（不再是 isolation level 選擇題）
• transaction 上限：Cloud SQL 無硬限 → Spanner 10s timeout、要重構成短交易
• read consistency：default eventual → default strong、需顯式選 bounded staleness

詳細 consistency model 差異看 consistency-models-comparison。

Component diff

退役：

• PgBouncer / pgcat（connection pool）
• Cloud SQL HA / Patroni cluster
• pgBackRest（備份外掛）
• Citus extension（若有用）
• 各種 postgres extension（時間敏感、逐個 audit 是否 Spanner 支援等效）

新增：

• Spanner client library（Go / Java / Node / Python）
• Dataflow（用於 bulk export-import）
• Datastream / Database Migration Service（用於 CDC catch-up）
• Spanner Studio（query UI）

Application diff

ORM 兼容性是 time-sensitive claim — JPA / Hibernate / SQLAlchemy 在 Spanner PostgreSQL dialect 上的行為隨 dialect 版本演進、實作前查最新 vendor docs。讀者要把 ORM 兼容測試放 Phase 0、不能假設「PostgreSQL ORM 直接搬到 Spanner」。

Data topology diff

• Single primary（write）+ read replica → multi-region voting + read-only replica
• Primary key 設計：避免單調遞增（SERIAL）造成 hot split、改 UUID 或 bit-reversed
• Partition：PostgreSQL declarative partition → Spanner 不需要顯式 partition（自動 split）

Sizing / cost diff（第 7 規格面）

觸發 sizing audit 的時機：workload 行數、QPS、跨 region 需求都明確後、把「Cloud SQL HA monthly bill」對「Spanner 100 pu × monthly rate + egress」做 cost crossover 分析、無法 cost crossover 證明 → 不升。

Cost crossover 不是「Spanner 成本必須低於 Cloud SQL」、是「Spanner 多付的成本要對應到具體 benefit」：

• 若 benefit 是 multi-region write residency、Spanner 多付的 cost 換得跨 region 一致性 — 對齊
• 若 benefit 只是「更新的技術」、Spanner 多付的 cost 沒對應產品價值 — 不升

Type 判定

Type E（paradigm shift）、不是 drop-in。schema / app / operation / data topology / cost 五軸都動、不能用 Type B（drop-in）思路規劃 phase。詳細 type 判定方法看 migration-playbook-methodology。

Phase Plan：9 段、每段有驗證門檻

Phase 0 — Compatibility audit + sizing audit

跑 schema-converter（pgloader / Spanner migration tool）、列出 incompatible feature、決定哪些改 schema、哪些改 app。hot key 風險評估（SERIAL primary key、單調遞增 timestamp）。

同時跑 sizing audit：

• 估 target Spanner pu 數（基於 QPS、storage size、cross-region replication factor）
• 做 Cloud SQL HA cost vs Spanner cost crossover 分析
• 若 cost crossover 證明不出來 → halt migration、回到 driver 段重審

Phase 0 是 migration 的決策閘門 — 不過閘門就停、不浪費 Phase 1+ 的 engineering effort。

Phase 1 — Target schema design

• interleaved table 設計（base on Phase 0 access pattern audit）
• Index 重寫（GIN / GiST 用 STORING column 替代、其他用 B-tree）
• Primary key 反序（避免 hot split）
• Storing column 選擇（trade-off：query latency vs index size）

Output 是 target DDL、跟原 PostgreSQL schema 並排 diff 文件、給 application 團隊審。

Phase 2 — Application dual-target preparation

• 抽象 DB layer（repository pattern、避免直接呼 SQL）
• SDK 並存（go-pg + Spanner client）
• Feature flag 控制讀寫路徑（read-from-pg / read-from-spanner / dual-write）
• Transaction 模式 audit（長交易拆短）

Phase 3 — Bulk initial load

Cloud SQL → Cloud Storage（CSV / Avro）→ Dataflow → Spanner。Row count + checksum 驗證、column-level diff sample。

Phase 4 — CDC catch-up

Datastream from Cloud SQL → Dataflow → Spanner。Replication lag < 1s 為前進門檻、sustained 24h。

Phase 5 — Shadow read

Production read 同時打 Cloud SQL 跟 Spanner、diff log 異常。至少 7 天觀察、divergence rate < 0.1%、p99 latency Spanner < 1.5x Cloud SQL。

Phase 6 — Dual write

Cloud SQL 為 source-of-truth、Spanner 為 mirror。偵測 dual write divergence、評估是否提早升 source-of-truth。

Phase 7 — Cutover

read-only window（< 5 min）→ 最後 catch-up → switch source-of-truth → cutover application write。

Phase 8 — Cleanup

退役 Cloud SQL primary、保留 backup、清 PgBouncer / Patroni / 監控 dashboard。

Stage 0 variant 規劃

若 read-only window 不可接受（24/7 不能停機的金融 / 醫療系統）、Phase 6 dual write 期間做 conflict resolution（last-writer-wins + manual reconcile）、進入 fail-forward 模式、不走 read-only cutover。

Evidence：每階段驗證材料

Cost crossover 報告（Phase 0 必交付）：

 1Item                          | Cloud SQL HA | Spanner 100 pu | Delta
 2------------------------------|--------------|----------------|------
 3Compute monthly               | $X           | $Y             | $Y-X
 4Storage monthly               | $A           | (included)     | -$A
 5Cross-region replication      | $B           | (included)     | -$B
 6Egress (est)                  | $C           | $C             | $0
 7Total monthly                 | $X+A+B+C     | $Y+C           | $Y-X-A-B
 8Annual                        | 12*above     | 12*above       | -
 9Benefit (qualitative)         | -            | multi-region write residency / external consistency | -
10Crossover verdict             | -            | proceed / halt | -

Verdict = proceed 才進 Phase 1；halt → 回到 Driver 段重審 driver 是否成立。

所有 evidence 進 incident decision log、回 4.20 Observability Evidence Package。

Cutover：決策與 rollback

Cutover window

選用戶最低流量時段、< 5 min read-only freeze、預先通知。受監管產業（對照 9.C14 Standard Chartered）要算合規 lead time、每市場各自審。

Decision owner

DB lead + product lead + on-call SRE 共同 sign-off。受監管產業多加合規 owner。

Rollback condition

• cutover 後 30 min 內 p99 write latency 持續 > SLA 2x → rollback
• error rate > 1% sustained 5 min → rollback
• 對帳系統發現 divergence > 0.1% → rollback

Rollback 機制

保留 Cloud SQL 為 read-only mirror 14 天、Spanner 改 read-only、reverse CDC（Spanner → Cloud SQL）需事先準備。Reverse CDC 在 Phase 4-6 期間就要 dry-run 過、不能 cutover 才第一次試。

連結 rollback-window、rollback-condition。

Cleanup：退役清單跟保留責任

退役清單

• Cloud SQL primary instance
• PgBouncer 配置
• Patroni cluster
• pgBackRest backup job（保留歸檔 90 天、依產業合規）
• Datastream pipeline
• Dataflow job

監控清理

postgres-specific dashboard（exporter / wal lag / autovacuum）改成 Spanner dashboard（commit_latencies / clock_skew_ms / cpu_utilization_by_priority）。

文件 / runbook 更新

postgres operation runbook 標記 deprecated、Spanner runbook 上線。新 runbook 含：

• DDL long-running operation 監控
• TrueTime ε 異常處理
• Cross-region instance failover drill
• Cost monitoring alert

稽核 / 合規

保留 final pg_dump 7 年（依產業）、incident write-back 完成、合規市場各自留檔（對照 Standard Chartered case 的 per-市場合規 lead time）。

邊界與整合：sibling、對照、anti-recommendation

Sibling deep articles

• truetime-api-depth：app 對 timestamp 假設審計（Phase 2 必讀）
• schema-migration-interleaved-tables：Phase 1 target schema 設計
• consistency-models-comparison：Phase 0 應用層一致性要求釐清、Driver 段 latency no-go 的物理硬限

跟其他 migration 對照

• PostgreSQL → Aurora DSQL Migration：兩者都是 PostgreSQL → distributed SQL paradigm shift、選 GCP / AWS 看生態
• 1.12 大規模 DB 遷移實戰：通用大規模遷移方法論

跟 case 對照

• 9.C10 Cloud Spanner planetary scale：dogfood case、揭露 Spanner 設計目標、不是 customer-facing capacity reference
• 9.C14 Standard Chartered Aurora banking：受監管產業遷移要算合規 lead time、per-市場容量規劃

Anti-recommendation

讀者讀完本文應該能判斷：

• 若 driver 只是「想用新技術」→ 回 Cloud SQL
• 若 workload 小（QPS < 1000、行數 < 數百萬）→ Cloud SQL HA 更划算
• 若應用層延遲容忍 < 50ms write → Cloud SQL 單 region
• 若 cost crossover 證明不出來 → halt migration、不升

Driver 是真正跨 region write residency / external consistency 對帳契約 / 單 primary 容量天花板 → 才升。Migration playbook 的目標不是把所有 Cloud SQL workload 升到 Spanner、是把「適合升」的部分用低風險路徑遷過去。

本文是 Cloud Spanner overview 的 implementation-layer deep article、寫作參照 vendor deep article methodology。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 Change Streams — Spanner 把 commit 後的 row mutation 變成下游可消費事件流的 CDC 機制。

問題情境：OLTP 的變更要餵給搜尋、快取、分析三個下游

Change Streams 的責任是把 Spanner 內已 commit 的 row mutation 變成有序、可重放、攜帶 commit timestamp 的事件流、讓搜尋索引、快取、分析倉儲三類下游不用反覆 full-table scan 就能跟上主資料庫。OLTP 主庫負責正確寫入、下游各自負責自己的 query shape、兩邊之間需要一條「只送變更、不送全表」的管線、這條管線就是 CDC 的職責。

讀者徵兆通常從這幾個地方浮現：搜尋團隊每 5 分鐘跑一次 full scan 把 orders 重灌進 Elasticsearch、Spanner CPU 被掃表打到 70%；快取層靠 TTL 過期被動失效、使用者看到舊價格;分析團隊想做近即時 dashboard、卻只有每日 batch export。共同壓力是「主庫的變更沒有一條乾淨的出口」、每個下游各自發明輪子去 poll 主庫。

真實壓力場景：全球電商把訂單寫進 Spanner multi-region instance、需要把每筆訂單狀態變更同時推給 (1) 搜尋索引更新庫存可售性、(2) Pub/Sub 通知履約系統、(3) BigQuery 做近即時營收儀表板。三個下游對延遲、順序、retention 的要求不同、但都需要從同一條變更流取得資料。

Case anchor：9.C10 Cloud Spanner planetary scale 提供「全球大規模 OLTP 寫入」的壓力 anchor — Google Ads / Play 計費的寫入量級說明為什麼下游不能靠 full scan 跟上。dogfood 邊界明示：9.C10 是 Google 內部 dogfood case、未展開 change streams 實作細節；本文 change stream 的物件模型、partition 行為與 retention 上限均來自 GCP vendor 規格、不是 9.C10 case 揭露。

核心機制：data change record、partition token、commit timestamp

Change Stream 是一個用 DDL 建立、綁定到特定 table / column 集合的 schema 物件、commit 後 Spanner 把對應 row 的 mutation 寫成 data change record 供消費。它跟「在 application 層自己寫 outbox table」最大的差異是：change record 由 Spanner 內部跟 transaction commit 綁定產生、攜帶該 mutation 的 commit timestamp、繼承 external consistency 的全序性質、不需要 application 額外保證原子性。

建立語法是 DDL：

 1-- 監看整個資料庫
 2CREATE CHANGE STREAM everything_stream FOR ALL;
 3
 4-- 只監看特定 table 的特定欄位
 5CREATE CHANGE STREAM orders_stream
 6  FOR orders(status, total_amount), inventory(available_qty)
 7  OPTIONS (
 8    retention_period = '7d',
 9    value_capture_type = 'NEW_AND_OLD_VALUES'
10  );

value_capture_type 決定 record 攜帶多少資料、三個選項對下游的意義不同：

Data change record 的關鍵欄位

每筆 data change record 攜帶 commit timestamp、record sequence、transaction tag、mod type（INSERT / UPDATE / DELETE）、以及 primary key 與依 capture type 決定的 value payload。下游靠 commit timestamp + record sequence 在同一個 transaction 內重建變更順序、跨 transaction 則靠 commit timestamp 的全序。這條順序保證是 Spanner CDC 跟「自己 poll updated_at column」的根本差異：poll updated_at 在 clock skew 下會漏序、change stream 的順序由 TrueTime 撐住。

Watch partition：change stream 的 partition 模型

Change stream 的讀取單位是 partition、不是整條流。Spanner 把 change stream 依底層 key range 切成多個 partition、每個 partition 用一個 partition token 標識、消費者對每個 token 各開一個 read 呼叫並行讀。當底層資料 split 或 merge（Spanner 自動 re-balance key range）、partition 會產生 child partition — 父 partition 的 record 讀到結束時回傳 child partition token、消費者要接著去讀 child token、才不會漏掉 split 後的變更。

這個 child partition 的接力機制是 change stream 消費的核心複雜度。手刻消費者必須維護一張 partition token 的 watermark 表、處理 parent 結束 → child 開始的交棒、保證每個 token 只被一個 worker 讀。多數團隊不該手刻這層、應走 Dataflow connector（下節）讓它代管 partition 生命週期。

Scope warning：本節 data change record 欄位、value_capture_type 選項、child partition 接力語意均屬 GCP Spanner change streams 規格、實作前 cross-verify Spanner change streams 官方文件。retention_period、partition 切分行為隨版本演進、非 9.C10 case 揭露。

操作流程：建立 change stream 到 Dataflow 下游

Step 1：建立 change stream 並驗證

用 DDL 建立 change stream 後、用 information schema 確認它存在、並用 metadata 查詢確認監看範圍正確。

1CREATE CHANGE STREAM orders_stream
2  FOR orders, inventory
3  OPTIONS (retention_period = '7d');

驗證：查 INFORMATION_SCHEMA.CHANGE_STREAMS 確認 stream 已建立、查 CHANGE_STREAM_TABLES 確認監看的 table 集合符合預期。若監看範圍寫錯（漏了某 table）、下游會靜默漏掉那張表的變更、這是高代價的靜默失敗、必須在這步驗證。

Step 2：選消費路徑 — Dataflow connector 為預設

消費 change stream 有三條路徑、對應不同的下游能力與運維成本：

Dataflow connector 是預設路徑、因為它代管 partition token 的 split / merge 接力、提供 checkpoint 與 exactly-once 到下游 sink。

Step 3：部署 Dataflow pipeline 並驗證 end-to-end

用官方 Spanner-to-BigQuery 或 Spanner-to-PubSub Dataflow template 部署。驗證 end-to-end：在 Spanner 寫一筆變更、量它多久出現在下游、確認 commit timestamp 在下游被保留、確認 INSERT / UPDATE / DELETE 三種 mod type 都被正確處理（DELETE 特別容易在下游被漏掉、要專門測）。

Step 4：rollback boundary

Change stream 是可加可刪的 schema 物件、DROP CHANGE STREAM orders_stream 即停止捕捉、不影響主表寫入。rollback boundary 在「停掉 Dataflow pipeline + 標記下游資料為 stale」、不是「改主庫 schema」 — change stream 本身對 OLTP write path 的影響極小、刪除它不需要 cutover window。

失敗模式：retention 過期、下游慢於 retention、DELETE 漏處理

Retention 窗口過期導致 partition 不可讀

change stream 的 record 只保留 retention_period（預設 1 天、上限數天、查官方文件確認當前上限）。若下游消費者停機超過 retention 窗口、過期 partition 的 record 被 GC、消費者重啟後讀到 partition token 已失效的錯誤、那段變更永久漏掉。徵兆是消費者重啟後報 partition not found、下游資料出現一段空洞。修法是 retention_period 設成大於「最壞情況下游停機 + 重啟趕上」的時間、並對 change stream 的 consumer lag 設告警、lag 接近 retention 一半就 page。

Scope warning：retention_period 的預設值與上限屬 GCP 規格、隨版本變動、cross-verify 官方文件。本段 lag 告警閾值（retention 一半）是通用工程估算、不是 9.C10 case 揭露的數字。

下游消費吞吐慢於主庫寫入速率

主庫 write rate 持續高於下游消費速率、consumer lag 單調上升、最終撞 retention 窗口漏資料。這在全球大規模 OLTP 寫入下是真實壓力 — 對應 9.C10 揭露的 Google internal dogfood 寫入量級（dogfood 邊界：該量級是 Google 全使用者加總、不是單一 instance 配額）。修法是擴 Dataflow worker、確認 partition 數足夠讓消費並行、必要時把單一 change stream 依 table 拆成多條降低單條負載。判讀訊號是 Dataflow backlog metric 持續成長、不是偶發 spike。

DELETE 變更在下游被漏處理

下游 pipeline 只處理 INSERT / UPDATE 的 upsert、忘了處理 DELETE 的 tombstone、導致下游索引 / 快取殘留已刪除的資料。徵兆是搜尋結果出現主庫已不存在的項目、對帳發現下游 row count 高於主庫。修法是 pipeline 顯式 handle mod type = DELETE、依 capture type 決定能否拿到 old values 來反向補償；若用 NEW_VALUES capture、DELETE record 只攜帶 key、下游必須靠 key 刪除、不能假設拿得到完整 old row。

把 change stream 當可靠 message queue 用

change stream 是 變更捕捉、不是 general-purpose message bus。團隊若把它當成「任意事件都塞進來」的 queue、會發現它只能攜帶 row mutation、不能攜帶 application 自定義事件、且 retention 比專用 message broker 短。Anti-recommendation（何時不用）：需要長期保留、任意 payload、複雜 routing 的事件流、用 Pub/Sub 或 Kafka 當 SSoT、change stream 只負責「資料庫變更」這一類來源；把 application 業務事件硬塞進 change stream 是把 CDC 機制誤用成 event bus。

容量與觀測：consumer lag 是核心健康訊號

Change stream 的容量壓力集中在「下游能不能跟上主庫寫入」、核心 metric 是 consumer lag 與 partition 並行度。

必看 metric：

1Dataflow data freshness / system lag   → 下游落後主庫 commit 的時間
2Dataflow backlog bytes / elements      → 未消費的 record 積壓量
3Spanner change stream partition count  → 並行讀取單位、隨底層 split 變化
4Spanner CPU utilization                → change stream 讀取也消耗主 instance CPU

Change stream 的讀取消耗主 instance 的 CPU 與 read capacity、不是免費旁路。容量規劃要把「change stream 消費」當成額外 read workload 算進 instance sizing、回 9.6 容量規劃模型。用 4.20 Observability Evidence Package 把 consumer lag 跟 Spanner CPU 配成 evidence pair：lag 上升且 CPU 飽和、是 instance 容量不足；lag 上升但 CPU 有餘、是 Dataflow worker 不足。

Alert 建議：

Scope warning：上述閾值為通用工程估算、依各團隊 retention 設定與 SLA 調整、非 9.C10 case 揭露的 production 數字。

邊界與整合：跟 DynamoDB Streams 對照、何時不用 change streams

跟 DynamoDB Streams 的對照

Change Streams 跟 DynamoDB Streams 都是 managed CDC、但 partition 模型、ordering 範圍、retention 的設計取捨不同、選型時這三軸最關鍵。

關鍵差異在 ordering：Spanner change stream 繼承 external consistency、跨 partition 的 record 可用 commit timestamp 排出全序;DynamoDB Streams 只保證單 partition key 內有序、跨 partition 重組需要下游自己處理。retention 上 DynamoDB Streams 固定 24 小時、Spanner 可設更長、對「下游可能長時間停機」的場景 Spanner 較有彈性。消費模型上 DynamoDB Streams 跟 Lambda 整合最順、Spanner 跟 Dataflow / BigQuery 生態整合最順。

Scope warning：DynamoDB Streams 24 小時 retention 與 StreamViewType 屬 AWS 規格、Spanner retention 上限屬 GCP 規格、兩者均隨版本演進、cross-verify 各自官方文件。

何時不用 change streams

單純需要「下游讀到最新狀態、不在意中間每筆變更」、且主庫變更率低、定期 batch export 反而更簡單、不必引入 change stream + Dataflow 的運維成本。對延遲不敏感的分析、走 BigQuery federation 直接查 Spanner（見 sibling）比建 CDC 管線更省。Anti-recommendation 的判準是：若下游不需要「每一筆變更的順序」、只需要「定期最新快照」、CDC 是過度工程。

Sibling deep articles 路由

• bigquery-federation：不想建 CDC 管線、直接 federated query 查 Spanner 的 OLAP 路徑、跟 change stream → BigQuery 是兩條互補的整合方式
• truetime-api-depth：change stream 的 commit timestamp 全序來自 TrueTime、理解順序保證的物理基礎
• consistency-models-comparison：change stream 繼承 external consistency、跟 DynamoDB Streams 的 per-partition ordering 對照回 linearizability 定義

跟 knowledge card 的互引

• change-data-capture — 本文是這張卡的 Spanner 實作範例
• external-consistency — change stream 的全序保證來源

跟 04 / 09 章節的互引

• 4.20 Observability Evidence Package：consumer lag × Spanner CPU 的 evidence pair
• 9.6 容量規劃模型：change stream 讀取當額外 read workload 算進 sizing

本文是 Cloud Spanner overview 的 implementation-layer deep article、寫作參照 vendor deep article methodology。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 PostgreSQL dialect — Spanner 為降低 PostgreSQL 生態遷入門檻提供的 PG-compatible 介面、跟原生 GoogleSQL dialect 的差異與邊界。

核心定位：PG dialect 是介面層、不是換引擎

Spanner PostgreSQL dialect 的責任是讓 PostgreSQL 生態的語法、型別系統與 wire protocol 能跑在 Spanner 的分散式引擎之上、降低團隊既有 PostgreSQL 知識與工具的遷移成本。它改變的是 query 語言與 client 介面、不改變底層的 split-based 儲存、Paxos 複製、TrueTime commit 與 external consistency — 這些 Spanner 的分散式語意在兩種 dialect 下完全一致。

把這條定位放在最前面、是因為最常見的誤解是「選了 PG dialect 就等於用 PostgreSQL」。實際上 PG dialect 是「用 PostgreSQL 的方言跟 Spanner 對話」、不是「在 Spanner 裡裝一個 PostgreSQL」。team 帶著 PostgreSQL 的 psql、libpq driver、PG 語法進來、但要寫的仍是 Spanner — 一個沒有 single-primary、沒有本地 sequence、partition 由系統管理的分散式 SQL。

GoogleSQL dialect 是 Spanner 原生方言、語法接近 BigQuery 的 GoogleSQL、攜帶 Spanner-specific 的 INTERLEAVE IN PARENT、array 型別、PENDING_COMMIT_TIMESTAMP 等原生概念。兩種 dialect 是 instance / database 建立時就固定的選擇、之後不可變更。

問題情境：PostgreSQL 團隊想遷入 Spanner、但不想重寫所有 SQL

PostgreSQL dialect 的存在價值、在「既有 PostgreSQL 應用要拿到 Spanner 的全球強一致與線性擴展、但團隊的 SQL、ORM、tooling、人員技能都綁在 PostgreSQL」這個壓力下浮現。讀者徵兆：團隊評估 Spanner 時發現 GoogleSQL 語法陌生、ORM（如 SQLAlchemy、Hibernate）的 PostgreSQL dialect 已深度整合、DBA 熟悉 psql 與 PG 工具鏈、不想為了遷移把整套 SQL 知識重學。

真實壓力場景：一個建在 Cloud SQL for PostgreSQL 上的金融 ledger、撞到 single-primary 寫入上限、需要遷到 Spanner 拿跨 region 強一致;團隊有數萬行 PostgreSQL SQL、用 libpq-based driver、若 target 是 GoogleSQL、application 層改動範圍會大到讓遷移 ROI 不成立。PG dialect 把這個改動範圍縮小到「相容子集邊界內的 SQL 多數可沿用、邊界外的功能需要改寫」。

Case anchor：本主題在 case 庫覆蓋稀薄。9.C10 是 Google internal dogfood case、未展開 dialect 選擇細節、且不是 customer-facing 參考。本文 dialect 機制、相容子集邊界、wire protocol 行為均以 GCP vendor 規格 + 通用遷移工程展開、case 僅作「為什麼 PostgreSQL 團隊要遷 Spanner」的壓力 anchor。延伸的遷移流程在 sibling migrate-from-cloud-sql-pg。

相容子集邊界：哪些 PostgreSQL 功能不在範圍內

PG dialect 提供 PostgreSQL 語法、型別、function 與 wire protocol 的 一個子集、邊界由「Spanner 分散式引擎能不能支援該語意」決定、不是 PostgreSQL 有什麼就有什麼。理解邊界的關鍵是分清三類：相容沿用的、Spanner 用不同方式達成的、根本不存在的。

相容沿用：多數標準 SQL

標準 DML（SELECT / INSERT / UPDATE / DELETE）、多數 JOIN、聚合、CTE、常見型別（bigint / text / numeric / timestamptz / bool / jsonb）、prepared statement、parameterized query 在 PG dialect 下沿用 PostgreSQL 語法。libpq-based driver 與 psql 可直接連、wire protocol 相容讓 PostgreSQL client 工具多數可用。

Spanner 用不同方式達成：sequence、schema change、PK

PostgreSQL 的 SERIAL / bigserial 在分散式系統下會製造熱點（單調遞增的 PK 集中寫到同一個 split）、Spanner 引導用 UUID 或 bit-reversed sequence 分散寫入。schema change 在 PG dialect 下仍是 Spanner 的 long-running operation、不是 PostgreSQL 的同步 DDL — DDL 語法是 PG 風格、但執行語意是 Spanner 的（見 schema-migration-interleaved-tables）。primary key 設計直接決定資料分布、跟 PostgreSQL 把 PK 當邏輯約束的心智不同。

根本不存在：PostgreSQL 重度功能

部分 PostgreSQL 的進階功能不在 PG dialect 範圍內、團隊若依賴它們、遷移要先找替代路徑。常見的缺口包含：自訂 extension（PostGIS、pgvector 等需另尋路徑）、stored procedure / 觸發器生態、部分 window function 與進階型別、LISTEN / NOTIFY、以及 PostgreSQL 特有的 lock 與 vacuum 心智。這些缺口不是 bug、是「Spanner 不是 PostgreSQL」的直接後果。

Scope warning：PG dialect 的具體支援清單（支援哪些型別、function、語法）逐版本擴充、本文列舉的相容子集邊界屬 GCP 規格、實作前必須 cross-verify Spanner PostgreSQL dialect 官方文件 的當前支援矩陣、不能依本文清單當最終依據。

操作流程：建立 PG dialect database、連線、驗證相容性

Step 1：建立 PG dialect database

dialect 在建立 database 時指定、不可事後變更。建立時明確選 PostgreSQL dialect：

1gcloud spanner databases create my-pg-db \
2  --instance=my-instance \
3  --database-dialect=POSTGRESQL

驗證：查 database metadata 確認 dialect 是 POSTGRESQL。這步若選錯、唯一修法是建新 database 重遷、沒有 in-place 轉換 — 這是本文反覆強調的不可逆決策。

Step 2：用 PostgreSQL client 連線

PG dialect 接受 PostgreSQL wire protocol、可用 psql 或 libpq-based driver 連線（透過 PGAdapter proxy 或支援的 client library）。

1# 透過 PGAdapter 用 psql 連線
2psql -h localhost -p 5432 -d my-pg-db

驗證：跑一個簡單 SELECT 1、確認 wire protocol 通;再跑一個帶 PG 型別的 query、確認型別映射正確。

Step 3：相容性 audit — 跑既有 SQL 測邊界

把既有 PostgreSQL application 的 SQL 集合在 PG dialect database 上跑一遍、標出哪些直接通過、哪些報不支援。這步是遷移評估的核心 evidence — 它把「相容子集邊界」從文件文字變成「我的 SQL 有多少落在邊界內」的具體數字。

驗證點：統計通過率、把不通過的 SQL 分類（用 different way 達成 vs 根本不支援）、對「根本不支援」的部分評估改寫成本。若改寫成本過高、這是 PG dialect 路徑的 no-go 訊號。

Step 4：rollback boundary

dialect 不可變更、所以 rollback boundary 在「遷移評估階段」、不在「上線後」。決策樹是：相容性 audit 通過率高 + 改寫成本可控 → 選 PG dialect;通過率低 + 大量 Spanner-only 優化需求 → 直接學 GoogleSQL。一旦 database 建好、dialect 就鎖定、rollback 等於重建 database 重遷。

失敗模式：把 PG dialect 當完整 PostgreSQL、與 dialect 鎖定

把 PG dialect 當完整 PostgreSQL 用

團隊假設「PG dialect = PostgreSQL」、直接把依賴 extension、stored procedure、SERIAL PK 的應用搬過來、上線後發現 extension 不存在、SERIAL 製造熱點、p99 write latency 因 PK 集中而退化。徵兆是特定 PK range 的 split CPU 飆高、其餘 split 閒置。修法是審查 PK 設計改用分散式友善的 key（UUID / bit-reversed sequence）、把 extension 依賴改成 application 層或外部服務。這個失敗的根因是心智模型錯位、不是 bug。

Dialect 鎖定後才發現需要另一種 dialect

dialect 是 database 建立時的不可逆選擇、團隊選了 PG dialect、後續發現需要 GoogleSQL 才有的某個原生能力（或反之）、唯一路徑是建新 database 重遷全部資料。這個失敗的代價遠高於一般 config 錯誤 — 它不是改一行設定、是一次完整的資料遷移 + application cutover + 驗證 + rollback 規劃。回退路徑是把它當成一次 Type E migration（見 migrate-from-cloud-sql-pg 的 paradigm shift 結構）、不能當成 hotfix。預防勝於回退：在 Step 3 的相容性 audit 階段就要把「未來可能需要哪種 dialect 的能力」一起評估、而不是只看當下的 SQL 通過率。

以為換了 PG dialect 就不用懂 Spanner 分散式語意

PG dialect 降低語法門檻、但 Spanner 的 split、hot range、interleaved table、commit wait、cross-region quorum 在 PG dialect 下完全一樣。團隊若以為「用 PG 語法就能當 PostgreSQL 維運」、會在 hot partition、跨 region latency、schema change 是 long-running operation 這些 Spanner-specific 議題上踩雷。修法是不論選哪種 dialect、Spanner 的分散式機制都要懂 — dialect 是介面、不是引擎。

容量與觀測：dialect 不改變容量模型

PG dialect 跟 GoogleSQL 共用同一個 Spanner 引擎、容量模型、metric、sizing 完全一致 — 選 dialect 不影響容量規劃。核心觀測仍是 Spanner instance 的 CPU、split distribution、commit latency、跟原生 GoogleSQL database 沒有差別。

需要額外觀測的是 PG dialect 特有的接入層：若透過 PGAdapter proxy 連線、proxy 本身是一跳、要監控 proxy 的延遲與可用性、避免它成為單點。

1Spanner CPU utilization        → 跟 dialect 無關、共用引擎指標
2split / hot range distribution → PK 設計（含 SERIAL 熱點）直接反映在這
3PGAdapter proxy latency        → PG dialect 接入層的額外一跳（若使用）
4commit_latencies               → external consistency 的 commit wait、兩 dialect 一致

容量規劃路由回 9.6 容量規劃模型 — sizing 邏輯跟 dialect 無關。觀測接 4.20 Observability Evidence Package。

Scope warning：PGAdapter 的部署模型（sidecar / standalone proxy）與其延遲特性屬 GCP 規格、cross-verify 官方文件、非 9.C10 case 揭露。

邊界與整合：何時選 PG dialect、何時選 GoogleSQL

選 PG dialect 的條件

既有 PostgreSQL 應用要遷入、SQL / ORM / tooling 深度綁 PostgreSQL、相容性 audit 通過率高、且不需要大量 Spanner-only 原生優化 — 這是 PG dialect 的適用條件。它讓遷移的 application 層改動最小化、保留團隊既有 PostgreSQL 技能。

選 GoogleSQL 的條件

全新專案、團隊願意學 Spanner 原生方言、需要深度用 interleaved table、array 型別、Spanner-specific 優化、或想跟 BigQuery 的 GoogleSQL 生態對齊 — 選 GoogleSQL。它是 Spanner 的一等公民方言、新功能通常先在 GoogleSQL 落地。

何時兩者都不選（不該升 Spanner）

若 workload 是單 region、不需要全球強一致、PostgreSQL dialect 的相容性吸引力不該成為升 Spanner 的理由 — Cloud SQL for PostgreSQL 是真正的 PostgreSQL、相容性 100%、成本更低。Anti-recommendation 的判準是：PG dialect 的價值在「已經要遷 Spanner、想降低遷移成本」、不在「因為它像 PostgreSQL 所以選 Spanner」。把 dialect 相容性當升級理由是把次要因素當主要決策。

Sibling deep articles 路由

• migrate-from-cloud-sql-pg：PG dialect 是 Cloud SQL → Spanner 遷移降低改動成本的關鍵、本文的相容子集邊界對應該 playbook 的 diff audit
• schema-migration-interleaved-tables：PG dialect 下 DDL 仍是 Spanner long-running operation、interleaved table 在兩 dialect 都要懂
• consistency-models-comparison：兩 dialect 共用 external consistency、dialect 不改變一致性語意

跟 knowledge card 的互引

• distributed-sql — PG dialect 是 distributed SQL 上的相容介面、不改變 distributed SQL 的本質
• isolation-level — 兩 dialect 共用 Spanner 的 external consistency、isolation 語意一致

跟其他 vendor 的對照路由

• CockroachDB vendor：CockroachDB 走 PostgreSQL wire 相容是其核心策略、跟 Spanner PG dialect 是兩種「PostgreSQL 相容的 distributed SQL」路線、相容程度與邊界不同

本文是 Cloud Spanner overview 的 implementation-layer deep article、寫作參照 vendor deep article methodology。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 Spanner Graph（2024 推出）— 建在 relational 引擎上的 property graph 能力、跟 SQL 表共用同一份資料與 transaction。

核心定位：graph 是 relational 表上的視圖、不是另一個資料庫

Spanner Graph 的責任是讓「實體之間的多跳關係查詢」用 property graph 模型（node、edge、property）表達、底層仍儲存在 Spanner 的 relational table、graph 與 SQL 共用同一份資料、同一個 transaction、同一套 external consistency。它不是在 Spanner 旁邊掛一個獨立的 graph database、是在既有 relational 表之上定義一層 graph 映射、讓同一份資料能同時被 SQL query 與 GQL graph query 存取。

把這條定位放最前面、是因為 graph database 常被想成「需要單獨的儲存引擎、單獨的資料同步管線」。Spanner Graph 的設計取捨相反：node table 跟 edge table 就是普通的 Spanner table、graph schema 定義它們之間的映射、查詢時引擎在 relational 儲存上執行圖遍歷。這帶來兩個直接後果 — graph 與 transactional 寫入天然強一致（同一份資料、同一個 commit）、不需要把資料從 OLTP 同步到專用 graph DB;但也意味著 graph 效能受 relational 引擎的特性約束、不是專用 graph engine 的記憶體圖結構。

問題情境：關係查詢在 SQL 裡變成難以維護的多層 self-JOIN

Graph 能力的價值、在「資料本質是關係網絡、但被迫用 relational JOIN 表達多跳查詢」的壓力下浮現。讀者徵兆：反詐欺團隊要查「跟某個可疑帳號在 3 跳內共用過裝置 / 地址 / 付款方式的所有帳號」、寫成 SQL 是 3-4 層 self-JOIN、query 既難寫又難優化;推薦團隊要查「買過 A 的人也買過什麼」的多跳關聯;權限團隊要查「使用者透過群組 / 角色繼承鏈能存取哪些資源」的傳遞閉包。這些查詢的共同形狀是「沿著關係邊走 N 跳」、用 JOIN 表達時跳數越多 SQL 越複雜、優化器越難處理。

真實壓力場景：金融反詐欺系統把交易、帳號、裝置、地址存在 Spanner、需要即時查可疑帳號的關係網絡;這份資料同時要支援交易的強一致寫入。傳統做法是把資料從 OLTP ETL 到專用 graph DB（Neo4j 等）、付出資料同步延遲 + 兩套系統的運維成本 + graph DB 上的資料不是強一致快照。Spanner Graph 讓「強一致的交易資料」與「圖遍歷查詢」在同一個系統、避開同步管線。

Case anchor：本主題在 case 庫覆蓋稀薄。9.C10 是 Google internal dogfood case、未展開 graph 能力、且不是 customer-facing 參考。本文 graph 物件模型、GQL 語意、relational 共存機制均以 GCP vendor 規格 + 通用 graph 工程展開、case 僅作「全球大規模 OLTP 之上要做關係查詢」的壓力 anchor。Spanner Graph 是 2024 推出的較新能力、所有能力 claim 屬時間敏感、實作前查官方文件。

核心機制：node table、edge table、graph schema 映射

Spanner Graph 用 property graph 模型 — node 代表實體（帳號、裝置）、edge 代表關係（共用、轉帳）、兩者都可帶 property。底層每個 node 類型對應一張 relational table、每個 edge 類型對應一張記錄「來源 PK → 目標 PK」的 relational table、graph schema 用 DDL 把這些表宣告成 node / edge。

 1-- 底層仍是普通 relational table
 2CREATE TABLE Account (
 3  id INT64 NOT NULL,
 4  risk_score FLOAT64,
 5) PRIMARY KEY (id);
 6
 7CREATE TABLE AccountTransfersAccount (
 8  src_id INT64 NOT NULL,
 9  dst_id INT64 NOT NULL,
10  amount NUMERIC,
11) PRIMARY KEY (src_id, dst_id);
12
13-- graph schema 把表映射成 node / edge
14CREATE PROPERTY GRAPH FraudGraph
15  NODE TABLES (Account)
16  EDGE TABLES (
17    AccountTransfersAccount
18      SOURCE KEY (src_id) REFERENCES Account(id)
19      DESTINATION KEY (dst_id) REFERENCES Account(id)
20  );

關鍵是 edge table 的 PK 設計直接決定圖遍歷效能。edge table 通常用 (src_id, dst_id) 當 PK、讓「從某 node 出發的所有 out-edge」落在相鄰的 key range、遍歷時是一次 range scan 而非散落查詢。這個物理 layout 跟 interleaved table 的思路相通 — 把一起查的資料在 storage 上放近。

GQL 查詢：用 pattern matching 表達遍歷

graph 查詢用 GQL（ISO graph query language）的 pattern matching 語法、把多跳遍歷寫成 path pattern、比多層 SQL JOIN 直觀。

1-- 查跟某帳號 1-3 跳內有轉帳關係的高風險帳號
2GRAPH FraudGraph
3MATCH (a:Account {id: 12345})-[:AccountTransfersAccount]->{1,3}(b:Account)
4WHERE b.risk_score > 0.8
5RETURN b.id, b.risk_score;

->{1,3} 表達 1 到 3 跳的可變長度路徑 — 這在 SQL 裡需要 recursive CTE 或多個 self-JOIN、在 GQL 裡是一個 pattern。引擎把 pattern 編譯成在底層 relational 表上的遍歷計劃。

Scope warning：Spanner Graph 是 2024 推出的能力、GQL 語法、支援的 pattern、graph schema DDL 均屬 GCP 規格且逐版本演進。本文語法為示意、實作前必須 cross-verify Spanner Graph 官方文件 的當前語法與支援範圍、不可依本文當最終依據。

graph 與 relational 共存的語意

同一份資料能同時被 SQL 與 GQL 查 — 對 Account 表的 SQL UPDATE 立即反映在 graph 查詢、因為它們是同一份 storage。寫入走標準 Spanner transaction、graph 查詢看到的是 external-consistent 的快照。這個共存是 Spanner Graph 跟「ETL 到專用 graph DB」最根本的差異：沒有同步延遲、graph 看到的就是 OLTP 的當前一致狀態。

操作流程：定義 graph、查詢、驗證遍歷效能

Step 1：設計 node / edge table 與 PK layout

先設計底層 relational table、edge table 的 PK 用 (src, dst) 讓 out-edge 連續。這步是 graph 效能的決定性步驟、也是最難回退的步驟（見失敗模式）。驗證：對「最高頻的遍歷方向」確認 edge table PK 讓該方向的 out-edge 落在連續 key range。

Step 2：建立 property graph schema

用 CREATE PROPERTY GRAPH 宣告 node / edge 映射。驗證：查 information schema 確認 graph 已建立、node / edge 映射符合預期、edge 的 source / destination key 正確 reference 到 node 的 PK。

Step 3：跑代表性 GQL 查詢並量遍歷成本

用真實業務的代表性遍歷（例如反詐欺的 3 跳查詢）跑 GQL、用 query plan 確認遍歷走 range scan 而非 full scan、量 latency 與掃描的 row 數。驗證點：跳數增加時 latency 的成長曲線 — 圖查詢的成本對「每跳的扇出（fan-out）」非常敏感、高扇出的 node（super node、例如被百萬帳號連到的熱門裝置）會讓遍歷成本急遽放大。

Step 4：rollback boundary

graph schema 本身可加可改（在相容範圍內）、DROP PROPERTY GRAPH 不刪底層 relational 資料 — graph 是視圖層、刪 graph schema 不影響 SQL 存取。真正難回退的是底層 edge table 的 PK 設計（見失敗模式）。所以 rollback boundary 分兩層：graph schema 層可逆、底層 table layout 層接近不可逆。

失敗模式：edge table layout 設計錯誤的高代價

graph 的失敗模式跟前述機制型文章不同 — 它的核心風險是「資料模型的物理設計錯誤、且代價不可逆」、所以這節用更完整的代價與回退敘事處理、不壓成兩句式。

Edge table PK 方向選錯、最高頻遍歷變成 full scan

這是 graph 設計最高代價、最難回退的失敗。edge table 的 PK 決定哪個遍歷方向是連續 range scan、哪個是散落查詢。若團隊把 PK 設成 (dst_id, src_id)、但 99% 的查詢是「從 src 出發找 dst」、那最高頻的遍歷變成對整張 edge table 的 scan、隨資料量線性退化。

代價之所以高、是因為它不在上線時暴露 — 小資料量下 full scan 也快、效能崩塌在資料長到一定規模、流量打到 production 之後才浮現。徵兆是特定遍歷的 latency 隨 edge table 成長而單調惡化、query plan 顯示 full scan 而非 range scan、Spanner CPU 被掃描打滿。

回退路徑的代價是這個失敗的關鍵：edge table 的 PK 不能 in-place 變更、修正需要建一張新的 edge table（正確 PK 方向）、backfill 全部 edge、更新 graph schema 指向新表、驗證遍歷走 range scan、再 drop 舊表。對 100 億 edge 的圖、backfill 是數小時到數天的 long-running operation、期間要管 capacity 升幅、要保證 graph 查詢在切換期間的正確性。這不是 hotfix、是一次完整的 schema migration。所以這個失敗的真正教訓是「在 Step 1 設計階段就把最高頻遍歷方向定死」、而不是「上線後再優化」 — 設計階段花一天想清楚遍歷方向、勝過上線後花一週重建 edge table。

Super node 讓遍歷扇出急遽放大

某些 node 的 degree（連出的 edge 數）極高 — 例如一個被百萬帳號共用的熱門 IP、一個被千萬使用者關注的明星帳號。多跳遍歷經過 super node 時、單跳就扇出百萬條 edge、查詢成本急遽放大、可能拖垮整個 instance。徵兆是「多數遍歷快、少數遍歷極慢」、慢的那些都經過已知的高 degree node。修法不是純技術 — 要在業務層決定如何處理 super node：限制遍歷的 degree（只取前 N 條 edge）、把 super node 的關係單獨建模、或在應用層對經過 super node 的查詢設上限。這個失敗的代價在「它讓 tail latency 不可預測」、容量規劃要把 super node 的扇出當成 worst-case。

把 graph 當專用 graph DB 的全功能替代

團隊把 Spanner Graph 當 Neo4j 用、期待專用 graph DB 的所有演算法（PageRank、community detection、複雜圖分析）與圖原生效能。Spanner Graph 的強項是「跟強一致 OLTP 共存的關係查詢」、不是「重度圖分析引擎」。徵兆是想跑的圖演算法不在支援範圍、或重度分析查詢效能不如專用引擎。Anti-recommendation（何時不用）：純圖分析、不需要跟 OLTP transaction 共用資料、需要豐富圖演算法庫的場景、用專用 graph DB 或圖分析框架;Spanner Graph 的定位是「OLTP 資料順便要做關係查詢」、不是「圖是核心工作負載」。

容量與觀測：遍歷扇出是核心容量訊號

graph 查詢的容量壓力不在「資料量」、在「遍歷的扇出與跳數」 — 同樣的資料量、低扇出的遍歷便宜、高扇出的急遽放大。核心觀測是 graph query 掃描的 row 數與 query plan 的遍歷形狀。

1GQL query 掃描的 row / edge 數    → 遍歷扇出的直接指標
2query plan: range scan vs full scan → edge table PK layout 是否匹配遍歷方向
3Spanner CPU during graph query    → 高扇出遍歷會打滿 CPU
4特定遍歷的 p99 latency 隨資料成長  → edge layout 錯誤的早期訊號

容量規劃要把「最壞情況遍歷」（經過 super node 的高扇出多跳）當 worst-case 算進 sizing、不能只用平均遍歷成本、回 9.6 容量規劃模型。用 4.20 Observability Evidence Package 把「遍歷掃描 row 數」跟「Spanner CPU」配成 evidence pair：掃描 row 數突增且 CPU 飽和、是某個查詢撞到 super node 或 layout 退化。

Scope warning：Spanner Graph 的具體效能特性、query plan 工具、graph 相關 metric 屬 2024 後的新能力規格、隨版本演進、cross-verify 官方文件、非 9.C10 case 揭露。

邊界與整合：何時用 graph、何時用純 relational 或專用 graph DB

選 Spanner Graph 的條件

資料已在 Spanner、本質是關係網絡、需要多跳遍歷查詢、且這份資料同時要支援強一致的 OLTP 寫入 — 這是 Spanner Graph 的適用條件。它的核心價值是「免去 OLTP → graph DB 的同步管線、graph 看到的就是強一致的當前資料」。反詐欺、權限傳遞、即時推薦這類「在交易資料上做關係查詢」的場景最適合。

何時用純 relational

關係查詢的跳數固定且淺（1-2 跳）、用標準 SQL JOIN 已足夠清晰、不值得引入 graph schema 的額外概念。graph 的價值隨跳數與遍歷複雜度上升、淺查詢用 relational 反而簡單。判準是：若查詢用 JOIN 寫起來不痛、就不需要 graph。

何時用專用 graph DB

純圖工作負載、需要豐富圖演算法（PageRank、最短路徑、社群偵測）、不需要跟 OLTP transaction 共用強一致資料 — 用專用 graph DB 或圖分析框架。Spanner Graph 不是要取代專用 graph engine、是要服務「OLTP 順便要關係查詢」的場景。把重度圖分析硬塞 Spanner Graph 是用錯工具。

Sibling deep articles 路由

• schema-migration-interleaved-tables：edge table 的 PK layout 思路跟 interleaved table 相通、都是「把一起查的資料在 storage 上放近」、且 graph 的 edge layout 錯誤回退跟 schema migration 同代價
• consistency-models-comparison：graph 查詢繼承 external consistency、graph 看到的快照跟 OLTP 一致
• bigquery-federation：重度圖分析若超出 graph 即時查詢範圍、可考慮把資料分到分析層

跟 knowledge card 的互引

• distributed-sql — Spanner Graph 是 distributed SQL 引擎上的 property graph 層、繼承其分散式語意

跟其他 vendor / 章節的對照

• DynamoDB vendor：DynamoDB 的 adjacency list 設計是另一種「在 KV 上做關係查詢」的路線、跟 Spanner Graph 的 native graph 是不同取捨
• 1.11 全球分散式 OLTP：graph 是 Spanner 在 OLTP 之上擴展的查詢能力之一

本文是 Cloud Spanner overview 的 implementation-layer deep article、寫作參照 vendor deep article methodology。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 Spanner ↔ BigQuery federation — OLTP 與 OLAP 的責任分工、以及讓分析查詢存取 OLTP 活資料的整合機制。

核心定位：OLTP 與 OLAP 是兩種不同的資料責任

Spanner ↔ BigQuery federation 的責任是讓「分析查詢」存取「交易資料」、同時把 OLTP 與 OLAP 兩種根本不同的工作負載分開、各自用適合的引擎與運算資源。Spanner 承擔交易責任 — 低延遲、高並發、行級讀寫、強一致;BigQuery 承擔分析責任 — 掃描大量資料、複雜聚合、欄式儲存、吞吐優先。federation 是讓這兩種責任協作的橋、不是讓一個引擎兼做兩件事。

把這條分工放最前面、是因為最常見的反模式是「在 OLTP 庫上直接跑分析查詢」。一個掃描全表做月度營收聚合的查詢、跑在 Spanner 上會吃掉本該服務交易的 CPU、把 OLTP 的 p99 latency 拖垮。federation 的價值是讓分析查詢「邏輯上看得到 OLTP 資料、物理上不搶 OLTP 資源」。理解這點、才能正確判斷哪些查詢該留在 Spanner、哪些該推到 BigQuery。

問題情境：分析查詢正在拖垮交易系統

federation 的價值、在「分析需求與交易需求共用同一個 OLTP 庫、互相干擾」的壓力下浮現。讀者徵兆：BI 團隊的 dashboard 每小時跑全表聚合、每次跑都讓 Spanner CPU spike、交易 p99 跟著抖;資料團隊想做 ad-hoc 分析、卻被告知「不要在 production Spanner 上跑大查詢」;為了避免干擾、團隊每天 batch export 一次到 BigQuery、但分析師抱怨資料延遲一天、看不到當天的活資料。

真實壓力場景：全球電商把訂單寫進 Spanner、營運團隊要即時看「過去一小時各區域的訂單趨勢」。這個查詢需要近即時的活資料（不能等隔日 batch）、又是掃描大量 row 的聚合（不該跑在 OLTP 上）。兩個需求拉扯：要新鮮就得查 Spanner 活資料、要不干擾交易就得分到分析引擎。federation + Data Boost 正是為了同時滿足這兩端 — 查 Spanner 的活資料、但用獨立運算資源。

Case anchor：9.C10 Cloud Spanner planetary scale 提供「Spanner 定位在 OLTP、analytics workload 交給 BigQuery」的分工 anchor — overview 已指出 Spanner 的不適用場景包含「需要 OLAP 分析能力」、替代是跟 BigQuery 整合。dogfood 邊界明示：9.C10 是 Google 內部 dogfood case、未展開 federation 實作細節;本文 federation 機制、Data Boost 行為均以 GCP vendor 規格 + 通用 OLTP/OLAP 工程展開、case 僅作分工壓力 anchor。

核心機制：external dataset federated query 與 Data Boost

federation 讓 BigQuery 把 Spanner database 註冊成 external dataset、之後用標準 BigQuery SQL 直接查 Spanner 的表、查詢在執行時把資料從 Spanner 拉進 BigQuery 的執行引擎。資料不複製、查的是 Spanner 當前狀態 — 這是 federation 跟「定期 export 一份 copy 到 BigQuery」的根本差異:federated query 看到的是活資料、export 看到的是某個時間點的快照。

1-- BigQuery 端：透過 external connection 查 Spanner 活資料
2SELECT region, COUNT(*) AS order_count, SUM(total) AS revenue
3FROM EXTERNAL_QUERY(
4  'my-project.us-central1.spanner-conn',
5  'SELECT region, total FROM orders WHERE created_at > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)'
6)
7GROUP BY region;

Data Boost：分析查詢的 workload 隔離

federated query 直接查 Spanner、預設仍消耗 Spanner instance 的運算資源 — 大分析查詢還是會干擾 OLTP。Data Boost 解的就是這層:它讓分析查詢用 獨立的、按需配置的運算資源 讀 Spanner 資料、不消耗服務交易的 instance CPU。Data Boost 讀的是同一份 storage、但用獨立 compute、所以「分析查詢看活資料」與「不干擾 OLTP」可以同時成立。

這是 federation 整套機制的關鍵 — 沒有 Data Boost、federated query 只是把查詢入口換到 BigQuery、底層仍搶 Spanner CPU;有了 Data Boost、workload 隔離才真正成立。Data Boost 適合 batch / ad-hoc 的大型分析讀取、按使用量計費、不需要預先 provision。

Scope warning：external dataset / EXTERNAL_QUERY 的語法、Data Boost 的計費模型與資源隔離邊界屬 GCP 規格、逐版本演進。實作前 cross-verify BigQuery Spanner federation 與 Data Boost 官方文件、不可依本文當最終依據。

兩條整合路線：federation vs change-stream-to-BigQuery

把 Spanner 資料給 BigQuery 分析有兩條路線、取捨不同：

federation 是「需要時去查」、change stream 是「持續推一份到 BigQuery 落地」。federation 適合不需要把資料常駐 BigQuery、偶爾查活資料的場景;change stream（見 change-streams-cdc）適合要在 BigQuery 累積歷史、做高頻或需要 BigQuery 原生效能的分析。兩者不互斥 — 即時 ad-hoc 用 federation、長期歷史分析用 change stream 落地。

操作流程：建立 connection、federated query、啟用 Data Boost

Step 1：建立 BigQuery → Spanner external connection

在 BigQuery 建立指向 Spanner 的 external connection、設定 IAM 讓 BigQuery service account 有讀 Spanner 的權限。驗證：用 EXTERNAL_QUERY 跑一個簡單 SELECT 1 確認 connection 通、權限正確。

Step 2：跑 federated query 並確認查的是活資料

跑一個帶時間條件的 federated query、在 Spanner 端寫一筆新資料、立即用 federated query 確認讀得到 — 驗證它查的是活資料、不是快照。這步確立 federation 的核心性質。

Step 3：對大分析查詢啟用 Data Boost 並驗證隔離

對會掃描大量資料的分析查詢啟用 Data Boost、然後在跑分析查詢的同時觀測 Spanner OLTP 的 CPU 與 p99 latency。驗證點：開 Data Boost 後、大分析查詢執行期間 Spanner OLTP CPU 不應 spike、交易 p99 不應退化。這是 Data Boost 隔離是否生效的直接 evidence — 若 OLTP CPU 仍 spike、表示查詢沒走 Data Boost。

Step 4：rollback boundary

federation 是讀取路徑、不改 Spanner 資料、rollback 成本低 — 停掉 federated query 即可、不影響 OLTP。決策的回退在「分析需求是否該用 federation」:若 federated query 即使開 Data Boost 仍無法滿足效能 / 成本、回退路徑是改用 change stream 把資料落地 BigQuery、用 BigQuery 原生效能查。

失敗模式：未隔離的查詢拖垮 OLTP、資料一致性誤解、過度依賴 federation

Federated query 未開 Data Boost、拖垮 OLTP

團隊用 federated query 跑大分析查詢、但沒啟用 Data Boost、查詢直接吃 Spanner instance CPU、把交易 p99 拖垮。徵兆是「BI 查詢一跑、交易 latency 就抖」、Spanner CPU 在分析查詢期間 spike。修法是對所有大分析查詢啟用 Data Boost、把「federation = workload 隔離」這個假設明確驗證 — federation 本身不保證隔離、Data Boost 才保證。這個失敗的代價是它直接傷害 production 交易、不是只影響分析。

把 federated query 的快照當成跨系統強一致

federated query 讀的是 Spanner 的活資料、但這份分析結果是「查詢執行那一刻」的快照、不是跟某個 OLTP transaction 綁定的一致點。團隊若把 federated 分析結果當成「跟某筆交易嚴格對齊的數字」、會在對帳場景出錯 — 分析查詢跨多張表掃描時、不同表讀到的時間點可能略有差異、不像單一 OLTP transaction 有 external consistency 的全序保證。

這個失敗的代價在它的隱蔽性:多數分析場景對「秒級的時間點差異」不敏感、所以平時看不出問題;但在「分析數字被當成財務對帳依據」的場景、這個鬆散的一致性會讓對帳對不上、且很難 debug — 因為資料「看起來都對」、只是時間點不嚴格對齊。修法是分清分析查詢的一致性需求:近似趨勢分析、federation 的快照足夠;需要跟交易嚴格對齊的對帳、要用 Spanner 的 read-only transaction 配明確 timestamp bound、或在 OLTP 側生成對帳快照、不靠跨表 federated 掃描拼湊。回退路徑是把「需要強一致對帳」的查詢移回 Spanner read-only transaction、不要硬用 federation 省事。

把所有分析都堆在 federation、不評估落地 BigQuery

團隊把所有分析都用 federated query 直查 Spanner、即使是高頻、重複、不需要活資料的查詢。federated query 每次都從 Spanner 拉資料、高頻重複查的成本與延遲都高於「資料已落地 BigQuery、用 BigQuery 原生欄式儲存查」。徵兆是同樣的分析查詢高頻跑、每次都付 federation 的拉取成本。Anti-recommendation（何時不該用 federation）:高頻、重複、可容忍近即時延遲的分析、用 change stream 把資料落地 BigQuery 更划算;federation 的適用範圍是低頻、ad-hoc、需要活資料的查詢。把高頻分析硬塞 federation 是用錯整合路線。

容量與觀測：OLTP CPU 隔離與 federation 拉取成本

federation 的容量壓力分兩端 — Spanner 側看「分析查詢有沒有被 Data Boost 隔離開」、BigQuery 側看「federated query 的拉取量與成本」。

1Spanner OLTP CPU during analytics   → Data Boost 隔離是否生效的關鍵指標
2Spanner read capacity used by 分析   → 未隔離的 federated query 會吃這部分
3BigQuery federated query bytes 處理量 → federation 拉取成本的計費基礎
4分析查詢 latency vs OLTP p99 抖動相關性 → 隔離失效會讓兩者正相關

核心容量判讀是「分析查詢執行期間、OLTP CPU 與 p99 是否穩定」 — 若穩定、Data Boost 隔離生效;若兩者正相關、隔離失效、分析查詢正在消耗本該服務 OLTP 的資源。用 4.20 Observability Evidence Package 把「分析查詢時段」跟「OLTP p99」配成 evidence pair。容量規劃上、若走 federation + Data Boost、OLTP sizing 不需為分析加碼（Data Boost 用獨立 compute）;若 federated query 未隔離、OLTP sizing 要把分析尖峰算進去、回 9.6 容量規劃模型。

Scope warning：Data Boost 的計費單位、federated query 的 bytes 計費、隔離的資源邊界屬 GCP 規格、隨版本演進、cross-verify 官方文件、非 9.C10 case 揭露的 production 數字。

邊界與整合：何時把分析 workload 完全分出去

何時用 federation + Data Boost

分析需要 Spanner 的活資料、查詢低頻或 ad-hoc、不想維護資料同步管線 — 這是 federation 的適用條件。Data Boost 讓它不干擾 OLTP、按需計費。即時營運 dashboard、臨時資料探索、不需要常駐 BigQuery 的分析都適合。

何時把分析完全分到 BigQuery（change stream 落地）

分析是高頻、重複、需要 BigQuery 原生欄式效能、或需要在 BigQuery 累積跨年歷史 — 把資料用 change stream 持續同步到 BigQuery 落地、分析直接查 BigQuery、不再回 Spanner。判準是:當分析 workload 穩定且高頻、落地的一次性同步成本會被「不再每次 federated 拉取」攤平。這是「分析 workload 完全分出去」的訊號 — OLTP 與 OLAP 不只查詢入口分開、連儲存都分開。

何時都不需要（分析量小）

若分析需求很小、Spanner 本身的 read capacity 有餘、偶爾在低峰跑個聚合不影響交易 — 不需要引入 federation 的額外設定。Anti-recommendation 的判準是:federation / Data Boost 的價值隨「分析與交易互相干擾的程度」上升;若兩者本來就不打架、保持簡單。

Sibling deep articles 路由

• change-streams-cdc：federation 的互補路線、高頻分析用 change stream 把資料落地 BigQuery、跟 federation 的「需要時去查」是兩種整合取捨
• consistency-models-comparison：federated query 的快照一致性鬆於 OLTP transaction 的 external consistency、對帳場景的差異對應該文的一致性等級定義
• truetime-api-depth：需要嚴格時間點的分析要用 read-only transaction 配 timestamp bound、回該文的 staleness 選項

跟 knowledge card 的互引

• federation — 本文是這張卡在 Spanner ↔ BigQuery 的具體應用
• distributed-sql — Spanner 作為 OLTP distributed SQL、跟 BigQuery 的 OLAP 分工

跟其他章節的對照路由

• 9.6 容量規劃模型：OLTP / OLAP 分工後各自的 sizing 不同、Data Boost 讓分析 sizing 跟 OLTP 解耦
• 1.11 全球分散式 OLTP：Spanner 定位在 OLTP、analytics 分到 BigQuery 是清楚的責任邊界

本文是 DB4 distributed SQL 選型的 entry point deep article — 讀者進來時還沒決定哪個 vendor、甚至還沒釐清「我是不是該換 distributed SQL」。本文先用 撞牆訊號分型 幫讀者識別自己屬哪條 driver path、再進三軸 vendor 對比、最後落到 team size + sizing 邊界檢查。配合 CockroachDB vendor overview + 1.11 全球分散式 OLTP 閱讀。寫作參照 vendor deep article methodology。

為什麼先講 driver path、不直接比 vendor

團隊評估「全球分散式 OLTP 三選一」時最常見的源頭錯誤：先比 vendor、再回頭問「我為什麼要 distributed SQL」。三家 vendor 文件都說「跨 region 強一致 SQL」、看不出實際取捨；做錯選擇後遷移成本極高。

正確順序應該反過來：先識別 自己為什麼要評估 distributed SQL、再進 vendor 比較。三條 driver path 各自的訊號、適配 vendor、決策路徑都不同 — 不識別 driver path 直接比 vendor 是源頭錯誤。

讀者進來最常問的問題（多數會問錯順序）：

• 我是不是真該換 distributed SQL、還是 Aurora / Cloud SQL 還能撐？
• Spanner 在 Google 跑了 10 年、CockroachDB 跟 DSQL 比較新、成熟度差多少？
• 我有 PostgreSQL 應用、三家相容性差在哪？
• 跨雲是硬需求還是被 fear 推的？
• DSQL 2024 才 GA、production 風險多大？
• 我團隊 50 人能不能養 self-managed CockroachDB？
• Spanner 100 pu 起跳對我中小 PG workload 划算嗎？

7 題本文都會回答、但先回答「你是哪條 driver path」這個前置問題 0。

三條 driver path 的 case anchor

• 9.C39 DoorDash：Aurora Postgres 1.636 M QPS single-primary 撞牆 → 換 multi-primary、PostgreSQL wire 相容降低遷移阻力（F4.1 / F4.2 / F4.4）
• 9.C40 Netflix：Cassandra eventual consistency 撐不住 transactional → 補 distributed SQL、self-managed 380+ cluster + Database Platform Team（F4.6 / F4.9）
• 9.C41 Hard Rock Digital：Wire Act 合規驅動 + 50 人 tech team + Outposts 混合部署（F4.10 / F4.14）

對照 9.C10 Spanner planetary scale 提供 Spanner ground truth（含 sizing barrier、F3.16）、9.C14 Standard Chartered 提供 Aurora 受監管金融的另一條路徑、9.C4 DraftKings Aurora financial ledger 提供 Aurora 內 business sharding 路徑（不換引擎）。

撞牆訊號分型：你的 driver path 是哪一條（前置問題 0、F4 Frame 1）

讀者進來前先回答：你 為什麼 要評估 distributed SQL？三條 driver path 各自的訊號、適配 vendor、決策路徑都不同。

Path A — single-primary 寫入撞牆（9.C39 DoorDash 路徑、F4.2 + F4.6）

訊號：

• 寫入量持續成長、Aurora / RDS / Cloud SQL primary CPU + WAL flush rate 接近上限
• 轉折點 不是 IOPS、是 primary CPU + WAL flush rate（F4.2、DoorDash 策略段 1）
• 已嘗試 vertical scale primary、撞 instance ceiling

DoorDash concrete reference：2020-04-17 高峰 > 1.636 M QPS、multi-hour outage（觀察段表格）。Scope warning（F4.1、case 自帶警示）：1.636 M QPS 是 Aurora 撞牆的痛點 — 不是「CockroachDB throughput claim」、case 沒揭露遷移後單一 CockroachDB cluster 的峰值、只說「跑更多 cluster、alert volume 反而下降」。

適配 vendor：CockroachDB / Aurora DSQL / Spanner 都解、選擇看其他軸。

Path B — eventual consistency 缺口（9.C40 Netflix 路徑、F4.6）

訊號：原本用 Cassandra / Riak / DynamoDB eventual consistency、遇到 5 條件並存 需求：

1. multi-active topology（多 region 都可寫）
2. global consistent secondary index（跨 region 一致的二級索引）
3. global transaction（跨 row / 跨 region 的 ACID）
4. open source
5. SQL

Cassandra 在 transactional 場景下 湊不齊 這五項。Netflix 2019 評估後選 CockroachDB（5 條件 case 直接列出、判讀段 1）。具體場景：Studio Cloud Drive（強一致 metadata + 全球可寫）、Open Connect 控制平面、Spinnaker（持續交付）、Maestro（ML / 資料 workflow）、Gaming 控制平面。

適配 vendor：CockroachDB（open source + SQL 兩條件硬卡）、Spanner（若 GCP-only 可放鬆 open source 要求）。

Path C — 合規驅動的地理邊界 + 跨 boundary 業務邏輯需求（9.C41 Hard Rock 路徑、F4.10）

訊號：

• 法規要求資料留某地理邊界（Wire Act 跨州、GDPR 跨國、各州博彩牌照）
• 同時 業務邏輯需要跨 boundary（跨州統一帳戶 / 跨州 reporting / 欺詐偵測）

Hard Rock concrete reference：跨 8 州（AZ / IN / TN / FL / OH / IL / NJ / VA）+ AWS Outposts + 邏輯一個 cluster（觀察段表格）。詳細 schema 配置見 locality-aware schema。

適配 vendor：CockroachDB（locality + placement + Outposts）、Spanner（GCP region 內 placement、無 Outposts 等效）、Aurora DSQL 跨 region 強一致但 Outpost 部署現階段未完整覆蓋。

不該換 distributed SQL 的訊號

• single-region OLTP 已足夠
• 寫入量未撞 single-primary 天花板（Aurora db.r6g.16xlarge 還沒滿）
• 無跨 region 業務需求
• 無跨 boundary 合規需求

→ PostgreSQL / Aurora 足夠、distributed SQL overhead（寫入 2-5x latency、ops 複雜度）不划算。對應 9.C4 DraftKings 走 Aurora + application sharding 的路徑、不換引擎也能解單主寫入瓶頸。

數字口徑：本段「2-5x latency」屬通用工程估算（Raft / Paxos round trip 跟 single-leader replication 的 latency ratio）、case 未直接揭露對照數字、實際值依拓樸 / 寫入大小 / 一致性層次而異、應該以自家 benchmark 驗證。

核心機制：三軸 vendor 對比

完成 driver path 識別後、進三軸 vendor 對比。

軸 1 — 部署 topology

Path C 場景（Hard Rock Outposts hybrid）強制走 CockroachDB — 另兩家不提供等效部署。

軸 2 — Managed 成熟度

Scope warning（來源分層）：3 case 都沒揭露成熟度比對、本軸依 case + vendor 公開文件 + 外部知識合成：

• Spanner：10+ 年 Google 內部 + 外部 GA（依 9.C10 case + Google research paper、屬 vendor 公開文件 + dogfood frame）
• CockroachDB：自管 + Cockroach Cloud（managed 較新、依 Cockroach Labs 公告）
• Aurora DSQL：2024-05 GA（依 AWS 公告）

引用紀律：「Spanner 10+ 年」是 vendor 公開 + Google dogfood 的合成、不是 case 直接揭露的 production stability 數字。Aurora DSQL「2024-05 GA」屬 AWS 公開公告、production case ground truth 還在累積。引用時要明示來源層次。

軸 3 — SQL 相容性

PostgreSQL 相容性 audit checklist 4 項（F4.4、DoorDash 揭露）

DoorDash case 揭露 PG wire protocol-level 相容、SQL 行為「仍要驗證」。把這個警語展開成 audit checklist：

1. Serializable default：CockroachDB default SERIALIZABLE、PG default READ COMMITTED → application transaction 行為差異（細節見 transaction retry pattern）。Aurora DSQL 預設行為要看 AWS 公告。
2. Retry semantics：CockroachDB 發 40001 serialization_failure、application 必須包 retry loop。PG / Aurora 預設不需要、application 沒 retry middleware。Aurora DSQL 比照 CockroachDB 模型、需要 retry loop。
3. Partial index：CockroachDB 支援程度與 PG 有差異、application 用到的 partial index 要逐一驗證。Spanner GoogleSQL 跟 PG 行為不同。
4. 其他 SQL 行為：sequence、auto-increment、stored procedure、custom function、extension 等都需 case-by-case audit。

引用紀律：DoorDash 揭露的是「PG wire protocol-level 相容、SQL 行為要 audit」這個 fact、本章把 audit 內容展開成 4 項屬通用工程議題、不是 DoorDash case 直接揭露。

Consensus 機制差

三家共識機制的差異直接決定 external consistency 的實作路徑：Spanner 用 TrueTime + commit-wait 撐 external consistency；CockroachDB 用 HLC + max-offset 撐 linearizability、不保證 external consistency；Aurora DSQL 走類 Spanner 路徑但細節未完全公開。三家 multi-region 配置都吃 Cross-Region Quorum 的物理 latency tax。詳細機制見 HLC + Raft consensus。

Pricing model 差

• CockroachDB self-managed：node × resource、cluster 至少 3 node
• Cockroach Cloud / Spanner / DSQL：consumption-based（read / write / storage / network）

Sizing barrier 邊界（F3.16、9.C10 Spanner case 揭露）

Spanner 100 processing unit 起跳是 最小 footprint — 對中小 PostgreSQL workload 是 cost 邊界：

• workload 月寫入若只夠 PG db.m6g.large 級別、付 Spanner 100 pu 起跳 cost 不對
• CockroachDB 最小 3 node、storage / compute 線性 — 中小 workload 較友善
• Aurora DSQL consumption-based 無 minimum、中小 workload 最友善（但 production case 累積較少）

判讀：sizing barrier 是 vendor 強制最小 footprint、不是「啟動成本」— 即使 workload 縮小、minimum 不會降。中小 PG workload 直接套 Spanner = 付不必要的 minimum cost。

對應 distributed SQL 卡、quorum 卡、vendor lock-in 卡。

決策樹：七問題

前置問題 0 在 撞牆訊號分型 段已回答（你的 driver path 是 A / B / C 哪一條）。以下進三家 vendor 對比的七個問題。

問題 1：是否硬需求跨雲 / on-prem？

• Yes → CockroachDB（唯一選項；對應 9.C40 Netflix 跨 AWS region、9.C41 Hard Rock AWS Outposts 混合）
• No → 進問題 2

跨雲是 硬需求 而不是 fear-driven 訊號：

• 真硬需求：法規明文跨雲、acquisition 後多雲整合、vendor risk 政策強制
• fear-driven：「萬一 AWS 全球 outage」（多數公司實際走 single-cloud、跨雲 portability premium 卻沒實際 multi-cloud 部署）

數字口徑：本段「多數公司 single-cloud」屬通用工程估算、case 未揭露明確比例、實際分佈依產業 / 監管 / 規模而異。判斷自己是否需要跨雲時、看具體規範跟 risk 條款、不直接套通用比例。

問題 2：已在 AWS 還是 GCP 還是中立？

• AWS 深 → Aurora DSQL（操作模型對齊、PostgreSQL 相容）
• GCP 深 → Spanner（10 年成熟、Google 內部驗證）
• 中立 / 多雲 → CockroachDB（可 portable）

雲商生態深度判讀：IAM / VPC / monitoring / cost mgmt 已深度整合 AWS → Aurora DSQL 整合阻力低；同樣道理 GCP → Spanner。

問題 3：production 風險預算？

• 低（金融 / 醫療）→ Spanner（最成熟）或 CockroachDB（>5 年外部 production case）
• 中 → 三者皆可
• 高（願意當 early adopter）→ Aurora DSQL（2024 GA）

風險預算對應的不是「會不會掛」、是「邊界 case 文件成熟度 + production troubleshooting case 量」。Aurora DSQL 2024 GA、production case 累積中、邊界 case 仍在被發現。

問題 4：PostgreSQL 相容性是 hard requirement？

• Yes（既有 application）→ CockroachDB 或 Aurora DSQL（兩者都做 PG 相容、但走 audit checklist 驗證 SQL 行為）
• No → Spanner（GoogleSQL 也可）

PG hard requirement 訊號：application 用 PostgreSQL-specific feature（partial index、JSONB operator、PostGIS、PG extension 生態）、ORM / driver 深度綁 PostgreSQL wire。

問題 5：管理負擔誰承擔？

• 自管 → CockroachDB（唯一可自管）
• Managed → 都行、依雲商生態

自管 vs managed 不只是「省人月」、是「邊界 case 出現時誰修」— managed 的 vendor 負責、自管的自己負責。

問題 6：team size 是否撐得起 self-managed（F4.14、9.C41 Hard Rock + 9.C40 Netflix 揭露）

distributed SQL 的 ops 槓桿來自系統內建 Raft / placement 把「DBA 養單區、跨區 sync 養運維」工作量壓進系統內。

Hard Rock 50 人 tech team 估「若用 PostgreSQL 需多加 10-20 工程師」（觀察段表格 + 策略段 4）。Case 自帶警示：「省了 10-20 工程師」是 機會成本（沒招那麼多 DBA）、不是 節省支出（已 hire 後解雇）。引用必須明示口徑：

• 正確：「distributed SQL 對小團隊的 ops 槓桿 = 不必招那麼多 DBA」
• 錯誤：「上 CockroachDB 可裁員」、「節省人月支出」

Self-managed 規模化的另一極：Netflix 養 380+ cluster 需要 專屬 Database Platform Team（含 backup / upgrade / incident response / capacity review、F4.9）。沒這量級團隊直接 self-host 大規模 cluster 是 ops 自殺、Cockroach Cloud 才是合理路徑。判讀訊號：「self-managed cluster 數量 vs 平台團隊規模」轉折點 case 沒講具體閾值、引用時不可宣稱閾值、但方向清楚：

• team size 小（< 100 人 tech team、無專屬 DB platform team）→ Cockroach Cloud / Spanner / DSQL（managed）優先
• team size 大 + 有專屬 DB platform team → self-managed CockroachDB 可考慮
• team size 中等但要 self-host 大規模 cluster → 評估專屬 platform team 投資後再決定

問題 7：sizing 是否撐得起 vendor minimum（F3.16）

• Spanner 100 processing unit 起跳對中小 PG workload 是成本門檻、月寫入 < 某 baseline 時付 Spanner 起跳費不划算
• 中小 workload 但需 multi-region 強一致 → CockroachDB 3 node 起 / Aurora DSQL consumption-based 較友善
• 大 workload（已過 single-primary 撞牆訊號）→ 三家皆可、進問題 1-6 再篩

Cluster boundary 顆粒：per-app cluster vs 邏輯一個 cluster（CockroachDB cluster boundary SSoT）

位置標：本段是 _module-outline.md Section G「CockroachDB cluster boundary 顆粒」的 SSoT 主寫段、是 已選 CockroachDB 後 的拓樸決策（跟前面七問題 vendor 選擇分流）。其他 vendor cluster boundary 議題不在本段重複展開 — Aurora fleet 治理（business sharding / 200 cluster 模式）見 aurora/read-replica-scaling、MongoDB blast radius 切多 cluster（Toyota 20 DB 模式）見 mongodb/shard-key-selection。

選完 vendor 還有一個正交的拓樸決策：CockroachDB cluster 的「顆粒」要切多細。一個微服務一個 cluster（per-app）、還是多個微服務共用一個邏輯 cluster（shared / 邏輯一個 cluster）。這條軸的判讀獨立於跨雲 / 風險預算 / 管理負擔等七問題、是 cluster 拓樸 議題、不是 vendor 選擇議題。判讀核心是 blast radius 的取捨 — 是把故障半徑限縮在單服務（per-app）、還是接受邏輯 cluster 內事故跨業務影響但換 transactional cross-domain 能力（邏輯一個 cluster）。本段是 CockroachDB cluster boundary 顆粒的主寫位置、其他 sibling 文章（hlc-raft-consensus、survival-goals、locality-aware-schema）cross-link 不重複展開。

Per-app cluster（Netflix 380+ 路徑、F4.7 揭露）

每個微服務 / 每個業務邊界各自獨立 cluster。Netflix 揭露的具體形貌：380+ cluster、每個 cluster 規模小（屬「artery of small DBs」哲學、不是巨型 DB）、每個服務 own 自己的 schema 跟容量。

判讀訊號：

• 服務之間資料 硬隔離（compliance / blast radius / 不同 SLA tier）— 共用 cluster 一旦 schema migration / hot range 出事、影響面跨服務
• 跨服務 query 需求低（沒有 cross-domain JOIN 場景）
• 容量規劃可以 per-cluster（每個服務自己估、不需共池）
• 有專屬 Database Platform Team 養 cluster lifecycle（backup / upgrade / incident response / capacity review、F4.9）— ops surface area 隨 cluster 數 線性成長

代價：ops surface area 大、每個 cluster 都要獨立 upgrade / monitoring / capacity review。沒這量級平台團隊直接 self-host 380 cluster 是 ops 自殺。

邏輯一個 cluster（Hard Rock 路徑、F4.10 揭露）

業務邏輯上是 一個 CockroachDB cluster、物理上跨多地理 placement（locality + replication zone 把 range 釘到特定 region / AZ / Outpost）。Hard Rock 揭露的具體形貌：跨 8 州 + AWS Outposts、邏輯一個 cluster、跨州統一帳戶 / 跨州 reporting / 欺詐偵測在同一 cluster 內做 transactional query。

判讀訊號：

• 跨服務 / 跨地理需要 transactional query（跨州統一帳戶、跨業務統合 reporting）— 拆獨立 cluster 會破壞業務邏輯
• 合規顆粒 細 到 region / 州 / AZ、但 不要求 完全隔離 cluster（Wire Act 要求州內運算、但允許跨州 application 邏輯）
• Team size 中小（Hard Rock 50 人 tech team）、ops surface area 集中比攤平好管
• 容量規劃集中、跨服務資源共享（不同服務的 range 可以 colocate 同 cluster）

代價：cluster 內複雜度高（要設計 placement / locality / replication zone 把 range 釘對地方）、blast radius 是 整個邏輯 cluster、cluster 級事故影響跨業務。

兩條路徑的判讀軸

判讀順序：先問「跨服務 query 需要 transactional 嗎」— Yes 偏邏輯一個 cluster、No 進下一條；再問「服務之間 SLA / compliance 是否硬隔離」— Yes 偏 per-app、No 看 team / ops 槓桿。

跟 Aurora fleet 治理的本質差異

Aurora fleet 治理 SSoT（read-replica-scaling 邊界段）展開的是 Aurora cluster 之間 怎麼拆（business sharding / blast radius / read fanout），cluster 是 single-primary 抽象、拆 cluster 是 繞過 single-primary 上限。

CockroachDB cluster boundary 的問題不一樣 — CockroachDB 本身就是 distributed、單 cluster 內可橫向擴展、cluster boundary 是 業務 / 合規 / blast radius 邊界、不是繞 single-primary。

兩條路徑的 拆與不拆 動機本質不同。Aurora 拆是 被迫（單 cluster 撐不住）、CockroachDB 拆是 選擇（單 cluster 撐得住、拆是為了治理）。

跨 vendor 路徑對照

• Aurora fleet（DraftKings 200 cluster）— business sharding 繞 single-primary 上限、每 cluster 仍可多 service、平均負載低（9.C4 case 揭露單 cluster ~80 ops/sec、200 cluster 加總 17K ops/sec）
• CockroachDB per-app（Netflix 380+）— 微服務級拆 cluster、artery of small DBs、需要專屬 Database Platform Team；單 cluster 內 Range Sharding + Leaseholder 負責內部 scaling
• CockroachDB 邏輯一個（Hard Rock）— 跨地理單一 cluster、locality + placement 撐合規 + transactional 跨域、本地化讀靠 Follower Read 降低跨 region cost
• CockroachDB fleet per-jurisdiction（Standard Chartered）— 每監管市場一個 cluster、合規 禁止 跨市場資料流動時的 forced pattern、跟 Hard Rock 對照（合規顆粒粗到要拆 vs 細到能用 placement）

進階閱讀：合規驅動的 cluster boundary 選擇見 locality-aware-schema；單 cluster 容量規劃見 hlc-raft-consensus 容量與觀測段。

失敗模式：常見錯配

過度 fear AWS / GCP lock-in

承接 問題 1：是否硬需求跨雲 段的 fear-driven 訊號（多數場景單雲、跨雲是想像中需求）— 把 fear 當硬需求選 CockroachDB，付 portability premium（自管 ops + Cockroach Cloud 較新）卻沒實際 multi-cloud 部署，結果付的是 lock-in 保險、實際沒用上。

判讀：跨雲訊號要 具體場景（acquisition 後整合 / 法規明文 / vendor risk 政策強制）、不是 fear。

低估 DSQL 成熟度風險

2024-05 GA、production case 少、邊界 case 文件不全 — early adopter 才適合。production 風險預算低的場景（金融 / 醫療 / 合規嚴格）不應該選最新 GA 的服務。

Spanner 假設 PostgreSQL 全相容

Spanner PostgreSQL interface 是 子集、部分 PostgreSQL feature 不支援。應用 migration 仍需 audit、不可直接 lift-and-shift。

Self-managed CockroachDB 低估 ops cost（9.C40 Netflix concrete reference、F4.9）

Raft / backup / upgrade / monitoring 自管比 PostgreSQL 複雜、DBA bandwidth 沒到位變 disaster。Netflix 養 380+ cluster 需要 專屬 Database Platform Team — 含 backup、upgrade、incident response、capacity review。

判讀訊號：「self-managed cluster 數量 vs 平台團隊規模」轉折點 case 沒講具體閾值、引用時不可宣稱閾值、但方向清楚 — 小規模 self-managed 不需要、大規模一定需要、之間有 grey zone 要實際評估團隊能力。

用 distributed SQL 解 single-region OLTP

90% 場景 PostgreSQL / Aurora 夠用、distributed SQL overhead 是 2-5x latency（Raft round trip 額外成本）。沒撞 single-primary 寫入上限的情況下、上 distributed SQL 是付不必要的 latency premium。

合規邊界誤判

受監管市場可能 不能 用任何跨境 distributed SQL（Standard Chartered 模式）、要拆每市場獨立 cluster。反過來、合規顆粒小（跨州 vs 跨國）+ 跨 boundary 業務邏輯需求高（跨州統一帳戶）時、Standard Chartered fleet 拓樸不適合、需走 Hard Rock locality + placement 路徑（細節見 locality-aware schema）。

Sizing barrier 誤判（F3.16）

中小 PG workload 直接套 Spanner 100 pu 起跳、付的是不必要的 minimum cost。中小規模的硬一致 multi-region workload、CockroachDB 3 node / Aurora DSQL consumption-based 更划算。

Team size 誤判（F4.14）

把「省 10-20 工程師」當已 hire 後可裁員的節省支出、實際是 機會成本（沒招那麼多 DBA）。上 CockroachDB 不代表可裁掉現有 DBA — 現有 DBA 反而要轉型成 distributed SQL 運維。

容量與觀測

三家共同 metric

• write QPS
• cross-region latency p99
• storage growth
• replica lag（CockroachDB Raft / Spanner Paxos / DSQL replica）

觀測黑箱程度

• CockroachDB Console：暴露 Raft / range / leaseholder 細節、observability 細
• Spanner / DSQL：managed、metric 經 GCP Cloud Monitoring / AWS CloudWatch、observability 黑箱程度高 — 邊界 case troubleshooting 仰賴 vendor support

容量公式

write QPS × replication factor × cross-region latency = required node / capacity。中小 workload 撞 vendor minimum 才是真實 cost 下界。

Cost signal

三家定價模式不同、cross-region traffic 對 cost 影響都大：

• CockroachDB self-managed：node × resource、可控但要自運維
• Spanner：100 pu minimum + consumption、適合穩定 workload、中小 burst 不划算
• Aurora DSQL：consumption-based、burst 友善、長期穩定 workload 累計可能比 Spanner 高

回路徑

• 9.6 容量規劃模型
• 1.11 全球分散式 OLTP 完整對比

邊界與整合

Sibling deep articles

• HLC + Raft consensus（軟體時鐘 vs TrueTime）
• locality-aware schema（locality model 對比）
• survival goals（HA model 對比）
• transaction retry pattern（application contract 重塑）

Sibling 跨 vendor

• Aurora vendor overview（async cross-region、不是 distributed SQL）
• Spanner vendor overview 對照頁
• PostgreSQL vendor overview（單區 OLTP fallback）

Migration playbook

• PG → CockroachDB
• PG → Aurora DSQL

1.x 章節互引

• 1.11 全球分散式 OLTP 上游
• vendor lock-in 卡
• distributed SQL 卡

何時不用本文

• single-region OLTP 已夠（90% 場景）→ 用 PostgreSQL / Aurora、不必走 distributed SQL
• 無 multi-region requirement、無跨 boundary 合規需求 → 同上
• workload 規模未撞 single-primary 寫入上限 → 走 Aurora vertical scale + read replica 即可

相關連結

• CockroachDB vendor overview
• 9.C39 DoorDash（Path A — single-primary 寫入撞牆）
• 9.C40 Netflix（Path B — Cassandra 缺口、Database Platform Team）
• 9.C41 Hard Rock Digital（Path C — 合規驅動 + team size 槓桿）
• 9.C10 Spanner planetary scale（Spanner ground truth + sizing barrier）
• 9.C14 Standard Chartered（合規邊界 anti-recommendation）
• 9.C4 DraftKings（Aurora sharding 不換引擎路徑）
• 1.11 全球分散式 OLTP
• distributed SQL 卡 / vendor lock-in 卡 / quorum 卡
• 官方：Cockroach Labs Documentation / Spanner Documentation / Aurora DSQL Documentation