本章是 01 模組的基礎章節之一、之後章節（1.3 transaction boundary / 1.10 KV / Document 容量規劃 / 1.11 全球分散式 OLTP / 1.12 大規模 DB 遷移實戰）都會回引這層的概念。跨模組對接 9.4 Saturation Discovery 跟 9.5 瓶頸定位流程。

本章目標

學完本章後、讀者能夠：

1. 理解資料庫 client 為什麼應該共用
2. 分辨 query、exec、rows 與 transaction 的不同邊界
3. 了解連線池參數對高併發的影響
4. 設計多層 connection pool 架構（app + middleware + DB）
5. 識別 hot row / lock contention 並選擇對策
6. 用 read replica 擴 read traffic、注意 replication lag
7. 用 context 與 timeout 控制慢查詢
8. 判斷什麼情況該換 KV / 緩衝模式而非繼續硬擴 SQL

【觀察】資料庫 client 通常代表連線池入口

多數後端語言的資料庫 client 都會包住連線池或連線管理能力。一般情況下、服務會在啟動時建立可重用的 database handle、讓 request handler、worker 或 service layer 共用它、並在需要時從池子裡取出可用連線。

這種模型的好處是：

• 呼叫端不用自己管理每個連線的生命週期
• 多個 request 或 worker 可以同時發出資料庫操作
• 連線回收與重用由 sql.DB 處理

【判讀】高併發需要有界連線

高併發時的核心風險是把 application concurrency 誤解成 database concurrency。語言端的 thread、task、coroutine 或 goroutine 可能很容易建立、但資料庫有自己的容量上限；連線池只是把壓力從應用端平滑地送到下游、無法消滅壓力。

連線池調校的核心觀念是：

• SetMaxOpenConns 太低、request 會在應用端排隊。
• SetMaxOpenConns 太高、可能把 DB 直接打滿。
• SetMaxIdleConns 影響高峰與尖峰之間的重用效率。
• SetConnMaxLifetime / SetConnMaxIdleTime 影響長連線與資源回收節奏。

第一個爆的通常是連線、不是 CPU 或 disk

SQL DB 在 surge 場景的 first bottleneck 不是 CPU、也不是 disk I/O、是 連線數量。原因：傳統 RDB（PostgreSQL、MySQL）每個連線吃記憶體 + 一個 process / thread、connection pool 上限通常 1K-5K。流量湧入時、application 想開更多連線、DB 直接拒絕（PostgreSQL：FATAL: too many connections）、看起來像 DB 故障、實際是連線數限制。

對應 9.C29 Lemino — NTT DOCOMO 串流平台選 DynamoDB 而非 RDB 的原因之一是「connection limit 在快速流量增加時變成 bottleneck」。DynamoDB 的 HTTP API 模型沒有 connection state、天然解決這個瓶頸。

判讀順序：surge 期間 DB 看起來慢、先 SHOW PROCESSLIST / pg_stat_activity 看連線數、再看 CPU / disk。連線數已經滿、再加 CPU 沒用；要加 middleware pool（pgBouncer / ProxySQL）或換 HTTP-based DB。

多層 Connection Pool 架構

實務上 production-grade 服務的 connection pool 通常分三層：

Layer 1：Application pool（每個 instance 內）

• 每個 application instance 維護自己的 driver-level pool
• 典型大小：30-50 connection / instance
• 工具：HikariCP（Java）、SQLAlchemy pool（Python）、sql.DB（Go）

Layer 2：Middleware pool（共享層）

• PostgreSQL：pgBouncer（最常見、transaction pooling）、PgCat（rust、支援 sharding）
• MySQL：ProxySQL（query routing + pool）
• 為什麼需要：多個 application instance 同時打 DB、總 connection 數會爆
• pgBouncer 把 1000 application connection mux 到 50 個 DB connection、應用感覺有 1000 connection、DB 只看到 50

Layer 3：Database 端 max_connections

• PostgreSQL default 100、實務常設 200-500
• MySQL default 151、實務常設 1000-5000
• 每個 connection 吃記憶體（PG ~10MB、MySQL ~3MB）、設太高會 OOM

典型配置範例（中型網路服務）：

150 application instance × 30 connection (app pool)
2  → pgBouncer transaction pool (4 instance × 100 connection)
3  → PostgreSQL primary (max_connections = 200)

1500 application connection mux 到 200 DB connection、4 倍 multiplexing。

反模式：

• 跳過 middleware pool、application 直連 DB
• 應用 instance 50 個 × 30 connection = 1500 connection、PostgreSQL 直接拒絕

對應 9.C29 Lemino case — RDB connection limit 是 surge 場景的隱性 bottleneck、Lemino 選擇遷移到 DynamoDB 而不是擴 connection pool（因為 HTTP-based KV 沒這個問題）。

Query 反模式如何放大連線池壓力

連線池被占滿的根本原因不只是「連線數不夠」、還有「單一連線被占用的時間太長」。Query 反模式直接放大每筆 request 的連線占用時間：

• N+1 query 讓一個 request 占用連線從 1 個 round trip 拉長到 N+1 個。同樣的 throughput、需要 N+1 倍的連線數來 sustain
• Long-running transaction 把一個連線從幾毫秒占用變成幾秒，相當於把連線池的有效容量除以幾百倍
• 缺索引的 query 在熱表上跑 full scan、單筆 query 從 10ms 變成 1-5 秒、連線占用時間放大兩個數量級
• SELECT * 載入大欄位：reader 在反序列化大物件期間連線一直 hold、不是 query 本身慢、是 serialization overhead 拉長占用

這些反模式單獨看是「query 寫法問題」、但放到連線池語境就是「連線池容量被間接削減」。先用 1.13 query 反模式 的清單收回連線占用時間、再考慮加 9.14 connection pooler 中介層 — 順序顛倒會讓 pooler 治標不治本。

【策略】讀取與寫入要分開看

讀取的核心風險通常是慢查詢、掃描過大、N+1、熱點資料與連線被占住太久。寫入的核心風險則常常是 transaction 太大、衝突太高、鎖時間太長、重試邏輯不清楚。

讀取

• 用索引支援常見查詢條件。
• 避免一次載入過多資料。
• 需要分頁時、先考慮游標或穩定排序。
• 熱讀資料可以在上層加 cache、同時保留資料庫作為正式狀態來源。

寫入

• transaction 只包住真正需要一致性的範圍。
• transaction 範圍只保留必要資料操作、外部 API 呼叫、使用者等待或長迴圈應放在交易外。
• 高衝突寫入要搭配重試、唯一鍵或明確去重策略。
• 需要高吞吐時、先評估批次化、分段處理與有界並發。

詳見 1.3 Transaction Boundary 對 transaction 設計的深度討論。

Hot Row / Lock Contention 識別與處理

當多個 request 同時想 update 同一筆資料、會在 DB 層出現 lock contention。這跟 KV 的 hot partition 是同類問題、但 機制不同。

典型 hot row 場景：

• inventory counter：所有用戶搶同一個 product 庫存
• counter / metrics：實時計數器（view count、like count）
• queue / job ledger：所有 worker 競爭同一個 job table
• session：高頻 session 更新

識別訊號：

• pg_stat_activity / SHOW PROCESSLIST 顯示大量 lock waiting
• 整體 QPS 沒滿、但某些 endpoint p99 飆
• pg_locks / INFORMATION_SCHEMA.INNODB_LOCK_WAITS 有大量等待

對策：

1. 分散熱點：

• counter shard：把 1 個 counter 拆成 N 個 sub-counter、寫入時隨機選一個、讀取時 SUM
• 例：view_count_0 ~ view_count_9 → 10 倍寫入吞吐
• 對應 Hot Partition 卡片 在 SQL DB 的對應做法

2. Asynchronous batching：

• 不要每次點擊就 update counter、先進 in-memory buffer、定期 flush
• 應用層 Redis INCR + 定期同步回 SQL

3. Optimistic concurrency control：

• 用 WHERE version = ? 樂觀鎖、避免 SELECT FOR UPDATE
• 衝突時應用層 retry

4. 換 KV / cache：

• counter workload 本來就不適合 SQL transaction
• 用 Redis INCR、DynamoDB 的 atomic counter

5. Queue + worker 序列化：

• 把搶資源的 request 排隊、worker 序列化處理
• 對應 9.C15 Tixcraft 案例 — 售票把 inventory 搶購塞進 DynamoDB queue、legacy server 慢慢消費、避免 SQL hot row

Read Replica Scaling

當 read traffic 超過 primary 吞吐、用 read replica 擴 read。

Read replica 機制：

• PostgreSQL：streaming replication（async / sync）
• MySQL：async replication（binlog）
• Aurora：storage-level replication（lag 10-30ms）

Routing 策略：

1. Read / write split（application-level）：

• 應用層判斷 query 類型、寫走 primary、讀走 replica
• 工具：ProxySQL（MySQL）、application 自管

2. Routing 自動化（middleware）：

• pgBouncer + 路由規則
• HAProxy + health check

3. Stale read 容忍策略：

• 「能容忍秒級 stale」的 read → replica（用戶 profile、報表）
• 「不能 stale」的 read → primary（剛寫入後的查詢、餘額確認）
• read-after-write consistency：用 session token 標記「剛寫過」、N 秒內讀走 primary

Replication lag 監控：

• PostgreSQL：pg_stat_replication.replay_lag
• MySQL：SHOW SLAVE STATUS\G 的 Seconds_Behind_Master
• Aurora：CloudWatch AuroraReplicaLag
• 對應案例：9.C4 DraftKings Aurora — replication lag 從 30 秒降到 10-30ms、是切換到 Aurora 的關鍵改善

注意事項：

• replica 數量不是無限、Aurora 最多 15 個、PostgreSQL 通常 3-5 個（chain replication 更多但複雜）
• 跨 region replica 通常 async、不能保證 read-after-write
• 對應 9.C28 FanDuel Super Bowl 5-10x peak、需要動態加 replica

儲存層 replication vs compute 層 replication

Aurora / Cosmos DB / Spanner 的 replication 跟傳統 PostgreSQL streaming replication 是兩種本質不同的設計、決定 read replica 怎麼擴、replication lag 落在什麼量級、容量規劃要顧哪些瓶頸。

傳統 RDB（compute 層 replication）：

• primary 寫入後、把 WAL / binlog 流到 replica
• replica 自己 replay log、消耗 CPU 跟 disk
• primary 寫入量大、replica 跟不上、replication lag 飆
• 加 replica 增加 primary 的 replication 負擔、不能無限加

Aurora / Cosmos DB（storage 層 replication）：

• compute 跟 storage 分離、storage 是分散式 log-based
• replication 在 storage 層 處理、不經過 compute
• replica 不用自己 replay、直接讀同一份 storage
• 加 read replica 不增加 primary 寫入負擔
• replication lag 從 30 秒級降到 10-30ms（Aurora）

為什麼這層差異反映在應用層設計：compute 層 replication 的 replication lag 通常在秒級、應用層必須處理「剛寫的資料 N 秒內讀不到」的情境 — 常見補丁是 read-after-write consistency（session token 標記「剛寫過」、N 秒內走 primary）、cache invalidation 延遲、或刻意走 primary 的關鍵查詢路徑。Storage 層 replication 的 lag 在毫秒級、這些補丁多半不需要、read 可以幾乎無條件走 replica。對應 9.C4 DraftKings — 從 30 秒到 10-30ms 不只是「快」、是讓整個應用層 cache invalidation 跟 session routing 邏輯大幅簡化。對應 9.C23 Netflix Aurora consolidation — Aurora 75% performance improvement 主要來自 storage layer 設計、不是 CPU 改善。

選型含義：如果應用層 依賴 read-after-write（餘額確認、剛寫的查詢、session 狀態）、storage 層 replication 比 compute 層 replication 大幅簡化設計。代價是 vendor lock-in 加深、應用層綁定特定雲商。

對應 9.C32 Clearent Azure SQL Hyperscale 跟 Aurora 是同類設計（log-structured 分散式 storage）、選哪家看 application 已在哪個 cloud、技術哲學一致。Sharding 觸發點（managed DB 容量上限）跟業務一致性需求決定 sharding 粒度的討論、見 1.11 Sharding 粒度跟業務一致性需求。

【執行】查詢與 rows 的生命週期要收乾淨

查詢回傳 rows 後、呼叫端要負責把它關掉、並檢查迭代錯誤。這不只是記憶體管理問題、也會影響連線何時能回到池子裡。

典型模式是：

 1rows, err := db.QueryContext(ctx, "SELECT id, name FROM users WHERE status = ?", status)
 2if err != nil {
 3    return err
 4}
 5defer rows.Close()
 6
 7for rows.Next() {
 8    var id int64
 9    var name string
10    if err := rows.Scan(&id, &name); err != nil {
11        return err
12    }
13}
14if err := rows.Err(); err != nil {
15    return err
16}

【策略】慢查詢要靠 timeout 與上層限流處理

在高併發服務裡、database timeout 應由 request timeout、client timeout 與資料庫 timeout 共同定義。語言端需要能把取消、deadline 或 timeout 往資料庫 client 傳遞、讓慢查詢在合理時間內釋放資源。

如果下游開始變慢、通常要搭配：

• request-level timeout
• worker pool 或 semaphore
• queue 長度限制
• 降級或拒絕策略

這樣做的目標是避免應用自己堆出大量等待中的工作、最後把問題放大成整個服務卡死。

什麼時候該換 KV / 緩衝模式而非繼續硬擴 SQL

SQL 的 transactional 模型有結構性限制、超過某個規模硬擴 SQL 不如換工具。

換工具的訊號：

1. Connection saturate 但 CPU / RAM 還閒：connection 是 SQL 的早期 bottleneck。對應 9.C29 Lemino — RDB connection limit 是 surge 場景的瓶頸、換 DynamoDB（HTTP-based、無 connection 概念）解決。

2. Hot row contention 無法分散：應用層改不了 schema、無法把 counter shard、SQL 就是 contention 源頭。換 Redis atomic counter / DynamoDB atomic update。

3. Write throughput > 50K WPS 單機：sharding 工程成本變高、不如換 KV 或分散式 SQL。詳見 1.10 KV / Document DB 容量規劃 或 1.11 全球分散式 OLTP。

4. Flash-sale spiky workload：用 SQL 接搶購、connection 跟 lock 都會爆。對應 9.C15 Tixcraft 用 DynamoDB 當 durable queue、legacy SQL 慢慢消費。

5. 跨 region 強一致 OLTP：傳統 PostgreSQL / MySQL 跨 region 是 async、滿足不了強一致。換 Spanner / Aurora DSQL / CockroachDB（1.11）。

不要因為「現在 SQL 慢」就跳結論換 NoSQL — 先確認問題是 結構性的（connection、contention、跨 region）、不只是 調校問題（index、query、cache）。

【延伸】語言端的責任是邊界

這一章不討論 PostgreSQL、MySQL、SQLite 的語法差異、也不討論 migration 工具本身。語言端需要掌握的是：怎麼共用 database client、怎麼控制並發、怎麼縮小 transaction、怎麼把 timeout 和取消傳下去。

具體 schema、index、isolation level 與 migration 寫法、會放在這個模組的其他資料庫教材中。

案例對照

9.C1 Prime Day 是高併發章節的 上限參考點：Amazon 自家 Prime Day 在 24 小時內、DynamoDB 服務 1.51 億 RPS 毫秒級回應、Aurora 處理 5000 億次 transaction。這份數字的意義不是「要達到這個量級」、而是給定 可預期峰值 跟 無限預算 時、AWS 自家服務的設計上限長這樣。讀本章其他內部 baseline（connection pool、replica lag、isolation level）時、要記得最終物理上限遠高於大部分服務日常會碰到的水位。

跨語言適配評估

資料庫高併發邊界會受語言 runtime 影響。Thread-based runtime 要管理 thread pool 與 connection pool 的比例；async runtime 要確認 database driver 是否真正非阻塞（很多老 driver 只是包了 sync 在 thread pool 上、會吃 thread limit）；輕量 task runtime（Go、Erlang）要限制同時查詢數量、避免把大量 task 轉成下游連線壓力。強型別語言可以用型別保護 row mapping 與錯誤分類；動態語言則需要用 migration、runtime validation、contract test 與 fixture 保護 schema 邊界。

小結

高併發下處理 SQL 的核心原則：

1. database client 共用、不要每 request 新建
2. 連線池可控 — 三層架構（app pool + middleware + DB max_connections）
3. transaction 要短 — 詳見 1.3
4. rows 要關、避免連線被占住
5. timeout 要傳遞 — 從 request 一路到 DB
6. Hot row 要識別 — counter shard、optimistic concurrency、async batching、或換 KV
7. Read replica 要會用 — 但注意 lag、stale read 容忍度
8. 下游壓力要限流 — request timeout、worker pool、queue 長度、降級拒絕
9. 知道什麼時候換工具 — connection saturation、hot contention、flash-sale、跨 region 強一致都是 SQL 結構性限制的訊號

應用端並發可以很多、但資料庫連線必須受控、這兩者的邊界要分開管理。

讀「峰值」數字的工程細節

容量規劃時看到「100 萬 ops/分鐘」、「150 萬 RPS」這類數字、要拆三個維度看、否則容量規劃會錯位。

容量數字的三個口徑

最大瞬時 是觀測得到的最高峰值、通常是年度某秒、不能拿來訂 baseline。在 Grafana / CloudWatch / Datadog 上看 max 指標就是這個數字 — 用來知道系統 曾經 撐過多少、不是 日常 要撐多少。

99 百分位平均 是 capacity 規劃的主要依據。在監控工具看的是 p99 隨時間的平均值（rolling 30 天或 90 天）— 代表 99% 的時間流量低於這個水位。Auto-scaling 上限通常訂在這個值的 1.5-2 倍、確保 99% 時間有足夠 headroom。

常態流量 是 average / median、訂 cost baseline 跟 auto-scaling 的下限。在 PaaS（Aurora Serverless、Cosmos DB serverless）這是「最低保留容量」的依據；在 IaaS 是「永遠開著的 instance 數量」。

9.C5 Amazon Ads 揭露這個議題：「9000 萬 reads / 秒」通常是年度峰值最高一秒、不是平均。讀案例時要區分這三個口徑、否則容量規劃會錯位。

對應 9.C4 DraftKings — 「100 萬 ops/分鐘」≈ 17K ops/秒、跨 200 個獨立 cluster 平均下來每 DB 約 80 ops/秒。讀峰值要看 分散到多少 shard、不只看總數。

延遲改善要看 percentile、不是平均

「延遲降 90%」這類敘述要追問：是 p50 還是 p99？兩者改善幅度通常差很多、平均值會掩蓋尾巴問題。

對應 9.C20 Zomato — 「90% 延遲降」實際可能是 p50、p99 / p999 改善幅度通常較小。判讀重點：用戶體驗主要受 p99 / p999 影響、不是 p50。看到「平均 50ms 降到 5ms」要追問「p99 從多少降到多少」、否則可能用戶感受沒改善。

延遲監控的必要 percentile：p50、p95、p99、p99.9。p99.9 對 1000 個 request 才偵測一次、但通常代表系統最差表現、是 SLO breach 的早期訊號。

Headroom budget：事件型 vs 突發型峰值

Headroom budget 是 提前預留的容量空間、給可預期或不可預期的峰值用。讀「Super Bowl +50% no sweat」這種敘述、工程意義是團隊事前預留了 headroom、不是 vendor 神奇。

對應 9.C4 DraftKings — Super Bowl 是已知事件、+50% 是歷史經驗、所以可以提前 pre-scale。整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成「不流汗」。

兩種峰值的 headroom budget 規劃完全不同：

事件型峰值（已知時間 + 已知幅度）：

• 例：Super Bowl、Black Friday、票券開賣、財報日
• 規劃做法：歷史 peak × 預期成長 × headroom（通常 1.5-2x）= baseline、事件前 scheduled scale-up
• headroom 預算可以較低（20-30%）、因為峰值可預測、可在事件前測試
• 對應 9.11 高峰事件準備

突發型峰值（未知時間或未知幅度）：

• 例：突發新聞、KOL 推廣、競爭對手出包導致流量湧入、病毒式擴散
• 規劃做法：常態 baseline 預留高 headroom（50-100%）、加 auto-scaling 跟動態 capacity
• headroom 預算要高、因為事故發生前沒時間 scale
• 對應 9.C2 GR8 Tech AI 預測式擴容

判讀重點：事件型 headroom 適合可預測峰值、突發型 headroom 適合不可預測峰值；兩者預算邏輯不同。把事件型 headroom 套用在突發型場景、突發事件發生時容量會不足；把突發型的高 headroom 套用在事件型、會付大量浪費成本。

讀寫峰值錯位：dual peak workload

部分業務有 讀峰值跟寫峰值不同時段 的特性、容量規劃要按 peak 之和 而非 單一 peak。

對應 9.C4 DraftKings — 「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」。比賽進行時讀爆量（用戶看餘額、看下注狀態）、比賽結束 payout 時寫爆量（賠付寫進帳本）、兩個 peak 錯位。

容量規劃含義：

• 不能只規劃「讀 peak + 寫常態」或「寫 peak + 讀常態」
• 要規劃「讀 peak 跟寫 peak 各自的容量」、即使不同時發生、底層 DB 都要撐
• read replica 動態增減可以平滑讀 peak、但寫 peak 要靠 primary capacity 撐住

類似 dual peak 業務：

• 體育博彩：比賽中讀、payout 時寫（DraftKings）
• 票券：開賣前 30 分鐘讀爆量（用戶看座位）、開賣瞬間寫爆量（搶票）
• 電商促銷：促銷前讀爆量（用戶看價格）、促銷瞬間寫爆量（下單）
• 股票交易：開盤前讀爆量（看開盤價）、開盤瞬間寫爆量（送單）

判讀重點：dual peak workload 是業務 天然 特性、不是異常。容量規劃要識別這層、否則尖峰時段會踩到沒預期的瓶頸。

關鍵路徑切分：低頻流量保護

當系統有「高頻流量（如選位、瀏覽）」跟「低頻但關鍵流量（如付款、結算）」共存時、必須切分、否則高頻流量會塞爆低頻路徑、讓低頻關鍵業務無法完成。

對應 9.C15 Tixcraft — 拓元把 Payment EC2 拉出來、直連傳統金流 server、不放在搶票流量會打到的 ELB / DB 後面。讓「選位 + 下單」的高頻流量塞爆時、「付款」的低頻流量仍能跑。

切分策略：

• 資料路徑切分：高頻 query 走 DynamoDB / read replica、低頻關鍵 query 走 primary
• 連線池切分：高頻 service 跟低頻 service 用不同 connection pool、避免高頻吃光連線
• runtime 切分：低頻關鍵 service 部署到獨立 instance、不跟高頻共用 CPU / memory
• 限流切分：高頻 endpoint 設高限流、低頻關鍵 endpoint 設保護性低限流（避免 cascading failure）

判讀重點：切分前要先盤「哪些流量是業務關鍵但量小」、這些路徑要事先保護、不能等爆了再分開。

下一步路由

• 上游：Connection Pool 卡片
• 上游：1.13 應用層查詢反模式與 Query 預算（connection saturation 常因 N+1 / long transaction 放大、先檢查 query 寫法）
• 平行：1.2 Schema Design、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（SQL 不夠用時的替代）/ 1.11 全球分散式 OLTP / 1.12 大規模 DB 遷移實戰（換 DB engine 的決策跟流程）
• 跨模組：9.4 Saturation Discovery、9.5 瓶頸定位流程、9.6 容量規劃模型、9.13 擴展軸（hot row 是不可分散瓶頸的 application 層表現）
• Vendor：PostgreSQL、MySQL、Aurora
• 規模成長路線下一站 → 2.2 cache aside 與失效策略（連線池 / replica 擴完後、進入應用層快取設計）
• MongoDB connection storm 深入：MongoDB connection 管理與 cache 層 / replica set read preference
• Aurora read replica 擴展：Aurora read replica scaling（reader endpoint / lag 治理）
• Freshness token 卡片：Freshness Token（read-after-write 保證選項）

本章是 01 模組的基礎章節之一、結合 1.3 transaction boundary（交易範圍）、1.7 schema migration rollout evidence（演進證據）與 1.10 KV / Document 容量規劃（partition key 設計）一起讀。讀完後能回答：table 怎麼切、index 怎麼選、什麼時候 denormalize、partition 怎麼設、命名怎麼治理。

先定義狀態責任

資料模型第一步是定義狀態責任：哪些欄位代表正式狀態、哪些欄位是派生值、哪些欄位只為追蹤與審計。這個分層會直接決定 table 邊界與 relation 方向。

在訂單服務中、訂單主檔、付款狀態、庫存扣減屬於正式狀態；展示排序欄位、快取摘要屬於派生值；版本號、更新時間與來源欄位屬於可追蹤證據。把三類混在同一模型裡、後續查詢與演進成本會持續上升。

詳見 1.8 State Ownership 與 Query Boundary。

Table 與 Relation

table 切分要對齊業務聚合邊界。聚合內需要交易一致性的欄位、放在同一交易可控範圍；跨聚合流程透過事件或引用關係接續。relation 的責任是表達資料約束、不是替代流程編排。

主鍵策略要先回答「如何穩定識別」與「如何支援查詢」。自然鍵可讀性高但變動風險高；代理鍵穩定且易擴展、常搭配業務唯一鍵一起使用。外鍵策略則要平衡完整性與演進自由度：正式核心域可強約束、跨域整合可由應用層保護並保留遷移彈性。

主鍵選擇實務：

ID 設計不只是「選個格式」，而是在五個維度做取捨。先理解取捨、再按場景選型。

ID 設計的五個取捨維度

ID 類型選型矩陣

選型決策流程

1需要跨機器唯一？
2  └─ 否 → Bigint sequence（最簡單、效能最好）
3  └─ 是 → ID 對外部可見？
4           └─ 是 → 隱私敏感？
5                    └─ 是 → UUID v4（不可預測）
6                    └─ 否 → UUID v7（有序、DB 友好）
7           └─ 否 → 空間敏感（8 byte vs 16 byte）？
8                    └─ 是 → Snowflake（需要 machine_id 協調）
9                    └─ 否 → UUID v7（簡單、標準）

有序 ID 的 DB 效能影響

B-tree 索引的插入效能和 key 的分布有直接關係。UUID v4 的隨機分布導致每次插入都可能落在 B-tree 的不同 leaf page，造成大量隨機 I/O（page split、cache miss）。UUID v7 的時間戳前綴讓插入集中在 B-tree 的尾端，接近 sequential insert。

上表數字是基於 NVMe SSD 環境的量級估算（源自 UUID v4 的 random page split 成本約為 sequential 的 1/3-1/4 這個 B-tree 特性推導），實際效能依硬體和 workload 而定。核心結論：UUID v7 的插入效能約為 v4 的 3 倍，接近 bigint sequential。

隱私考量：v4 vs v7

UUID v7 的前 48 bit 是 Unix 時間戳（毫秒精度）。攻擊者拿到 UUID v7 可以推算「這個 ID 在幾點幾分產生」。這在不同場景有不同風險：

經驗法則：對外暴露給不可信第三方的 ID 用 v4（不可預測），內部 ID 用 v7（有序、效能好）。

各語言的標準庫支援

Go 的 google/uuid v1.6+ 內建 uuid.NewV7()，效能約 350ns/op（含 crypto/rand），和 JSON 解析（5-10μs）、DB 寫入（200μs）相比不是瓶頸。

對應 KV 案例：9.C5 Amazon Ads partition key、9.C15 Tixcraft composite key 都是主鍵策略的延伸。

Index 設計

index 設計要從查詢路徑反推、不是從欄位列表前推。每個高頻查詢至少要回答三件事：過濾條件是什麼、排序規則是什麼、回傳範圍有多大。這三件事能否由索引覆蓋、決定了 latency 與成本。

