"Spanner"
- Spanner TrueTime API 深度：GPS + 原子鐘、commit wait、為什麼 line-rate scaling 才是設計目的
TrueTime 是手段、line-rate scaling 才是 Spanner 的設計目的。本文先扣商業邏輯：傳統 OLTP coordinator 為什麼是 bottleneck、Spanner 怎麼用 TrueTime + Paxos 換成拓樸感知多 leader；再展開 TrueTime ε / commit wait 數學、ε 暴衝失敗模式、cross-region voting 對 latency 的影響、跟 9.C10 Google internal dogfood 揭露的線性擴展模式對照
- Spanner Consistency Models 對照：external consistency vs serializability vs linearizability
external consistency、serializability、linearizability 是三個常被混用的概念。本文先精確定義三者差異、再用 line-rate scaling 對照表（PG SSI / CockroachDB / Spanner / Aurora DSQL）回答為什麼 Spanner 不只是『更強的 serializable』、最後用 9.C10 揭露的 cross-region quorum 100-200ms 物理硬限解釋『強一致 + 全球部署』的真實 cost
- Spanner Schema Migration Without Downtime + Interleaved Tables
Spanner DDL 是 long-running operation、用 TrueTime 給每次 schema change 分配 version timestamp、所有 read / write 對應自己 transaction timestamp 看到對應 schema。Interleaved table 是 storage-level parent-child 物理交錯、不是 logical FK。本文走 schema change lifecycle、interleaved layout 機制、backfill capacity 影響、5 production 踩雷、跟 PostgreSQL online schema change 對照
- Migration Playbook：Cloud SQL for PostgreSQL → Cloud Spanner
Cloud SQL → Spanner 是 paradigm shift 級遷移、不是 drop-in。本 playbook 走 6 規格面 Driver / Diff / Phase / Evidence / Cutover / Cleanup：Driver 段明示 sizing barrier（100 pu 起跳）跟 < 50ms write latency 兩條 no-go；Diff 段加 sizing / cost 第 7 規格面；Phase 0 含 sizing audit；Evidence 段補 cost crossover 報告；對照 9.C10 Google internal dogfood 邊界跟 Standard Chartered 受監管 banking case
- Spanner Change Streams (CDC)：捕捉資料變更、watch partition、下游整合與 DynamoDB Streams 對照
Change Streams 是 Spanner 把 commit 後的 row mutation 變成可消費事件流的 CDC 機制、用 data change record 攜帶 commit timestamp 把外部一致性延伸到下游。本文走 change stream 物件模型、watch partition 的 child partition 切分、Dataflow / Pub/Sub 下游整合、retention 與 staleness 失敗模式、跟 DynamoDB Streams 的 partition / ordering / retention 對照
- Spanner PostgreSQL dialect：PG-compatible interface vs GoogleSQL、相容子集邊界、何時選 PG dialect
Spanner PostgreSQL dialect 是建在 Spanner 分散式引擎之上的 PG-compatible 介面、提供 PostgreSQL 語法、型別與 wire protocol、但不是完整 PostgreSQL。本文先定義 PG dialect 跟 GoogleSQL dialect 的責任差異、再劃相容子集邊界（哪些 PG 功能不在、哪些 Spanner-only 概念仍要懂）、最後給選 dialect 的決策判準與 dialect 不可變更的失敗代價
- Spanner Graph (2024)：property graph 能力、跟 relational 表共存、適用場景與邊界
Spanner Graph 是建在 Spanner relational 引擎上的 property graph 能力、用 GQL 查詢 node 與 edge、底層仍是 relational table、graph 跟 SQL 共用同一份資料與 transaction。本文走 graph 物件模型（node / edge table 映射）、跟 relational 共存的設計、GQL 查詢、graph schema 不可逆設計的失敗代價、何時用 graph、何時用純 relational 或專用 graph DB
- Spanner ↔ BigQuery federation：OLTP/OLAP 分工、federated query、Data Boost、何時把分析 workload 分出去
Spanner 是 OLTP、BigQuery 是 OLAP、federation 讓 BigQuery 直接查 Spanner 的活資料、Data Boost 讓分析查詢用獨立運算資源不搶 OLTP CPU。本文先定義 OLTP/OLAP 的責任分工、再走 external dataset federated query、Data Boost 的 workload 隔離機制、federation vs change-stream-to-BigQuery 兩條整合路線的取捨、以及何時該把分析 workload 完全分出去
- CockroachDB vs Aurora DSQL vs Spanner：撞牆訊號分型 + 七問題決策樹
Distributed SQL 三選一決策樹。先用撞牆訊號分型識別 driver path（DoorDash 單主寫入撞牆 / Netflix Cassandra 缺口 / Hard Rock 合規驅動）、再走七問題（跨雲 / 雲商生態 / 風險預算 / PG 相容 / 管理負擔 / team size / vendor sizing barrier）。PostgreSQL 相容性 audit checklist 4 項、Spanner 100 pu sizing barrier、Hard Rock 「省 10-20 工程師」機會成本警示、Netflix Database Platform Team 規模