Index 類型對照：

常見設計原則：

1. 先保護交易關鍵查詢、再處理報表與後台查詢
2. 複合索引依查詢過濾與排序順序排列、避免僅憑欄位熱門度排列
3. 大表變更前先評估索引建立成本與回退方案、避免在高峰時段同步放大風險
4. 定期 review 未用 index（PostgreSQL pg_stat_user_indexes、MySQL sys.schema_unused_indexes）— 寫入吞吐被舊 index 拖垮
5. partial index 對 boolean / status column 特別有用 — 只 index 「pending」「failed」等小集合

Index 反模式：

• 每個欄位都建 index：寫入吞吐被拖垮
• 不看 EXPLAIN 就建 index：可能跟 query planner 不對齊
• 用 OR 條件依賴單一 index：query planner 不一定能用
• 大表 ALTER INDEX 不分批：lock 整個表

Denormalization 模式

normalize 是 SQL 的預設、但 denormalize 有時是更好的工程選擇。

Precomputed aggregate：

• 把 COUNT / SUM 結果存在 parent row 而非每次 query 算
• 例：posts.comment_count 存實際值、不每次 SELECT COUNT
• 風險：consistency（comment 寫入後 count 沒更新）
• 對策：用 trigger 或應用層 transaction 確保同步、或定期 reconcile

Embedded one-to-many：

• 小量 1-many 關係可以 embed 成 JSONB / nested column
• 例：order.line_items JSON column、不另建 line_items table
• 風險：個別 line item 查詢不便
• 適合：line items 通常一起讀寫（同 transaction boundary）

Materialized view：

• 預計算 query 結果、定期 refresh
• 適合：複雜 JOIN / aggregation 重複跑
• 風險：refresh window 內看到舊資料

Read model（CQRS）：

• 寫入路徑跟讀取路徑用不同 schema
• 寫入 normalize、讀取 denormalize 成不同 read model
• 詳見 1.8 State Ownership

對應案例：

• 9.C27 Disney+ watch list — denormalize 用戶 metadata、跨裝置查詢方便
• 9.C5 Amazon Ads — DynamoDB single-table design 是極端 denormalization

Partition 策略

單表 > 1 TB 時、partition 是必要的維運手段。partition 不是「擴 storage」、是「讓 vacuum / index / DROP 可分批跑」。

Partition 類型：

• Range partition：按 timestamp / id 範圍切。orders_2024_q1, orders_2024_q2…
• List partition：按枚舉值切。orders_us, orders_eu…
• Hash partition：按 hash 均勻切。適合無自然切分維度的大表

Partition 設計要點：

1. partition key 必須出現在 多數 query 的 WHERE clause（partition pruning 才能生效）
2. partition 數量 適中（10-100）— 太少 partition 太大、太多 partition metadata 開銷大
3. 老 partition 可以 DROP 或 archive、儲存成本可控
4. cross-partition unique constraint 限制 — 唯一鍵必須含 partition key

對應案例：

• 9.C4 DraftKings — 200 個獨立 Aurora cluster 是極端 partition by business
• 9.C5 Amazon Ads — DynamoDB 透明 partition、應用層不必管

Schema Evolution 友好設計

schema 從 day 1 就要為演進設計、不能假設「以後不會改」。

避免 breaking changes：

• 加欄位：safe（nullable 或 default）
• 刪欄位：unsafe（先讓所有 code 不再讀 → 部署 → 再刪）
• 改欄位類型：unsafe（先加新欄位、雙寫、backfill、移除舊欄位）
• 改欄位名：unsafe（同上）
• 加 NOT NULL constraint：unsafe（先 backfill default、再加 constraint）

Evolution-friendly schema 原則：

1. 欄位 nullable by default：除非業務不允許 null、否則先 nullable、之後再 tighten
2. 避免大表 ALTER TABLE：用 Expand / Contract 模式
3. predict breaking changes：訂版本、跟 application code 同步演進
4. schema version column：每 row 帶 version、應用層按版本處理
5. migration 工具版本控：Flyway / Liquibase / Atlas / golang-migrate 必須有

詳見 1.6 Database Migration Playbook 跟 1.7 Schema Migration Rollout Evidence。

Naming 與一致性

命名規則的責任是維持跨版本可讀性。table、column、index 的命名若沒有一致語意、migration 與故障排查會持續變慢。穩定做法是把命名和業務語意對齊、並保留可辨識版本與作用域。

Naming 慣例：

• Table：複數名詞、snake_case（orders, payment_methods）
• Column：snake_case、明確語意（created_at 不是 ts）
• Foreign key：{referenced_table}_id（user_id 指 users.id）
• Boolean：is_* / has_* / can_*（is_active, has_subscription）
• Timestamp：*_at for events（created_at, paid_at）、*_on for dates（born_on）
• Index：idx_{table}_{cols}（idx_orders_user_id_created_at）
• Unique constraint：uq_{table}_{cols}
• Foreign key constraint：fk_{table}_{ref}

避免的反模式：

• 縮寫不一致（u_id vs user_id）
• 隱性意義（status 是 enum、值在哪裡？）
• 跨表同義不同名（user.name vs customer.full_name）
• 反向命名（name_first vs 業界 first_name）

schema 演進時、命名與結構要一起考慮。欄位重命名、拆欄位、合併欄位都應配合 Expand / Contract 與 schema migration 策略、讓新舊版本在過渡期可共存。

判讀訊號

常見誤區

把 schema 設計等同於「先能寫入就好」、會把結構債延後到流量成長與事故時一次爆發。資料模型的工程價值在於可演進性、不在於初版欄位數量最少。

把索引當成效能補丁、忽略查詢模型與資料責任、也會讓後續維護成本持續疊加。索引與查詢要一起設計、才能在演進中保持穩定。

把 normalize 當成 絕對守則、忽略 denormalize 的工程效益。1NF / 2NF / 3NF 是理論起點、不是 production 必須。

案例對照

案例回寫

資料建模議題可以用 GitHub 2018 Oct21 MySQL Topology Incident 做回寫練習。讀這個事件時、先看跨區拓樸切換如何影響資料一致性、再回到本章檢查三件事：聚合邊界是否清晰、交易查詢與對帳查詢是否分層、修復時是否有可追蹤欄位與對帳鍵。

這個案例主要支撐的是「查詢與資料模型邊界」判讀、不直接支撐 transaction retry 或 queue replay 調校；若問題是重試放大、應轉到 1.3 或 3.x 章節處理。

當事件呈現長時間人工比對或查詢語意漂移時、先修正本章的 query boundary 與 naming 一致性、再補 1.6 資料庫轉換實作 的驗證與回退路徑。

跨模組路由

schema 設計會直接影響後續可靠性與事故處理。

1. 與 1.3 的交接：交易一致性邊界落在 transaction boundary。
2. 與 1.6 的交接：演進策略落在 資料庫轉換實作。
3. 與 1.7 的交接：欄位責任進入 production rollout 時、讀 Schema Migration Rollout 證據實作示範。
4. 與 1.8 的交接：state ownership 跟 query boundary 設計落在 State Ownership。
5. 與 1.10 的交接：KV / Document 的 partition key 設計落在 KV / Document 容量規劃。
6. 與 4.20 的交接：查詢與資料驗證證據進入 Observability Evidence Package。
7. 與 6.11 的交接：高風險 schema 變更進入 Migration Safety。
8. 與 8.19 的交接：資料修復與回退決策記錄進入 Incident Decision Log。

下一步路由

• 平行：1.3 Transaction Boundary、1.8 State Ownership
• 下游：1.6 Database Migration Playbook / 1.7 Schema Migration Rollout Evidence / 1.10 KV / Document 容量規劃
• Vendor：PostgreSQL index 設計、MySQL InnoDB clustered index、DynamoDB single-table design
• DynamoDB schema 深入：single-table design / partition key 反模式 / GSI / LSI 設計
• MongoDB schema 深入：schema design pattern / shard key 選型
• Cosmos DB schema 深入：partition key 設計

本章從業務邊界切分開始、進入 isolation level 工程細節、再到 retry 策略、最後處理跨服務 / 跨 region 的 distributed transaction。讀完後讀者能回答：transaction 範圍該多大、isolation 該訂多嚴、deadlock 怎麼處理、跨服務一致性怎麼設計、什麼時候該換 Saga 模式。

邊界先於語法

交易邊界先從業務動作切分、再回到 SQL。建立訂單、扣庫存、寫付款狀態是一個動作；更新推薦分數、寫審計摘要、送通知事件屬於不同節奏、適合拆成後續流程。

當同一個動作內同時包含高延遲外部呼叫、交易範圍會直接放大鎖持有時間。穩定做法是把交易內責任收斂在「需要同時成功」的資料集合、讓外部呼叫或延伸副作用透過 queue / outbox 交給後續流程。

Isolation Level 五級深度

SQL 標準定義四個 isolation level、實務上 PostgreSQL / MySQL / Spanner 等實作有微妙差異。理解各級的具體行為、才能在 正確性 vs 性能 之間做取捨。

0. Read Uncommitted（dirty read 可能）：

• 可讀到別的 transaction 還沒 commit 的資料
• 多數 DB 不真的支援這級（會 fallback 到 Read Committed）
• 實務不要用

1. Read Committed（PostgreSQL / Oracle 預設）：

• 只讀到 commit 的資料
• 同一個 transaction 內、多次 SELECT 同一筆資料可能讀到不同值（non-repeatable read）
• 適合：read-heavy workload、不要求同 transaction 內 read consistency

2. Repeatable Read（MySQL InnoDB 預設）：

• 同 transaction 內 read 一致（snapshot at transaction start）
• 不防 phantom read（標準定義）、但 InnoDB 的 RR 加 gap lock 實際上防住了
• 適合：報表類 transaction、需要 snapshot 一致性

3. Serializable（最強）：

• 看起來像所有 transaction 序列執行
• 兩種實作：strict 2PL（lock-based、MySQL）vs SSI（snapshot isolation + 衝突檢測、PostgreSQL）
• 衝突時會 serialization failure、應用層必須 retry
• 適合：金融交易、ticketing inventory、需要絕對正確

4. External Consistency / Linearizable（Spanner、Aurora DSQL）：

• 比 Serializable 更強：跨 transaction 的順序跟 wall clock 一致
• 全球分散式系統的特殊取捨
• 詳見 1.11 全球分散式 OLTP 的 Spanner TrueTime 段
• 詳見 9.C10 Spanner case

選擇原則：

• 90% 業務用 Read Committed 夠
• 報表 / 對帳用 Repeatable Read
• 金融交易 / inventory 用 Serializable
• 全球強一致用 Spanner / Aurora DSQL 等 linearizable 系統

Isolation 跟 Retry 的關係

isolation level 的責任是定義交易彼此可見性。Read Committed 在高併發寫入下可維持一般業務一致性；Repeatable Read 與 Serializable 提供更強約束、同時提高鎖競爭與重試頻率。

併發交易的常見結果是 deadlock 或 serialization failure。這些結果代表資料庫在保護一致性、應用層需要把它視為可重試路徑：

• 重試次數有上限（通常 3-5 次）— 避免 retry storm
• 重試間隔有抖動（exponential backoff + jitter）— 避免同步衝突
• 重試前提是動作可重入（idempotent）— 不會放大副作用

對應 Exponential Backoff 跟 Idempotency 卡片。

Optimistic vs Pessimistic Locking

當多個 transaction 同時操作同一筆資料、有兩種防衝突策略：

Pessimistic locking（悲觀鎖）：

• SELECT ... FOR UPDATE、提前 lock 行
• 適合：衝突機率高、retry 成本高
• 缺點：lock 期間其他 transaction 等待、容易 deadlock

Optimistic locking（樂觀鎖）：

• 不 lock、用 version column 或 WHERE old_value = ?
• commit 時若 version 不對、整個 transaction 失敗、應用層 retry
• 適合：衝突機率低、性能優先
• 缺點：高衝突場景 retry 多、整體吞吐反而低

選擇邏輯：

• 衝突 < 5% → optimistic（更高吞吐）
• 衝突 > 30% → pessimistic（避免 retry waste）
• 中間區 → 量測再決定

對應 hot row contention 處理（1.1）— 高衝突 hot row 通常該換 KV / cache、不該硬擴 SQL。

服務情境：Checkout 多層邊界

電商 checkout 是典型的 transaction boundary 設計題、可拆成兩層邊界。

第一層：交易層（即時一致）：

• 建立訂單主表
• 寫入訂單項目
• 扣減可售庫存
• 寫入付款待確認狀態

第二層：延伸層（最終可達）：

• 寄訂單確認 email
• 同步 CRM 系統
• 觸發 analytics event
• 更新推薦模型

這種切法讓交易控制面跟非同步控制面各自穩定：

• 交易層關注 鎖、隔離與回退
• 非同步層關注 投遞、重試與補償

對應案例：

• 9.C4 DraftKings Aurora — 體育博彩 ledger、200 個獨立 cluster 處理 transaction、後續 settlement 跑非同步
• 9.C14 Standard Chartered — 跨市場銀行 transaction、各市場獨立、跨市場結算非同步

Distributed Transaction：2PC vs Saga

當業務動作跨越 多個服務 / 資料庫、傳統 ACID transaction 不夠用、需要 distributed transaction 模式。

Two-Phase Commit (2PC)：

• 階段 1：coordinator 詢問所有 participant「你能 commit 嗎？」
• 階段 2：所有都說 yes → coordinator 廣播 commit；任一說 no → 廣播 abort
• 優點：強一致、ACID 保證
• 缺點：coordinator failure 會 block 所有 participant、性能差、跨服務複雜
• 適合：少數高一致性需求的場景（金融交易、跨多 DB 一致性）

Saga Pattern：

• 把長 transaction 拆成多個 local transaction + compensating transaction
• 每個 step 成功 → 進下個；任一失敗 → 倒回去跑 compensation
• 例：訂單 step1 扣庫存、step2 收款、step3 送貨。step2 失敗 → 跑 step1 的 compensation（補庫存）
• 優點：高可用、性能好、容易擴展
• 缺點：不是強一致、中間狀態可見、compensation 必須設計
• 適合：multi-service 業務流程、可接受 eventual consistency

Choreography vs Orchestration：

• Choreography：每個 service 自己決定下一步（event-driven）
• Orchestration：中央 orchestrator 控制流程（state machine）
• 大規模傾向 orchestration（容易追蹤、debug）、小規模 choreography 足夠

對應案例：

• 9.C15 Tixcraft — 售票 + 付款分開：DynamoDB 接搶單（local transaction）、legacy server 跑付款（compensation 處理庫存回退）
• 9.C28 FanDuel — 投注 → 結算的 saga 流程

詳見 Outbox Pattern 卡片 跟 3.3 Outbox Pattern。

跨 Region Transaction：CAP 取捨

當 transaction 必須跨 region 同時成立、CAP 定理開始作用。

Single-region transaction（PostgreSQL / MySQL / Aurora）：

• ACID within region
• 跨 region 用 async replication、不是 transaction

Multi-region eventual consistency（DynamoDB Global Tables、Cosmos DB session/eventual）：

• 各 region 都能寫
• LWW 或 application-level conflict resolution
• 不是 ACID、是 BASE

Multi-region strong consistency（Spanner、Aurora DSQL、CockroachDB）：

• 跨 region linearizable transaction
• 代價是 latency（跨洲 100-200ms quorum）
• 對應 1.11 全球分散式 OLTP

決策邏輯：

• 業務不需要跨 region 強一致 → single-region OLTP + eventual replication
• 需要跨 region 強一致 + 接受 latency → Spanner / Aurora DSQL
• 需要跨 region 寫但接受最終一致 → Cosmos DB session / DynamoDB Global Tables

判讀訊號

常見誤區

交易保護的是一致性、不是吞吐量最大化。把過多步驟包進單一交易、會同時放大鎖競爭與回退成本。把交易切成可驗證的業務單位、能讓高併發下的可預期性更高。

重試保護的是暫時性失敗、不是所有失敗。沒有冪等保護的重試會放大副作用、特別是金流、庫存、配額這類正式狀態。

isolation level 不是「越強越好」。Serializable 比 Read Committed 慢數倍、且 retry rate 上升。只在 必要 場景用最強 isolation、其他場景用最低可接受 isolation。

distributed transaction 不是「跨服務就要 2PC」。多數 multi-service 業務用 Saga 更可靠、2PC 是少數場景的特殊工具。

案例對照

案例回寫

交易邊界可用 GitHub 2018 Oct21 MySQL Topology Incident 做回寫。先看事件中的主從切換與恢復順序、再回到本章判讀三件事：哪些變更必須同交易成功、哪些副作用應拆到 outbox、哪些錯誤屬於可重試而非立即回退。

這個案例主要支撐的是「提交與副作用切分」判讀、不直接支撐 schema naming 或 cache freshness；若問題落在資料命名或快取新鮮度、應回到 1.2 或 2.x。

若事件出現資料已寫入但外部流程落後、或重試後副作用重複、先收斂本章的邊界切分與重試前提、再同步更新 3.3 outbox pattern 與 3.4 consumer 設計。

跨模組路由

交易邊界設計會直接影響後續模組的可操作性。

1. 與 03 的交接：交易外副作用透過 outbox pattern 與 consumer 落地。
2. 與 1.7 的交接：付款狀態拆欄位、雙寫與回呼更新要進入 Schema Migration Rollout 證據 的驗證流程。
3. 與 1.10 / 1.11 的交接：KV 跟全球分散式 OLTP 的 transaction model 不同、選型時要回到本章邊界判讀。
4. 與 04 的交接：交易失敗需要對齊 Observability Evidence Package 的查詢與證據欄位。
5. 與 06 的交接：高風險交易變更納入 Release Gate 與 Migration Safety。
6. 與 08 的交接：交易層回退或 fail-forward 判斷記錄到 Incident Decision Log。

下一步路由

• 平行：1.1 高併發資料存取（connection pool / hot row）
• 下游：1.6 資料庫轉換實作 / 1.7 Schema Migration Rollout 證據 / 1.10 KV / Document DB 容量規劃 / 1.11 全球分散式 OLTP
• 跨模組：3.3 outbox pattern / 6.11 Migration Safety / 9.5 瓶頸定位流程
• 卡片：Isolation Level / Transaction Boundary / Idempotency / Outbox Pattern / Exponential Backoff
• Spanner 一致性深入：TrueTime API 深入 / Spanner 一致性模型對照
• CockroachDB retry / 隔離深入：CockroachDB transaction retry pattern / Aurora DSQL / Spanner / CockroachDB 決策樹
• Aurora 寫入語意深入：Aurora 儲存層架構（6 寫 / 4 讀 quorum 對 transaction 的影響）

本章從 hexagonal architecture 的 port / adapter 模式出發、處理 mapping、error translation、testing 跟跨服務 transaction 等實作議題。讀完後讀者能設計一個可演進、可測試、可換 DB 的 repository 層。

Port / Adapter 邊界

Repository 在 hexagonal architecture（也叫 ports & adapters）中是 outbound port 的實作。

Port（domain layer 定義）：

• 抽象 interface / protocol、描述 領域語意
• 不暴露 SQL、不暴露 DB 細節
• 例：type OrderRepository interface { Find(id) Order; Save(order); ... }

Adapter（infrastructure layer 實作）：

• 實作 port、負責跟具體 DB 對話
• 翻譯 domain entity ↔ DB row
• 翻譯 DB error → domain error
• 例：type SQLOrderRepository struct { db *sql.DB }

為什麼這層抽象有價值：

1. 可替換性：DB 換 vendor 時、domain layer 不必改
2. 可測試性：在 domain layer test 時可注入 memory fake、不必起 DB
3. 語意清楚：domain 不被 SQL 細節污染、business rule 集中
4. 演進可控：schema 改動時、只在 adapter 改 mapping、不擴散到全程式

詳見 Repository Adapter 卡片。

Adapter 三個核心責任

adapter 接收應用層輸入、負責三件事：查詢與命令組裝、row mapping、錯誤翻譯。業務規則判斷留在 service / usecase 層、adapter 聚焦在資料持久化語意與資料庫行為。

邊界清楚的好處是演進可控。schema 調整時、只需要在 adapter 收斂欄位映射與查詢變更、不用把 SQL 細節滲透回 domain 層。

1. 查詢與命令組裝

把 domain 操作翻成具體 SQL / NoSQL query。實作層級有取捨：

• Raw SQL：完全控制、易追 query plan、但容易拼錯字、易 SQL injection
• Query builder（GORM Build、Knex、SQLAlchemy Core）：型別安全、不寫字串、但學 DSL
• ORM（GORM、SQLAlchemy ORM、Active Record）：高抽象、自動 mapping、但隱藏細節、容易產生 N+1

詳見下方「ORM vs Query Builder vs Raw SQL」段。

2. Row Mapping 與 Nullable Handling

row mapping 的責任是把資料庫欄位轉成穩定模型。欄位型別、時間格式、枚舉值、可空欄位都要有明確轉換規則。可空欄位需要顯式處理、避免把「缺值」誤當有效預設值。

Nullable handling 模式：

• Optional type：Go sql.NullString、Java Optional<T>、Rust Option<T>、Python Optional[T]
• Sentinel value：用特殊值代表 null（不推薦、易混淆）
• Default fallback：null → 預設值（要明確、不要悄悄轉換）

資料模型演進時、新舊欄位可能共存。adapter 要支援過渡期讀寫相容、讓版本切換能分批進行。詳見 1.7 Schema Migration Rollout Evidence。

3. Error Translation

error translation 的責任是把底層錯誤分類成應用層可決策訊號。唯一鍵衝突、外鍵限制、交易衝突、連線逾時、都需要翻譯成可行動錯誤類型、而不是將原生錯誤字串直接外漏。

常見錯誤分類：

這層翻譯會直接影響重試、回退與事故判讀。分類越穩定、越能在 06/08 模組形成一致決策語言。

ORM vs Query Builder vs Raw SQL

選 mapping 工具是 repository adapter 的核心取捨。

Raw SQL

• 優勢：完全控制 query plan、易 tune
• 優勢：大規模 query 性能最好
• 限制：易拼錯字、IDE 支援差
• 風險：一不小心就 SQL injection（用 prepared statement / parameterized query）
• 適合：性能極限關鍵 / 複雜 query / 已有 SQL 專家團隊

Query Builder

主流工具：Knex（Node）、SQLAlchemy Core（Python）、jOOQ（Java）、sqlc（Go）、Diesel（Rust）。

• 優勢：型別安全、IDE 自動完成
• 優勢：不需要 ORM 的複雜度
• 優勢：仍可看到生成的 SQL
• 限制：學 DSL 成本
• 適合：中等複雜度 + 想要安全性 + 想看 SQL

ORM

主流工具：GORM（Go）、SQLAlchemy ORM（Python）、Active Record（Rails）、JPA / Hibernate（Java）、Entity Framework（.NET）、Prisma（TypeScript）。

• 優勢：CRUD 操作快速、boilerplate 少
• 優勢：自動 mapping、自動 transaction
• 優勢：migration 工具通常整合
• 限制：隱藏 SQL 細節、易產生 N+1 query
• 限制：複雜 query 反而比 raw SQL 難寫
• 風險：lazy loading 容易意外性能問題
• 適合：CRUD 為主的應用、團隊偏業務開發

選型決策

1. 小團隊 + CRUD-heavy：ORM（快速 prototype、boilerplate 少）
2. 中型 + 混合需求：Query Builder（安全 + 仍能寫複雜 query）
3. 大型 + 性能極限：Raw SQL + Query Builder（複雜 query 用 raw、簡單用 builder）
4. microservice 私有 store：通常 Query Builder 為主（見 9.C23 Netflix 模式）

ORM 反模式

• find() 隨手呼叫導致 N+1 query
• lazy loading 在 view 層觸發 query
• 用 ORM 寫複雜 aggregation（應該 raw SQL）
• 不 eager load 關聯資料

Testing 策略

repository 是 infrastructure 層、test 策略不同於 domain layer。

Memory Fake（unit test 友善）

• 用 in-memory implementation 滿足 port interface
• 不必起 DB、快、可隔離
• 適合：domain layer test、test repository 的 呼叫者
• 反模式：用 memory fake test repository 本身（測不到實際 SQL 行為）

Integration Test（驗證真實 DB 行為）

• 用 testcontainers / Docker 起真實 DB（PostgreSQL / MySQL）
• 跑真實 SQL、抓真實 error
• 用 transaction rollback 隔離各 test
• 適合：test repository adapter 本身

Contract Test

• 驗證 adapter 對外語意穩定：同一輸入是否得到一致輸出、同一錯誤是否被穩定分類、同一查詢語意在 schema 演進後是否保持相容
• 測試重點是邊界語意覆蓋、資料庫產品特性覆蓋是另一件事
• 例：「unique 衝突必須回 ErrAlreadyExists」這條 contract、不管底層是 PostgreSQL / MySQL / SQLite 都成立

詳見 Contract 卡片 跟 6.10 Contract Testing。

SQLite 作為 test DB

• 起 quick、無 external dependency
• 但 SQL dialect 跟 PostgreSQL / MySQL 有差異
• 適合：簡單 query 的 test、不適合 production-fidelity test
• 對應 SQLite vendor page

Transaction 傳遞

repository 操作通常要支援「我自己起 transaction」跟「在已有 transaction 內操作」兩種模式。

Pattern 1：repository 自己起 transaction：

1func (r *OrderRepo) PlaceOrder(ctx context.Context, order Order) error {
2    tx, _ := r.db.BeginTx(ctx, nil)
3    defer tx.Rollback()
4    // ... 操作 ...
5    return tx.Commit()
6}

問題：跨多個 repository 時無法共用 transaction。

Pattern 2：unit of work pattern：

1func (s *Service) PlaceOrder(ctx context.Context, order Order) error {
2    return s.uow.Do(ctx, func(tx Transaction) error {
3        s.orderRepo.Save(tx, order)
4        s.inventoryRepo.Decrease(tx, order.Items)
5        s.paymentRepo.Create(tx, order.Payment)
6        return nil
7    })
8}

把 transaction 從 repository 抽到 unit-of-work、跨 repository 共用。

Pattern 3：context-based transaction：

• 把 transaction 塞進 context
• repository 從 context 拿 transaction（有 → 用、沒有 → 自己起）
• Go 常用 pattern、但有「context 不該裝這種東西」的爭議

選擇邏輯：

• 簡單應用：pattern 1 夠用
• 跨 repository transaction：pattern 2 或 3
• 大型 application：pattern 2（最清楚）

詳見 1.3 Transaction Boundary。

Microservice 私有 Store 對應

現代 microservice 設計強調「每個 service 私有 DB」、不跟其他 service 共用。

對 repository adapter 的影響：

• 每個 service 自己的 schema、自己的 adapter
• 跨 service 不直接 DB query、要透過 API
• transaction 不跨 service（用 Saga 或 outbox）
• 對應 9.C23 Netflix、9.C7 Lyft 100+ microservice

反模式：

• 共用 DB schema、不同 service 都 query 同一張表 → 強耦合、schema 改一個影響全部
• 跨 service 用 DB foreign key → 不能 enforce、會壞掉

Repository Adapter 五個常見變體

實務上 repository 不止「CRUD」這個樣態：

1. Pure CRUD repository：Find / Save / Delete、最簡單
2. Aggregate repository：操作 aggregate root、含 nested entities
3. Read model repository（CQRS）：專門 read、不 write
4. Event-sourced repository：存 events、不存 state
5. Cached repository：包一層 cache（pass-through、refresh-ahead）

實作時要明確選哪種、不要讓一個 repository 跨多種 pattern。

判讀訊號

常見誤區

把 repository adapter 寫成「直接包 SQL 的工具函式」、容易讓業務規則與資料邏輯混雜。邊界失焦後、schema 演進與事故修復都會擴大影響面。

把資料庫錯誤原樣往上拋、也會讓上層決策不穩定。錯誤翻譯是可靠性控制面的必要前置。

把 ORM 當銀彈、忘了 SQL 還在背後。N+1 query、lazy loading 災難、複雜 aggregation 反而難寫 — 這些都是「過度信任 ORM 抽象」的後果。

把 memory fake 拿來 test repository 本身、不會抓到實際 DB bug。memory fake 是給 呼叫者 test 用的、不是給 repository test 用的。

案例對照

案例回寫

adapter 邊界可用 3.C9 反例 的資料一致性段落回寫。若事件中出現同一錯誤在不同路徑被不同方式處理、通常代表 adapter 的錯誤翻譯與契約分層不足。

這個案例主要支撐的是「錯誤分類與契約映射」判讀、不直接支撐 broker delivery 參數調整；若根因在 ack/retry 節奏、應回到 3.1/3.2。

回寫步驟是先盤點錯誤分類、再對齊重試與回退決策、最後把分類結果映射到 6.10 Contract Testing 與 Schema 演進 的驗證欄位、讓發版前可先發現漂移。

跨模組路由

1. 與 1.2 的交接：欄位與索引語意回到 schema design 與資料建模。
2. 與 1.3 的交接：交易錯誤與重試語意回到 transaction 與一致性邊界。
3. 與 1.12 的交接：cross-DB migration 時、repository 是 關鍵抽象 — 詳見 大規模 DB 遷移實戰。
4. 與 6.10 的交接：跨服務契約一致性回到 Contract Testing 與 Schema 演進。
5. 與 8.19 的交接：資料層錯誤判斷與回退決策回到 Incident Decision Log。

下一步路由

• 平行：1.2 Schema Design、1.3 Transaction Boundary
• 下游：1.6 Database Migration Playbook / 1.12 大規模 DB 遷移實戰
• 跨模組：6.10 Contract Testing 與 Schema 演進 / 9.5 瓶頸定位流程
• 跨 vendor adapter 深入：DynamoDB single-table design（document KV adapter 邊界）、MongoDB schema design pattern（document adapter 的 ODM 取捨）、Cosmos DB MongoDB API vs SQL API（multi-API adapter 取捨）

本章聚焦在 資料層（DB 自身）的攻擊面、跟 7 資安與資料保護模組 的網路 / 身份 / 加密層形成互補。讀完後讀者能盤點：DB 上有哪些 攻擊路徑、哪些 外洩管道、哪些 偵測訊號。

資料層弱點的主要軸線

資料層弱點可分成三條軸線：存取邊界、狀態邊界、資料流邊界。

存取邊界：看 authorization 與 tenant boundary。哪些 user / role / tenant 可以 read / write 哪些資料。 狀態邊界：看 transaction 與 isolation level。同時讀寫時的 race condition、TOCTOU。 資料流邊界：看查詢結果、匯出、備份、觀測與支援工具的資料暴露路徑。

三條軸線各有典型攻擊模式、要分別檢查。

DB 攻擊面的外圍層次

DB 攻擊面分三層、每層有典型攻擊向量跟防禦邊界、紅隊盤點要逐層檢查。傳統做法常把 90% 精力放在最內層 DB、外圍兩層的失守會讓內層防禦變成無效投資。

Layer 1：DB 本身（最直接、防禦最成熟）— SQL injection、authentication、authorization、RLS 都在這層。

Layer 2：DB 周邊產品（最常被忽略）— file transfer service（MFT）、API gateway、search proxy、admin console 都「接 DB」、且通常 perimeter 設定比 DB 鬆。對應 MOVEit 2023 — MOVEit Transfer 是 file transfer 產品、漏洞讓攻擊者直接存取後端資料、屬於 edge-exposure 類別的批量利用事件。判讀重點：任何「接 DB」的產品都屬於 DB 攻擊面、要盤 所有上游 caller 產品。類似結構還有 GoAnywhere MFT 2023、Progress WS_FTP 2023。

Layer 3：認證信任根（最致命、最少人想到）— signing key、token issuer、IAM federation 都決定「誰能宣稱是哪個 user」。對應 Microsoft Storm-0558 — 簽章金鑰外洩後、攻擊者偽造可被驗證的身分權杖、application 層的 BOLA / BOPLA / RLS 都會在底層 trust 失守時被繞過。判讀重點：DB authorization 接受上游認證結果、上游 trust 失守時、DB 層的精緻設計就被旁路掉。

設計含義：紅隊盤點順序是由外向內。先盤「誰能通過認證」（trust root）、再盤「通過認證後能打到哪些產品」（caller surface）、最後盤「打到 DB 後能做什麼」（DB authorization）。三層任一失守、後續層的防禦投資都會被旁路。

攻擊模式 1：注入類

SQL Injection：

• 經典攻擊、把 user input 拼進 SQL 字串
• 防禦：parameterized query / prepared statement、絕不字串拼接
• 二階注入：input 已存進 DB、後續 query 時才觸發 — 比一階更難偵測

NoSQL Injection：

• MongoDB / DynamoDB 也可能被注入（不同形式）
• MongoDB：{$where: ...} operator injection、{$ne: null} 跳過 auth
• DynamoDB：FilterExpression 注入（少見、需要特定 application 結構）
• 防禦：白名單 user input、不直接組 query operator

ORM Injection：

• 即使用 ORM、Raw() / Exec() 等 escape hatch 仍能注入
• 用 where clause 接 user input 不過濾、ORM 不會自動防
• 防禦：永遠 parameterized、Raw() 必須 review

Second-order Injection：

• 第一次寫入時看起來安全、第二次讀出來時觸發
• 例：username 帶 SQL fragment、寫入時 escape、後續 admin 查詢時不 escape
• 防禦：所有 DB output 都當 untrusted、不能依賴「寫入時的 escape」

真實事件對照：MOVEit 2023 mass exfiltration 是 SQL injection 升級成 mass data exfil 的代表性事件。Progress Software 的 MOVEit Transfer 是 file transfer 產品、漏洞讓未認證攻擊者直接打到後端 DB、跨上百家客戶持續外洩。判讀重點：file transfer 這類「次要產品」也接 DB、且因為通常 perimeter 設定鬆、變成最先被打的點。

對應 Attack Surface 卡片 跟 7.3 entrypoint security。

攻擊模式 2：授權繞過類

BOLA（Broken Object Level Authorization）：

• 用戶 A 改 user_id 為 B 的請求、後端不檢查就回 B 的資料
• 最常見的 web app 漏洞（OWASP API Top 10 第 1 名）
• 防禦：每個 DB query 都帶 WHERE owner_id = current_user_id、不只信 URL parameter
• 對應 BOLA / IDOR 卡片

BOPLA（Broken Object Property Level Authorization）：

• 物件級檢查過了、但物件內 某些屬性 不該被存取 / 修改
• 例：用戶能更新自己 profile、但不該改 is_admin flag
• 防禦：應用層 allowlist 屬性、不是 deny-list
• 對應 BOPLA 卡片

Mass Assignment：

• 應用層直接把 request body bind 到 DB row、含未檢查欄位
• 例：Order.fromJSON(request.body) 自動 set is_admin_override 為 true
• 防禦：明確 allowlist 哪些 field 可從 request 來
• 對應 Mass Assignment 卡片

Multi-tenant Boundary Leak：

• multi-tenant SaaS：tenant A 的 query 不該看到 tenant B 的資料
• 常見錯誤：忘了 WHERE tenant_id = ?、用 application 層而非 DB 層強制
• 進階防禦：Row-Level Security（PostgreSQL RLS）、由 DB 強制 tenant boundary

真實事件對照：Snowflake 2024 credential abuse 揭露 資料平台帳號沒強制 MFA 的代價、攻擊者拿到外洩 credential 後直接 query 多家客戶的 Snowflake account、大量外送資料。判讀重點：DB 認證 = 資料邊界、但雲端資料平台預設未必開 MFA、要主動 enforce。對應 Microsoft Storm-0558 紅隊版 — signing key 洩漏後攻擊者直接以任意 user 身份查任意 mailbox、application 層 BOLA / BOPLA 全部失效、因為攻擊者通過了底層 trust boundary。

攻擊模式 3：資料外洩類

Excessive Data Exposure：

• API 回應比需要的多（內部欄位、PII、信用卡末四碼）
• 「前端會 filter」是反模式 — 攻擊者直接看 raw response
• 防禦：DTO / response schema 明確列哪些欄位可回、不要 SELECT *
• 對應 Excessive Data Exposure 卡片

Log / Trace 洩漏：

• 把 query 含 PII 直接寫進 log、log 進 SIEM、SIEM 給多人看
• distributed tracing 把 query 跟 user_id 都記下來
• 防禦：log 前 redact、敏感欄位 mask、distributed tracing 的 attribute allowlist

Backup / Export 洩漏：

• DB backup 沒加密、放公開 S3 bucket
• 客服 / BI 工具導出 CSV、檔案被搬到不該的地方
• 防禦：backup encryption、export audit、emit-once endpoint
• 真實事件對照：LastPass 2022 backup chain — 開發環境被入侵後、攻擊者沿著 備份路徑 拿到 production vault backup、雖然 vault 內容是加密的、但 master password 弱的客戶可被離線爆破。判讀重點：備份檔案的 存放位置 跟 加密狀態 是攻擊面、不只 production DB。

Support Tool Path：

• 客服 admin 工具可以 query 任何用戶資料
• 內部工具沒有 audit log、不知道誰看了什麼
• 防禦：客服 tool 必須 audit log、敏感欄位 mask、access 按 ticket 限制
• 真實事件對照：Okta Support System 事件 — 攻擊者拿到 Okta support 系統存取後、能看到客戶上傳的 HAR 檔（含 session token）、再用 token 進客戶 tenant。Support tool 的 查詢能力 跟 資料分級 不對等就會放大事故面。

對應 7.4 data protection and masking 跟 7.7 audit trail。

攻擊模式 4：競態 / TOCTOU 類

TOCTOU（Time of Check Time of Use）：

• 檢查時是 A 狀態、用的時候是 B 狀態
• 例：先 SELECT 確認 user 有 100 credit、再 UPDATE 扣 100、中間有別的 transaction 改了 credit
• 防禦：用 SELECT ... FOR UPDATE 鎖、或用 atomic operation（UPDATE ... WHERE credit >= 100）

Double-spend 攻擊：

• 多個 request 同時花同一筆錢
• 防禦：optimistic locking with version、unique constraint、或交易層 serializable
• 詳見 1.3 Transaction Boundary 的 isolation level 段

Race condition in business logic：

• 註冊：兩個 request 同時用同一個 email、可能都成功
• 防禦：unique constraint 在 DB 層、不只 application 層 check

攻擊模式 5：DoS / 資源耗盡類

Unrestricted Resource Consumption：

• 沒分頁的 SELECT *、用戶傳 ?limit=999999
• 沒 timeout 的長 query
• 防禦：query timeout、pagination 強制上限、rate limit

Connection 耗盡：

• 攻擊者開大量 connection、佔光 DB connection pool
• 防禦：connection pool 限制、application 層 connection limit、PgBouncer 共享

Storage 灌爆：

• API 允許大量 insert、storage 被填滿
• 防禦：rate limit、quota per tenant、auto-archive

對應 Unrestricted Resource Consumption 卡片。

何時要提高紅隊檢查優先級

下列訊號出現時、資料層弱點通常會放大成系統風險：

• 角色與租戶模型快速增加、且查詢條件跨多個權限層
• migration 頻率提高、且 schema 與讀寫流程同時變更
• 匯出、對帳、客服查詢與搜尋索引共用同一批敏感欄位
• 事故修復高度依賴人工 SQL 與臨時腳本
• 新引入的 ORM / query builder / cache layer 改變了 query 路徑

失敗代價

資料層弱點會把單點錯誤轉成長尾影響。

• 越權查詢：直接資料洩漏 → 通知監管 + 客戶 + 媒體
• 交易邊界混亂：部分寫入與狀態偏移 → 對帳成本 + 退款處理
• 資料外洩進 log / backup：拉長處理週期 → 跨 team 清理
• support tool 濫用：無 audit log → 無法追究、信任成本上升
• 業務全面中斷：資料事件升級成 availability 事件、整條業務鏈停擺

這些問題的共同代價是：修復路徑長、稽核負擔高、信任成本上升。

真實事件對照：Change Healthcare 2024 ops impact 是「資料事件變成業務連續性事件」的代表。攻擊者進入 DB 後、不只外洩資料、還破壞處理能力、讓整個美國醫療支付網路停擺數週。判讀重點：DB 失守不只代表 資料外洩 一種損失、還可能直接停掉 上游業務流程、評估代價時要把這層算進去。MGM 2023 identity lateral impact 是另一個對照：vishing 拿到 identity 後橫向到核心系統、酒店訂房 / 自助 check-in / 老虎機全停。資料層的攻擊代價要跨業務流量去評估、不只看 DB 本身。

Incident 三角：DB 事故的同步處置

DB 事故的處置三角是 同步 執行三件事、共同消除攻擊者在處置間隙繼續入侵的時間窗：

1. 漏洞修補：補上被利用的具體漏洞或 misconfiguration
2. Session / 憑證失效：撤銷所有可能被攻擊者拿到的 session、token、credential
3. 異常痕跡清查：盤點攻擊者已經做了什麼、哪些資料動過、哪些 backdoor 留下

同步執行的理由是 攻擊者擁有平行能力：用已拿到的 credential 在 patch 完成前重新進入、或用清查前還沒被發現的 backdoor 繞過修補。線性執行「先修漏洞、再失效憑證、再清查」會留下兩個時間窗、攻擊代價被放大。

對應 MOVEit 2023 — 公告漏洞到攻擊者大規模利用之間只有數小時、單純等 vendor 修補來不及。實務做法是：

• 發布前：對外服務建立 即時隔離開關、不等 vendor patch
• 事故中：先把入口下線（DNS 切走 / WAF rule 全擋）、同步進行 patch + token revoke + audit log review
• 前提：事先有 inventory（知道哪些產品接 DB）+ 自動化失效能力（不是手動逐個 revoke）

這個三角是 能力前提、不是 當下決策。事故當下發現缺哪一角、就只能線性執行、攻擊代價會被放大。

偵測與審計

紅隊檢查不只「找漏洞」、也要設計 持續偵測：

1. Query audit

• DB query 寫進 audit log（誰、什麼時候、查了什麼）
• 不只 admin tool、application 也要 audit
• 對應 Audit Log 卡片

2. Anomaly detection

• 異常 query pattern（突然 SELECT 全表、跨 tenant 範圍）
• 異常 export volume
• Cross-tenant token 異常（同一 issuer 出現本不應跨域的軌跡）
• 對應 7.13 detection coverage

Cross-tenant token 偵測是觀測單一 issuer 發出的 token 在不應跨域的 tenant 出現的能力。對應 Microsoft Storm-0558 — 偽造 token 形式上完全合法、單看 token validation 找不到異常、要看 軌跡（哪個 issuer 的 token 跨了哪些 tenant、跟歷史 baseline 比對）。這層偵測需要 application 跟 DB layer 都記下「token 來源 → tenant 目的」的對應、才能事後比對。

對應 Snowflake 2024 揭露的異常查詢偵測維度：

• query 體積異常（單一 user 短時間內查詢量遠超日常）
• 來源 IP 異常（從合法網段突然變成未知 endpoint）
• 跨 schema scan 模式（單一 user 突然查多個 tenant 的表）
• 匯出頻率異常（單位時間匯出次數遠超基線）

這些維度都需要足夠歷史 telemetry 建立基線、新部署的 DB 在累積基線前處於偵測盲區、要靠 絕對閾值 補（例如「任何 user 單次查詢 > 1GB 都告警」、不等基線）。

3. DB-level monitoring

• slow query log（可能是 attacker 在 enumerate）
• failed login（DB 層 connection attempt）
• privilege escalation event

4. Periodic review

• 每季 review role / permission
• 每年 audit support tool access pattern
• migration 後重新檢查 access boundary

認證 + 網路雙重防護

DB 認證 = 資料邊界、但雲端資料平台（Snowflake、BigQuery、Cosmos DB）預設未必開 MFA、且 網路層通常 open（任何 IP 都能嘗試連線）。任一層失守、攻擊者就進來。

對應 Snowflake 2024 — 外洩 credential + 未強制 MFA + 沒設 network policy → 攻擊者直接從任意 IP 用 leaked credential 登入、查多家 tenant 的資料。

雙重防護設計：

• 網路層：network rule allowlist（只允許公司 IP / VPN / 雲端 NAT 連線）— leaked credential 即使有效、也碰不到 DB
• 認證層：強制 MFA + 條件式存取（context-aware：時間 / 地點 / 裝置）— 即使網路層失守、credential 還要過 MFA
• 應用層：API key / service account 跟 user credential 分開、各有 lifecycle

兩層獨立、單層失守仍能阻擋資料外送。資料平台預設應強制 MFA + network policy、把「credential 外洩 = 資料外送」這條捷徑切斷。

批量憑證撤銷的工程能力

批量憑證撤銷能力是事故當下「攔停攻擊者」的核心動作、要 快速、大量、選擇性 執行可疑憑證撤銷。這個能力屬於 事先準備、事故當下臨時建來不及。

最小能力清單：

• Credential inventory：列出所有 active credential（user password、API key、service account token、session）。事故當下若靠工程師記憶查、會漏掉長期沒人動的 service account 或 OAuth integration、變成攻擊者 persist 的後門。Inventory 要 自動產生、不是人工維護的 spreadsheet。
• 分批撤銷 API：能按 user group / service / scope 批次撤銷、不是逐個 revoke。批次需要 idempotency key、避免重複撤銷產生競爭。受影響範圍大時、逐個撤銷可能需要數小時、攻擊者持續外送資料。
• 撤銷後 audit：撤銷紀錄要存（誰被撤、什麼時間、什麼原因、誰執行）、避免事後爭議。
• 重新發放流程：撤銷後使用者要重新登入、SSO + MFA 流程在事故當下要能撐住瞬間湧入的重新驗證請求。若流程卡住、會在「沒攻擊但用戶進不來」狀態下被迫降回安全等級較低的應急 fallback、形成新攻擊面。

對應 Snowflake 2024 的事故處置 — 平台級事故影響數百家客戶、撤銷必須跨 tenant 同步進行、單一客戶手動撤銷來不及。

長期可重複匯出工件

Long-lived repeatable export artifact 是事故後仍能持續產出資料的工件、屬於跨事故時間軸的 attack surface。攻擊者拿到一次、就能長期外送、不需要每次重新進入系統。常見類型：

• 預先生成的報表 URL（內部 BI tool 給 download link、URL 通常長期有效）
• API key 綁定的 export endpoint（key 沒過期、endpoint 一直能匯出最新資料）
• 資料平台的 scheduled / saved query（以合法 user 身份定期執行匯出）
• Database backup 的 share link（雲端儲存的 signed URL、有效期可達數年）

防禦設計：

• 預設短 TTL：所有匯出 URL / signed link 預設 1-24 小時失效
• 單次性匯出：sensitive export 限定 emit-once、用過就失效
• 匯出記錄審計：每次匯出寫進 audit log、定期審查哪些 endpoint 異常高頻使用

對應 Snowflake 2024 連結的紅隊 problem-card「Long-lived repeatable export artifact」— 這類工件的核心風險是 憑證撤銷後仍可運作、修復不只要撤 credential、還要盤所有由該 credential 建立的長效工件。

備份 vs 正式環境的權限獨立性

備份系統是 獨立 的攻擊面、跟正式環境要 不同權限域。常見錯誤是「備份用同一組 IAM principal 跟同一把 KMS key」、結果正式環境被打、攻擊者沿著 備份路徑 拿到所有歷史資料。

對應 LastPass 2022 backup chain — 開發環境被入侵後、攻擊者沿著備份路徑拿到雲端備份的加密保管庫資料、形成長尾資料保護壓力。判讀重點：備份的 存放位置、金鑰管理、存取權限 都是攻擊面、不只 production DB；備份檔加密本身不足以擋下取走後的離線分析。

權限獨立性設計：

• 不同 IAM principal：production 跟 backup 用不同 service account、production 帳號沒有 backup 讀權限
• 不同 KMS key audience：production 用 production key、backup 用 backup key、兩者 lifecycle 分離
• 不同 audit log：production read / write 跟 backup read 在 不同 audit stream、後續調查能區分「正常運作」vs「備份被讀」
• 不同 access pattern review：定期審查哪些 principal 在哪些時段讀 backup（正常情況很少有人讀 backup、頻繁讀取是異常訊號）

「正式環境的接管不直接通到備份」是設計準則、不是 best practice 加分項。對應 1.9 reconciliation 的備份 / PITR 段討論。

最低控制面

資料層在討論具體服務前、先定義四個控制面最穩定：

1. 權限模型：資料存取與角色、租戶、操作情境的對應關係
2. 交易與一致性模型：哪些操作必須同成敗、哪些可以延遲一致
3. 資料分級與遮罩模型：哪些欄位可回傳、可觀測、可匯出
4. 恢復模型：錯誤資料如何比對、回復、追蹤與稽核

案例對照

07 主案例（產品 / 平台事故）

07 紅隊案例（攻擊鏈 / 入侵路徑）

紅隊案例庫的完整入口看 紅隊案例參考地圖 — 那邊有按攻擊階段（exposure / exfiltration / identity / supply-chain）的完整索引。

跨模組路由

1. 與 1.3 的交接：race condition / TOCTOU 用 transaction boundary 的 isolation level 處理
2. 與 1.4 的交接：repository adapter 應用 allowlist / parameterized query — repository adapter
3. 與 1.8 的交接：state ownership 決定哪些資料需要嚴格存取控制 — State Ownership
4. 與 7.2 的交接：identity / authorization 邊界 — Identity & Access Boundary
5. 與 7.4 的交接：資料保護與遮罩 — Data Protection and Masking
6. 與 7.7 的交接：audit trail — Audit Trail and Accountability Boundary
7. 與 7.13 的交接：detection coverage — Detection Coverage and Signal Governance
8. 與 8.19 的交接：事故時的資料層判讀 — Incident Decision Log
9. 合規驅動的多 region 部署選型：Aurora global database 多 region、Aurora 跨 AZ failover RTO、Data Residency 知識卡

關聯卡片

• Attack Surface
• Trust Boundary
• Excessive Data Exposure
• BOLA / IDOR
• BOPLA
• Mass Assignment
• Audit Log
• Data Reconciliation
• Tenant Boundary
• Unrestricted Resource Consumption

本章跟 1.12 大規模 DB 遷移實戰 分工：

• 1.6 同 DB 內：schema 演進、資料變更、新舊欄位共存、雙寫驗證、切流。例：加欄位、改欄位、拆表、合表、加 partition。
• 1.12 跨 DB 引擎：換 vendor（PostgreSQL → Aurora、MongoDB → Cosmos DB、TiDB → DynamoDB）。例：9.C20 Zomato、9.C30 Microsoft 365。

兩者用同樣的工程方法論（dual-write、shadow、cutover、rollback）、但 stakes 跟 跨越的邊界 不同。本章先處理 1.6 的同 DB schema 轉換、1.12 處理更大規模的 cross-engine。若來源是託管平台（Shopify / Firebase / WordPress）的匯出而非自建資料庫、整場遷出的資產線盤點與並行期設計見 10.3 託管形態遷出；資料落地自建後的 schema 演進回到本章、跨引擎搬遷走 1.12。

實作流程

Expand-Contract 模式

Expand / Contract（也叫 parallel change）是同 DB schema 演進的核心模式。

為什麼需要這個模式：

• 應用 deploy 跟 DB migration 不能 原子 完成
• 在 deploy window 內、有些 instance 跑舊 code、有些跑新 code
• DB 必須同時容納舊 code 跟新 code 的 schema

Expand 階段（加新欄位、不刪舊）：

• 加 new_column、允許 nullable
• 應用層 dual-write：同時寫 old_column 跟 new_column
• 應用層 read 仍走 old_column

Backfill 階段（資料同步）：

• 把歷史 row 的 new_column 補上值（從 old_column 算出來）
• 分批跑、用 checkpoint 追進度、避開 peak
• 監控：rate、error、progress、unaffected rows count

Migrate Reads 階段（切讀）：

• 應用層 read 改走 new_column
• 仍 dual-write、可以快速 fallback 回 old_column
• 持續 shadow read 驗證一致性

Contract 階段（刪舊）：

• 確認所有 application instance 都跑新 code 後
• 刪 old_column、停止 dual-write
• 移除應用層的 fallback 邏輯

每個階段都是 可獨立 rollback 的、不像 big-bang 一次切完。

同 DB 內常見 migration 類型

Type A：加欄位（最簡單）

• 直接 ALTER TABLE ADD COLUMN（nullable 或 default）
• 應用層後續加寫入、讀取
• 風險：低
• 注意：大表 ADD COLUMN with DEFAULT 在 PostgreSQL 11+ 是 instant、之前要 rewrite

Type B：刪欄位

• 先讓所有 application 不再讀寫該欄位
• 部署完成、確認後再 DROP COLUMN
• 風險：中
• 注意：DROP COLUMN 是 instant、但無法 rollback、必須 backup

Type C：改欄位型別

• 用 expand-contract：加新欄位、dual-write、backfill、切讀、刪舊
• 風險：高（特別是大表）
• 注意：直接 ALTER COLUMN TYPE 可能 rewrite 整表、lock 時間長

Type D：改欄位名 / 表名

• 同型別改名：用 expand-contract、加新名 + dual-write、切讀、刪舊
• DB 端 native rename 是 instant 但 application 需要同步 update — 不適合大規模 deploy

Type E：拆表 / 合表

• 拆：先 dual-write 到新舊表、backfill、切讀、刪舊
• 合：先 dual-write 到新表、backfill、切讀、刪舊
• 風險：高 — 影響面廣

Type F：加 index

• PostgreSQL：CREATE INDEX CONCURRENTLY（不 lock 表、可能 slow）
• MySQL：gh-ost / pt-online-schema-change（ghost table）
• 風險：低-中（看 index 大小）

Type G：加 NOT NULL constraint

• 先確保 application 所有 instance 都不寫 null
• backfill null 為 default
• 加 NOT NULL constraint
• 風險：中

Type H：加 partition

• 先把現有表變成 partition 0
• 加新 partition 接新資料
• 漸進把舊資料 move 到對應 partition
• 風險：高（schema 大變）

Online Schema Change 工具

大表 ALTER TABLE 直接跑會 lock。生產級 migration 用 online schema change 工具：

PostgreSQL：

• CREATE INDEX CONCURRENTLY（內建）
• pg_repack（vacuum + reindex without lock）
• pgroll（zero-downtime migration）
• Atlas（schema-as-code）

MySQL：

• gh-ost（GitHub 開源、無觸發器、推薦）
• pt-online-schema-change（Percona、用觸發器）
• Vitess online DDL（managed via Vitess）

機制概要：

• 建 ghost table（新 schema）
• copy 資料到 ghost table（漸進、avoid peak）
• 用 trigger 或 binlog 同步 ongoing changes
• 切換：原 table → ghost table（atomic rename）

對應 MySQL vendor page 跟 PostgreSQL vendor page 的相關段落。

Validation Query 設計

migration 過程中必須有 validation query 確認資料一致性。

Checksum 對比：

• 跑 MD5(new_column) = MD5(derived_from_old)
• 抽樣 10% 跑、不打全表
• 不一致 → 修轉換函式、不直接修資料

Row count 對比：

• 新欄位 NULL count 跟預期 backfill 進度比對
• 過慢 → 增加 backfill worker
• 不一致 → 找出 backfill 漏跑的 batch

業務指標對比：

• 跟業務 metric 對齊（訂單金額總和、用戶數）
• 比 row-level checksum 更貼近 business correctness

詳見 Validation Query 卡片 跟 1.7 Schema Migration Rollout Evidence。

Backfill 設計

backfill 是 migration 中最 容易出錯 的環節 — 大量寫、影響 production。

設計要點：

1. 節流（throttle）：每秒寫入限制、跟 production peak 錯開
2. Checkpoint：紀錄進度、可 resume
3. 錯誤分類：可 retry 的錯誤 vs 必須人工處理
4. dry-run mode：先看會修改多少、不實際寫
5. monitoring：rate、error、progress、replica lag

backfill 反模式：

• 一個大 transaction 跑全表 → lock 太久、可能 OOM
• 沒 checkpoint → 中途失敗從頭開始
• 沒 throttle → 影響 production read

對應 Backfill 卡片。

各階段監控訊號

每階段都要監控、不只是「最後驗證」：

判讀訊號

常見誤區

把資料庫轉換當成單次 DDL 任務、會讓風險集中在 cutover 當下。穩定做法是把每一階段都做成可驗證、可回退的獨立里程碑。

把 dual-write 當成最終保障也常出錯。雙寫只能保證「兩邊都有寫」、不保證「語意一致」、仍要配 shadow read 與業務對帳。

把 online schema change 工具當「萬能」也是錯。gh-ost / pgroll 仍有 限制（例如 trigger 限制、IO 影響）、要按工具規格操作。

案例回寫

• 選型層案例： 0.C4 營運後技術轉換
• 可靠性治理： 6.11 Migration Safety
• 事故反饋： GitHub 2018 Oct21 MySQL Topology Incident
• 大規模跨 DB 遷移： 1.12 大規模 DB 遷移實戰（Zomato、Netflix、Microsoft 365 等 case）

這組案例主要支撐的是「分段切換與可回退驗證」判讀、不直接支撐快取 TTL 或 broker delivery 參數；若問題核心在快取新鮮度或投遞語意、應轉到 2.x 或 3.x。

跨模組路由

1. 與 1.2 的交接：欄位演進與命名語意回到 schema design。
2. 與 1.3 的交接：交易邊界與副作用切分回到 transaction boundary。
3. 與 1.7 的交接：production rollout 證據實作 — Schema Migration Rollout Evidence。
4. 與 1.12 的交接：跨 DB 引擎遷移 — 大規模 DB 遷移實戰。
5. 與 4.20 的交接：validation query 與一致性證據進入 Observability Evidence Package。
6. 與 6.11 / 6.8 的交接：放行與停損條件進入 Migration Safety 與 Release Gate。
7. 與 8.19 的交接：pause、rollback、fail-forward 決策記錄到 Incident Decision Log。

下一步路由

若你還在判斷是否該轉換、先回 0.C4 看決策訊號。若你要把這套流程寫成 production rollout evidence、接著讀 1.7 Schema Migration Rollout 證據實作示範。若你在設計放行與演練、接著看 6.11 與 6.8。若你在事故回溯、接著看 8.23 Post-incident Review。若你要做 跨 DB 引擎遷移、看 1.12。

服務路徑與狀態責任

這條服務路徑是 checkout-api -> order-db -> payment-callback -> reconciliation-job。Checkout 建立訂單時先寫入訂單主檔與付款待確認狀態；payment callback 會更新付款結果；客服後台與對帳 job 會讀取同一筆訂單狀態來判斷是否需要補償、退款或人工處理。

本篇示範的變更是把原本單一 status 欄位中的付款語意拆到 payment_state。這個欄位屬於正式狀態，會影響使用者看到的訂單結果、付款回呼的冪等更新、客服查詢與對帳流程，因此 rollout 的核心是讓新舊狀態語意在過渡期同時成立；DDL 只是其中一個執行動作。

這條路徑的前置概念來自 1.2 schema design 與資料建模、1.3 transaction 與一致性邊界 與 1.6 資料庫轉換實作。1.2 定義欄位責任，1.3 定義哪些更新要在同一個交易邊界內成立，1.6 定義 expand、backfill、cutover 與 contract 的執行節奏。

Rollout 階段

Migration rollout 的責任是把一次高風險資料變更切成多個可驗證階段。每個階段都要有輸入條件、完成訊號與停止條件，讓團隊能在資料漂移擴大前停下來。

這張表的重點是責任轉移。Expand 保護相容性，backfill 保護歷史資料，cutover 保護線上讀取，contract 保護長期維護成本；四者對應不同 evidence，也需要不同 release gate 判讀。

實作基準：先寫出狀態契約

狀態契約的責任是讓 migration 先有可驗證的語意邊界。這篇的範例把 orders.status 裡混合的訂單生命週期與付款語意拆開：訂單仍用 status 表示 created、fulfilled、cancelled 這類流程狀態，付款結果則交給 payment_state 表示 pending、authorized、captured、failed 與 refunded。

這張 mapping table 是 validation query、backfill job 與 incident decision log 的共同語意來源。Mapping table 留在工程師腦中時，後續 mismatch 會變成「資料看起來怪」；mapping table 進入 artifact 後，gate 就能判斷錯誤集中在哪個付款語意，而不是停在總筆數。

Expand：先建立相容窗口

Expand phase 的核心責任是讓新資料結構先進入 production，同時保留舊程式的可運作性。以 payment_state 為例，常見起點是新增 nullable 欄位、補上必要索引，並讓寫入路徑可以在新欄位缺值時仍使用舊 status 判讀付款狀態。

1ALTER TABLE orders
2  ADD COLUMN payment_state text NULL;
3
4CREATE INDEX CONCURRENTLY idx_orders_payment_state
5  ON orders (payment_state)
6  WHERE payment_state IS NOT NULL;

這段 SQL 的用途是示範 artifact 形狀。Nullable 欄位保留舊資料的相容窗口；partial index 讓新讀取路徑能先被驗證，同時避免把尚未 backfill 的歷史資料全部推進新查詢模型。不同資料庫會有不同線上 DDL 能力，release gate 要把 lock 行為、index build 進度與 replication lag 納入 checks。

應用程式在 expand 階段要支援 read compatibility。相容性較高的寫法是讀取時優先使用 payment_state，缺值時 fallback 到舊 status 的付款語意；寫入時則依交易邊界同步更新舊欄位與新欄位，直到 cutover 前都保留一致性檢查。

 1readPaymentState(order):
 2  if order.payment_state is not null:
 3    return order.payment_state
 4  return mapLegacyStatusToPaymentState(order.status)
 5
 6applyPaymentCallback(order, callback):
 7  nextPaymentState = mapCallbackToPaymentState(callback)
 8  update orders
 9    set status = mapPaymentStateToLegacyStatus(nextPaymentState),
10        payment_state = nextPaymentState
11    where id = order.id

這段相容讀寫的重點是「同一個 callback 只產生一個付款判讀」。舊欄位與新欄位可以同時存在，但它們要由同一份 mapping function 產生，否則 payment callback、客服修復與 reconciliation job 會各自形成一套隱性規則。

這裡要特別看 dual write 的風險。雙寫只表示兩個欄位都有被寫入，仍要用 validation query 驗證兩者語意是否一致。若付款回呼、手動退款與對帳修復走不同程式路徑，雙寫函式也要被這些路徑共同使用。

Dual-write divergence schema

Dual-write 的責任不只是「兩邊都寫」、是「兩邊寫的結果一致」。要證明這件事、需要明確的 divergence schema、否則事故當下無法區分 mapping bug 跟 race condition。

最小 divergence 紀錄欄位：

expected_new 跟 new_value 對不上、表示 mapping function 在某些 path 沒被使用、是 mapping bug。legacy_value 跟 new_value 對不上、且 expected_new == legacy_value 對得上、是 dual-write 本身少寫一筆、可能是 race condition 或部分失敗。兩種情況的修法完全不同、不分類會在事故當下亂修。

Dual-write 失敗回退策略：寫舊欄位成功、寫新欄位失敗時、不能直接 retry 新欄位（會跟主寫入競爭）。實務做法是把 divergence 寫進 outbox / repair queue、由 backfill 同類流程補。對應 9.C16 SeatGeek 的 outbox-style 設計。

線上 DDL 的 vendor 差異

Expand 階段加欄位 / 加索引、不同資料庫的 阻塞行為 差異極大、選錯時機會直接讓 production 鎖表。

• PostgreSQL：ALTER TABLE ADD COLUMN ... NULL 是 metadata-only、不重寫 table。ADD COLUMN ... NOT NULL DEFAULT ... 在 PG 11+ 才是 metadata-only。CREATE INDEX CONCURRENTLY 不阻塞寫入、但更慢、且 transaction 中不能用。ALTER TABLE ALTER COLUMN TYPE 通常會重寫整張表、要先評估規模。
• MySQL / Aurora MySQL：ALTER TABLE ... ALGORITHM=INSTANT 是 8.0+ 的 metadata-only、5.7 則靠 ALGORITHM=INPLACE / LOCK=NONE。Aurora MySQL 還有 fast DDL（部分變更秒級完成、不重寫）。判讀重點是 explicitly 指定 ALGORITHM、不要讓 MySQL 自己選（可能掉回 COPY 算法、整張表複製）。
• Spanner：schema change 預設非阻塞、後端 async 補欄位。新欄位 read 在 schema change 完成前可能讀不到、應用層要容忍。
• DynamoDB：表本身沒 schema、但 GSI（Global Secondary Index）創建是 async、可能跑數小時、且新 GSI 在 backfill 完成前查不到完整資料。判讀重點：cutover 不能假設新 GSI 立即可用、要等 IndexStatus = ACTIVE。
• Cosmos DB：document 級別無 schema、新 indexed path 加進 indexing policy 後、後端 re-index 整個 partition、期間 RU consumption 飆升。

各 vendor 的線上 DDL evidence 都要包含：操作開始時間、預估完成時間、是否阻塞讀寫、實際 lock duration。expand gate 通過條件不能只看 DDL 跑完、要看 所有副效應收斂（index status active、re-indexing 完成、replica 同步）。

對應 vendor pages：PostgreSQL、MySQL、Aurora、Spanner、DynamoDB、Cosmos DB 的線上 DDL 段。

Backfill：把歷史資料變成可驗證進度

Backfill phase 的核心責任是把歷史資料補齊成可追蹤、可暫停、可重試的進度。訂單表通常會同時承擔交易查詢、客服查詢與對帳查詢；backfill 若只追求速度，容易和線上流量競爭 I/O、放大 replication lag 或改變查詢計畫。

Backfill job 應以 checkpoint 管理進度。每批選取固定範圍的訂單，轉換 status 到 payment_state，寫入後立刻產生該批 validation query 結果。批次大小要能依延遲、鎖等待、replication lag 與線上錯誤率調整。

1checkpoint:
2  migration_id: orders-payment-state-2026-05
3  last_order_id: 18420000
4  batch_size: 5000
5  started_at: 2026-05-11T02:10:00Z
6  completed_at: 2026-05-11T02:12:40Z
7  rows_scanned: 5000
8  rows_updated: 4921
9  mismatch_count: 3

Checkpoint 的角色是把 backfill 變成可恢復流程。last_order_id 告訴下一批從哪裡繼續，rows_updated 與 mismatch_count 告訴 gate 這批是否可以被納入放行證據，時間欄位則讓 replication lag、slow query 與錯誤率能回到同一個觀察窗口。

Validation query 的責任是證明語意一致。最小集合包含總筆數、已補筆數、缺值筆數、新舊語意不一致樣本、每批耗時、慢查詢與 replication lag。這些查詢要保留 query link 與 time range，後續才能進入 4.20 Observability Evidence Package。

1SELECT
2  count(*) AS total_rows,
3  count(*) FILTER (WHERE payment_state IS NULL) AS missing_payment_state,
4  count(*) FILTER (
5    WHERE payment_state IS NOT NULL
6      AND payment_state <> map_legacy_status_to_payment_state(status)
7  ) AS mismatch_rows
8FROM orders
9WHERE id BETWEEN 18415001 AND 18420000;

Validation query 要和 mapping table 共用同一個語意。資料庫端缺少同一份 mapping function 時，查詢至少要把 mapping 規則展開成明確 CASE expression，並把 query version 保存在 evidence package；這樣事後才能知道 mismatch 是資料錯誤、mapping 規則改變，還是查詢本身落後。

Cutover：先切讀取，再收斂寫入

Cutover phase 的核心責任是把服務判讀權交給新欄位，同時保留可回退窗口。對訂單付款狀態來說，切換順序通常先從低風險讀取路徑開始，例如客服後台與內部對帳，再進入 checkout 查詢與使用者可見狀態；每一批切換都要有自己的 cutover window。

讀取 cutover 的 stop condition 要比寫入 cutover 更早觸發。新欄位讀取後出現 mismatch、客服查詢結果漂移、對帳 job 補償量異常時，先回到 fallback read，讓錯誤限制在判讀層，再重新驗證寫入收斂條件。

寫入 cutover 要確認所有更新來源都已對齊。付款回呼、手動修復、退款、訂單取消與 reconciliation job 都可能更新付款狀態；只切主 checkout 寫入路徑會留下長尾漂移。完成 cutover 前，要用 audit query 確認仍在寫舊欄位的程式路徑已經歸零或被納入例外清單。

Shadow read pattern：cutover 前的讀取驗證

Shadow read 的責任是讓新讀取路徑在 真實流量 下被驗證、但 不影響使用者結果。這跟 dual-write 是對偶機制：dual-write 證寫入收斂、shadow read 證讀取分歧。

實作模式：

1. 每一筆讀取請求、同時用 舊邏輯 跟 新邏輯 查一次。
2. 回給用戶的仍是舊邏輯結果（用戶體驗不變）。
3. 在背景把兩個結果差異寫進 divergence log。
4. 收集足夠樣本後、再決定切換 cutover。

 1readPaymentStateWithShadow(order):
 2  legacy = mapLegacyStatusToPaymentState(order.status)
 3  new_result = order.payment_state ?? legacy
 4  if legacy != new_result:
 5    asyncLogDivergence({
 6      order_id: order.id,
 7      legacy: legacy,
 8      new: new_result,
 9      sample_at: now(),
10      caller: requestContext.caller,
11    })
12  return legacy  // 用戶仍拿舊邏輯結果

Shadow read 的判讀重點：

• 抽樣率：1% / 10% / 100% — 高流量場景全量 shadow 會雙倍 DB 讀取、要先評估容量。Cosmos DB / DynamoDB 的 RU 成本要乘 2。
• 分歧分類：跟 dual-write 一樣、divergence 要分類（mapping bug / race condition / stale read）、不分類無法定位修法。
• 覆蓋條件：要驗證所有 caller path（checkout / support / reconciliation / external API）都跑過 shadow、否則 cutover 後可能踩到沒測試過的 path。
• 退場條件：shadow read 不該長期跑、會增加負載。設明確 sunset deadline、cutover 完成後一週內移除。

對應 9.C20 Zomato TiDB → DynamoDB migration — migration 期間用 shadow read 持續驗證 mapping 規則、抓到 mapping drift。

Dual-write 跟 shadow read 的選擇不是互斥、是依風險組合：

Multi-region 與跨服務協調

Migration 跨越 region 或多個 service 時、rollout 順序錯誤是最常見的失敗模式。Service A 切到新欄位、service B 還在讀舊欄位、結果整條業務流量看到不一致。

Multi-region rollout 順序

跨 region 的 schema migration 要從 最後寫入點 開始 expand、從 最後讀取點 開始 cutover。先 expand 寫端、再 expand 讀端；先 cutover 讀端、再 cutover 寫端。順序反了會在過渡期讀到沒被寫的新欄位、或寫了沒被讀的新欄位。

實務步驟：

1. Schema expand：所有 region 同步加新欄位（先寫端再讀端、不能跳）。確認跨 region replication lag 在新欄位上收斂、再進下一步。
2. Backfill：可以平行跑、但每 region 各自 checkpoint、不共用。某 region backfill stuck 不應該卡住其他 region。
3. Cutover read：region by region 切讀、用 canary region 先試 24-48 小時、再擴散。
4. Cutover write：所有 region 都切完讀、再統一切寫。寫端切換比讀端更敏感、跨 region 寫差異會放大成跨 region inconsistency。

對應 1.11 全球分散式 OLTP 的跨 region consistency 段。

Cross-service migration 協調

當 schema 變更影響多個 service 時、API contract 是 鬆耦合 介面、不該讓所有 service 同步切換。

協調機制：

• 新欄位先在 API 是 optional：API contract 加新欄位、預設 nullable / optional。下游 service 可選擇何時讀。
• 舊欄位保留至少一個版本週期：API 不能跟 DB schema 同步 contract、否則下游沒時間切。實務上保留 1-2 季、給下游充足 cutover 窗口。
• owner-by-owner cutover roster：明確列出每個下游 service 的 owner、預計 cutover 時間、目前狀態。常用工具是共享 dashboard、不是散落的 ticket。
• Contract test：每個下游 service 對新欄位都要有 contract test、在 CI gate 跑過。避免上游 cutover 後下游才發現沒讀對。

對應案例：9.C20 Zomato TiDB → DynamoDB — 跨多個 service 的 access pattern 變更、必須每個 service 各自驗證、不能假設「DB 切了就好」。

Evidence Package

資料庫 migration 的 evidence package 負責證明資料演進是否可判讀。這份 package 要把 validation query、時間窗、資料限制與 owner 包成後續放行與事故判斷可引用的證據，dashboard 只作為摘要入口。

Source 欄位要保留資料來源的能力邊界。Validation query 能證明欄位語意一致，DB metric 能看出 latency 與 lag，job log 能追進度，audit log 能判斷是否有高權限修復行為。把這些來源混在一起會讓下游誤判證據的用途。

Data quality 欄位要直接寫出限制。若查詢只跑 primary、replica lag 還在回復、某些 tenant 因資料遮罩未被抽樣，這些限制要跟 evidence 一起交給 release gate，讓 gate 能以證據完整度決定是否放行。

 1evidence_package:
 2  name: orders-payment-state-cutover-batch-37
 3  source:
 4    - validation_query: q_orders_payment_state_batch_37
 5    - db_metric: replication_lag_orders_primary
 6    - job_log: backfill_orders_payment_state_2026_05
 7  time_range: 2026-05-11T02:10:00Z/2026-05-11T02:20:00Z
 8  owner:
 9    database: data-platform-oncall
10    service: checkout-oncall
11    reconciliation: finance-ops-owner
12  data_quality:
13    replica_freshness: "primary only; replica lag still recovering"
14    sample_completeness: "tenant tier enterprise covered; sandbox tenants excluded"
15  confidence: suspected
16  known_gap:
17    - "manual refund repair path not yet sampled"

這份 package 故意把 confidence 標成 suspected。原因是 evidence 已能支持 backfill 繼續前進，但還不足以支持使用者可見讀取 cutover；這種中間狀態要被明確寫出，gate 才能做分階段決策。

Release Gate

Schema migration 的 release gate 負責判斷下一階段是否可以放行。它接收 evidence package，但決策語言要回到 6.8 Release Gate 與變更節奏：Gate decision、Checks、Stop condition、Rollback window、Owner。

Gate decision 要用服務語言書寫。migration pass 這種結論對下游不夠具體；放行 10% 訂單 backfill、暫停使用者可見讀取 cutover、維持 fallback read 24 小時 才能讓執行團隊知道下一步。

Rollback window 是資料庫 migration 的關鍵欄位。Expand 與 backfill 階段通常能回到舊讀取；cutover 後仍可 fallback；contract 後舊語意被移除，回退會變成資料修復或 fail-forward。gate 要在每階段說清楚目前還剩哪種退路。

 1release_gate:
 2  gate_decision: "allow next 10% backfill; block customer-visible read cutover"
 3  checks:
 4    mismatch_rate: "0.04%, below 0.1% batch threshold"
 5    replication_lag: "p95 12s, below 30s stop condition"
 6    slow_query: "no new support-admin slow query above 500ms"
 7  stop_condition:
 8    - "mismatch_rate >= 0.1% for two consecutive batches"
 9    - "replication_lag >= 30s for 10 minutes"
10    - "support-admin query drift confirmed by reconciliation owner"
11  rollback_window: "fallback read available until contract phase starts"
12  owner: checkout-oncall

這份 gate record 把「繼續 backfill」和「暫緩讀取 cutover」拆成兩個決策。資料庫 migration 常見的判讀問題是 evidence 只支撐下一批資料修補，還支撐不了使用者可見行為切換。

Incident Decision Log

Migration 進入 production 後，pause、rollback 與 fail-forward 都是事故決策。這些決策要同步寫入 8.19 Incident Decision Log，讓事中交班與事後復盤能回放當時的證據與限制。

常見決策包括暫停 backfill、降低 batch size、回到舊讀取、停止 contract、手動修補 mismatch、選擇 fail-forward。每筆都要保留 Timestamp、Decision、Context、Evidence、Owner、Expected effect 與 rollback condition。

例如 cutover 後發現客服查詢 mismatch 升高，decision log 可以寫成：

 1incident_decision:
 2  timestamp: 2026-05-11T03:05:00Z
 3  decision: "rollback support-admin read path to legacy status fallback"
 4  context: "support-admin mismatch increased after internal read cutover"
 5  evidence:
 6    - query: q_orders_payment_state_support_mismatch
 7    - window: 2026-05-11T02:35:00Z/2026-05-11T03:05:00Z
 8    - interpretation: "suspected callback mapping drift"
 9  owner: checkout-incident-commander
10  expected_effect: "support ticket misclassification returns to baseline"
11  rollback_condition: "mismatch remains above threshold after 15 minutes"

這種記錄能避免事後只剩「當時有回退」的模糊敘事。後續 8.23 Control Plane Decision Log and Write-back 實作示範 可承接同一組決策紀錄，把缺少 validation、owner 或 runbook 的地方回寫成改善項。

判讀訊號

判讀訊號的責任是讓讀者知道何時該繼續、何時該停、何時該改路線。Migration 訊號要同時看資料正確性、線上健康度與回退窗口。

這些訊號要放回服務路徑判讀。Mismatch 要看集中在哪個業務入口；若 mismatch 只出現在延遲付款 callback，它代表外部 provider 回呼語意未對齊。Replication lag 要看是否和 backfill 批次對位；若它只在 backfill 批次出現，gate 應調整 migration 節奏，再判斷 schema 設計是否需要修正。

Dual-write 跟 shadow read 的 divergence 要分開看 — 兩者偵測不同層的問題。Dual-write divergence 偏向 mapping bug 或 race condition；shadow read divergence 偏向讀取邏輯漂移或 stale read。混在同一個 dashboard 會讓 reviewer 看不出問題真正在哪一層。

常見誤區

把 schema migration 寫成 DDL 任務，會讓風險集中在切換當下。穩定做法是先建立相容窗口，再用 evidence 證明資料語意已經跟上，最後才收斂舊路徑。

把 validation query 當成事後對帳，也會削弱 rollout 控制。Validation query 適合在 expand、backfill、cutover 每一階段都產生證據，讓 release gate 能在風險擴大前停下來。

把 rollback 寫成單一動作容易誤導團隊。資料庫 migration 的 rollback 會隨階段改變：expand 可回退 schema 使用，backfill 可暫停與重跑，cutover 可回到 fallback read，contract 後多半只能做資料修復或 fail-forward。

把 dual-write 跟 shadow read 當成同一個工具。兩者偵測不同層、結合使用可以互補、互相替代會留下盲點。Dual-write 不跑 shadow read、cutover 後可能踩到沒驗過的讀取 path；shadow read 不跑 dual-write、新欄位可能在某些寫路徑根本沒被寫進去。

把線上 DDL 當「一個 SQL 跑完就好」。各 vendor 的 DDL 語意差異大、PostgreSQL 的 ADD COLUMN NOT NULL DEFAULT 在 PG 10 重寫整張表、PG 11+ 是 metadata-only；MySQL 不指定 ALGORITHM=INSTANT 可能掉回 COPY。Expand evidence 要包含 實際 lock duration、不是只看 DDL 是否回傳成功。

只在主寫入路徑切 cutover、忘記補償流程跟 reconciliation job 也會寫舊欄位。這些長尾寫入會在 contract 階段才暴露、那時候已經沒有 fallback 可走。Cutover 前要 audit 所有寫舊欄位的程式路徑、不只看主流程。

案例回寫

0.C4 營運後技術轉換 可以回寫這篇的決策層。當服務營運後需要拆欄位、拆庫、分片或升級儲存引擎，先用 0.C4 判斷「為什麼要換」，再用本篇判斷「進入 production 後如何證明每一步成立」。

GitHub 2018 Oct21 MySQL Topology Incident 可以回寫這篇的事故層。該事件顯示資料一致性優先時，團隊需要可回放的 fail-forward / fail-back 判準；本篇則把這個需求落到 migration rollout 的 evidence、gate 與 decision log。

這兩個案例共同支撐的是「資料狀態演進需要證據閉環」。0.C4 提供轉換動機與選型壓力，GitHub 事故提供資料一致性與恢復決策的代價；兩者都不直接替代 validation query、release gate 與 decision log 的實作細節。

跨模組路由

1. 與 1.2 的交接：欄位責任、命名與查詢模型回到 schema design。
2. 與 1.3 的交接：付款回呼、手動修復與對帳更新的交易邊界回到 transaction boundary。
3. 與 1.6 的交接：expand、backfill、cutover 與 contract 的執行流程回到 資料庫轉換實作。
4. 與 4.20 / 4.22 的交接：validation query、row count、lag 與 slow query 進入 Observability Evidence Package 與 Checkout API Evidence Package。
5. 與 6.11 / 6.8 / 6.25 的交接：migration 可逆性與放行條件進入 Migration Safety、Release Gate 與 Provider Dependency Release Gate。
6. 與 8.19 / 8.23 的交接：pause、rollback、fail-forward 與 write-back 進入 Incident Decision Log 與 Control Plane Decision Log and Write-back。

下一步路由

要把資料庫 migration 的 evidence 交給 release gate，接著讀 6.25 Provider Dependency Release Gate 實作示範，並把 provider 依賴示範中的 gate 欄位改寫成 migration gate 欄位。要看下一條分類服務路徑，接著進 02 Cache / Redis 模組 的 Cache migration and stampede rollback 服務路徑。

跨 vendor schema migration 深入：

• Spanner interleaved table 的 schema migration — 全球分散式表結構變更的 evidence shape
• Aurora 從自管 PostgreSQL / MySQL 遷入 — schema 比對與 dual-write 證據鏈
• Cosmos DB MongoDB API vs SQL API — multi-API document 在 rollout 階段的相容性 evidence

本章從 source of truth 的責任分層開始、引入 CQRS / event sourcing / materialized view 等模式、最後處理四種 query 邊界的設計。讀完後讀者能回答：哪些資料是正式狀態、什麼時候該分讀寫 model、materialized view 怎麼用、replica lag 怎麼影響 query。

State Ownership

State ownership 的責任是判斷哪些資料是 source of truth、哪些資料屬於 cache、search index、event log 或報表副本。正式狀態會影響交易結果、權限判斷、對帳與客服修復、因此需要清楚的 owner、schema、驗證方式與變更流程。

訂單狀態、付款狀態、會員方案、權限授權與發票紀錄通常屬於正式狀態。商品搜尋索引、快取值、統計摘要與推薦結果通常是派生狀態；派生狀態可以錯過短暫更新、但正式狀態需要能被追溯、修復與稽核。

Canonical State vs Derived State

Canonical state 的特徵：

• 業務決策依據（付款、權限）
• 不能從其他地方重建（一旦丟、無法找回）
• 需要 audit log、point-in-time recovery、backup
• 通常在 OLTP DB（PostgreSQL / Aurora / Spanner）

Derived state 的特徵：

• 從 canonical 推算出來
• 可以「rebuild」（lazy 或 eager）
• 失效可接受（用戶可能看到舊的）
• 通常在 cache / search / analytics store
• 對應案例：9.C6 Tinder ElastiCache 配對快取、9.C25 Tubi ML feature store feature

設計原則：

• 同一資料 不能 同時是兩個地方的 canonical → 衝突時不知道信誰
• 寫入永遠先寫 canonical、再 propagate 到 derived
• derived 出錯只能 rebuild、不能拿來「修正 canonical」

CQRS 在資料庫情境的應用

CQRS 的概念定義、設計判準與代價見知識卡。本段聚焦在資料庫層面：state ownership 的決策如何影響你要不要分離讀寫模型。

State ownership 跟 CQRS 的交叉點是：當 canonical state 的 schema 為寫入正確性最佳化（normalize、強一致、transaction boundary 清楚），但讀取面的多種消費者各自需要不同的反正規化形狀（列表頁要扁平 summary、報表要聚合、搜尋要全文索引），canonical schema 無法同時服務這些讀取需求。這時候分離 write model 跟 read model 是解決形狀不對稱的方式。

資料庫情境的 CQRS 有不同的實作強度：

最輕量 — 同 DB 不同 query path：寫入走 canonical table，讀取走 materialized view 或反正規化 view。同一個 PostgreSQL 裡用 materialized view 就能實現最基本的讀寫分離，不需要兩個 DB、不需要事件同步。適合讀寫形狀不同但流量規模還不需要獨立擴展的階段。

中度 — 同 DB 加 read replica：寫入走 primary，列表跟報表走 read replica。Replica lag 決定哪些 query 能走 replica（見下方 Replica Lag 段）。適合讀取流量開始壓迫寫入的階段。

完整 — 獨立 read store：寫入走 OLTP DB，讀取走獨立的 analytics store（BigQuery、Athena）或搜尋引擎（Elasticsearch）。透過 CDC 或事件同步維護 read store。適合讀取形狀、流量、SLA 都跟寫入完全不同的階段。

對應案例：9.C17 BookMyShow — 交易層（OLTP）跟資料層（BigQuery / Athena）分開。9.C22 Wayfair — on-prem OLTP + GCP BigQuery analytics。

Event Sourcing 與 State Ownership

Event sourcing 的概念定義、設計判準與代價見知識卡。本段聚焦在資料庫層面：event sourcing 怎麼改變 state ownership 跟 query boundary。

Event sourcing 把 state ownership 的正式紀錄從 mutable row 改成 append-only event log。這個改變影響本章的每一個面向：

對 canonical / derived 分類的影響：採用 event sourcing 後，event log 是 canonical state，current state 變成 derived state。這跟傳統 CRUD 架構相反 — 傳統架構中 current state（mutable row）是 canonical，歷史紀錄（audit log）是 derived。

對 query boundary 的影響：event log 不適合直接服務交易查詢跟列表查詢（每次 replay 整條事件流太慢）。Event sourcing 幾乎必然搭配 projection 維護 read model — projection 持續消費事件流、更新反正規化的查詢 view。交易查詢讀 projection 的輸出而非直接讀 event log。

對修復流程的影響：傳統架構的資料修復是「直接改 row」；event sourcing 的修復是「發一筆補償事件（compensating event）」。修復本身也是事件、會被記錄在 event log 裡、提供完整的修復 audit trail。

Event sourcing 的設計門檻在於 projection 的維護跟 event schema evolution。Projection 數量增長後，每次 event schema 改版都需要同步更新所有 projection；projection 的 replay 跟 reconciliation 是長期運維的主要成本。這些代價決定了 event sourcing 適合「需要完整變更歷史」的業務場景（金融帳務、訂單流程、法規合規），而非所有資料存取場景。

Materialized View 在資料庫的應用

Materialized view 的概念定義見知識卡。本段聚焦在 OLTP 資料庫裡 materialized view 作為最輕量 read model 的具體實作。

Materialized view 是「同 DB 內最簡單的讀寫分離」。不需要事件同步、不需要獨立 read store、不需要 projection consumer — 資料庫自己定期執行查詢、存放結果。

跟 regular view 的差別：regular view 是 SQL 別名，每次 query 重跑底層查詢；materialized view 有實體儲存，query 時直接讀預計算結果。差別在 query-time cost — 複雜 JOIN / aggregation 重複跑時，materialized view 把計算推到 refresh 時、query 時接近零成本。

Refresh 策略：

• 全量 refresh：PostgreSQL 的 REFRESH MATERIALIZED VIEW，refresh 期間 view 預設 unavailable。
• Concurrent refresh：PostgreSQL 的 CONCURRENTLY 模式，refresh 期間 view 仍可讀但資料可能 stale。
• 增量 refresh：PostgreSQL 的 pg_ivm、Oracle 的 fast refresh — 只更新變更的部分，成本低但配置複雜。
• Trigger-based：特定 event 觸發 refresh，適合低頻變更的資料。

在 state ownership 的定位：materialized view 是 derived state，修復方式是 refresh（重建）而非直接修改。大量 materialized view 會拖累寫入吞吐 — 每次 base table 變更都可能觸發 refresh 計算。設計時要平衡 refresh 頻率跟 query freshness 需求。

跟觀測領域的對照：觀測領域的 recording rule 在概念上等同於 TSDB 層的 materialized view — 定期執行 query expression、把結果寫成新 series。兩者面對同樣的設計問題：refresh 頻率、freshness lag、維護成本與儲存增長。觀測領域的 CQRS 特化應用見 4.23 觀測查詢設計。

Query Boundary 四種

Query boundary 的責任是讓不同查詢路徑承擔不同服務問題。交易查詢、列表查詢、報表查詢與對帳查詢都可能讀同一張表、但它們的正確性、延遲與資料新鮮度要求不同。

這四種查詢混在一起時、資料庫會同時承擔低延遲交易與高成本分析、最後讓任何一種資料庫選型都變得模糊。

交易路徑的邊界

交易路徑的責任是維持使用者動作的即時正確性。它需要短查詢、明確 index、可控 transaction boundary 與清楚 timeout。

交易路徑的設計要把報表聚合或長時間掃描移到其他查詢路徑。若下單 API 同時查歷史報表、計算大範圍統計或同步重建派生狀態、交易延遲會被非交易責任拖慢。

對應 9.C4 DraftKings — 200 個獨立 Aurora cluster 把不同業務 transaction 分開、避免互相影響。

列表與報表的邊界

列表查詢的責任是支援產品體驗中的瀏覽與定位。列表查詢需要穩定排序、分頁策略、篩選條件與查詢成本界線；它應建立自己的讀取模型或索引策略、避免直接借用交易查詢的資料模型造成 slow query、排序漂移與 pagination 重複。

報表查詢的責任是支援分析與決策。報表通常可以接受資料延遲、因此更適合使用 read replica、materialized view、ETL 或 analytics store。把報表直接壓在線上 primary 上、會讓交易服務承擔不必要的容量風險。

對應 9.C22 Wayfair hybrid burst、9.C17 BookMyShow — 交易層跟資料層分開部署。

對帳查詢的邊界

對帳查詢的責任是驗證正式狀態是否與外部事實一致。付款、發票、庫存與訂閱方案都需要對帳查詢、但對帳查詢要保留時間窗、資料來源、差異定義與人工修復入口。

對帳查詢承擔比報表更直接的修復責任。報表回答「現在看起來如何」、對帳回答「哪一筆正式狀態需要修復」。因此對帳查詢結果要能進入 Observability Evidence Package 與 Incident Decision Log。

詳見 1.9 Reconciliation 與 Data Repair。

Replica Lag 對 Query Boundary 的影響

當應用使用 read replica 擴 read traffic 時、replica lag 會直接影響 query boundary 設計。

典型 lag：

• PostgreSQL streaming：< 100ms（同 AZ）
• Aurora：10-30ms（同 region）
• 跨 region replica：秒級到分鐘級

不同 query 對 lag 的容忍：

• 交易查詢：不可容忍 lag、必須走 primary
• read-after-write（剛寫完查自己）：必須 primary、或 session sticky
• 列表查詢：通常容忍 lag < 1 秒
• 報表查詢：lag 分鐘級可接受
• 對帳查詢：通常用 batch、lag 不關鍵

Stale read 容忍策略：

• 「能容忍秒級 stale」的 read → replica（用戶 profile、報表）
• 「不能 stale」的 read → primary（剛寫入後的查詢、餘額確認）
• read-after-write：用 session token 標記「剛寫過」、N 秒內讀走 primary

對應 1.1 高併發資料存取 的「Read Replica Scaling」段。

選型前判準

資料庫選型前要先回答四個問題：

1. 哪些資料是正式狀態、哪些是派生狀態
2. 哪些查詢屬於交易路徑、哪些可以延遲或離線化
3. 哪些查詢結果會觸發修復、退款、補償或人工決策
4. 哪些資料需要 audit、masking、retention 或刪除責任

這些問題決定後續該比較 relational database、document database、search index、analytics store 還是 cache。工具差異要放在責任邊界之後討論。

實體服務討論承接點

實體資料庫文章要承接本篇的 state ownership 與 query boundary。PostgreSQL、MySQL、MSSQL 或其他 relational database 的比較、應先問它們如何支援正式狀態、交易查詢、列表查詢、報表查詢與對帳查詢、再進入索引、隔離層級、replica 或工具語法。

若主問題是正式狀態與交易一致性、後續文章要優先比較 transaction、isolation、index 與 migration 能力。若主問題是報表與搜尋、後續文章要評估 read replica、materialized view、search index 或 analytics store。若主問題是對帳與修復、後續文章要比較 validation query、audit log、backup/restore 與資料修復流程。

案例對照

跨模組路由

1. 與 1.2 的交接：欄位與索引語意回到 schema design
2. 與 1.3 的交接：transaction boundary 設計影響哪些 query 走 primary、哪些可走 replica
3. 與 1.7 的交接：正式狀態變更要進入 production rollout — Schema Migration Rollout Evidence
4. 與 1.9 的交接：對帳查詢的下游修復 — Reconciliation and Data Repair
5. 與 2 的交接：cache layer 是 derived state 最常見的形式 — 02 快取模組
6. 與 4.20 的交接：query evidence 跟 reconciliation evidence — Observability Evidence Package

下一步路由

要進一步處理 schema 與資料模型、接著讀 1.2 schema design 與資料建模。要處理 schema 演進與正式狀態變更、接著讀 1.6 Database Migration Playbook 跟 1.7 Schema Migration Rollout 證據。要處理對帳跟資料修復、接著讀 1.9 Reconciliation。要設計 KV / Document 的 state ownership、接著讀 1.10 KV / Document 容量規劃。

本章從不一致分類開始、進入偵測模式（連續 vs scheduled）、處理修復策略（auto vs manual）、最後對接 audit trail 跟 backup recovery。讀完後讀者能設計：對帳機制、修復 runbook、evidence handoff、audit chain。

Reconciliation

Reconciliation 的責任是比較兩個或多個資料來源、確認正式狀態是否與外部事實一致。付款狀態要和金流 provider 對齊、發票狀態要和開票系統對齊、庫存狀態要和出貨或倉儲系統對齊。

對帳需要明確定義資料來源、時間窗、比對鍵、差異分類與 owner。這些欄位能把「資料看起來不一致」轉成可分派、可修復、可驗證的決策材料。

對帳系統的設計欄位

設計對帳作業時、要先把這幾件事談清楚、再寫 query。少談任何一項、對帳結果都會在事故當下被質疑可信度。

來源 A 與來源 B：明確指出哪個是內部 source of truth、哪個是外部事實。金流對帳的 A 是訂單表、B 是 provider 結算檔；庫存對帳的 A 是訂單庫存表、B 是倉儲 WMS 報表。兩邊都要有明確 owner、否則差異發生時沒人能解釋為何資料長那樣。

比對鍵（comparison key）：A 跟 B 要用什麼欄位對齊。最理想是雙方共用的業務 ID（例如金流交易序號）；次優是 timestamp + 業務外鍵組合；最差是用 fuzzy matching（金額 + 時間範圍）、這時對帳結果天然帶有噪音、要在 output schema 標示信心度。

時間窗（time window）：對帳要對哪段時間的資料、什麼時候做。每日對帳通常設定 T-1 整天、跳過今天（避免 in-flight 資料）；分鐘級對帳要明確處理 in-flight：是排除最近 N 分鐘、還是允許重複跑直到收斂。在跨時區業務裡、時間窗要對齊雙方 timezone、不然每天差異會穩定出現在 0:00 前後。

差異分類規則：mismatch 不是只有「不一致」一種。常見要再切：「A 有 B 沒有」（missing in B）、「B 有 A 沒有」（missing in A）、「兩邊都有但欄位不同」（value mismatch）、「同一個 key 在 A 有多筆」（duplicate）。每類差異的處理路徑跟 owner 都不同、不分類會讓修復決策無法分派。

Output schema：對帳產出的不是「對 / 不對」、而是一份結構化報告。最少要有：mismatch 樣本（不是全部）、總筆數與金額影響、覆蓋率（總共比對了多少筆）、未覆蓋資料（哪些 A 或 B 沒涵蓋）、結果時間戳。這份報告會被 4.20 Observability Evidence Package 收進釋出證據鏈、結構不穩定會讓上游 release gate 拒絕採信。

對帳跟 anomaly detection 的差異

兩件事都是「找資料異常」、但本質不同、不能互相替代。

對帳是 deterministic：給定兩個來源、結果是確定的差異集合、可以被任何工程師重跑驗證。anomaly detection 是 statistical：用模型或閾值判斷一筆資料是否「看起來不對」、結果帶機率、不同模型跑出來不一樣。

在金流、庫存、付款這類正式狀態場景、對帳是必須、anomaly detection 是補充。anomaly detection 適合抓「對帳沒設計到的維度」（突然某 tenant 訂單量爆增）、但不能用它當 source of truth、因為事故時無法回答「為何這筆被判定為異常」。

兩者輸出格式也不同：對帳輸出 mismatch list、anomaly detection 輸出 confidence score。把兩者混在同一份報告會讓 incident reviewer 無法判斷哪些是必修、哪些是可疑。

不一致的三種分類

不是所有「資料不一致」都一樣。按 成因 分三類、各有不同處理策略。

Temporal Inconsistency（時間性不一致）

• 來源：replication lag、async event delivery、eventual consistency
• 特徵：兩邊都是「對的」、只是 時間點 不同
• 例：cache 跟 DB 看到不同 value（cache 還沒 invalidate）、replica 跟 primary 不同步
• 處理：等待收斂或主動觸發 sync、不必修資料
• 持續時間：通常 < 1 秒到分鐘級

Structural Inconsistency（結構性不一致）

• 來源：schema migration 期間、dual-write 失敗、partial write
• 特徵：兩邊應該一致但實際不一致、其中一邊是 錯的
• 例：訂單寫進主表但 line items 沒寫、外鍵 reference 一個不存在的 row
• 處理：必須修復、不能等
• 持續時間：永久（直到修復）

Semantic Inconsistency（語意不一致）

• 來源：業務邏輯 bug、應用層 race condition、人工誤操作
• 特徵：資料結構 OK、但 業務語意 錯
• 例：訂單付款狀態是 paid 但金流端是 refunded、帳戶餘額跟交易紀錄 sum 不符
• 處理：複雜、需要業務判斷哪邊是 source of truth
• 持續時間：永久（且容易擴大）

處理優先序：Semantic > Structural > Temporal。Semantic 影響業務最深、Temporal 通常自動收斂。

偵測模式

不同類型的不一致需要不同偵測模式。

Continuous Detection（持續偵測）

• 每筆寫入跑 sanity check（trigger、constraint）
• 應用層 invariant check
• 適合：structural inconsistency（讓 DB 自己擋）
• 成本：每筆寫入有 overhead

Scheduled Detection（定期對帳）

• 每 N 分鐘 / 每天跑對帳 query
• 跟外部 provider 比對
• 適合：semantic inconsistency（業務級對齊）
• 成本：對帳 query 本身耗資源

Sampling Detection（抽樣偵測）

• 不跑全表、抽樣 10% / 1% 跑 checksum
• 適合：大表（全表對帳成本高）
• 成本：可能漏掉低頻 inconsistency

Reactive Detection（反應式偵測）

• 用戶 / 客服回報後才查
• 適合：尾長 inconsistency（找不到通用 pattern）
• 成本：用戶體驗已受影響

對應 9.C20 Zomato — migration 期間 shadow read 持續對帳、抓 mapping 規則漂移。

Data Repair

Data repair 的責任是把已確認的資料差異修回正式狀態、並保留修復原因、範圍、證據與回退條件。修復可以是 SQL update、補事件、補發 webhook、重建 projection 或人工客服流程、但每種修復都要有範圍控制。

資料修復要先分成三種：

修復前要先確認問題落在哪一層。正式欄位錯誤要修 source of truth；派生狀態錯誤要重建副本；外部副作用漏做要走補償流程。

欄位修復的判讀重點是 mapping 規則是否正確、因為錯誤規則會把單點差異擴成批次污染。派生狀態重建的判讀重點是 source of truth 是否已經正確、否則重建會複製錯誤。補償動作的判讀重點是副作用是否可逆、因為退款、通知或外部 webhook 可能已經被使用者或第三方看見。

Repair 原則

不管哪種修復、都遵守三個原則：

1. Idempotency（冪等）

• 同樣的修復跑兩次、結果跟跑一次一樣
• 用 WHERE current_value != target_value 而不是無條件 update
• 補通知 / webhook 帶 idempotency key、第三方可去重
• 對應 Idempotency 卡片

2. Auditable（可稽核）

• 每次修復都有 record：誰、什麼時候、改了什麼、為什麼
• 修復前 + 修復後的 snapshot 都要存
• 對應 Audit Log 卡片、1.5 Red Team 的 audit 段

3. Reversible（可逆）

• 萬一修復是錯的、能回退到 before state
• 不可逆操作（DELETE）必須有 dry-run、必須備份
• 對應 Rollback Window 卡片

修復前的 dry-run 與 impact assessment

修復前要先回答「這次修復會碰多少筆、影響多少業務、最壞情況是什麼」、才能進入執行。直接跑 update 是 production-grade 流程的反例、即使在 incident 壓力下也不能跳過這步。

Dry-run 的責任：把 update 改成 select、用同樣的 WHERE 條件、產出將被修改的資料樣本。Dry-run 結果要包含：影響筆數總計、影響金額或業務值（如果有）、affected tenant / user list 的抽樣、未涵蓋的邊界 case。Dry-run 跟正式修復必須共用 mapping 規則、否則 dry-run 結果無法當審核依據。

規模分級的執行策略：影響筆數會決定執行方式。

• 單筆到十筆：客服等級的修復、一名工程師執行 + 一名同儕審核 + audit log 即可。
• 百筆到千筆：要在低流量時段執行、分批跑、每批跑完比對 invariant、發現意外停下。
• 萬筆以上：當成 production deploy 處理、要有 deploy review、staged rollout（先 1% tenant、再 10%、再全量）、跟 oncall 同步。
• 跨表 / 跨 service：必須先做跨團隊 review、確認下游依賴（cache、search index、外部 webhook）的處理計畫、不能單一團隊獨自決定。

Impact assessment 的必看欄位：除了筆數、還要看 連帶影響。修復 orders 表會不會觸發 audit trigger 把每筆寫進 audit log 表？會不會觸發 outbox event 把每筆當成新事件對外發布？會不會讓某 tenant 的 metric 一次性異常、誤觸 alert？這些 second-order effect 在 dry-run 階段就要識別、否則修復本身會變成新事故。

Sandbox / staging 驗證：不可逆或大規模修復、先在 staging 跑一次、確認 query plan、執行時間、lock 行為。Production 規模沒辦法在 staging 重現的話、至少要在 production 的某個低風險 tenant / region 先試跑、再擴大。

Approval gate（4-eyes process）：超出單筆規模或修復金錢、權限、個資的場合、必須 兩位以上人員 各自看過 dry-run 結果再簽核。常見實作是：執行者提 PR / ticket 帶 dry-run output、reviewer 簽核後才能執行、執行後產出 audit log 帶兩人簽核紀錄。Reviewer 的責任不是橡皮圖章、是獨立驗證 dry-run 結果跟 incident 描述一致。

Repair Patterns

實務上常見的 repair pattern：

Pattern 1：條件式 UPDATE

最簡單也最安全的修復。

1UPDATE orders
2SET status = 'paid'
3WHERE id = 12345
4  AND status = 'pending'
5  AND payment_id = 'abc';

AND 條件確保只在 當前狀態符合預期 時才改、避免 race condition。

Pattern 2：批次修復 + 節流

大量資料修復、必須節流避免影響 production。

1-- 每批 100 筆、間隔 1 秒
2UPDATE orders SET status = 'fixed'
3WHERE status = 'broken'
4  AND id IN (SELECT id FROM orders WHERE status = 'broken' LIMIT 100);

對應 Backfill 卡片 — backfill 跟 batch repair 是同類技術。

Pattern 3：補事件 / 補 webhook

外部副作用漏做時、補發事件。

• 必須帶 idempotency key（third-party 才能去重）
• 紀錄補發原因（incident report 連結）
• 注意：補發前確認 third-party 是否真的沒收到

Pattern 4：重建 derived state

cache 跟 search index 是 derived state、出錯通常 砍掉重建。

• 不是直接修 cache value、是 invalidate 讓下次 read 重算
• 大規模重建用 batch job 跑、避免 thundering herd
• 對應 9.C25 Tubi feature store 重建模式

Pattern 5：Point-in-time Recovery

當資料 損毀且無法重建 時、靠 backup recovery。

• PostgreSQL：WAL + base backup → PITR
• MySQL：binlog + snapshot → PITR
• Aurora：cluster snapshot + continuous backup
• 注意：recovery 期間可能要 整個 DB restore、影響範圍大

Repair Runbook

Repair runbook 的責任是讓資料修復可重複執行、並降低對當下工程師記憶的依賴。最小 runbook 需要包含：

1. 差異查詢與 query link
2. 影響範圍與 tenant / region / time range
3. 修復方式與 dry-run 結果
4. 審核 owner 與執行 owner
5. rollback condition 與後續 validation query

runbook 要和 validation query 共用語意。若查詢與修復程式用不同 mapping 規則、修復結果就難以被同一份 evidence 驗證。

Audit 與權限邊界

Data repair 常常需要高權限、因此必須接到 audit 與資料保護邊界。修復個資、付款、權限或方案資料時、要保留操作者、審核者、查詢範圍、寫入範圍與修復前後樣本。

Audit log 必要欄位：

• timestamp（操作時間）
• actor（誰執行）
• reviewer（誰審核、如果是 4-eyes process）
• query（執行了什麼 SQL / API call）
• before / after snapshot（值的變化）
• reason（為什麼做這次修復、incident ID）
• rollback path（如何回退）

這裡要接到 7.7 Audit Trail 與 Accountability Boundary。資料修復同時是可靠性、資安與合規問題。

權限分離與憑證時效

修復權限不該是常駐權限。日常開發 / SRE 帳號只該有 read-only、修復需要時才透過 break-glass 流程申請臨時 write 權限。

常見實作：

• 角色分離：reviewer 跟 executor 是不同帳號、reviewer 不能執行、executor 不能 self-approve。系統強制檢查兩個帳號不同、避免一人偽造另一身分。
• 時效性憑證：申請 write 權限時帶 expiry（30 分鐘 / 2 小時）、過期自動回收。不是「給了就一直有」、避免遺留高權限帳號變成攻擊面。
• 範圍限定：申請時要指定哪張表、哪個 tenant / region。粒度不細的話、一次申請就拿到全 production write、超出實際需求。
• 同步 alert：高權限被啟用要同步發 alert 到 security channel、給 security team reviewer 看見。事後若 audit log 跟 alert 對不上、表示權限被繞過。

對應 Identity Access Boundary 跟 Secrets and Machine Credential Governance。修復權限管理跟 incident-time 緊急存取是同一套機制、不該各做各的。

跨服務 / 跨組織的對帳責任

當對帳跨團隊、跨子系統、跨外部 provider 時、責任不清是首要失敗模式。對帳結果在組織邊界 穿越 時、要明確標記每段的 owner、否則 mismatch 出現後、所有相關方都會說「不是我們的問題」。

跨服務對帳的責任切分：

• 資料 owner：誰擁有那張表 / 那組欄位、誰負責解釋為何資料長那樣。資料 owner 通常是寫入該表的服務團隊。
• 對帳作業 owner：誰負責定義 reconciliation query、跑、看結果。可能跟資料 owner 是不同人（例如平台團隊跑對帳、業務團隊擁有資料）。
• 差異處理 owner：mismatch 出現後、誰負責決定修復策略。通常跟資料 owner 一致、但跨團隊 mismatch 要先約定誰主導。
• 修復執行 owner：實際下 SQL / call API 的人。可能跟差異處理 owner 不同（後者決策、前者執行）。

四個 owner 在簡單場景可以是同一人、在複雜跨團隊場景必須清楚分派。AGENTS.md 規範優先序段的「明確 owner」原則在這裡指的是 對每一段流程 都有人能簽收、不是只指對帳這件事整體有 owner。

跨組織對帳的特殊問題：跟外部 provider（金流、物流、SaaS supplier）對帳時、對方不見得會接受你的對帳結果、也不見得會給差異列表。常見處理：

• 自己跑兩份對帳：A vs provider report（每天）、A vs provider API（即時抽樣）、兩份結果不同代表 provider report 本身有問題。
• 約定差異仲裁流程：簽 SLA 時就寫清楚、mismatch 出現後雙方各保留多久的資料、誰先給對方檢視。
• 不能依賴 provider 修：金流 provider 通常只負責對帳、不負責修你的 DB。修復永遠是你方責任。

跟 Backup / PITR 整合

備份的 權限獨立性 跟 attack surface 屬於 1.5 Red Team 備份段 — 本段聚焦 recovery 角度的資料修復責任。兩者互補：1.5 解決「備份本身怎麼防被攻擊」、本段解決「事故後怎麼用備份回復」。

當修復必須跨越「point in time」時、需要 backup 配合。

Snapshot-based recovery

• 整個 cluster 從 N 小時前的 snapshot 還原
• 影響：所有 其他 資料也回到那個時間點
• 適合：catastrophic data corruption

PITR（Point-in-Time Recovery）

• snapshot + WAL / binlog replay 到指定時間
• 影響：只在指定時間點 stop replay
• 適合：「3 小時前 admin 誤刪一張表」這類精準回放

Logical backup（mysqldump / pg_dump）

• 整個 schema + data 的 SQL script
• 適合：跨環境遷移、特定表回復、小規模修復

Continuous archive

• WAL / binlog 持續備份到 S3 / GCS
• 一直可以回放到 任何時間點
• 對應 9.C24 Genesys 99.999% — 高可用需要快速 PITR

Recovery 時的對抗壓力

PITR / snapshot recovery 不是純技術問題、會在事故當下面對「為了快、要不要跳檢查」的取捨。對應 VMware ESXiArgs 2023 ransomware recovery pressure — 虛擬化平台勒索後、團隊在 營運壓力 跟 資料可信度 之間擺盪：snapshot 是否乾淨、回復後資料是否被污染、跳過 integrity check 換 RTO 是否可接受。判讀重點：recovery 流程要事前 演練 過、否則事故當下不知道要 verify 什麼、容易在壓力下接受被污染的 backup。對應 8.5 Incident Decision Log、事故當下的取捨要寫進 decision log。

RTO/RPO 跟業務可接受中斷的對照表

業務可接受中斷時間是 RTO/RPO 的判讀對照基準。RTO（Recovery Time Objective、多久能恢復）跟 RPO（Recovery Point Objective、最多丟多少資料）是技術指標、要對照業務側的可接受上限才能判斷夠不夠。常見錯誤是把 RTO/RPO 訂在「技術上能做到的最佳值」、忽略業務實際的容忍範圍。

對應 Change Healthcare 2024 — 「定義核心流程的 RTO / RPO、讓資料修復時間跟業務可接受中斷時間明示對照、不藏在直覺」。事故當下發現「DB 能 2 小時恢復、但業務只能容忍 30 分鐘中斷」、來不及補救。

對照表設計：

關鍵情境延伸：

• 付款（必須 active-active）：業務可接受中斷為 0、單一 region failover 都不能用（failover 期間用戶看到失敗）、必須多 region 同時寫入、靠 Aurora DSQL / Spanner / Cosmos DB multi-region write 撐。設計權衡是 跨 region 寫入延遲 跟 對帳一致性的特殊處理（同一筆款項可能在兩個 region 各被處理一次、要靠 idempotency key 去重）。詳見 1.11 全球分散式 OLTP。
• 訂單寫入（outbox + replay）：30 分鐘容忍區間夠用 outbox pattern — 訂單寫進 DB 同步寫進 outbox table、async worker 把 outbox event 推下游。即使下游中斷、訂單本身已落地、event 可在恢復後 replay。設計權衡是 outbox table 的儲存成本跟 replay 邏輯的冪等性、跟 03 訊息佇列模組 的 outbox pattern 整合。
• 用戶登入（standby region failover）：5 分鐘容忍意味 自動 failover 必須在這時間內完成、人類介入做不到、要靠 DNS health check + Route 53 / Cloudflare 自動切流。權衡是 standby region 平時付閒置成本、跟 active-active 比、便宜但 failover 時有 1-3 分鐘延遲跟 cache miss。

落差是 投資訊號、不是「忽略它」。RTO > 業務容忍時、要嘛降 RTO（加 HA / DR 投資）、要嘛跟業務協商提高容忍（通常不接受）。

判讀重點：對照表要每年 review。業務模式變了（例如從 B2C 變 B2B 客服 SaaS）、容忍時間會大幅縮短、RTO 必須跟著降。

事故角色預定義

DB 事故當下、資安處置 跟 業務連續性處置 要 分軌並行、不是線性執行。這要求事先有 dual-track IC（Incident Command）角色、不是事故當下臨時拉人。

對應 Change Healthcare 2024 — 「技術處置與業務處置分軌並行的前提是事先有 dual-track IC 角色」。沒事先定義、事故當下會出現「資安 team 在隔離系統、business team 在喊客戶等不及」、兩條軌道互相干擾。

Dual-track IC 角色定義（以下為通用 IC 模型、非案例直接揭露；具體角色細分視組織規模調整）：

Overall IC 跟一般技術 IC 的差異：一般 IC 主要在技術軌道內決策（要不要 rollback、要不要重啟）；Overall IC 額外承擔 跨軌道仲裁 責任 — 當 Tech IC 想停服務止血、Business IC 想保服務維持收入、兩者衝突時、由 Overall IC 拍板。這個角色需要對技術跟業務都有足夠理解、不能只懂一邊；通常由高階工程主管或 CTO/VP Eng 兼任、不是輪值的 oncall。

Data IC 的特殊角色：跟其他軌道相比、Data IC 的決策時間軸最長 — 技術修復可能 1 小時完成、但 資料是否被污染、要不要 PITR、PITR 到哪個時間點 可能要 24-72 小時驗證。Data IC 不能被 Tech IC 跟 Business IC 的「快快上線」壓力推動、必須有獨立判斷權。實務上常見的失誤是讓 Tech IC 兼任 Data IC、結果為了 RTO 跳過 integrity check、事後發現資料污染擴大。

事先準備：

• Primary + backup 雙人配置：每個角色都要有 primary + backup、避免單人不可用（休假、生病、被另一事故占住）讓事故當下卡住。實務上要有 指定流程 而非「臨時找誰」、避免事故當下浪費 30 分鐘喬人。
• 責任寫進 runbook：runbook 要列出每個角色該做什麼決策、不該做什麼決策（避免越權）。事故當下查職位、會在最壓力大的時候做組織決策、出錯機會高。
• 定期 tabletop 演練：演練的重點不是「技術修復對不對」、是「角色交接是否流暢」。Overall IC 跟 Tech IC 之間的權限邊界、Data IC 何時介入、Comms Lead 何時對外發言、都要在演練中試出來。
• 跨時區 follow-the-sun 輪值：B2B SaaS 跟全球業務、事故不分時區、要有 24/7 覆蓋。單一時區團隊在事故發生在凌晨時、人力不足或反應慢、會放大事故代價。

判讀重點：DB 事故不只是技術事件、會成為 跨多軌道 的事件。角色預定義是組織能力、不是技術能力、但缺它會放大技術事故的代價。

對應 8.5 Incident Decision Log 跟 7.13 Security Routing — 角色預定義是這些跨模組工作的前置。

Evidence Handoff

資料修復的 evidence handoff 要能支援 release gate 與 incident review。

這份 handoff 要進入 4.20 Observability Evidence Package 與 8.22 Incident Evidence Write-back。

判讀訊號

常見誤區

把對帳當成「定期 batch job」、不關心 當下不一致。實時對帳跟 batch 對帳是 不同工具、不能互相替代。

把資料修復當成「一個工程師動手改」、沒 audit、沒 review、沒 rollback。資料修復本質是 production 操作、跟 deploy 同等嚴格。

把 PITR 當成 常規修復工具。PITR 影響大、適合 catastrophic event、不適合單筆資料修復。

把 derived state 不一致跟 canonical state 不一致 混在一起 處理。derived 是 再生 的、canonical 是 永久 的、處理流程完全不同。

把對帳結果跟 anomaly detection 結果放同一份報告。前者是 deterministic、後者是 statistical、混報會讓 incident reviewer 無法判斷必修跟可疑。對帳 mismatch 要有獨立追蹤面板、anomaly 走另一條路徑。

跳過 dry-run、直接 update。即使單筆修復、也要先 select 看到當前 row、確認 WHERE 條件命中預期。incident 壓力下尤其容易跳、結果反而把單點問題擴成批次污染。

把修復權限當常駐權限發放。長期 write 權限放在工程師帳號上、會在事故無關時段被誤用、且事後無法區分「正常工作」跟「非法修復」。修復權限要時效化、申請即用即收。

案例對照

實體服務討論承接點

實體資料庫文章要承接本篇的 reconciliation 與 data repair 責任。PostgreSQL、MySQL、MSSQL 或其他資料庫的差異、應放在它們如何產生 validation query、保留 audit trail、支援 point-in-time recovery、處理 replica lag 與控制修復權限。

若服務需要高頻對帳、後續文章要比較查詢成本、索引策略與 replica 讀取延遲。若服務需要高風險資料修復、後續文章要比較 transaction log、backup/restore、row-level audit 與權限分離。若服務需要跨系統補償、後續文章要把資料庫能力接到 queue replay 與 incident decision log。

跨模組路由

1. 與 1.3 的交接：transaction boundary 決定哪些不一致可避免 — Transaction Boundary
2. 與 1.5 的交接：audit 跟 access control — Red Team Data Layer
3. 與 1.7 的交接：migration 後驗證 — Schema Migration Rollout Evidence
4. 與 1.8 的交接：canonical vs derived 是修復的前置 — State Ownership
5. 與 3.8 的交接：消息重放與補事件 — Queue Consumer Retry / Replay
6. 與 4.20 的交接：evidence handoff — Observability Evidence Package
7. 與 7.7 的交接：audit trail — Audit Trail and Accountability Boundary
8. 與 8.22 的交接：incident evidence write-back — Incident Evidence Write-back

下一步路由

要處理 migration 造成的資料差異、接著讀 1.7 Schema Migration Rollout 證據。要處理事件漏發造成的副作用修復、接著讀 3.8 Queue Consumer Retry 與 Replay Handoff。要設計跨服務 reconciliation 跟 saga compensation、接著讀 1.3 Transaction Boundary 的 Saga 段。

KV / Document DB 的容量規劃跟傳統 OLTP 完全不同。OLTP 容量靠「instance type 升級 + read replica」、KV 靠「partition 切分 + capacity unit 配置」。兩者瓶頸不同、可擴範圍不同、設計取捨也不同。

本章針對 DynamoDB、Azure Cosmos DB、Google Cloud Bigtable、MongoDB Atlas 等主流 KV / Document DB、整理容量規劃的共通方法論。讀完後讀者能回答：partition key 怎麼設計才不會 hot partition、on-demand vs provisioned 怎麼選、什麼時候從 single-region 升到 multi-region。

跟 1.1 高併發資料存取 的關係：1.1 處理 OLTP 高併發、本章處理 KV 高併發。兩者讀者群有重疊但解法不同。

跟 9.4 Saturation Discovery 跟 9.6 容量規劃模型 的關係：本章從 DB 視角 看容量、9.4 / 9.6 從 workload 視角 看容量、兩者互補。

KV / Document DB 的容量模型

KV 容量模型可以簡化成一條公式：總容量 = partition 數量 × 每 partition 上限。

vendor 不同、細節不同，但都遵循這個邏輯。

HTTP API DB vs connection-based DB 的本質差異

KV DB 在 surge 場景比 OLTP 有結構性優勢的主因、不只是 partition 設計、是 連線模型 的本質差異。

Connection-based DB（PostgreSQL、MySQL、MongoDB、Cassandra）：

• 用戶端跟 DB 維持 TCP connection、connection 有 state（authenticated session）
• 每個 connection 在 DB server 端佔記憶體 + 一個 process/thread
• connection 上限通常 1K-5K
• application 想開更多 connection、DB 直接拒絕

HTTP API DB（DynamoDB、Cosmos DB、Bigtable、Firestore）：

• 用戶端每次 request 開新 HTTP connection（或用 keep-alive 池）
• DB 端沒有「per-user connection state」、是 stateless API server
• 沒有 connection 上限概念、能力上限是 每 partition 的 RU / RCU
• application 加多少 instance 都不影響 DB

對應 9.C29 Lemino — NTT DOCOMO 串流服務選 DynamoDB 而非 RDB 的關鍵原因是 RDB 的 connection limit 在 surge 場景變成 bottleneck、HTTP API 模型沒這個問題。

判讀含義：選 KV DB 不只是「擴容容易」、是 連線模型 適合無 state HTTP 服務的天然契合。微服務數量增加時、HTTP API DB 不需要每次都 review connection pool 設定。但若 application 仍以 SQL transaction 為主流程設計、改 KV 需要 改 application 架構、不是換 driver 而已。

Amazon DynamoDB：

• 容量單位是 RCU（Read Capacity Unit）跟 WCU（Write Capacity Unit）
• 1 RCU = 1 strongly consistent read of 4KB / sec、2 eventually consistent reads
• 1 WCU = 1 write of 1KB / sec
• 每個 partition 上限：3000 RCU / 1000 WCU、底層 partition 數量透明

Azure Cosmos DB：

• 容量單位是 RU（Request Unit）— 把 read / write / query 統一抽象
• 1 RU = strongly consistent read of 1KB document
• 寫成本約 5x read、複雜 query 可達數百 RU
• 每個 logical partition 上限：10,000 RU/s

Google Cloud Bigtable：

• 容量單位是 node（SSD / HDD）
• 每個 node 約 10,000 reads/sec、10,000 writes/sec（依 row size）
• partition 透明、靠 tablet 自動分裂

MongoDB Atlas：

• 容量單位是 cluster tier（M10、M30、M60 等）+ shard
• 每個 shard 是獨立 mongod replica set、容量按 instance type 跟 storage
• 主動 sharding 設計、跟 DynamoDB 透明 partition 不同

共通點：容量上限不是「單一 number」、是「partition / shard 數量 × 每 partition 上限」。要擴容、要嘛加 partition、要嘛升級 partition、不能像 OLTP 一樣換更大 instance。

Partition key 設計：容量的命脈

partition key 設計不均勻、實際容量遠低於名義。這是 KV DB 最常見的 production issue。

Hot partition 的成因：

• 名義容量 = partition 數量 × 每 partition 上限
• 實際容量 = 最熱 partition 上限（如果分布不均）
• 100K RPS 名義能撐、若 80% 流量集中在 1 個 partition、實際 只能撐 3K RPS（DynamoDB partition 上限）

識別 hot partition 的訊號：

• throughput 上不去、但 average resource utilization 低
• 某些 key 的 request latency 飆、其他 key 正常
• DynamoDB throttling event 出現（即使 capacity 還沒滿）
• Cosmos DB 顯示「per-partition RU consumption skew」

設計策略：

1. 天然均勻 partition key：user_id、order_id、device_id 等天然分布廣的 ID。最簡單、最常用。
2. Composite partition key：把容易集中的維度（event_id）跟均勻的維度（user_id_hash）組合。例如 event_id#user_id_hash_mod_100、強制把同一 event 的流量分散到 100 個 sub-partition。
3. Write sharding：在 partition key 後加 random suffix。event_id#0 ~ event_id#9 讓同一個 event 變成 10 個 partition。讀的時候要 scatter-gather 從 10 個 partition 讀回來。
4. Time-bucket：對時序資料、加 minute / hour bucket。metric#2026-05-13-T12、每個時段一個 partition。

對應案例：

• 9.C5 Amazon Ads — 9000 萬 reads/sec 靠 partition 設計均勻、不是純擴 capacity
• 9.C15 Tixcraft — 售票 event_id 天然容易 hot、必須用 composite key 或 write sharding 分散
• 9.C11 Minecraft Earth — Cosmos DB synthetic partition key 強制分散

詳見 Hot Partition 卡片。

彈性來自 partition key 均勻分布

KV DB 的吞吐彈性等於 partition key 均勻分布的結果。partition key 均勻時、總容量 ≈ partition 數量 × 單 partition 上限；partition key 不均時、實際容量 = 最熱 partition 上限（DynamoDB 每 partition 3000 RCU / 1000 WCU）、跟 partition 總數無關。

對應 9.C15 Tixcraft — 售票 IOPS 從 20 衝到 135K 的 6,750 倍彈性、前提是 partition key 把流量分散到大量 partition（合理做法是 composite key event_id + user_id_hash 或 write sharding event_id + random_suffix）。若用裸 event_id 當 partition key、同一場演唱會所有訂單擠進同一個 partition、實際 IOPS 上限被鎖在 1000 WCU、跟 partition 總數無關。

判讀重點：讀「Amazon Ads 9000 萬 reads/sec」、「DynamoDB 1.51 億 RPS」這類數字、要追問「partition 設計是什麼」、再判斷自己的服務能否複製。換 DynamoDB 是必要前提、partition key 設計是充分前提；只換 DB 而沒解決 partition key、會出「換了 DB 但 hot partition 依舊」的事故。

Capacity mode：on-demand vs provisioned

DynamoDB / Cosmos DB 都提供兩種容量模式、各有適用場景。

On-demand（pay-per-use）：

• 不需事前配置 RCU / WCU / RU
• 自動 scale up / down、處理突發流量
• 單位成本高（約 7x provisioned）
• 適合：流量不可預測、burst 頻繁、開發 / 測試環境

Provisioned（預配置）：

• 預先訂購 RCU / WCU / RU
• 超過配額會 throttle（除非開 auto-scaling）
• 單位成本低
• 適合：流量可預測、sustained workload、生產環境

選型決策：

對應案例：

• 9.C20 Zomato — TiDB 必須長期 over-provision、換 DynamoDB on-demand 後 pay-per-use、50% 成本下降
• 9.C26 PayPay — sustained 3 億 msg/day 適合 provisioned + auto-scaling
• 9.C5 Amazon Ads — 9000 萬 RPS sustained workload 必然 provisioned + careful tuning

詳見 9.7 成本邊界與 efficiency 的成本曲線分析。

計費粒度 vs 工程顆粒

KV / Document DB 的計費單位（DynamoDB 的 RCU/WCU、Cosmos DB 的 RU、Spanner 的 processing unit）決定容量規劃可以從多小開始。計費粒度太大、中小規模負載付過多錢；計費粒度太小、大規模負載要管理很多細項。

對應 9.C10 Spanner — Spanner 早期最小單位是 100 processing units（pu）≈ 1 node、對中小負載門檻過高。後來推出 100 pu 起跳的 granular sizing、讓容量規劃可以從小開始、降低 onboarding 門檻。

選型含義：

• 新服務 / 中小規模：選計費粒度小的選項（Cosmos DB serverless、Spanner granular sizing、DynamoDB on-demand）、避免一開始就為了「未來會用到」過配。中小規模付過配成本、實際就是替「不確定的未來」付保險費、保險費過高代表選錯產品。
• 穩定大規模：計費粒度可大（DynamoDB provisioned with reserved capacity、Spanner full-node provisioning）、單價較低。Reserved capacity 通常綁 1-3 年合約、要看業務 未來 12-24 月需求是否穩定、若業務量可能下降或遷移、Reserved 反成沉沒成本；若業務量穩定上升、Reserved 是合理 hedging。
• POC / 測試：選 on-demand 或 serverless、付實際用量、別為了未實際 production 的 workload 付 reserved 成本。

判讀重點：計費粒度同時是 vendor 商業策略 跟 工程顆粒、選 vendor 時要看 min sizing 跟 增量 granularity、不只看 max throughput。

業務邏輯變化 → 讀寫比跳量級

讀寫比變化是容量規劃的早期警訊、但常被忽略。原始容量規劃通常基於某個讀寫比（例如 1:1 或 5:1）、業務邏輯改變可能讓比例跳一個量級、原容量規劃失效。

對應 9.C5 Amazon Ads — 廣告事件量測讀寫比 18:1（曝光發生 1 次、後續查詢 18 次）。如果業務新增即時報表功能、讀次數從 18 跳到 50、容量規劃要重做、不是「再加一點 capacity」。

常見業務變化導致讀寫比跳量級：

• 新增即時 dashboard：每筆資料被查詢頻率從 1 次跳到 N 次
• 新增推薦演算法：每用戶 read profile 從每次登入 1 次變成每次推薦 1 次（× 推薦頻率）
• 新增 audit / compliance 查詢：每筆敏感資料額外被查 5-10 次
• 新增 cache：讀次數從 100 降到 5（cache hit rate 95%）— 跟其他變化方向相反、是 capacity 該縮容 的訊號、若沒同步 review 反而會繼續按舊容量付錢
• 新增 anti-fraud 檢測：每寫入觸發 N 次 read 驗證

判讀重點：容量規劃 review cadence 不只看流量、要 review 讀寫比 是否漂移。比例跳量級是設計需要重做的訊號、不是單純 capacity 增加（或減少）的訊號。

一致性模型：strong vs eventual vs session

KV / Document DB 通常提供多個 consistency level、不同 level 對應不同延遲跟可用性。

DynamoDB：

• Eventually consistent reads（預設、便宜）：1 sec 內收斂、cost = 0.5 RCU
• Strongly consistent reads：跨 AZ quorum、cost = 1 RCU、不可跨 region
• 沒有中間 level

Cosmos DB（最豐富）：

• Strong：linearizable、跨 region quorum、最高 latency
• Bounded staleness：訂上限（時間 / 版本差異）
• Session：同一 session 內強一致（最常用）
• Consistent prefix：保證寫入順序、不保證收斂時間
• Eventual：最便宜、最終一致

Bigtable：

• Single-region：strongly consistent
• Replicated：eventually consistent

選 consistency level 的工程後果：

• Strong consistency → 跨 region 延遲（quorum round-trip）
• Eventual → 用戶可能看到舊資料、需要 application 容忍
• Session → 大多數網路服務的 sweet spot（用戶看自己寫的東西要立即、別人寫的可以稍晚）

對應案例：

• 9.C10 Spanner — external consistency（線性化）跨地區、付出 quorum 延遲代價
• 9.C30 Microsoft 365 Cosmos DB — 分析平台用 weakest consistency 換最大 throughput

詳見 1.3 Transaction Boundary 的一致性取捨。

Multi-model 取捨

部分 KV / Document DB 支援多個 model interface、同一服務跑不同抽象。

Cosmos DB（最廣 multi-model）：

• SQL API（document）
• MongoDB API（document、wire-protocol compatible）
• Cassandra API（wide-column）
• Gremlin（graph）
• Table（key-value）

DynamoDB（KV + document）：

• 原生 KV、但 attribute 可以是 nested map / list（document-like）
• 沒有 SQL interface（PartiQL 是 query language、不是 model）

Bigtable（wide-column）：

• 沒有 multi-model、純 wide-column
• 替代方案：用 Spanner + Bigtable 組合

Multi-model 的優缺：

• 優勢：同一團隊不必管多個 vendor、ops 簡化
• 優勢：不同 use case 用同一 datastore、減少 data sync
• 限制：vendor lock-in 加深、難換
• 限制：每個 API 都不是 最好 的（compromise）— MongoDB API 跟 native MongoDB 有 behavior 差異

選型建議：

• 已用 single model → 不必為 multi-model 而換
• 多種 use case 同時上 → 評估 Cosmos DB（特別是 MongoDB workload + 新需求）
• 純 KV 高吞吐 → DynamoDB / Bigtable 比 Cosmos DB 通常便宜

對應案例：

• 9.C30 Microsoft 365 — MongoDB → Cosmos DB MongoDB API、應用層幾乎不改、底層改用 Cosmos 分散式架構
• 9.C11 Minecraft Earth — 用 SQL API、不需要 MongoDB compat

KV DB 作為寫入緩衝的特殊用法

本節展開 KV 在 flash-sale 架構 的特殊角色、屬於資料層責任、但跟 9.11 高峰事件準備 跟 03 訊息佇列模組 互補（後者主寫 broker / queue 設計、本節聚焦把 KV 當 buffer 的取捨）。

9.C15 Tixcraft 揭露一個非傳統用法：DynamoDB 不當 OLTP、當 durable queue。

模式：前端把訂單塞進 DynamoDB（高吞吐、partition 均勻）、後端 legacy server 按自己能承受的速度從 DynamoDB 消費。

為什麼用 DynamoDB 而非 SQS / Kafka：

• DynamoDB Stream 提供 change data capture、後端可以 stream 消費
• 寫入後立即可查（OLTP-like）、不是純 fire-and-forget
• partition 設計讓單一事件可以分散到多個 partition
• 同樣 vendor、不必另起一個 broker 服務

適用場景：

• 突發流量遠超後端處理能力
• 後端是 legacy、不容易擴
• 需要寫入後立即可查（用戶看「我下單成功了」）

不適用場景：

• 純 fire-and-forget（用 SQS 更便宜）
• 高吞吐 stream processing（用 Kafka 更專業）
• 順序性嚴格要求（DynamoDB Streams 只在 partition 內保證順序）

詳見 9.C15 Tixcraft 案例 的詳細分析。

連線管理：跟 OLTP 完全不同

KV / Document DB 通常是 HTTP / gRPC 介面、不是 connection pool。這是跟 OLTP 完全不同的設計、影響應用層架構。

OLTP（PostgreSQL / MySQL）：

• 每個 application instance 維護 connection pool（10-100 connections）
• connection 是有狀態的（transaction、session variable）
• pool size × instance 數量 ≤ DB 上限（PostgreSQL 預設 100、PgBouncer 可破百）
• 9.C29 Lemino 案例 揭露 RDB connection 是隱性 bottleneck

KV（DynamoDB / Cosmos DB）：

• 純 HTTP / gRPC、無 stateful connection
• 每個 request 獨立、不必預先 establish connection
• 沒有 connection limit 概念
• 應用層擴容不會打爆 DB connection

這個差異是 KV DB 在 surge 場景 比 OLTP 有優勢的主因 — KV 不會 connection saturate。

隱性限流 vs 明確限流

flash-sale 或極端負載場景的限流可能分散在多層元件、不是單一「rate limiter」。同一架構可能同時包含 隱性 限流（用 DB / LB 上限自然攔截）跟 明確 限流（用排隊系統精確控速）。

對應 9.C15 Tixcraft — 售票架構圖上看不到明確「rate limiter」元件、但限流發生在多層：

• DynamoDB 寫入排隊：DynamoDB 把訂單塞進 queue、傳統 server 按自己能力消費 — DynamoDB throughput 就是隱性限流
• ELB max connection：load balancer 上限自動拒絕超量請求
• Application 層 connection pool：超過 pool size 的 request 排隊或被拒
• 付款層獨立：搶票流量塞爆時、付款不受影響、低頻路徑「自然限流」

對比 9.C16 SeatGeek Virtual Waiting Room 的 明確限流：用 Counters table 精確控發 token 速率、用戶看得到排隊位置。

選擇取捨：

失敗模式延伸：隱性限流的失敗特徵是「provisioned capacity / connection pool 飽和、用戶看到 5xx / timeout、沒人收到排隊位置」— 監控訊號是 DynamoDB throttling event 或 ELB queue length 飆。明確限流的失敗特徵是「排隊系統本身的 DB / counter 飽和、token 發不出來、所有用戶包含 VIP 都被擋」— 監控訊號是 token issuance success rate 掉。兩種失敗對應不同 runbook、混在同一 alert dashboard 會誤判。

適合業務延伸：隱性限流適合「流量瞬間到頂、業務願意接受用戶看不見排隊」的場景（演唱會搶票、Black Friday 開賣瞬間、限量商品）— 業務優先收住流量、用戶體驗可以事後解釋。明確限流適合「流量持續高、用戶等待時間長、需要顯示進度減少跳離」的場景（IPO 開盤、長期熱門商品上架、跨小時的搶購事件）— 用戶能看到「我還有 30 分鐘」會繼續等。

判讀重點：選哪種限流取決於業務願意接受什麼用戶體驗、不是工程偏好。隱性限流用透明度換流量吸收能力、明確限流用流量吸收能力換體驗可見度。兩者並存、沒有「best practice」。

案例對照

9.C16 SeatGeek 把 DynamoDB 當 排隊調度系統、不只當 queue buffer：用 Counters table 控發 token 的速率、Queue table 紀錄序號、Connection table 串 WebSocket。這個架構跟 9.C15 Tixcraft 的「全部塞進 DynamoDB 隱性緩衝」是兩種對立取捨 — Tixcraft 用透明度換流量吸收能力、SeatGeek 用流量吸收能力換體驗可見度。判讀重點：KV DB 不只能當 OLTP 替代品、4 張表組合就能變成業務級調度引擎、選表前要先確定業務需要哪一面。

下一步路由

• 上游：0.2 State Storage Selection — KV vs OLTP vs SearchIndex 選型
• 平行：1.1 高併發資料存取（OLTP 版本）/ 1.3 Transaction Boundary
• 下游：1.11 全球分散式 OLTP、1.12 大規模 DB 遷移實戰（含「預設 DB 治理 pattern」— KV 在大規模平台的選型治理）
• 跨模組：9.4 Saturation Discovery（hot partition 量測）、9.6 容量規劃模型、9.7 成本邊界
• DynamoDB 深入：partition key 反模式、on-demand vs provisioned 切換、single-table design、GSI / LSI 設計
• Cosmos DB 深入：partition key 設計、RU 成本模型、一致性層次工程
• MongoDB 深入：shard key 選型、schema design pattern、connection 管理與 cache 層

既建知識卡片

• Hot Partition
• Saturation Point
• Connection Pool
• Tail Latency

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

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

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

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

CAP 跟 PACELC：理論工具

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

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

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

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

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

工程含義：

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

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

Spanner / TrueTime 模型

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

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

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

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

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

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

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

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

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

對等技術跟取捨：

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

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

容量規劃：

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

適用場景：

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

不適用：

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

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

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

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

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

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

Aurora DSQL：AWS 的全球 strong consistency 答案

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

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

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

跟 Spanner 的差異：

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

適用場景：

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

CockroachDB 跟 TiDB：自管選項

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

CockroachDB：

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

TiDB：

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

選擇取捨：

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

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

Cosmos DB multi-region write 模式

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

五個 consistency level（從強到弱）：

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

Multi-region write 特色：

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

適用場景：

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

對應案例：

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

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

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

典型法規：

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

設計策略：

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

對應案例：

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

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

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

典型跨 region quorum latency：

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

工程含義：

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

對應案例：

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

詳見 Latency Budget 卡片。

業務的不同延遲代價曲線

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

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

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

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

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

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

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

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

容量單位：

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

規劃要點：

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

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

可用性目標的成本曲線

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

九的數學意義：

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

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

適用場景的業務理由：

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

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

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

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

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

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

Sharding 粒度跟業務一致性需求

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

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

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

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

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

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

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

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

案例對照

下一步路由

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

既建知識卡片

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

DB 遷移是後端工程中 風險最高的長期工作 之一。一次失敗的遷移可能造成資料丟失、用戶體驗劣化、合規違約、團隊信心受挫。本章整理近 5 年公開的大規模 DB 遷移案例、提煉出可重用的工程流程。

跟 1.6 database migration playbook 的關係：1.6 是 generic playbook、本章針對「跨 DB 種類」遷移（PostgreSQL → Aurora、TiDB → DynamoDB、MongoDB → Cosmos DB）、規模較大、風險較高。

跟 1.7 Schema Migration Rollout Evidence 的關係：1.7 處理 同一 DB 內 的 schema 演進、本章處理 換 DB engine 的遷移。兩者都用 evidence-based gate、但 stakes 不同。

讀完後讀者能回答：跨 DB 遷移該怎麼分階段、dual-write 怎麼設計、shadow read 怎麼驗證、cutover 怎麼安全進行、rollback window 訂多久。

遷移類型分類

DB 遷移不是單一概念、按 變動範圍 分四類、每類風險跟流程不同。

Type 1：scale-up（換 instance）：

• 例：m5.large → m5.4xlarge
• 變動：硬體規格、不變 schema、不變 DB engine
• 風險：低、通常 minutes downtime 即可
• 工具：vendor 提供 in-place scaling

Type 2：schema migration：

• 例：加欄位、加 index、改 data type
• 變動：schema 結構、不變 DB engine
• 風險：中、需要 expand-contract 模式
• 詳見 1.7 Schema Migration Rollout Evidence

Type 3：cross-DB engine migration：

• 例：PostgreSQL → Aurora、SQL Server → PostgreSQL、TiDB → DynamoDB
• 變動：DB engine、可能 schema、可能 query language
• 風險：高、可能需要應用層改寫、cutover 風險大
• 本章重點

Type 4：cross-model migration：

• 例：RDBMS → KV、Document → Graph
• 變動：資料模型、必須應用層大改寫
• 風險：極高、通常分 service 漸進遷移、不會一次切完
• 對應 9.C20 Zomato TiDB → DynamoDB

為什麼要做大規模 DB 遷移

不是所有遷移都值得做。理由要強過 成本 + 風險、不然不該開工。

合理動機：

• 舊系統規模上限：9.C20 Zomato TiDB 必須長期 over-provision 應付 spike、成本不划算 → 換 DynamoDB on-demand 後 50% 成本下降
• 舊系統運維成本：9.C9 Spotify 自管 Kafka 工程成本太高 → 換 managed Pub/Sub 釋放 SRE
• 舊系統失能：9.C23 Netflix 多套 RDBMS（PostgreSQL、MySQL、Oracle）DBA 負擔重 → 統一到 Aurora、效能 +75% 成本 -28%
• vendor 終止支援：mongoDB 改授權、TiDB 改授權、Mesos 被棄、Oracle 升級費高
• 合規要求：9.C14 Standard Chartered 新市場上線、需要本地合規 cluster
• 新功能需求：9.C30 Microsoft 365 需要 global distribution、原 MongoDB 達不到

不合理動機（要警惕）：

• 「新技術好酷」：fad-driven、通常會後悔
• 「vendor sales 推銷」：sales 利益跟你 ROI 不一致
• 「同行 X 也在遷」：人家的場景跟你不同
• 「主管要看到 transformation」：政治、不是工程

遷移階段流程

成熟的大規模 DB 遷移分五階段、每階段有明確 exit criteria。

階段 1：可行性評估（T-180 ~ T-90）

輸出：可行性報告、決定 go / no-go。

評估項目：

• workload 在新 DB 上是否真的能跑（不是 marketing、是實測 POC）
• 應用層改寫成本（哪些 query 需要改、哪些 ORM 需要換）
• 遷移時程預估（含 合規審查 lead time、如金融業可能 3-12 個月）
• 成本對比（總成本曲線、不只當下 snapshot）
• 失敗代價（如果遷移失敗、business 影響多大）

跨雲遷移特有 gap 分析：當遷移橫跨雲廠商時、評估項目要加上 0.19 雲端服務對照地圖 的「對應 ≠ 等價」差異維度：

• 一致性模型差異（如 DynamoDB eventual vs Cosmos DB 五級可選）
• failover 時間差異（vendor 文件 vs 實測長尾）
• 計價模型差異（per-request vs provisioned capacity 換算）
• 配額差異（partition 上限、batch size、throttling 行為）
• Data gravity / egress lock-in（PB 級資料的 egress fee 常是被低估的單筆最大成本）

跨雲遷移的失敗多數來自 0.19 對照表沒做完整 gap 分析、把「名稱對應」當「能力等價」。

對應案例：

• 9.C20 Zomato — POC 驗證 DynamoDB 撐得住、再決定遷移
• 9.C30 Microsoft 365 — MongoDB API 相容讓 POC 成本低、加速決策

階段 2：應用層相容性改造（T-90 ~ T-30）

輸出：應用層支援 新舊 DB 雙寫、可以隨時切換。

改造項目：

• Repository adapter 抽象化（1.4 Repository Adapter）
• 新增 新 DB 的 adapter 實作
• 配置「寫入 mode」：old only / dual-write / new only
• query 端「讀取 mode」：old / new / shadow（讀兩邊比對）
• error handling 兼容（不同 DB 的錯誤碼）

API-compatible 遷移的優勢：

• 9.C30 Microsoft 365 MongoDB → Cosmos DB MongoDB API — 應用層幾乎不用改、只換 connection string
• Aurora PostgreSQL-compatible → 不改 SQL 跟 ORM
• 缺點：API 相容不等於行為完全相同、要 特定 query pattern 驗證

階段 3：Dual-write + shadow read 驗證（T-30 ~ T-7）

dual-write / shadow read / backfill 的 generic 機制 詳見 1.6 database migration playbook 跟 1.7 schema migration rollout evidence（含 Dual-write divergence schema 詳細分類）；本章只強調 跨 DB engine 遷移的特殊取捨。

輸出：新 DB 已 並行寫入、跟舊 DB 結果一致。

Dual-write 流程：

1. 應用層同時寫入 old 跟 new DB
2. 用 old DB 結果回應用戶
3. log 兩邊寫入是否成功、有差異就 alert
4. backfill 之前的歷史資料到 new DB

Shadow read 驗證：

1. 應用層查 old DB 拿結果回用戶
2. 也 查 new DB、比對結果是否一致
3. 不一致記錄到 audit log
4. 跑 N 天（建議 7-14 天）確認一致性高

注意事項：

• Dual-write 期間 兩邊都要可寫、寫失敗的 fallback 流程明確
• 新 DB 還沒承擔流量、容量規劃要 提前 ramp up、不要等 cutover 才發現容量不夠
• 監控指標：write success rate、cross-DB inconsistency rate、replication lag、performance metrics

對應案例：9.C20 Zomato — 遷移前用 dual-write 驗證 4 倍吞吐改善是真的、不是 POC marketing。

階段 4：Cutover（T-7 ~ T-0）

輸出：用戶流量切到 new DB、old DB 變成 fallback。

Cutover 策略：

Big-bang cutover：一次切全部流量

• 優點：簡單、不必維護 跨 DB consistency
• 缺點：風險集中、rollback 困難
• 適合：小規模、low-stakes

Gradual cutover（推薦）：分階段切

• T-7：1% 流量到 new DB、觀察 1 天
• T-6：5% → 觀察 1 天
• T-5：25% → 觀察 1 天
• T-3：50% → 觀察 2 天
• T-1：100%

Reverse rollout：某些工作負載先切（read-only first、再 write）

• T-7：所有 read 切到 new DB（write 還在 old）
• T-3：write 切到 new DB（read 已驗證）

階段 5：Rollback window + 清理（T+0 ~ T+30+）

Rollback window：cutover 後保持 可隨時 rollback 回 old DB 的狀態。

Rollback window 設計：

• 短期（T+7）：保持 dual-write、可以即時切回 old DB
• 中期（T+30）：保留 old DB read-only、需要 manual 切回但快
• 長期（T+90）：保留 old DB snapshot、disaster recovery 用
• 結束：徹底刪除 old DB（含 backup、ETL pipeline 改寫）

Cleanup 工作：

• 移除 dual-write code
• 移除 shadow read code
• 簡化 repository adapter（只保留 new DB）
• 文件更新（runbook、onboarding doc）
• decommission old DB（不立即砍、保留至少 90 天備援）

對應案例：9.C9 Spotify Kafka → Pub/Sub — 大規模事件交付系統的 multi-month 漸進遷移、有明確 rollback path。

API-compatible vs 應用層改寫

跨 DB 遷移的關鍵決策：要不要追求 應用層零改動。

API-compatible 遷移：

• 新 DB 提供舊 DB 的 wire protocol / API
• 應用層只換 connection string、不改 query
• 例：MongoDB → Cosmos DB（MongoDB API）、Cassandra → Cosmos DB（Cassandra API）、MySQL → Aurora（MySQL）

優點：

• 遷移成本低（不必改 application code）
• 風險低（不會引入 query bug）
• 時程快（不必等 application 改寫）

缺點：

• 行為可能不完全一致（subtle bug）
• 性能可能不是最佳（compat 層有 overhead）
• vendor lock-in 更深

應用層改寫：

• 換 query 風格、ORM、access pattern
• 例：PostgreSQL → DynamoDB（SQL → NoSQL access pattern）

何時必須應用層改寫：

• 跨 model（RDBMS → KV）
• 跨 query paradigm（SQL → MongoDB 風格）
• 想拿 native 性能 / 成本優勢

對應案例：

• 9.C30 Microsoft 365 — MongoDB API compat、應用層幾乎不改
• 9.C23 Netflix — 多套 RDBMS → Aurora、PostgreSQL / MySQL 相容、最小應用層改動
• 9.C20 Zomato — TiDB（SQL）→ DynamoDB（KV）、必須改 access pattern、不能 API compat

容量規劃在遷移中的角色

DB 遷移期間有特殊的容量挑戰、跟一般 capacity planning 不同。

遷移期容量需求：

• old DB 持續服務 production
• new DB 接 dual-write（額外負載）
• backfill historical data（額外負載）
• shadow read（讀兩倍）
• 應用層擴容（dual-write 邏輯吃 CPU）

典型容量增加：

• 應用層 +20-30%（dual-write、cross-DB logic、metric）
• new DB 必須 提前 provision 接 100% 流量
• 監控 / log 容量 +50%（要追蹤更多事件）

對應 9.6 容量規劃模型：遷移期是「臨時 over-provisioning 期」、要算進 cost。遷移完才能 right-sizing。

對應 9.10 Production-Side 驗證：dual-write 跟 shadow read 是 production validation 的特殊形式、要按 9.10 的安全邊界設計。

案例對照

遷移評估的成本曲線

遷移 ROI 評估常見錯誤是 只看當下流量下的成本對照、忽略未來流量曲線。決策時要算 12-24 個月的累積成本、不是 snapshot。

對應 9.C20 Zomato TiDB → DynamoDB — Zomato 帳單系統「成本降 50%」是當下流量下的對照。如果未來流量繼續成長、DynamoDB on-demand 的單位成本可能比 TiDB 自管 cluster 高、達到某規模後 TiDB 反而更便宜。

評估公式：

1未來 N 個月累積成本 = sum(月流量 × 月單位成本)

各 DB 的「月單位成本 vs 流量」曲線形狀不同：

• DynamoDB on-demand：線性、按用量計費、單位成本固定
• DynamoDB provisioned + reserved：階梯、預訂量越大單價越低
• 自管 TiDB / PostgreSQL：階梯 + 固定基線、低流量時單位成本高（基線分攤）、高流量時單位成本低
• Aurora Serverless：線性、但有最低 ACU 基線
• Spanner：節點數 × 單價、增量是 100 pu 一單位

曲線交叉點是選型決策的關鍵：DynamoDB on-demand 跟自管 PostgreSQL 在某個流量水位交叉、流量低於此值前者便宜（無基線成本）、高於此值後者便宜（基線分攤後單價低）。Aurora Serverless 跟 Aurora provisioned 也有類似交叉、波動大的 workload 在 Serverless 划算、穩定的在 provisioned 划算。Spanner 因為節點數階梯式增加、跨節點交叉點通常在 每節點 70-80% 利用率 — 過了就要加節點、新節點利用率掉回 50% 是常態。判讀重點：選型不該只看 當下流量點、要看未來 12-24 月的流量曲線會跨過哪些交叉點、再決定哪種計費模式總成本最低。

遷移 ROI 評估的維度：

機會成本延伸：機會成本是遷移期間 不能做新功能 的時間。大型遷移通常綁住核心 team 6-12 個月、期間業務側看不到產品演進、可能流失市場機會。實務上要算「如果這 6 個月去做新產品、營收 / 競爭優勢值多少」、若超過遷移節省的 infra 成本、遷移不划算。

Lock-in 成本延伸：vendor lock-in 不是「不能換」、是「換的時候要付多少」。包含：(1) 應用層改寫成本（DynamoDB → Spanner 要改 access pattern）、(2) 合約終止 penalty（reserved capacity 提前解約罰款）、(3) 資料導出成本（雲商出口流量費）、(4) 人才再訓練（DBA 從 Aurora 轉 Spanner 需要時間）。選 vendor 時就要評估這四項、即使沒打算換、合約年限到時也要面對。

判讀重點：「遷移後成本降 50%」這種敘述只看 infra 成本、且只看當下。完整評估要看所有六個維度跨 12-24 月、決策才不會出「短期省、長期更貴」或「短期看似賺、合規卡 1 年」的事故。

合規審查 lead time 是時程主要拉力

受監管產業（金融、醫療、電信、政府）的 DB 遷移、合規審查 通常是時程主導因素、不是技術整合。

對應 9.C14 Standard Chartered — 跨 7 個受監管市場遷移到 Aurora、每個市場各自審查（中央銀行 / 金融監管機關 / 個資主管機關）、單一市場審查 3-12 個月、總時程是「市場數 × 平均審查月份」、不是「技術遷移月份」。

合規 lead time 的常見項目：

• 中央銀行核心系統變更審查（金融業）
• 個資主管機關的跨境傳輸審批（GDPR / 各國個資法）
• 醫療資料的隱私審查（HIPAA / 各國醫療法）
• 雲端服務商的合規認證對應（PCI-DSS、ISO 27001、SOC 2）
• 跨市場資料駐留限制（中國《數據安全法》、印度資料保護法、歐盟 GDPR）

規劃含義：

• 技術側 ready ≠ 可上線、合規簽核才是 cutover gate
• 合規審查通常 serial、不能 parallel（單一審查機關沒法平行處理多 case）
• 高風險變更（DB 換 vendor、cross-border）審查週期最長
• 跨市場部署、各市場各自審、不能用某市場結果代替

判讀重點：受監管產業的遷移計畫、預設技術側 50%、合規 50% 工時、不是「技術 90% / 合規 10%」。低估合規 lead time 會讓專案在最後關頭卡關、且無法用工程資源補。

Benchmark 對照基準的解讀

遷移案例的「X% improvement」要追問 跟什麼基準比、否則容易誤導。

對應 9.C14 Standard Chartered — 「10x throughput」是 vs 舊系統、不是 vs 競爭對手。受監管銀行的舊系統通常是 1990s-2000s 的 mainframe 或自建 OLTP、性能本來就低、改善幅度大不代表絕對性能領先。

對應 9.C23 Netflix Aurora consolidation — 「up to 75% improvement」是 跨多個 workload 的最大改善幅度、不是「每個 workload 都 +75%」。實際每個 workload 改善從 10% 到 75% 不等、平均可能 30-40%。

benchmark 解讀的關鍵問題（遷移情境專屬）：

• vs 什麼基準：跟舊系統比 vs 跟競爭對手比 vs 跟理論最佳比
• 哪個 workload：是平均 vs 最快 vs 最慢
• 規模對照：在多大流量下測的、自家業務規模類似嗎

讀 vendor 案例研究時、這三個遷移專屬維度都要對照、否則「75% 改善」可能變成「在某個 cherry-picked workload、跟舊系統比、規模跟自家不同」、實際搬過去未必有對應收益。

規模對照延伸：vendor 案例研究最容易誤判的維度。讀者要識別三個訊號才能判斷規模是否類似 — (1) 資料量（vendor 揭露的是 GB 還是 PB？自家在哪個量級？）、(2) QPS 分布（vendor 是 sustained 還是 bursty？自家流量形狀是否類似？）、(3) 讀寫比（vendor 案例是 write-heavy 還是 read-heavy？自家業務性質是否吻合？）。三個訊號至少要有兩個跟自家對齊、benchmark 數字才有參考價值。對應 9.C5 Amazon Ads 案例的 18:1 讀寫比、跟一般電商的 5:1 完全不同、不能用同一份 benchmark 推論。

Percentile 跟時間窗口維度 — 是更通用的容量數字判讀問題、詳見 1.1 高併發資料存取的「讀峰值數字的工程細節」 段（容量三口徑、p50/p99/p999 解讀）。遷移情境只需在這個基礎上加「vs 基準 / workload / 規模對照」三個遷移專屬問題。

「預設 DB」治理 pattern

大規模平台選 DB 的做法是建立「預設 DB」規則、新團隊用其他要 justify、逐案決定在這個規模行不通。這個治理 pattern 簡化 onboarding、降低 DB 種類太多的運維成本。

對應 9.C24 Genesys — Genesys Cloud 的 Chief Architect 明確說「Amazon DynamoDB is our primary data layer by default, and teams have to justify the use of something else」。對應 9.C23 Netflix — 把多套 RDB 整合到 Aurora、降低 DB 種類就是降低運維 surface area。

預設 DB 治理的工程含義：

• 新團隊預設用 X、特殊需求才評估其他、減少 DB 評估的認知負擔
• DBA / SRE 知識集中、不必養多個 vendor 的專業
• 監控、backup、compliance 流程統一、運維成本下降
• 多個服務的 schema migration / capacity planning 可以共用 tooling

選擇預設 DB 的判讀條件：

• 平台規模夠大（10+ 微服務）、運維 surface area 是真實成本
• 業務需求大部分可以收斂到單一 DB（OLTP 90%、KV 10% 可以選 OLTP 為預設）
• vendor 提供完整能力組合（managed + multi-region + auto-scaling）

預設 DB 對應：

• AWS 生態大規模 OLTP → Aurora（Netflix）
• AWS 生態大規模 KV → DynamoDB（Genesys、Capcom、Disney+）
• Azure 生態 multi-model → Cosmos DB
• GCP 生態 OLTP → Spanner / AlloyDB

同一雲廠商兩個預設 DB 怎麼選邊界：AWS 生態同時有 Aurora（OLTP 預設）跟 DynamoDB（KV 預設）、不衝突、但要清楚兩者邊界。預設選 Aurora 的條件是「需要 SQL JOIN / ACID 跨表 transaction / 既有 ORM」、預設選 DynamoDB 的條件是「access pattern 已知且固定 / 預期跨 region 寫入 / surge 場景下 connection-based DB 撐不住」。這條邊界要寫進平台的 onboarding doc、否則新 team 會在「Aurora 還是 DynamoDB」之間反覆 review、抵消預設 DB 治理的價值。

判讀重點：小規模平台（< 5 微服務）不必預設 DB 治理、case-by-case 決定即可。隨著服務數量增加、DB 種類失控成為大規模平台的隱性成本、預設 DB 治理變成規模化階段的工程紀律。

Vendor dogfood 是 selection signal

Vendor dogfood signal 是 vendor 自家 production-critical workload 對該服務的使用程度、反映 vendor 對自家服務的真實信任度。讀 vendor 案例研究時、這個訊號比 sales material 更可信、因為 vendor 自己賭身家。

對應 9.C1 AWS Prime Day — Amazon Prime Day 用自家 DynamoDB + Aurora 撐 1.51 億 RPS + 500B txn。對應 9.C10 Spanner — Google 自家 Ads、Play、Search 都用 Spanner。對應 9.C30 Microsoft 365 — Microsoft 365 usage analytics 用自家 Cosmos DB。

Dogfood 訊號為什麼重要：

• vendor 自家賭身家、出問題自己第一個踩
• 內部 dogfood 通常比外部 customer earlier 用、bug 修得快
• vendor sales team 的「能撐 X」如果跟內部 dogfood 不一致、是 marketing
• 內部用量大、vendor 對該服務的工程投入比 marginal customer 多

Dogfood 訊號的限制：

• vendor 內部享有專屬資源配額跟內部成本機制、外部用戶在公開計費下、單位成本邊界不同
• vendor 內部享有深度 API 客製化跟特殊 SLA、外部用戶實際可取得的能力是公開版本
• vendor 自家業務的 workload pattern 反映 vendor 自己的業務需求、跟你業務的 workload 可能不同

判讀重點：dogfood 是必要訊號、不是充分訊號。看 vendor 自家用代表服務經過嚴格驗證；但「自家業務 vs 你業務」的相似度（資料量、QPS、讀寫比、一致性需求）才是 dogfood signal 是否能套用的判讀條件。

反模式

大規模 DB 遷移的常見錯誤：

• 沒做 POC 就 commit 遷移：發現新 DB 撐不住某個 query pattern、時程崩
• dual-write 沒 monitoring：兩邊不一致沒被發現、cutover 後資料錯亂。divergence 該怎麼分類追蹤、詳見 1.7 Dual-write divergence schema
• shadow read 跑太短：1-2 天就 cutover、long-tail bug 沒暴露
• 沒 rollback path：cutover 後發現問題、回不去
• app 跟 DB 一起遷：兩個 risk source 疊加、追根因困難
• 忽略合規 lead time：技術側 ready 但合規審查還在跑、整個 stuck
• 忽略 ETL pipeline：production cutover 完、下游 BI / analytics 還在打 old DB

下一步路由

• 上游：1.6 database migration playbook（基本流程）/ 1.7 Schema Migration Rollout Evidence（schema 演進）
• 平行：1.10 KV / Document DB 容量規劃 / 1.11 全球分散式 OLTP
• 跨模組：9.10 Production-Side 驗證（dual-write、shadow）、9.6 容量規劃模型、6.11 Migration Safety、8.19 Incident Decision Log
• 跨 vendor 實戰深入：Cosmos DB MongoDB API vs SQL API（document → multi-model）、Aurora 從自管 PG / MySQL 遷入、Spanner 從 Cloud SQL PG 遷入、MongoDB 遷入 Atlas

既建知識卡片

• Schema Migration
• Expand / Contract
• Dual Write
• Backfill
• Cutover Window
• Rollback Window
• Shadow Traffic
• Fallback Read

為什麼查詢反模式比 vendor 細節更重要

多數團隊面對「資料庫變慢」時，會先去看 vendor 的調校（buffer pool、配置升級、replica 加開）。這些調校通常把基礎效能拉高 1-2 倍；一個 N+1 query 反模式可以讓回應時間慢 10-1000 倍（具體倍數取決於 N 跟 RTT — N=100 + RTT=1ms 約慢 100 倍）。先解掉應用層的反模式、再去調 vendor 配置，整體效益遠高於反過來。

這條優先序也對應 9.5 瓶頸定位流程 的精神：先定位真正的瓶頸再決定是否加資源。應用層 query 是最常被忽略的瓶頸來源。

N+1 Query：最常見也最隱性的反模式

N+1 query 指「先發一個 query 取回 N 筆資料、再對每一筆各發一個 query 取相關資料」，總共 1 + N 次 round trip。N 越大、整體越慢。

典型範例：列出 100 個訂單跟每筆訂單的客戶資料。錯誤寫法是先 SELECT * FROM orders LIMIT 100 拿到 100 筆訂單、再對每一筆訂單做 SELECT * FROM customers WHERE id = ?，總共 101 次 query。正確寫法是 JOIN 或 IN 一次取回：SELECT o.*, c.* FROM orders o JOIN customers c ON o.customer_id = c.id LIMIT 100，1 次 query 完成。

N+1 在 ORM 環境特別隱性，因為它常被框架的 lazy loading 機制隱藏。Django ORM 的 order.customer 看起來像存取 attribute，背後對應一次 query。寫程式時看不到 SQL，發布後才從 slow log 發現問題。

判讀方式：開啟 ORM 的 query log（debug mode）、看一個 API request 跑出幾個 query。預期是個位數；若 query 數隨著資料集大小線性成長（例如 list 100 筆觸發 100 query、list 1000 筆觸發 1000 query），這條 scaling 訊號就是 N+1 — 比固定閾值更可靠的判讀。

修正方向：

• ORM 端用 eager loading（Django select_related / prefetch_related、Rails includes、SQLAlchemy joinedload）
• 自己寫 SQL 用 JOIN 或 IN 條件批次取
• 確認 ORM 預設不是 lazy（有些 ORM 的設計鼓勵 lazy，需要明確標示 eager）

Select * 與超量讀取

SELECT * 把表的所有欄位都拉出來，包含可能很大的欄位（content、blob、JSON）跟根本用不到的欄位。代價有三：

1. 網路傳輸成本：query 結果在 DB 跟應用之間傳輸，欄位越多越大。
2. 記憶體成本：應用程式要 deserialize 整個 row，物件越大記憶體佔越多。
3. 隱性耦合：欄位有變動（新增、刪除、改型別）時，所有 SELECT * 的 query 都會被影響。

修正方向是明確列出需要的欄位：SELECT id, name, status FROM orders。如果擔心欄位列表太長，問自己是不是 query 試圖一次處理太多責任。

例外是 ad-hoc query 跟 DB tool 環境，可以接受 SELECT *。production code 不應該有。

缺索引：查詢計畫沒走索引

缺索引的徵兆是 query 在小資料量時很快、資料一多就突然慢。原因是 query 走了 full table scan，資料量小時 scan 還快、資料量上百萬筆就慢。

判讀方式是用 EXPLAIN 看查詢計畫：

• type=ALL 或 Seq Scan 代表沒走索引
• rows 估計值跟實際表大小接近，代表掃描範圍過大
• Using filesort / Using temporary 代表排序或暫存資料的成本

修正方向不是「對每個 WHERE 條件都建索引」，這會讓寫入變慢、索引變大。要建索引的判讀條件：

• 該 query 是熱路徑（頻率高、影響 user）
• 該欄位有足夠選擇性（distinct 值多）
• 該欄位沒有跟其他索引重複覆蓋
• 寫入路徑能承受多一個索引的維護成本

複合索引的欄位順序也要對齊 query 的 WHERE 條件。WHERE a = ? AND b = ? 適合 (a, b) 複合索引，不適合 (b, a)。這部分屬於 1.2 schema design 與資料建模 的範圍、本章只標出徵兆跟診斷起點。

ORM Lazy Load 陷阱

ORM 的 lazy load 預設行為是「存取 attribute 時才發 query」，這在開發時讓 code 很乾淨，但隱藏了 query 的數量。

常見陷阱：

• 跨 transaction 邊界存取 lazy attribute：query 在原 transaction 已關閉後才發，連線狀態錯誤。
• 在 template / serializer 裡存取 lazy attribute：一個 page render 觸發數十個額外 query。
• lazy load 跨服務邊界：DTO 傳遞時不知道哪些 attribute 是 lazy、哪些是 eager，前端拿到 DTO 後 trigger 額外 query。

修正方向：

• 明確標示 eager loading 邊界，serializer 之前完成所有需要的資料載入
• ORM 配置改成 default eager 或 strict mode（query 太多會 warning）
• DTO 出 service 邊界前做 fully materialized

Long-Running Transaction

長時間佔住的 transaction 會擋住其他 query、產生 lock 等待、消耗連線池資源。

常見成因：

• 在 transaction 內做 HTTP call 或外部 API 呼叫
• 在 transaction 內做檔案 I/O 或長計算
• 用 transaction 包住整個 request handler（從 request 開始到 response 結束都在 transaction）
• ORM 設定 default transaction-per-request 但業務只需要短交易

修正方向是把 transaction 範圍縮到最小：只包住「需要原子性」的那幾個 SQL 操作。外部呼叫、計算、檔案 I/O 都要在 transaction 之外。詳見 1.3 transaction 與一致性邊界。

其他常見反模式

上面五個是讀路徑高頻反模式。實務上其他幾類在 slow log 出現頻率不低、要一併列入發布前檢查：

• Cardinality explosion / cross join 誤用：兩個多對多關聯 join 沒加 filter、結果集從 N 行炸成 N×M 行。判讀訊號：query 結果行數遠超業務直覺、EXPLAIN 估計 rows 異常大。修正方向：補 filter、改 EXISTS / IN 半連接、或拆兩段 query。
• OFFSET-based pagination on large tables：LIMIT 20 OFFSET 100000 在大表退化成「掃描 100020 行 + skip 100000 行」。修正方向：用 keyset / cursor pagination（WHERE id > last_seen_id LIMIT 20）— 一致 O(LIMIT) 而非 O(OFFSET + LIMIT)。
• 隱式型別轉換讓 index 失效：WHERE varchar_col = 123 把 column 轉成 int 比較、index 失效退到 full scan。判讀訊號：EXPLAIN 顯示 index 沒命中但 schema 上有 index。修正方向：明示型別（WHERE varchar_col = '123'）。
• 應用層做大結果集排序 / 聚合：把 100 萬行拉回應用、在記憶體 sort 或 group。應該 push 給 DB 做 ORDER BY / GROUP BY + LIMIT。判讀訊號：應用程式記憶體用量隨 endpoint 流量線性升高。
• N+1 write：在 loop 內單筆 insert / update 而非 bulk insert。每筆觸發一次 round trip + 可能的 fsync。修正方向：用 INSERT ... VALUES (), (), () 或 executemany / bulk_create。

NoSQL / KV DB 也有 sibling 反模式（hot partition、read amplification、scan-and-filter），不在本章 SQL 範疇但邏輯類似 — 詳見 1.10 KV / Document DB 容量規劃。

每請求的 Query 預算

把上面這些反模式收斂成一個發布前可檢查的判準：每個 API request 允許發多少個 query。

超過預算不一定錯，但需要解釋。CI / staging 可以加 middleware 統計每個 endpoint 的 query 數，超過閾值在 PR review 時觸發討論。這比事後從 slow log 找問題更有效。

這張表以 OLTP API 為主。Dashboard / report / search endpoint 常需要 10-30 query 解 join / aggregation、用「Complex」涵蓋不夠精確；batch / bulk write（一次寫入 1000 筆訂單）不該用 query count 評估、應該看 batch size 跟 transaction 範圍。預算是判讀工具、不是硬閾值。

判讀訊號

常見誤區

把「資料庫變慢」直接解讀成「該升級資料庫」。先看應用層 query。多數效能問題是反模式造成的、而不是 DB 規格不夠。

把索引當「想加就加」。每個索引都有寫入成本跟空間成本。索引太多會讓 INSERT/UPDATE 變慢、backup 變大。要建索引前先驗證該 query 是熱路徑。

把 N+1 當「在 ORM 環境無解」。多數 ORM 都有 eager loading 選項，只是預設 lazy。問題是團隊沒把這當作預設策略。設定 ORM 為 default eager 或在 CI 加 query 數量檢查就能避免。

把 transaction 範圍當「越大越安全」。長 transaction 是 lock 風險來源，不是一致性保證。一致性靠正確的 isolation level 跟業務邏輯，不是靠長 transaction 鎖住整個流程。

定位邊界

本章專注「應用層發給資料庫的 query 反模式」。當問題進入 schema 設計（要不要拆表？要不要 partition？）交給 1.2 schema design；進入 transaction 語意（什麼時候用 SERIALIZABLE？怎麼 retry？）交給 1.3 transaction boundary；進入跨服務的查詢責任拆分（哪些查詢屬於該服務？）交給 1.8 state ownership 與 query boundary；進入瓶頸定位的工程流程交給 9.5 瓶頸定位流程。

案例回寫

09 案例庫的主軸是規模、vendor 與容量壓力，直接以「query 反模式」為主題的案例較少。下列案例可以反向讀：每一個都展示了「在沒有先用 query 反模式優化收回壓力的前提下、團隊直接走 vendor 遷移或 scale-out 路徑」的決策。讀者讀完應追問：這些 case 啟動遷移前、是否有可能用本章的反模式清單先收回一部分容量？

• 9.C39 DoorDash：Aurora Postgres 寫入瓶頸 → CockroachDB — DoorDash 撞到 Aurora single-primary write 天花板（瓶頸在 primary CPU + WAL flush rate）、用 PostgreSQL wire protocol 相容的 CockroachDB 換成多主寫入、ORM 不必重寫。對照本章可問：寫入熱點是否伴隨長 transaction 或熱 row 競爭？這些是 vendor 遷移前可以先用本章「Long-Running Transaction」清單檢查的點。
• 9.C20 Zomato：TiDB 遷到 DynamoDB — Zomato 判斷 billing 事件本身可接受 eventually consistent、用一致性語意換取 4 倍吞吐 + 50% 成本。對照本章可問：遷移前每筆業務動作平均發了多少 query、是否有 N+1 或 select * 在放大壓力？把這條問題擺進「每請求 Query 預算」段一起讀。
• 9.C14 Standard Chartered：Aurora 4000 TPS 合規容量 — Standard Chartered 在 7 個受監管市場各跑獨立 Aurora cluster（資料不能跨境）、容量規劃單位是「per 市場」、合規邊界決定了 cluster 拓樸。對照本章可問：query 預算假設是否進入容量模型？預算寫鬆、規劃出的 per-cluster TPS 上限會偏低。

DoorDash 案例是這條反向追問最直接的應用 — 寫入瓶頸的判讀不該停在 vendor 規格、而是先檢查 transaction 範圍跟熱 row 競爭。Zomato 跟 Standard Chartered 的反向追問則退一步問「query 預算假設是否進入容量模型」。三條追問共享同一條診斷邏輯：應用層 query 不是事後解釋的細節、是事前可以收回的容量。這個讀法承認案例本身不直接示範 query 反模式、是用反向追問把案例當成 query 反模式重要性的反證。

跨模組路由

1. 與 1.1 高併發下的 SQL 讀寫邊界 的交接：1.1 處理連線池與 read replica 機制、1.13 處理 query 寫法本身。高併發場景下兩者要同步檢查。
2. 與 1.2 schema design 的交接：索引設計是 schema 層的事、本章只指出徵兆。
3. 與 04 observability 的交接：slow query log、APM、query trace 是判讀反模式的主要訊號來源。
4. 與 9.5 瓶頸定位流程 的交接：先在應用層查反模式，再考慮 DB 配置升級。
5. 與 9.13 擴展軸 的交接：規模成長路線上、9.13 解擴展軸選擇後、1.13 是緊接著的下一站 — 在加機器或加 replica 前、先用本章反模式清單收回單機能撐住的容量。
6. 與 10.1 服務拆分 的交接：拆服務常被用來「解決 DB 慢」，但本章的反模式優化通常比拆服務 ROI 更高、應該優先嘗試。

下一步路由

規模成長路線下一站 → 1.1 高併發下的 SQL 讀寫邊界：query 反模式收完後、處理連線池與 read replica 的擴展。

其他延伸方向：

• Schema 與索引設計 → 1.2 schema design 與資料建模
• Transaction 範圍收斂 → 1.3 transaction 與一致性邊界
• 瓶頸定位完整流程 → 9.5 瓶頸定位流程

Slow log 的兩種讀法

多數團隊把 slow log 當「事故診斷工具」— 服務變慢時去翻一下、找出當下的罪魁禍首。這條讀法在事故時有效、但有 systemic 缺陷：所有 catch 到的反模式都已經影響使用者一段時間。

另一條讀法是把 slow log 當「定期審視訊號」— 每週 / 每 release cycle 抓 slow log top-N、看哪些 query 模式持續存在、哪些是新出現的。這條讀法的關鍵在於「對比基線」、不是「找絕對閾值」。

兩種讀法的對比決定了 closed loop 的設計方向：

定期審視這條讀法是本章的核心、後續四個動作都環繞它建立。

Loop 第一步：採集

Slow log 採集的設計關鍵是「採集標準要穩定、retention 要夠長」。常見的採集配置選擇：

• Threshold 設定：MySQL long_query_time、PostgreSQL log_min_duration_statement 設多久才記？常見 default 1 秒太寬鬆、會漏掉「200ms-1s」這層慢但累積成大量壓力的 query。建議 100ms 或更低（依 application 需求）。
• 採集對象：純 SELECT 慢？還是含 INSERT/UPDATE/DELETE？寫路徑慢通常代表 lock contention 或 transaction 範圍問題、跟讀路徑反模式不同、要分開分析。
• Retention：log 保留多久？至少 30 天（覆蓋一個 sprint）、有資源的話 90 天（覆蓋季度 regression 對比）。雲端 managed DB（RDS / Aurora）的 slow log 通常自動匯出到 CloudWatch / S3、設定 retention policy 而不是依賴 DB instance 本身的 log。
• Sample rate：高流量服務全採會把 disk I/O 拖垮。Production 環境用 sampling（如 10% 取樣）平衡採集完整度跟系統壓力。

採集出來的 raw log 不適合直接讀、要先 normalize。

Loop 第二步：Normalize 與聚合

Raw slow log 每筆都帶具體參數（WHERE user_id = 12345、WHERE user_id = 67890），直接看會看到上千筆「不同 query」。實際上多數是同一個 query template 的不同參數實例。

Normalize 動作把參數抽掉、留 query shape：

• WHERE user_id = 12345 → WHERE user_id = ?
• IN (1, 2, 3, 4, 5) → IN (?)
• 字串常數同樣抽掉

工具上：MySQL 用 pt-query-digest（Percona Toolkit）；PostgreSQL 用 pg_stat_statements extension（已內建 normalize）；雲端用 vendor 工具（AWS Performance Insights、GCP Query Insights、Azure SQL Insights）。Normalize 後可以按 query shape 聚合、看哪些 shape 累計時間最長、出現次數最多、平均延遲最高。

聚合後產出三條訊號：

1. Top-N by total time：累計時間最長的 query — 改一條就能省最多 DB 壓力
2. Top-N by count：出現次數最多的 query — 改一條就能降最多 connection 占用
3. Top-N by avg latency：平均延遲最高的 query — 個別 request 體驗最差的

三條訊號可能指向不同 query、各自值得 attention。

Loop 第三步：PR review 整合

把 slow log 的 top-N 帶回 PR review 是 closed loop 的關鍵。常見三種整合機制：

• 每週 slow log review 會議：固定時段（每週 30 分鐘）、團隊輪流 owner、把 top-10 過一輪、決定每筆是修 / 留 / 標 acceptable。產出進 backlog、不是當場修。
• PR-level query budget check：CI 加 middleware 統計每個 endpoint 的 query 數（per 1.13 query 預算）、超過閾值的 PR 在 review 時觸發討論。這層比 slow log 早、catch 的是「新引入」反模式。
• Production regression alert：當某個 query shape 的 P99 latency 比上週 baseline 偏高 50%+、自動發 alert 給該服務 owner。這層 catch 的是「漸進惡化」反模式（如資料量增加、index 失效）。

三層機制按介入點分層：PR check 是「進 production 前」、weekly review 是「進 production 後的固定盤點」、regression alert 是「漸進惡化的訊號偵測」。三層覆蓋率最高、單跑任一層都會漏。

Loop 第四步：Regression 偵測

Slow log 的對比基線需要主動維護。沒有基線、定期審視會退化成「每次都看到同樣的 top-10、習以為常」。建立基線的常見做法：

• 每 release 凍結 baseline：上線新版本前抓一份 slow log snapshot、release 後跟它比。新增的 query shape 跟惡化的 query shape 都會浮出來。
• 資料量分位點 marker：在 schema 加註「這張表預期 1M / 10M / 100M 行的 query 計畫」、實際成長到對應規模時驗證 plan 是否還對。Index 失效常常是「資料量過某個門檻、optimizer 改用 full scan」造成的。
• 跨 release 趨勢圖：把 slow log top-10 的累計時間做時序圖、看一年的趨勢。穩定升高代表反模式 / 資料成長壓力、突然升高代表新引入問題。

Regression 偵測的 false-positive 風險是「業務本身在變、流量本身在長」、不是反模式造成的。用「query shape 佔比」而非「絕對延遲」當訊號可以降低 false positive — 某個 query shape 從佔 5% 變成佔 30%，不論絕對延遲是否升高、都值得審視。

判讀訊號

常見誤區

把 slow log 當「事故工具」、不做定期審視。事故時的 slow log 是 lagging indicator — 反模式已經影響使用者一段時間才被看見。定期審視是把它變成 leading indicator 的關鍵。

把 threshold 設太鬆（1 秒、5 秒）。多數反模式落在 100ms-1s 區間、設 1 秒會漏掉。Threshold 應該對齊「user-perceived 慢」門檻、通常 100-500ms。

把 top-10 當「不能動」。一些 top-10 是業務本質慢（複雜 report、bulk write）、改起來代價遠超效益。Review 時要明示標記「acceptable」、避免下週又被當未解決問題討論。

定位邊界

本章專注「production slow log 怎麼變成 closed loop」。當問題進入具體反模式分析（這條 query 是哪種反模式？怎麼改？）、回到 1.13 應用層查詢反模式；進入 EXPLAIN 解讀細節、回到 1.2 schema design；進入 application-side query 數量控制機制（ORM middleware、query log 觀察），跨到 04 observability 模組。

案例回寫

09 案例庫中、slow log closed loop 直接示範的案例稀少（多數案例談規模 / vendor、不談 ops loop 設計）。可用以下案例反向追問：

• 9.C39 DoorDash：Aurora Postgres 寫入瓶頸 — 寫入飽和被識別為 vendor 層問題、但若 production slow log loop 早期就 catch 到 transaction 範圍跟熱 row 競爭、可能延後遷移時點。對照本章可問：DoorDash 在啟動遷移前、是否有定期 slow log review 機制？
• 9.C14 Standard Chartered：合規驅動容量規劃 — 容量規劃以合規為驅動、但 query 預算假設若無 production 驗證、規劃出的 TPS 上限會偏低。對照本章「Regression 偵測」段：合規 cluster 是否有 query shape 趨勢圖？

反向追問框架（per #146）：案例本身不直接示範 closed loop、但用「啟動 vendor 升級前、closed loop 能不能延後撞牆」這條追問、能看出 slow log loop 的事前價值。

跨模組路由

1. 與 1.13 query 反模式 的交接：1.13 給反模式清單、本章給「定期 catch 它們」的機制。
2. 與 04 observability 的交接：slow log 採集跟聚合是 observability 的子問題、跨服務的 query trace 需要 04 的 telemetry pipeline。
3. 與 9.5 瓶頸定位 的交接：9.5 用 USE / RED method 定位、本章用 slow log 在 DB 層做更精細的 query-level 定位。
4. 與 06 reliability ci-pipeline 的交接：PR-level query budget check 是 CI 環節、屬 06 模組的 release gate 設計。

下一步路由

要看具體反模式怎麼修、回 1.13 應用層查詢反模式。要把 query 觀測接進完整 telemetry pipeline、進 04 observability。要看 PR-level check 怎麼接 release gate、進 6.8 release gate。

這份規格承接 Vendor 深度技術文章寫作方法論 與 Migration Playbook 寫作方法論。本文只處理資料庫模組的落地規格：哪些內容留在 vendor overview，哪些議題升級成 deep article，哪些變更需要 migration playbook。

判讀錨點

資料庫 vendor 文章的錨點是正式狀態如何被保存、查詢、複製、演進與修復。產品功能、版本差異與雲端價格都只是材料；正文要把材料轉成讀者可操作的判準，讓讀者能判斷資料模型、交易需求、查詢邊界、容量壓力、操作責任與替代路由。

PostgreSQL 與 MySQL 的 batch 顯示三個穩定事實。第一，SQL baseline 已經足以支撐其他服務頁開寫；第二，深度文章需要「何時不用」與真實案例 anchor 防止過度工程化；第三，跨 vendor 或 topology 變更需要獨立 playbook，不適合塞回 overview。

Vendor Overview 規格

Vendor overview 的責任是教讀者完成第一輪服務判斷。這一層回答服務承擔什麼資料責任、適合什麼壓力、日常有哪些操作決策、失效時先看哪些訊號，以及何時改走相鄰服務。

服務定位段要先把產品名稱放回資料庫分類語言。SQLite 的定位是 embedded formal state 與低操作成本；MongoDB 的定位是 document shape 與 schema governance；DynamoDB 的定位是 managed KV / document access pattern；Aurora 的定位是 managed SQL operation transfer；Spanner、Cosmos DB 與 CockroachDB 的定位是 global 或 distributed consistency。

資料形狀段要讓讀者知道服務為哪種查詢與寫入模式付成本。Row model 適合交易與 ad-hoc query；document model 適合聚合資料與 schema flexibility；KV model 適合固定 access pattern；distributed SQL 適合跨 region 一致性，但會把 latency、transaction retry 與成本模型帶進設計。

一致性與交易段要接回 transaction boundary、isolation level、replication lag 與 stale read。讀者需要知道的是哪種資料變更必須一起成功、哪種讀取可以接受延遲，以及跨 region 寫入是否值得支付協調成本。

操作責任段要把 managed 與 self-managed 的責任轉移寫清楚。自管服務保留控制權，團隊承擔 patch、backup、failover、capacity 與事故演練；managed 服務降低操作負擔，但增加平台限制、費用模型、版本節奏與 vendor-specific behavior。

替代邊界段要保留機會成本。PostgreSQL 或 MySQL 可以承擔多數 OLTP baseline；當 query 固定且高峰連線壓力明顯，DynamoDB 類服務可能更划算；當 document shape 主導資料模型，MongoDB 或 Cosmos DB 有更自然的操作語意；當 global write 是核心需求，Spanner、CockroachDB 或 Aurora DSQL 才進入主要比較。

案例與限制段要分開處理 evidence 與 backlog。案例提供流量形狀、資料形狀、失敗代價或回退路徑；limitation 承認正文還缺哪些維度，例如 PostgreSQL 目前仍需補 Security / RLS / audit logging、cross-region DR 與 managed PG 變體對比，MySQL 仍需補 deep article 的 anti-recommendation 與真實 incident anchor。

Deep Article 規格

Deep article 的責任是把 vendor overview 點到的單一機制展開成可操作教材。這一層不重寫服務選型，而是教讀者設定、觀測、除錯、容量估算與整合某個具體機制，例如 connection pool、replication topology、online schema change、CDC、partitioning、lock contention 或 PITR。

問題情境段要用具體壓力啟動，產品文件定義只作為補充材料。Connection pool 可以從連線風暴與 backend slot 說起；replication 可以從 lag 與 failover 說起；PITR 可以從 restore 能力與 RPO 說起；lock contention 可以從交易範圍與 deadlock 訊號說起。

核心機制段要保留 vendor-specific 語意。PostgreSQL 的 WAL / LSN / replication slot、MVCC / vacuum、process-per-connection model 與 extension lifecycle 都有自己的操作語意；MySQL 的 binlog / GTID、InnoDB clustered index、gap / next-key lock、ProxySQL query rule 與 Vitess VSchema 也要用自己的語言展開。

操作流程段要把設定與判準綁在一起。Config、SQL、CLI 或 dashboard query 只在能支撐判讀時出現；每個操作要回答「如何知道它生效」「失敗時看到什麼」「可以停在哪個 rollback boundary」。

失敗模式段是 deep article 的主要價值。PostgreSQL / MySQL 既有文章多數已具備「5 個 Production 踩雷」；後續服務要維持這個密度，並優先補真實案例 anchor，避免所有案例都停在合成數字或典型設定。

容量與觀測段要讓 deep article 接回 04 / 09。資料庫機制常見的訊號包括 connection usage、replication lag、lock wait、dead tuple、buffer hit ratio、slow query、binlog retention、WAL growth、partition pruning 與 restore duration；這些訊號要能回到 4.20 Observability Evidence Package 或 9.5 瓶頸定位流程。

邊界與整合段要補「何時不用」。MySQL audit 已經指出 deep article 容易缺 anti-recommendation；後續每篇 deep article 至少要有一段說明什麼規模、團隊能力或 workload 下暫時維持簡單設計更划算。

Hands-on / Artifact 規格

Hands-on / artifact 章節的責任是把 deep article 的機制判讀轉成可演練操作。這一層對齊 LLM hands-on/ 的教學功能：讀者能跑出一個 local / staging lab，取得 config、query output、metric snapshot、validation result 或 rollback note，而不只停在概念理解。

PostgreSQL、MySQL 與 SQLite 已建立 hands-on 入口：PostgreSQL hands-on、MySQL hands-on 與 SQLite hands-on。後續其他 database vendor 也要先建立 hands-on 入口，再依服務責任決定是否補完整操作正文。

Migration Playbook 規格

Migration playbook 的責任是處理跨 vendor、跨 topology 或跨 operational model 的變更流程。這一層的主體是差異盤點、階段切換、雙軌驗證、cutover、rollback / fail-forward 與 cleanup；它應作為獨立流程教材，而非 deep article 的長版或 vendor overview 的補充段。

Driver 段要先排除「因為新服務比較好」這類空泛動機。有效 driver 通常是單機 primary 上限、connection limit、replication lag、backup / restore 責任、multi-region residency、vendor operation transfer、schema feature gap 或成本曲線。

Diff audit 段要先決定 playbook type。MySQL → PostgreSQL 主要是 schema / dialect 差；PostgreSQL → Aurora 主要是 operational redesign；PostgreSQL → CockroachDB 或 Aurora DSQL 主要是 paradigm shift；partition redesign 是 topology re-layout。type 決定結構，不用把所有 playbook 壓成同一套 phase。

Phase plan 段要把不可逆動作放晚。Schema audit、application compatibility、shadow read、dual-write、backfill、CDC catch-up、read-only cutover 與 cleanup 要分出驗證門檻；長期混合架構要明確標示哪些 workload 保留在 source。

Evidence 段要把資料庫遷移接回 observability 與 reliability。Playbook 應要求 row count、checksum、replication lag、error rate、query latency、data quality 與 owner；這些 evidence 是 release gate、incident decision log 與 rollback 判斷的共同材料。

Cutover 段要把決策權責寫清楚。資料庫切流失敗通常代價高，正文要標示切流窗口、暫停條件、回退條件、資料凍結策略與 decision owner，並連到 rollback window 或 rollback condition。

Cleanup 段要防止雙軌永久殘留。舊 schema、舊 writer、舊 CDC connector、舊 backup、舊 dashboard 與舊 runbook 都需要退役判準；資料保留、稽核與 incident write-back 要在 cleanup 前確認。

從 PostgreSQL / MySQL 回收的調整項

PostgreSQL 與 MySQL 的正文已經足以讓其他服務頁開寫。下一輪調整應集中在橫向品質；SQL baseline 可維持現有正文作為後續服務頁的比較基準。

PostgreSQL

PostgreSQL 的下一輪擴充重點是補安全、災難復原與 managed variant。Security / RLS / audit logging 可以連到資料保護與稽核章節；cross-region DR 可以連到 reliability 與 incident decision；Managed PG Comparison 與 Specialized PostgreSQL Variants 承接 AlloyDB、Cloud SQL、Cosmos DB for PostgreSQL 與 pgvectorscale。

PostgreSQL 的既有 limitation 已經標示 PG-favoring narrative 與時間敏感 claim。後續補文時要保留對手 vendor 的強項，例如專業 vector DB 的 scale、專業 time-series DB 的 ingestion、distributed SQL 的 global consistency 與 managed 平台的 operation transfer。

MySQL

MySQL 的下一輪擴充重點是補 anti-recommendation 與真實 case anchor。多數 deep article 已經有 production 踩雷，但還要加上「何時暫時不用這個機制」的段落，讓讀者知道維持單 primary、簡單 replication、原生 partition 或標準 backup 何時更划算；security、audit、Document Store、multi-source replication、HeatWave、memory contention 與 metadata lock 已先建立 outline 路由。

MySQL 的案例段要把 GitHub、Shopify、Slack、YouTube / Vitess 這些業界來源升級成具體 anchor。案例不只列公司名稱，還要回收它提供的流量形狀、database sharding 策略、schema change 壓力、failover 責任或工具演化原因。

後續服務撰寫順序

後續服務撰寫順序要從 SQL baseline 推進到資料模型與操作責任差異。每一篇先完成 vendor overview，再依 overview 暴露出的機制缺口決定 deep article 或 migration playbook。

SQLite 的重點是讓讀者知道單機正式狀態何時成立。它不應被寫成小型 PostgreSQL，而要處理 file lifecycle、embedded process boundary、backup、concurrency、migration 與測試資料責任。

MongoDB / DynamoDB 的重點是把資料形狀放在 SQL baseline 之後。MongoDB 應教 document shape、index、schema governance 與 transaction boundary；DynamoDB 應教 access pattern、partition key、capacity mode、hot partition 與 connection-free scaling。

Aurora 的重點是 operation transfer。它把 PostgreSQL / MySQL 相容介面放進 AWS-managed operational model；storage / compute 分離、cluster endpoint、replica、backup、failover、cost model 與 AWS 限制都會改變團隊責任。

Spanner / Cosmos DB 的重點是 global data responsibility。Spanner 應教 TrueTime、strong consistency、multi-region latency 與 cost；Cosmos DB 應教 consistency level、API model、partition、RU 與 Azure 約束。

CockroachDB 的重點是 distributed SQL 對 application contract 的影響。SQL 相容降低導入門檻，但 transaction retry、range lease、hot range、schema feature gap 與 multi-region topology 會改變 application 與 SRE 的責任。

LLM-depth 下一輪擴章 Backlog

LLM-depth 下一輪的責任是把每個資料庫服務從 T1 overview 推進到可教學的章節群。Overview 只回答第一輪服務判斷；deep article 回答穩定運作與排錯；migration playbook 回答跨 vendor、跨 topology 或跨 operational model 變更。

Backlog 的排序以學習梯度為準。SQLite 先處理單檔案正式狀態，補足「低操作成本如何 production 化」；MongoDB / DynamoDB 再處理資料形狀與 access pattern；Aurora 接 SQL operation transfer；Spanner、Cosmos DB 與 CockroachDB 最後處理 distributed consistency 與 multi-region topology。

規格檢查清單

資料庫 vendor 文章完成前要跑一次規格檢查。檢查通過代表本次內容可作為後續服務的基準；未通過時，先修正文再開下一篇。

• Vendor overview 已說清楚服務責任、資料形狀、一致性、操作責任、替代邊界、案例與 limitation。
• Deep article 已包含問題情境、核心機制、操作流程、失敗模式、容量與觀測、邊界與整合。
• Migration playbook 已完成 driver、diff audit、phase plan、evidence、cutover 與 cleanup。
• 表格後有情境化說明，沒有讓表格取代判讀。
• 案例提供壓力、失敗代價或回退條件，不只列公司名稱。
• 「何時不用」或 no-go condition 已出現在 deep article / migration playbook。
• Time-sensitive vendor claim 有日期語境或指向官方文件。
• 下一步路由能接回主章、knowledge card、04 / 06 / 08 / 09 或 sibling vendor。