本篇先確立依賴圖怎麼驅動部署順序，再展開核心服務裡最需要謹慎描述的一類 — 資料庫。資料庫持有無法重建的狀態，它的 IaC 描述比其他 stateless 資源多出保護策略、連線管理與讀寫分流三個維度。

核心服務的部署順序

核心服務的部署順序由依賴方向決定：被依賴的先建，依賴別人的後建。網路與身分是幾乎所有上層服務的共同前置 — 資料庫要放進私有 subnet、運算要套用 IAM role 才能讀 S3、load balancer 要掛在公開 subnet 並引用 security group。這些底層平面若還沒成形，上層資源會在 apply 時因為找不到 subnet ID 或 role ARN 而失敗，或更糟，建在預設 VPC 裡繞過了所有隔離設計。

把順序交給 IaC 工具的依賴圖自動推導，比人工排序可靠。當運算資源的定義引用了 subnet 與 security group 的資源屬性，Terraform 會解析出「subnet 先於運算」的邊，apply 時自動排程。人工維護一份「先做 A 再做 B」的清單會隨資源增加而失準，依賴圖則隨程式碼本身演進。

四層依賴結構

依賴圖的典型展開順序呈現四層結構：

這四層不需要手動編排。只要程式碼裡的引用關係正確，Terraform 就會自動按這個順序 apply。當 plan 輸出的順序看起來不合直覺 — 例如 ALB 先於 ECS — 通常代表某個引用斷了、兩者之間沒有依賴邊。

順序失控的徵兆

順序失控的早期徵兆是：某個上層資源的定義裡寫了一串 hardcode 的 subnet ID 或 VPC ID。

1# 硬編碼 ID — 依賴圖斷裂，底層重建時上層不會跟上
2resource "aws_db_subnet_group" "private" {
3  subnet_ids = ["subnet-0abc123", "subnet-0def456"]
4}

這段 code 跟底層的 subnet 資源沒有引用關係。底層一旦重建、ID 改變，上層不會自動跟上，state 與雲端現實之間的不一致（即 drift）就此產生。修法是把硬編碼的 ID 換成對底層資源屬性的引用：

1# 引用資源屬性 — 依賴圖自動推導，底層重建時上層自動取得新 ID
2resource "aws_db_subnet_group" "private" {
3  subnet_ids = [for s in aws_subnet.private : s.id]
4}

跨 state 的情境（網路地基與核心服務分屬不同 state）則用 data source 取代直接引用 — 這個取捨在服務依賴與跨 state 引用展開。

隱性依賴與 depends_on

自動推導涵蓋的是「引用屬性時產生的邊」。少數情況下兩個資源之間有依賴卻沒有屬性引用 — 例如一個 IAM policy attachment 必須在某個 role 被 ECS task 使用之前完成，但 task 引用的是 role ARN 而非 attachment 的輸出。這時用 depends_on 顯式宣告邊：

1resource "aws_ecs_service" "api" {
2  # ...
3  depends_on = [aws_iam_role_policy_attachment.ecs_task_s3]
4}

depends_on 應該只出現在自動推導覆蓋不了的場景。如果一個 module 裡到處都是 depends_on，通常代表引用關係寫得不夠明確，該把隱性依賴改成屬性引用。

資料庫（RDS）

資料庫是核心服務裡最需要謹慎描述的資源，因為它持有無法重建的狀態。IaC 定義它的 instance class、引擎版本、所在的 subnet group（決定它落在哪些私有 subnet）、套用的 parameter group 與 security group。連線端點不要硬編碼，改用資源 output 暴露給上層運算引用，這樣端點隨主庫 failover 或重建而改變時，上層引用自動更新。

 1resource "aws_db_instance" "primary" {
 2  identifier             = "app-${var.env}-primary"
 3  engine                 = "postgres"
 4  engine_version         = "16.3"
 5  instance_class         = var.db_instance_class
 6  allocated_storage      = 100
 7  storage_encrypted      = true
 8
 9  db_subnet_group_name   = aws_db_subnet_group.private.name
10  vpc_security_group_ids = [aws_security_group.db.id]
11
12  multi_az                  = var.env == "prod" ? true : false
13  backup_retention_period   = var.env == "prod" ? 14 : 1
14  backup_window             = "03:00-04:00"
15  deletion_protection       = var.env == "prod" ? true : false
16  skip_final_snapshot       = var.env == "prod" ? false : true
17  final_snapshot_identifier = var.env == "prod" ? "app-prod-final-${formatdate("YYYYMMDD", timestamp())}" : null
18
19  tags = { service = "payments" }
20}
21
22output "db_endpoint" {
23  value = aws_db_instance.primary.endpoint
24}

加密的不可逆性

storage_encrypted = true 確保磁碟層級的加密在資源建立時就生效。RDS 不支援事後對既有 instance 開加密 — 漏了只能重建。補救路徑是匯出快照、用加密 KMS key 複製快照成加密版本、再用加密快照還原成新 instance。這個過程需要停機或切換端點，對已經承載流量的 production 資料庫代價很高。prod 的 RDS 若 storage_encrypted 為 false，這筆技術債越早處理越便宜。

parameter group 的角色

parameter group 定義資料庫引擎層級的行為參數（如 max_connections、work_mem、log_min_duration_statement），是 RDS instance 的設定骨架。IaC 描述 parameter group 的好處是讓這些參數進版本控制 — 有人改了 max_connections 會出現在 PR diff 裡，而不是某天在 Console 改了沒人知道。

 1resource "aws_db_parameter_group" "postgres16" {
 2  family = "postgres16"
 3  name   = "app-${var.env}-pg16"
 4
 5  parameter {
 6    name  = "log_min_duration_statement"
 7    value = "1000"
 8  }
 9
10  parameter {
11    name  = "shared_preload_libraries"
12    value = "pg_stat_statements"
13  }
14}

修改 parameter group 的某些參數需要重啟 RDS instance（稱為 apply_method = "pending-reboot"），修改前要先確認這個參數屬於「立即生效」還是「要重啟」。在 Terraform plan 裡不會明確標示重啟，要靠 AWS 文件交叉比對。

連線管理

運算到資料庫之間有一段常被略過的接線：連線管理。無狀態運算水平擴張時，每個實例各自開連線，容易把資料庫的連線數打滿。一個 ECS service 從 5 個 task 擴到 50 個、每個 task 開 10 條連線，就從 50 條跳到 500 條 — 而一台 db.r6g.large 的 max_connections 預設約在 1600 左右，500 條已經吃掉三分之一。

出現「擴運算反而拖垮 DB」的訊號時，解法是引入連線池或受管的連線代理。RDS Proxy 是 AWS 的受管方案：它在運算與 RDS 之間當一層連線池，把下游的數百條短連線收斂成對 RDS 的少量長連線。在 IaC 裡一併定義，輸出 proxy 端點給運算引用：

 1resource "aws_db_proxy" "app" {
 2  name                   = "app-${var.env}-proxy"
 3  engine_family          = "POSTGRESQL"
 4  role_arn               = aws_iam_role.rds_proxy.arn
 5  vpc_subnet_ids         = [for s in aws_subnet.private : s.id]
 6  vpc_security_group_ids = [aws_security_group.db.id]
 7
 8  auth {
 9    auth_scheme = "SECRETS"
10    secret_arn  = aws_secretsmanager_secret.db_password.arn
11  }
12}
13
14output "db_proxy_endpoint" {
15  value = aws_db_proxy.app.endpoint
16}

運算端引用 db_proxy_endpoint 而非 db_endpoint，連線管理就從各 task 自己處理轉成由 proxy 統一收斂。RDS Proxy 同時提供 failover 的連線保持 — 主庫切換到 standby 時，proxy 維護的連線不會全部斷開重建，應用端感受到的是短暫延遲而非連線錯誤。

判讀是否需要 RDS Proxy 的訊號是連線數成長曲線：如果運算的擴縮範圍固定且連線數上限遠低於 max_connections，直連即可；如果運算會頻繁擴縮或連線數可能逼近上限，proxy 值得引入。proxy 本身有額外成本（按 vCPU 計費），不是所有環境都划算 — dev 環境通常直連就夠。

read replica

當讀流量遠大於寫、且能容忍副本的複寫延遲（通常是毫秒到秒級）時，read replica 是把讀請求導離主庫的下一步。replica 在 IaC 裡用獨立資源描述，引用主庫的 identifier：

 1resource "aws_db_instance" "read_replica" {
 2  identifier             = "app-${var.env}-replica"
 3  replicate_source_db    = aws_db_instance.primary.identifier
 4  instance_class         = var.db_replica_class
 5  vpc_security_group_ids = [aws_security_group.db.id]
 6}
 7
 8output "db_replica_endpoint" {
 9  value = aws_db_instance.read_replica.endpoint
10}

運算端依讀寫分流引用不同端點 — 寫走 db_endpoint（或 db_proxy_endpoint），讀走 db_replica_endpoint。這個分流邏輯屬於應用層的責任，infra 只負責把端點暴露出來。

read replica 的邊界要講清楚：它緩解讀流量對主庫的壓力，但它不是備份。replica 會同步複製主庫的所有變更 — 包括誤刪的資料。需要還原到某個時間點的保護由 backup retention 與 PITR（point-in-time recovery）提供，這兩者的 IaC 描述在 stateful 保護策略。

引擎版本升級的取捨

RDS 引擎版本（engine_version）寫進 IaC 後，版本升級就成為一個需要 PR review 的變更。升級分 minor 和 major：minor 升級（16.2 → 16.3）通常向後相容、可在維護視窗自動套用；major 升級（15 → 16）可能有 breaking change，需要先在 dev 環境驗證、備份、排維護窗口。

在 IaC 裡把 engine_version 寫死是刻意的選擇 — 它阻止 AWS 在背景自動升級 major 版本，讓版本變更必須走 PR。代價是需要定期檢查是否有 EOL 版本還在用。如果 engine_version 指向的版本已經超過 AWS 的支援期限，Terraform apply 會在某天失敗（AWS 會強制升級），這比主動升級更不可控。

資料庫在規模放大後的治理維度也會改變。Netflix 把分散的 Aurora 叢集整併後成本降了 28%——多個團隊各自開的 RDS instance 加起來的閒置容量遠超一個整併後的叢集。infra 層的教訓是 RDS 的 IaC 描述不只管單一 instance 的設定，長期還要管叢集的分布與合併策略。另一個維度是合規需求驅動的資料落地：Hard Rock Digital 因為 Wire Act 法規要求資料留在特定州，用 AWS Outposts 在地端跑運算——這類情境下 infra 的 region 與可用區選擇由法規約束驅動，而非純技術決策。

跨分類引用

• → 模組三：網路地基：資料庫的 subnet group 引用 private subnet
• → 模組二：身分與憑證地基：RDS Proxy 的 IAM role 與 secret 存取
• → 模組四：環境分離與模組化：prod / dev 用同一個 module、不同參數值
• → stateful 保護與跨 state 引用：backup retention、deletion protection、multi-AZ 的完整討論
• → 運算上 IaC：運算端怎麼引用資料庫端點
• → backend 模組一：資料庫：schema 設計、migration、query 層面的服務端討論

本文 不 展開 vendor 機制細節（partition key 設計 / consistency level / RU sizing / connection management 等）— 那些屬 per-vendor deep article 的責任、本文在每個軸後 cross-link 過去。本文也 不 比較三家「誰比較強」— 三 vendor 在 workload-by-workload 適配光譜上各有位置、寫成優劣比較會誤導讀者把選型壓成單軸。

問題情境：讀者進來時的真實壓力

典型啟動壓力分兩類：

第一類、團隊評估 document / KV / multi-model NoSQL 三家、文件都說「scalable schema-less」、看不出實際取捨。讀者徵兆是「我的資料是 document-shaped 還是 KV-shaped？」「partition key 該怎麼選？」「Atlas 跟 Cosmos DB MongoDB API 不一樣的點在哪？」「Cosmos DB multi-model 是真用得到還是行銷話術？」「on-demand vs provisioned 怎麼選？」

第二類、既有 PostgreSQL / MySQL workload 撞 connection limit（surge 下 1K-5K pool 是隱性天花板、F1.7）、想換 KV 但不知道是否適合。讀者徵兆是「我已經有 Memcached、還要再加 MongoDB cache 層嗎？」「DynamoDB 適合當 OLTP 嗎？」「換 NoSQL 是不是解 connection 問題的銀彈？」

這兩類讀者進來時的 真實問題 不在 vendor 之間、在 workload 自己屬哪一型。Case anchor 覆蓋六個 unique 角度：

• 多型 document workload — 9.C38 Toyota Connected（車載 sensor schema 隨車型演進、20 個 Atlas DB blast radius 切分）
• Document 跨雲 hedging — 9.C37 Forbes（自管 → Atlas、6 個月遷移、跨雲彈性）
• 同 model 換 vendor 的 dogfood signal — 9.C30 Microsoft 365（MongoDB → Cosmos DB MongoDB API、保留 driver、wire compat 限制）
• KV-as-buffer 正向用例 — 9.C15 Tixcraft（DynamoDB 寫入緩衝、6750x 彈性、後端慢消費）
• PK 天然均勻典範 — 9.C5 Amazon Ads（90M reads/sec 年度峰值、KV pattern 純粹）
• Federated DB 真實系統 — 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween + freshness token）

Workload shape × access pattern × consistency 三軸前置判讀

進三家 vendor 對比前先回答：你的 workload 屬哪一型？三軸的組合決定 vendor 候選清單、軸不識別清楚直接比 vendor 是把選型壓成「品牌偏好」、不是工程決策。

軸 1 — 資料形狀：document / KV / 不清楚

資料形狀的核心判讀是 aggregate root 邊界是否明確 跟 schema 是否會隨產品演進新增欄位。document 適合的場景是資料天然多型、單筆記錄欄位差異大、應用層用 aggregate root 模式存取；KV 適合的場景是資料形狀固定、access pattern 數量少（< 5 種）、固定 lookup by key。

第三列的「暫緩 NoSQL」是反指標。NoSQL（特別是 DynamoDB single-table design）的核心假設是「access pattern 在設計時已知、後續變動有限」。資料模型還在探索、access pattern 半年內會大幅增減的場景、PostgreSQL + JSONB 給的彈性遠高於 NoSQL — JSONB 欄位可以演進、ad-hoc query 可以用 SQL 跑、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

軸 2 — Access pattern 穩定度（KV 適用度前置判讀）

KV 適用度的核心判讀是 partition key 天然均勻度。partition key 不均勻會讓 vendor 廣告的「scale infinitely」變成「scale 到 hot partition 為止」、單一 logical key 流量超過該 partition 上限就 throttle 或 latency spike（F1.1）。

• 天然均勻 PK + 穩定 access pattern（meeting_id / player_id / message_id / user_id）→ DynamoDB / Cosmos DB Table API 適用、PK 不需 composite key 修補。Amazon Ads 用 ad_id 撐 90M reads/sec、Zoom 用 meeting_id、Capcom 用 player_id、PayPay 用 message_id、Disney+ 用 user_id — 五個 case 都揭露同一 frame：業務天然存在均勻 key 時 KV 是最自然的選擇。
• 天然不均勻 PK（event_id 一場演唱會集中 / date 時間序集中）→ 需 composite key 或 write sharding 修補。Tixcraft（9.C15）用 event_id + user_id_hash composite key 把單一熱門演唱會的 6750x spike 攤平到 partition 上 — 不是 DynamoDB 自身彈性、是 partition key 均勻分散的結果（F1.2）。
• Access pattern 變動頻繁（探索期、< 5 種 query 還會增加）→ 不適合 DynamoDB single-table design、回 RDB。Single-table 把 access pattern 編進 PK / SK 結構、增加新 query 等於改 schema、改 schema 等於重新 load 資料、成本不對。

KV 適用度判讀的延伸細節（hot partition 反模式 / composite key 設計 / adaptive capacity）見 DynamoDB partition key antipatterns。

軸 3 — Consistency 需求是否可接受 eventual

Consistency 需求的核心判讀是 跨 partition / 跨 region transaction 是否為產品契約。三家 vendor 都支援單 partition / 單 region 強一致、但 cross-partition / cross-region transaction 的機制跟限制差異大。

• 可接受 eventual / session consistency：DynamoDB（default eventually consistent reads、可選 strong）、Cosmos DB（5 個 consistency level、default session）、MongoDB（read concern 多級）— 三家都可以、選擇看其他軸。多數 KV / document workload 屬此類（social timeline、watchlist、message queue、analytics aggregation）。
• 需要強一致 cross-partition transaction：DynamoDB 跨 partition transaction 限制（單一 transaction 最多 100 個 action、跨 region 不支援）、MongoDB 4.0+ 支援 multi-document transaction 但 sharded cluster 仍有 limitation、Cosmos DB 跨 logical partition transaction 受限 — 都不如 SQL／distributed SQL 自然、應回 DB4 entry point 評估 Aurora DSQL / Spanner / CockroachDB。
• 跨 region active-active write：三家機制完全不同 — Cosmos DB multi-region write 跟 Strong consistency 是 互斥 設定（CAP 取捨硬約束、見 Cosmos DB multi-region write conflict SSoT 主寫位置）；DynamoDB Global Tables 走 LWW（last-writer-wins）conflict resolution；MongoDB Atlas 跨 region 需手動 conflict 處理。三家不在同一光譜、選擇前必看各 vendor outline 的機制段。

Migration path 三型（跨 case 合成 frame）

本段是 跨 case 合成 frame、不是單一 case 揭露 — 從 Coinbase（9.C36）/ Forbes（9.C37）/ Microsoft 365（9.C30）三 case 萃取的共通結構（F2.1）。

讀者進來時通常不是綠地、是 既有系統演進。三型遷移路徑的風險、ROI、適用條件完全不同、選錯路徑會推到錯的 vendor。

第一型：保留原 DB + 補周邊工具

不換 vendor、加 connection proxy（mongobetween / pgbouncer 類）、加 cache（Memcached + freshness token）、加 predictive scaling — 主資料層不動、應用層跟 ops 層補強。

• 代表 case：Coinbase（9.C36）保留 MongoDB Atlas、自建 mongobetween 把 60K connections/min 降到 ~2K（一個量級）、用 Memcached + freshness token 撐 1.5M reads/sec、用 ML predictive scaling 把擴容時間從 70 → 25 分鐘提前 60 分鐘
• 路徑成本：中（自建工具、需要工程資源 build & operate proxy / cache layer / ML model）
• 風險：低（主資料層不動、回滾代價小）
• ROI：保留主資料 schema + access pattern、解 driver / 部署模型 / cache 一致性瓶頸
• 適合：MongoDB（或主 DB）資料層撐得住、但應用層 connection storm / cache miss / 擴容慢卡瓶頸；團隊有工程能力 build 跟 maintain 周邊工具

延伸實作細節見 MongoDB connection management（per-vendor article、cross-link 待寫稿）。

第二型：同 DB 換託管

自管 → managed（Atlas / Cosmos DB / DocumentDB）、保留 schema 跟 access pattern、遷移期 6 個月量級。

• 代表 case：Forbes（9.C37）自管 MongoDB → MongoDB Atlas、保留 CMS schema、6 個月遷移、揭露「TCO 改善 25%」
• 路徑成本：中（dual-write + shadow read 驗證、driver 行為差異、operation runbook 重寫）
• 風險：中（dual-write 期間雙寫一致性、cutover 時點選擇）
• ROI：operation transfer（DBA bandwidth 釋放給 schema design / query tuning）+ TCO 改善
• 適合：自管 ops burden 大（DBA bandwidth 被 backup / patching / replica lag 吃光）、不想換 model

Scope warning（Forbes 25% TCO）：「25% TCO 改善」是 Forbes 特定流量規模（120M MAU、70+ Atlas region）下的數字、不普適。引用要帶條件 — 不要寫成「Atlas 比自管便宜 25%」這種 vendor-neutral 結論。實際省多少要看自管當下的 license / hardware / ops 工時分配、跟 Atlas 在你流量規模下的 pricing tier。

第三型：換 vendor 保留 model

MongoDB → Cosmos DB MongoDB API、或 MongoDB → DocumentDB — wire protocol + driver 不變、底層架構整個換、ops 模型整個換。

• 代表 case：Microsoft 365（9.C30）MongoDB → Cosmos DB MongoDB API、保留 MongoDB driver
• 路徑成本：高（dual-write per query pattern 驗證、wire compat ≠ 100% 行為相同、aggregation pipeline 跟 transaction 行為要逐項驗證）
• 風險：高（每個 query pattern 都可能踩到不相容 edge case、cutover 點選擇難）
• ROI：跨 vendor 換（Azure 生態 / multi-model API / global distribution）+ 保留應用層 driver code

Scope warning（Microsoft 365 dogfood）：Microsoft 365 是 Microsoft 自家 dogfood、case 沒揭露具體 throughput / latency / cost 數字（F2.17）。dogfood 是 高權重 selection signal（雲商賭自家旗艦產品）、但 不是 production benchmark（沒公開數字可比對）。引用要明示「dogfood signal」而非「production proof」。

Scope warning（100% wire compat）：Cosmos DB MongoDB API 廣告「100% wire compatibility」是 vendor 行銷話術、實際是「在某些 query pattern 下相容」（F2.9）。遷移時必須 dual-write per query pattern 驗證 — 不是看 vendor 文件 spec list、是用 production query corpus 跑一遍實測行為。Phase 0 audit checklist 應列出 unsupported aggregation stage、transaction edge case、index behavior 差異、change stream 跟 Change Feed 對應關係。

延伸 Cosmos DB MongoDB API vs SQL API 選型見 Cosmos DB MongoDB API vs SQL API。

第四型不在 DB3 範圍：paradigm shift 換引擎

KV → SQL 或 SQL → distributed SQL 屬 paradigm shift、應進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。本文範圍是 DB3 三家內部選型、不展開 paradigm shift。

從 RDB 撞牆來的快速路徑

讀者若從 PostgreSQL / Aurora connection limit 撞牆過來、想評估 KV 替代、依撞牆訊號直接 route 到對應 article、不必先跑完三軸前置判讀：

• 撞 connection limit（surge 下 pool 1K-5K 隱性天花板、long-lived TCP 占滿）→ HTTP API 模型（no long-lived connection）的 KV 直接接寫入緩衝、進 dynamodb/single-table-design-pattern 的「durable queue / write buffer」段（Tixcraft 9.C15 路徑：DynamoDB 接訂單、傳統 server 慢消費）、或評估 Cosmos DB Table API
• 撞單 primary 寫入上限（單 leader 寫吞吐天花板、read replica 無法分擔寫）→ multi-primary distributed SQL 路徑、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree 的 Path A（DoorDash 1.636 M QPS 單主寫入撞牆）
• 撞單一 DB 撐不下 + 多 workload 形狀並存（read-heavy / write-heavy / analytics 混在一個 DB）→ federated DB 模式、看 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween）+ 9.C29 Lemino（PostgreSQL → DynamoDB 揭露 RDB connection limit 隱性 bottleneck）

進 dynamodb/single-table-design-pattern 前先確認軸 1 / 軸 2 的 access pattern 穩定度跟 PK 天然均勻度 — connection limit 訊號 必要但不充分、KV 適用度 4 軸還是要走完、避免「為了解 connection 把不穩定 access pattern 硬塞 single-table」反模式。

Federated DB + system role 視角（跨 case 合成 frame）

本段也是 跨 case 合成 frame（F2.18 + F1.6）— 三個 rich case（Coinbase / Toyota / Forbes）都揭露 production 系統是 DB + 周邊工具 組合、不是單一 DB monolithic 撐起來。

讀者常誤以為「全用 X」是正解 — 全用 MongoDB、或全遷 DynamoDB、或全換 Cosmos DB。真實 production case 揭露兩個更前置的事實：(a) production 系統是 federated（多 DB 按 workload 分流）、不是 monolithic；(b) 每個 vendor 在系統中扮演 特定角色（control plane vs data plane vs cache）、不是 all-purpose store。

Federated DB by workload

Coinbase（9.C36）production 配置：MongoDB Atlas（document 主資料、identity service）+ DynamoDB（部分固定 KV workload）+ Memcached（read cache）+ mongobetween（connection proxy）+ Kinesis（event stream）。不是「全用 MongoDB」也不是「全遷 DynamoDB」、是按 workload shape 分流。

Toyota Connected（9.C38）：MongoDB Atlas 20 個 DB（microservice 拆 blast radius）+ Lambda + Kinesis + Redis + Kubernetes。20 個 DB 不是吞吐撐不住（18B txn/月 ≈ 7K txn/sec、單一 cluster 撐得下）、是 microservice ownership + blast radius 切分（F2.6）。

Forbes（9.C37）：MongoDB Atlas + 中介 abstraction layer + 50+ microservice。abstraction layer 隔離 schema 變動、避免 50 個服務都依賴 DB schema 細節（F2.3）。

三 case 揭露的共同 frame 是：寫 production 系統時假設「DB 一個服務搞定」、忽略 cache / queue / proxy / abstraction layer 跨層責任、會撞 connection limit / cache miss / cross-region replication 等隱性瓶頸。

System role：control plane vs data plane

DynamoDB 在 surge 場景能撐 nearly infinitely 不是 DynamoDB 自己神奇、是 系統架構解耦 的結果（F1.6）：

• Control plane（metadata、state、user record）：DynamoDB / MongoDB / Cosmos DB 適合 — 流量是 small payload + high QPS pattern
• Data plane（影音、大型 BLOB、media stream）：CDN / S3 / object storage、不在 DB3 範圍 — 流量是 large payload + bandwidth-bound
• Cache layer：Redis / Memcached / DAX（DynamoDB 補位）— 跟主 DB 形成跨層架構、處理讀峰值 + read-your-own-write 一致性

三個 case 揭露同一 frame：Zoom 視訊 metadata 走 DynamoDB、影音走 WebRTC / edge servers；Disney+ watchlist 走 DynamoDB、影片串流走 CDN + S3；Capcom game state 走 DynamoDB + DAX、game server 走 EKS。把影音串流塞 DynamoDB 是違反 control plane vs data plane 分離、容量規劃會錯（每筆 1KB 的 KV vs 每筆 100MB 的 media chunk 是不同 workload）。

三 vendor 對比 10 軸

下表是三 vendor 在 selection 階段的 10 軸對比。每個軸後續都有 per-vendor deep article 展開機制、本文不重複展開。

軸的延伸子段

部署 topology / 跨雲 hedging：三家 topology 是 vendor lock-in 跟 跨雲彈性 的硬取捨。Forbes 選 Atlas 不是當下省錢（自管 MongoDB 也可以、TCO 改善是副作用）、是 未來雲商策略尚未底定 的 hedging — Atlas 提供 AWS / GCP / Azure 三家部署、未來換雲不用換 DB（F2.10）。對照 DynamoDB / Cosmos DB / Spanner / Aurora 都是單雲鎖定 — 選了就跟著該雲商生態走。團隊雲商策略已底定（深度用 AWS / Azure / GCP 其一）時、單雲 vendor 通常較划算（更好的 IAM 整合、更深的 ops 工具、單一 support 通道）。跨雲價值真正成立是 策略不確定 或 合規要求多雲 場景。

Capacity 抽象：三家 capacity 抽象的 思維遷移成本 可能高過 vendor 廣告的價差（F2.12）。MongoDB 用 CPU + IOPS + working set RAM 三軸思維、跟自管 PostgreSQL / MySQL 類似、團隊轉換成本低。DynamoDB 用 WCU/RCU 抽象、要學「估每個操作消耗多少 unit」、加上 on-demand / provisioned / adaptive capacity 三模式選擇。Cosmos DB 用 Request Unit（RU）抽象、1 RU ≈ 1 KB document 的 strong read 成本、寫 ~5 RU、複雜 query 數百 RU — 工程師要學會用 RU 思考、不是用 CPU 思考、團隊知識遷移成本可能高。容量規劃延伸見對應 vendor 的 sizing article。

Partition / shard key 可逆性：三家 不在同一光譜、是選 vendor 前必做的 access pattern audit 重點（F2.15）。MongoDB reshardCollection（4.4+）可改、但成本高、需要 cluster downtime 或長時間 background migration。DynamoDB partition key 技術上可改、實作上用 backfill（建新 table、新 PK、雙寫舊新、cutover）— ops 工作量大但可逆。Cosmos DB partition key 不可改、改 partition key 等於 export-recreate-import — 對 1TB+ 資料是大型 migration 工程。三家不可逆性遞增、選 Cosmos DB 前必須前期完整 access pattern audit、不能「先上 production 之後再調」。

Consistency model：三家機制設計哲學不同。MongoDB read concern 是 per-operation 選擇（同一 client connection 可以混用）；DynamoDB strong vs eventual 是 per-read 選項（write 端統一強一致）；Cosmos DB 5 個 level 是 account-level default + per-request override、且 Strong 跟 multi-region write 互斥（CAP 硬約束）。設計上 MongoDB 最 flexible、Cosmos DB 最 explicit、DynamoDB 介於中間。延伸機制細節見 Cosmos DB consistency levels engineering、Cosmos DB multi-region write conflict（SSoT 主寫位置）。

Multi-model 差異化：Cosmos DB 是 唯一單一服務支援 5 API 的雲商 DB（SQL / MongoDB / Cassandra / Gremlin / Table）— 對照 AWS 走多產品覆蓋（DynamoDB KV + DocumentDB MongoDB-compat + Neptune graph + Keyspaces Cassandra-compat）、GCP 走多產品覆蓋（Firestore + Spanner + Bigtable）。multi-model 的差異化價值是 減少多 DB 並存運維 — 一個產品團隊只養一個 service、一套 IAM、一套 backup / DR、一套 monitoring。但 是否真用上 multi-model 要看團隊實際 workload — 多數團隊只用 1-2 個 API、單一 model 的競品（DynamoDB / MongoDB）可能更專注（F2.16）。

失敗模式（cross-vendor 反模式）

下列七條是三 vendor 都會踩、跨 case 共通的反模式。Per-vendor 特定反模式（例如 DynamoDB on-demand 隱性 hot partition、MongoDB schema 三代並存）在 per-vendor deep article。

反模式 1：把 DynamoDB 當 OLTP

訊號：access pattern 還在探索期、5+ 種 query 還會增加、強一致 cross-partition transaction 是產品契約。應回 PostgreSQL / Aurora、不是繼續加碼 DynamoDB single-table design。

DynamoDB 的 正確 用法包含 control plane KV（Zoom / Disney+ / Capcom）跟 durable queue / write buffer（Tixcraft 9.C15 揭露的非 OLTP 正向用例、F1.3）— DynamoDB 接「訂單」寫入、不是即時生效、是讓 traditional server（金流 / 票庫）用自己能承受的速度消費。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」。

反模式 2：把 MongoDB 當 KV

訊號：access pattern 固定、PK 天然均勻、不需要 aggregation pipeline、document 內部從不展開（只查 root 欄位）。

應改 DynamoDB / Cosmos DB Table API。MongoDB 在這場景的 overhead（document overhead / connection model / aggregation engine 未用上）不划算 — KV vendor 的單筆讀寫成本更低、scaling 模型更簡單。

反模式 3：把 Cosmos DB 當跨雲服務

訊號：團隊評估 multi-cloud DR / 跨雲 portability、看到 Cosmos DB 文件強調「global distribution」就以為支援跨雲。

Cosmos DB 是 Azure-only、global distribution 指 Azure 內跨 region。想跨雲應改 MongoDB Atlas。multi-model 差異化是 Azure 生態內 的價值（F2.16）— 一旦離開 Azure、Cosmos DB 的所有獨特優勢都不存在。

反模式 4：federated DB 假設「全用 X」

訊號：寫架構設計時假設「DB 一個服務搞定」、不規劃 cache / queue / proxy / abstraction layer。

Production 真實系統都是 federated（Coinbase / Toyota / Forbes 都是）。寫架構時假設一個 DB 搞定會撞 connection limit（surge 下 RDB 第一個爆點、F1.7）/ cache miss（單靠 DB 撐不住讀峰值）/ cross-region replication（跨 region 一致性處理錯）等隱性瓶頸。預先設計 federated topology + 跨層責任分配、不是事後補。

反模式 5：誤判 dogfood case 數字

訊號：引用 Microsoft 365 / Amazon Prime Day 等 dogfood case 時、把它當 production benchmark、抄具體數字當 sizing 依據。

Dogfood case 數字常 不公開 或 不適用 customer-facing（F2.17 + F1.10）— Amazon Prime Day 「90M reads/sec」是年度峰值最高一秒不是平均、Microsoft 365 直接沒給數字、Google Spanner「10 億 req/sec」是 Google 全使用者加總不是單客戶配額。寫架構時引用要明示 selection signal（雲商賭身家、值得當高權重 vendor 訊號）vs production benchmark（具體 sizing 數字）— 兩者不可混為一談。

反模式 6：partition key 一上 production 才發現不可逆

訊號：選 Cosmos DB / DynamoDB 時、partition key 設計沒做完整 access pattern audit、上 production 一段時間後發現 hot partition、想改 PK。

三家不在同一光譜（見前段對比表）— MongoDB shard key 4.4+ 可改但成本高、DynamoDB 可 backfill 改、Cosmos DB 不可改 必 export-recreate。選 Cosmos DB 前要前期完整 access pattern audit、列所有預期 query 跟對應 PK 訪問頻率、確認最熱 PK 流量在單一 partition 容量上限內（F2.15）。

反模式 7：wire compatibility 當 100% 行為相同

訊號：選 Cosmos DB MongoDB API 或 DocumentDB、看到「MongoDB compatible」就假設 MongoDB driver 跑得起來就是相容、跳過 query pattern 驗證。

Wire compat ≠ 行為 100% 相同（F2.9）。Cosmos DB MongoDB API 廣告「100% wire compatibility」是行銷話術、實際是「在某些 query pattern 下相容」— aggregation pipeline 某些 stage 不支援、transaction edge case 行為差異、index 行為差異都會踩到。遷移必須 dual-write per query pattern 驗證、不是看 vendor spec list。

不該選 DB3 的訊號（升 SQL / 升 distributed SQL 路徑）

下列四條訊號出現時、選擇應跳出 DB3 範圍。

• JOIN-heavy + 強 normalize workload：應留 PostgreSQL（包括 PostgreSQL + JSONB 混合方案）、不該塞 NoSQL 再 $lookup。aggregation pipeline 的 $lookup 性能遠不如 SQL JOIN、在 sharded cluster 還有限制。
• 強一致 cross-region transaction 是產品契約：應進 DB4 entry point 評估 distributed SQL（CockroachDB / Spanner / Aurora DSQL）。三家 NoSQL 的 cross-region transaction 都有 limitation、不該當主路徑。
• 大流量 + 跨業務 fleet 治理：Aurora 200 cluster 模式（9.C4 DraftKings 揭露的 business sharding fleet）可能更合適、進 Aurora fleet 治理。NoSQL 的 fleet 治理工具鏈（cluster lifecycle / cross-cluster query / unified IAM）通常不如 managed SQL 成熟。
• 資料模型還在探索 + access pattern 變動快：暫緩 NoSQL 選型、用 PostgreSQL + JSONB 過渡。JSONB 給 document-like flexibility、SQL 給 ad-hoc query power、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

下一步路由（per-vendor outline 子組）

讀者識別 workload type（軸 1-3）+ migration path（三型）+ system role（federated / control plane）後、進對應 per-vendor 子組繼續深化。

MongoDB 子組

• 入門：schema design pattern（contract layer 三選一：DB 層 validator / app 層 abstraction / 混合）
• 容量：shard key selection（單 cluster vs 多 cluster blast radius、Toyota 20 DB 模式）
• Migration：migrate to Atlas（同 DB 換託管型）

DynamoDB 子組

• 入門：single-table design pattern（access pattern 設計 + 適用度前置判讀）
• 機制：consistency model optimization（strong vs eventually consistent 取捨）

Cosmos DB 子組

• 入門：MongoDB API vs SQL API（API model 選型、四層 framing）

跨層架構（federated DB / cache / proxy）

跨層架構的延伸內容見對應 per-vendor connection management / cache layer article（後續會寫）— 本文只在軸 2 / federated frame 點到、不展開機制。

進 DB4 evaluation

若需要強一致 cross-region SQL / paradigm shift（KV → distributed SQL 或 SQL → distributed SQL）、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。

Knowledge card 路由

本文涉及的 knowledge card：

• document-store — document model 的核心概念跟 aggregate root 邊界
• hot-partition — KV vendor 的 partition 容量上限機制
• database-sharding — shard key 跟 partition key 設計
• consistency-level — strong / eventual / session 三類取捨
• vendor-lock-in — 單雲 vs 跨雲的 hedging 取捨
• distributed-sql — 跳出 DB3 進 DB4 的概念入口

本章是 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 保證選項）

教學路線：SQL baseline 與交易演進

PostgreSQL 服務頁的教學目標是建立 SQL baseline。讀者讀完後要能用 PostgreSQL 理解 transaction、schema evolution、query boundary、connection pressure 與 managed / distributed SQL 的比較基準。

定位：OLTP 預設、SQL 工程深度

PostgreSQL 跟 MySQL 是兩大 SQL OLTP 主流、但設計取捨明顯不同：

• PostgreSQL 偏 特性深度 — JSON、GIS、full-text search、partial index、CTE、window function 都成熟
• MySQL 偏 簡單 query 效能 + 分片生態 — Vitess / PlanetScale 提供超大規模 database sharding

選 PostgreSQL 的核心訴求：需要進階 SQL 特性、需要長期 schema evolution 彈性、信任 community-driven 演進、想避免單一 vendor lock-in（PostgreSQL 是 open source、可跨雲 / on-prem）。

容量特性

PostgreSQL 沒有「vendor 給的容量數字」、要靠 instance 配置 + tuning 推估。但有幾個工程上限要知道：

單一 primary 寫吞吐：

• 一般 m5.4xlarge 級 instance：5K-10K WPS（依 schema、index、commit fsync）
• 高階 r6i.16xlarge + io2 storage：30K-50K WPS
• 超過這個級別 → 應用層 database sharding 或換 Aurora / Spanner

Connection 上限：

• 預設 100 connection、每個 connection ~10MB RAM
• 1000+ connection 必須 pgBouncer / PgCat 共享 pool
• 對應 9.C29 Lemino case — RDB connection limit 是 surge 場景的隱性 bottleneck

Read replica：

• streaming replication：1 個 primary + 多個 standby（async / sync）
• 跨 AZ replication lag 通常 < 100ms、跨 region 可能秒級
• 跟 Aurora 比、自管 PostgreSQL replication lag 較大

Storage 上限：

• 單一 table 32 TB（PostgreSQL 設計上限）
• 實務上單表超過 1 TB 開始有 vacuum / index 問題、建議 partition

適用場景

1. 多用途 OLTP、複雜查詢：

• 複雜 JOIN、CTE、window function、subquery
• 訂單系統、會員系統、訂閱方案、權限 RBAC
• 需要 strong consistency + ACID transaction

2. JSON / 半結構化資料：

• JSONB column 支援 indexing、partial query
• 比 MongoDB 適合 主要結構化 + 部分 JSON workload
• 不適合主要 document workload（用 MongoDB / Cosmos DB）

3. 地理 / 全文檢索：

• PostGIS 是業界標準 GIS extension
• 全文檢索（ts_vector）對中等規模夠用、超大規模用 Elasticsearch

4. 進階特性需求：

• partial index（WHERE 條件下才建 index）
• exclusion constraints（避免 booking 重疊）
• range types（時間 / 數字範圍）
• logical decoding / CDC（Debezium、pgcapture）
• foreign data wrapper（query 跨 DB）

5. 跨雲 / on-prem 部署：

• 不想 vendor lock-in
• 可用 Patroni / Stolon / pg_auto_failover 做 HA
• 對應 1.11 全球分散式 OLTP 的 CockroachDB / Aurora DSQL 比較段

6. 中小規模高峰場景：

• 流量 < 10K WPS 級別、PostgreSQL 自管或 RDS 通常夠
• 流量更高、考慮 Aurora（同 wire protocol、storage 升級）

不適用場景

1. 極高寫入吞吐（單機 > 50K WPS）：

• 必須進入 database sharding 或分散式 SQL
• 替代：CockroachDB、TiDB、Spanner、應用層 sharding

2. 全球 multi-region active-active write：

• PostgreSQL 是 single primary、不支援 multi-region active-active
• 替代：Aurora DSQL、Spanner、CockroachDB multi-region

3. KV 簡單查詢 + sub-10ms p99：

• PostgreSQL connection 開銷 + parsing + planning 已經 1-3ms
• KV-pattern workload 用 DynamoDB / Redis / Cosmos DB 更便宜更快

4. 大規模 OLAP：

• PostgreSQL 定位在 OLTP，analytics workload 交給 OLAP 系統
• 大數據分析用 ClickHouse / BigQuery / Snowflake / Redshift / Synapse

5. 連線量極大 SaaS（每個用戶一個 connection）：

• 即使有 pgBouncer、超大連線量仍是 PostgreSQL 結構性限制
• 對應 9.C29 Lemino 案例 — 流量上升 connection 爆是換 DynamoDB 的主因

跟其他 vendor 的取捨

vs MySQL：

• PostgreSQL：SQL 特性深、JSON / GIS / window 完整、replication 較簡單但 lag 較大
• MySQL：簡單 query 效能好、replication 機制成熟、Vitess 分片生態強
• 選 PostgreSQL：需要進階 SQL、複雜 query、JSON workload
• 選 MySQL：高併發簡單 query、需要 sharding、已用 MySQL 生態

vs Aurora（同 PostgreSQL wire protocol）：

• PostgreSQL：自管 / RDS、特性接近 upstream、跨雲可用
• Aurora：AWS managed、storage / compute 分離、更多 read replica
• 選 PostgreSQL：跨雲、想最新特性、預算敏感
• 選 Aurora：AWS 生態、需要更快 failover + 更多 read replica
• 詳見 Aurora vendor page

vs CockroachDB（PostgreSQL wire protocol 相容）：

• PostgreSQL：single-primary OLTP、SQL 特性完整
• CockroachDB：multi-region 強一致 SQL、PostgreSQL wire 相容但部分特性缺
• 選 PostgreSQL：single-region 或 read replica 跨 region 夠
• 選 CockroachDB：必須 multi-region active-active write
• 詳見 1.11 全球分散式 OLTP

vs Spanner / Aurora DSQL（全球分散式 SQL）：

• PostgreSQL：傳統設計、跨 region 是 async replication
• Spanner / Aurora DSQL：全球線性化、跨 region 強一致
• 選 PostgreSQL：90% 場景夠用、便宜、容易
• 選 Spanner / Aurora DSQL：金融交易、ticketing inventory、必須全球強一致

vs DynamoDB：

• 詳見 1.10 KV / Document DB 容量規劃 的 connection model 對比段

vs Neon（PostgreSQL serverless）：

• PostgreSQL：standard、自管或 RDS
• Neon：branch-based、scale-to-zero、適合 dev / preview environment
• 選 Neon：dev / preview、稀疏 workload、CI 用
• 選 PostgreSQL：production sustained workload

容量規劃要點

1. Connection pool 必須有：

• 直接連 1000+ connection 會壓垮 PostgreSQL
• pgBouncer（最簡單、transaction pooling）
• PgCat（rust 寫的進階替代、支援 sharding）
• application 層 pool（HikariCP、SQLAlchemy pool）
• 通常組合使用：application pool 30-50 connection × 多 instance → pgBouncer 共享 → PostgreSQL 200 connection
• 對應 Connection Pool 卡片

2. Replication 配置：

• streaming replication：async / sync / quorum
• 跨 AZ async：lag 通常 < 100ms、failover 1-2 分鐘
• 跨 AZ sync：lag 接近 0、但寫入要等 standby ack、會降寫吞吐
• 跨 region 通常 async
• HA 工具：Patroni（最常見）、pg_auto_failover、Stolon

3. Vacuum 跟 bloat 治理：

• PostgreSQL MVCC 會留下 dead tuples、必須 vacuum
• autovacuum 配置：throttle 大表、避免在 peak 跑
• bloat 監控：pg_stat_user_tables 看 dead_tup ratio
• 大表 vacuum 可能要 hours、影響 maintenance window

4. 大表 partitioning：

• 單表 > 1 TB 建議 partition（按時間、按 tenant）
• partition pruning 讓 query 只掃需要的 partition
• partition 限制：cross-partition unique constraint、跨 partition join 較慢

5. Index 策略：

• 預設 B-tree、適合大多數 query
• partial index 對 boolean / status column 特別有用
• GIN / GiST 對 JSON / full-text / GIS
• index 太多會拖累寫入、定期 review 未用 index（pg_stat_user_indexes）

安全、DR 與角色分工

PostgreSQL 的 production 完整性不只來自 SQL 特性，也來自資料存取、備份復原、升級責任與事故證據的分工。這一段補上 PG baseline 原本留在 limitation 的三個缺口：Security / RLS / audit logging、cross-region DR、application developer vs DBA / SRE 視角。

Access control / RLS 的判讀重點是把資料責任放在資料層與 application 層之間分工。PostgreSQL 支援 role、grant、schema、function security 與 row-level security；但 RLS 會把授權邏輯拉進 database，適合 multi-tenant row isolation、資料平台或共享 reporting schema，日常 OLTP 仍要保留 application authorization 與 audit trail。

TLS / credential 的判讀重點是連線安全與憑證生命週期。Self-managed PostgreSQL 要處理 server cert、client cert、DB user rotation 與 connection pool 重連；managed PostgreSQL 常把 certificate、IAM auth 或 secret integration 交給平台，但 application pool、migration tool 與 read replica 仍要一起更新。

Cross-region DR 的判讀重點是 RPO / RTO 與資料一致性。自管 PostgreSQL 可用 streaming replication、WAL archiving、PITR 與 Patroni 做 region failover；Aurora 把 backup、PITR 與 Global Database 交給 AWS；真正 active-active 或 global strong consistency 需求要回到 CockroachDB、Spanner 或 Aurora DSQL，single-primary PostgreSQL 保留為 region failover 與 async DR 路線。

Developer / DBA split 的判讀重點是把日常責任寫進流程。Application developer 擁有 query shape、transaction boundary、repository adapter 與 migration contract；DBA / SRE 擁有 backup、replication、pooler、extension、vacuum、index maintenance 與 DR drill；release gate 需要把兩邊 evidence 合在同一份 decision log。

Managed PG 與相容變體路由

PostgreSQL wire protocol 已成為 managed SQL 與 distributed SQL 的相容目標。選型時要區分「PostgreSQL 本體」、「managed PostgreSQL」、「PostgreSQL-compatible distributed SQL」與「PostgreSQL extension ecosystem」四種不同責任。

Managed PG 變體的引用規則是先查 compatibility，再談 migration。Extension whitelist、backup / restore API、logical replication 支援、connection endpoint 行為與 pricing 都是時間敏感 claim；實作前要回到官方文件確認版本，並把確認日期留在 migration plan 或 decision log。

Deep article + Migration playbook（已完成）

補充正文路由

當前 deep article、migration playbook、補充正文與 hands-on 已 cover replication / HA / OSC / connection / CDC / sharding / multi-master / MVCC / query opt / index / partitioning / JSONB / FTS / extension（含 TimescaleDB / pgvector / PostGIS）/ backup / slot / SQL features / upgrade / migration / security / DR / managed variant 等維度。下列補充正文用來承接 overview 中提到的延伸議題：

• Logical decoding plugins deep dive：wal2json / pgoutput / decoderbufs 對位、CDC pipeline 整合
• pg_partman advanced：retention 跟 child partition 自動 management
• Connection pooler comparison：PgBouncer vs Pgcat vs Odyssey 細部對比
• Aurora I/O-Optimized vs standard：cost model 取捨
• AlloyDB / Cloud SQL 比較：GCP managed PG 選型

上述補充篇已完成正文，並保留既有引用路徑。Logical decoding 接 Logical Replication + Debezium 與 Replication Slot Management；pg_partman advanced 接 Declarative Partitioning；pooler comparison 接 Connection Scaling 與 pgBouncer Config；Aurora cost 接 → Aurora；AlloyDB / Cloud SQL 接 Managed PG Comparison。

案例對照

PostgreSQL 沒有直接的 09 case（多數 09 case 用 managed vendor）、但作為 baseline 跟遷移源頭 在許多 case 出現：

已知 Limitation 與 Audit 紀錄

本 vendor 頁的 22 篇 deep article + 6 篇 migration playbook 經過 4-reviewer audit（A 寫作規範 / B 跨檔一致性 / C 技術準確性 / D 框架偏誤）、Phase 1-3 修法完成。承認以下 limitation：

• PG narrative bias：pgvector / TimescaleDB / extension-ecosystem / Citus 四篇對「PG 取代專業 DB」描述偏 PG-favoring；對手 vendor（Pinecone / InfluxDB / Vitess）的優勢段相對簡短。讀者選型時、請以 cost / ops / scale 三軸綜合判斷、不依本 vendor 頁單一視角。
• Anti-recommendation 深度不一：bdr-multi-master / extension-ecosystem 有「99% 不需要」明確邊界、其他篇章邊界較柔（如「Vector 量 > 5-20M」是粗略門檻）。實際 production 決策請參考多 vendor 對照 + 自家 workload 量測。
• Sibling cross-link 狀態：MySQL ↔ PG sibling、PG 既有 ↔ 新章節 cross-link 已補（refer #136 卡）；本輪同步補 Aurora / CockroachDB / Spanner / Cosmos DB / DynamoDB vendor 頁的反向 sibling 路由，剩餘精修可在各 migration playbook 補更細的 step-by-step 對照。
• 時間敏感 vendor claim：Aurora DSQL（2024-12 preview / 2025-05 GA）/ pgvector（0.8 iterative scan）/ TimescaleDB version matrix / DSQL extension 支援範圍持續演進、本 vendor 頁以 2025-2026 公開狀態為準、實作前請以 vendor 官方 docs 為準（refer #137 卡）。
• 補充維度已正文化：Security / RLS / audit logging、cross-region DR、application developer vs DBA 視角分工、YugabyteDB / TiDB migration playbook、specialized PG variants 已補成正文。本輪也補上跨 vendor 反向連結與時間敏感 claim 路由；下一輪可集中在 migration playbook 的操作步驟與 lab 化。

詳細 audit findings 跟修法見 #136 Sibling Vendor Cross-Link Bidirectionality / #137 Vendor Feature 時間敏感性 / #138 Cross-Reviewer Convergence。

常見陷阱

• connection 沒 pool 直接連：1000 application instance × 30 connection = 30K connection、PostgreSQL 撐不住
• 沒 vacuum 治理：dead tuple 累積、table bloat、query 變慢
• 大表沒 partition：> 1 TB 單表的 vacuum / index rebuild 變成事故
• index 不 review：寫吞吐被舊 index 拖垮
• 跨 AZ sync replication 給寫入吞吐高的 workload：每次 commit 等 standby ack、寫吞吐減半
• logical replication 拖太多 publication：可能造成 primary WAL 堆積、disk 爆

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：MySQL vendor、Aurora vendor（managed PostgreSQL）
• 操作：PostgreSQL Hands-on（local lab、pool、PITR、migration evidence、HA drill）
• 上游：1.1 高併發資料存取、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（PostgreSQL 不適用時的替代）/ 1.11 全球分散式 OLTP（PostgreSQL 不夠用時的升級路徑）
• 跨模組：9.5 瓶頸定位流程 — connection / replication lag / vacuum 都是 PostgreSQL 常見 bottleneck 源
• 官方：PostgreSQL Documentation

Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 PostgreSQL / MySQL / SQLite / MongoDB / DynamoDB / CockroachDB / Aurora，每個服務頁提供定位、適用場景、取捨、容量判準、案例對照與下一步路由。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

暫定分類

選型入口

資料庫選型的核心判斷是資料是否承擔正式狀態與一致性。當資料需要長期保存、支援查詢、被多個流程共同讀寫，並且需要交易保護時，應先評估 relational database 或 document database。

SQLite 適合單機服務、embedded app、測試資料庫與低操作成本場景；PostgreSQL 適合多使用者後端、複雜查詢、transaction、index 與長期 schema evolution。Migration 工具解決 schema 隨版本演進的問題；transaction boundary 解決多筆資料一起成功或失敗的問題；repository adapter 解決 application port 到具體 SQL 實作的轉換。

接近真實網路服務的例子包括訂單系統、會員系統、訂閱方案、付款紀錄與權限資料。這些資料都需要明確 source of truth，因此本模組會從資料模型、一致性、migration 與 repository adapter 邊界開始說明。

與語言教材的分工

語言教材處理 repository interface / protocol、取消與逾時、error wrapping、memory fake 與 contract test。Backend database 模組處理 SQL schema、migration tool、transaction isolation、connection pool 與資料庫錯誤語意。

跨模組端到端串聯（DB → cache → event → observability）見 0.15 跨模組 Checkout Episode。

章節列表

觀念網路補完方向

資料庫章節下一輪的核心責任是把正式狀態的演進路徑講完整。現有章節已經涵蓋 schema、transaction、repository adapter 與 migration playbook，但還需要補上 state ownership、query boundary、migration safety 與 reconciliation 之間的引用關係，讓讀者知道資料庫變更如何從設計、發布、觀測一路接到事故決策。

這些方向要寫成資料庫自己的敘事，避免把 04/06/08 的欄位直接搬進來。資料庫關心的是狀態能否正確演進；觀測、驗證與事故流程接收這個演進結果作為下游證據。

知識卡補強方向

資料庫模組的 knowledge card 缺口集中在「變更如何被驗證」與「資料如何被修復」。已有 schema migration、Expand / Contract、backfill 與 dual write 可作為第一批錨點。

下一批候選卡片包括 migration validation、read compatibility、cutover window、reconciliation、data repair runbook 與 fail-forward migration。這些卡片要先定義服務責任與使用時機，再讓 1.6 migration playbook 與後續實作文章引用。

Vendor 文章規格入口

資料庫 vendor 文章的下一輪重點是把 PostgreSQL / MySQL batch 經驗變成可重複使用的撰寫規格。後續寫 SQLite、MongoDB、DynamoDB、Aurora、Spanner、Cosmos DB 與 CockroachDB 前，先讀 資料庫 Vendor 文章撰寫規格；該文分清 vendor overview、deep article 與 migration playbook 的責任，並列出 PG / MySQL 回收出的橫向調整項。

實作探討入口

資料庫的第一條實作路徑已完成： 1.7 Schema Migration Rollout 證據實作示範。這篇以訂單資料表付款狀態欄位演進為例，說明 migration plan、validation query、rollback condition 與 incident decision route 如何一起成立。

這條路徑的前置引用是 1.2 schema design、1.3 transaction boundary、1.6 migration playbook、6.11 Migration Safety 與 4.20 Observability Evidence Package。完成後可依 Backend 學習路線 進入 02 cache migration。

資料庫路徑的 artifact 對齊重點是「先證明資料演進正確，再討論是否放行」。對 4.20 要交 Source/Time range/Query link/Owner/Data quality，並在 query 內容覆蓋 validation query、row count 差異與 replication lag；對 6.11 / 6.8 要交 Gate decision/Checks/Stop condition/Rollback window/Owner，呈現 expand/contract 分段結果；對 8.19 要交 Timestamp/Decision/Context/Evidence/Owner/Expected effect/Rollback condition，記錄 pause / rollback / fail-forward 的判斷與依據。

跨分類引用

• → infra 模組五：資料庫上 IaC：RDS 的 IaC 描述（subnet group、parameter group、連線管理、read replica）與部署順序
• → infra 模組五：Stateful 資源保護：multi-AZ、backup retention、deletion protection、PITR 的 IaC 設定

跨語言適配評估

資料庫使用方式會受語言的 connection pool、transaction scope、ORM 行為、錯誤處理與 migration 生態影響。同步 thread-based runtime 要控制 blocking query 與 pool 大小；async runtime 要確認 database client 是否真正非阻塞；輕量並發 runtime 要限制同時查詢數量，避免把大量 task 轉成資料庫連線壓力。強型別語言適合把 row mapping、schema 與錯誤分類型別化；動態語言則需要靠 migration、runtime validation、fixture 與 contract test 保護資料邊界。

本章是 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 設計

教學路線：高併發 OLTP 與分片生態

MySQL 服務頁的教學目標是把「簡單 SQL 查詢」推進到高併發 OLTP、replication、online schema change 與 sharding governance。讀者讀完後要能判斷 MySQL 何時是成熟預設、何時已經進入 Vitess / PlanetScale 或 application sharding 的討論。

定位：高併發簡單 SQL + 強分片生態

MySQL 跟 PostgreSQL 是 SQL OLTP 兩大主流、但設計取捨明顯不同：

• MySQL 偏 簡單 query 效能 + 分片生態 — InnoDB clustered index 對 primary key range query 特別快、Vitess 提供超大規模透明 database sharding
• PostgreSQL 偏 特性深度 — 詳見 PostgreSQL vendor page

選 MySQL 的核心訴求：需要超大規模分片（> 100 TB、> 100K WPS）、簡單 query 為主、已用 MySQL 生態工具鏈（gh-ost、pt-online-schema-change）。

容量特性

單一 primary 寫吞吐：

• 標準 InnoDB：10K-30K WPS（依 row size、commit sync、index 數量）
• 高階 instance + 優化 schema：50K-100K WPS
• 超過此級別 → Vitess sharding 或 PlanetScale

Connection 上限：

• 預設 max_connections = 151、實務常設 1000-5000
• 每個 connection thread stack ~3 MB + session buffer 累積、active 高峰時 ~8-10 MB（thread + sort/join buffer）
• 仍建議 ProxySQL / connection pool 限制 backend connection 數

Replication：

• async / semi-sync / GTID-based
• 跨 AZ async lag 通常 < 100ms
• 跨 region 通常用 chain replication 或 binlog 同步

Storage 上限：

• 單一 table 64 TB（InnoDB 設計上限）
• 實務超過 1 TB 表建議分片

適用場景

1. 大規模 OLTP + 分片需求：

• 流量 > 50K WPS、必須進入 database sharding 設計
• 用 Vitess / PlanetScale 透明 sharding、應用層幾乎不必改
• 對應產業：超大網路服務（GitHub、Shopify、Slack）

2. 簡單 query 為主：

• primary key lookup、簡單 range query
• 不太用 CTE、window function、複雜 JOIN
• InnoDB clustered index 對這類 workload 特別快

3. 既有 MySQL 生態工具：

• gh-ost / pt-online-schema-change（online schema migration）
• Orchestrator（HA topology 管理）
• ProxySQL（query routing + connection pool）
• Maxwell / Debezium MySQL（CDC）

4. 強一致 transaction 但容忍部分 SQL 功能缺失：

• 不需 partial index、不需 JSONB indexing
• 不需 PostGIS、用 spatial extension 夠

5. Aurora MySQL（managed 路徑）：

• 從自管 MySQL 上 AWS、保留 wire protocol
• 詳見 Aurora vendor page

不適用場景

1. 需要 PostgreSQL 等級的 SQL / JSON 特性：

• 複雜 CTE、recursive query、window function
• JSON Schema validation、JSONB GIN indexing
• PostGIS 等深度 extension

2. 全球 multi-region active-active write：

• MySQL 設計是 single primary、跨 region 是 async
• 替代：Aurora DSQL、Spanner、Vitess multi-cluster

3. 大規模 OLAP：

• MySQL 定位在 OLTP，analytics workload 交給 OLAP 系統
• 替代：ClickHouse、BigQuery、Snowflake

4. KV 簡單查詢 + sub-10ms p99：

• 跟 PostgreSQL 一樣有 parsing / planning 開銷
• 替代：DynamoDB、Redis

跟其他 vendor 的取捨

vs PostgreSQL：

• 詳見 PostgreSQL vendor page 對比段
• 摘要：MySQL 適合超大規模分片、PostgreSQL 適合進階 SQL 特性

vs Aurora MySQL（同 wire protocol）：

• MySQL（自管 / RDS）：可跨雲、彈性高
• Aurora MySQL：AWS managed、storage / compute 分離、更多 read replica
• 選自管 MySQL：跨雲需求、預算敏感
• 選 Aurora MySQL：AWS 生態深、需要 storage scaling

vs PlanetScale（Vitess managed）：

• MySQL（自管 + Vitess）：完全控制、可自管分片
• PlanetScale：managed Vitess、branch-based schema migration
• 選 MySQL + Vitess：team 有能力管 Vitess、預算敏感
• 選 PlanetScale：想 zero ops、branch-based workflow

vs TiDB：

• MySQL：single-primary、傳統分片靠 Vitess
• TiDB：MySQL wire protocol 相容、HTAP（OLTP + OLAP 同庫）、跨 region 強一致
• 選 MySQL：已有 MySQL 投資、不想換引擎
• 選 TiDB：需要跨 region 強一致 + OLAP 同庫

vs Vitess（self-managed sharding layer）：

• Vitess 本質是 MySQL 上層的 sharding layer
• 由 YouTube 設計、捐贈 CNCF
• 適合超大規模 MySQL 集群、需要透明 sharding

vs DynamoDB（document/KV 替代）：

• MySQL：SQL、有 transaction、ad-hoc query、connection-based
• DynamoDB：KV、partition 透明、無 connection 限制、5 個 9 SLA
• 選 MySQL：需要 ad-hoc query、複雜 JOIN、SQL transaction
• 選 DynamoDB：access pattern 固定、AWS-only、想避免 connection limit 問題
• 詳見 1.10 KV / Document DB 容量規劃 的 connection model 對比

vs Spanner / CockroachDB / Aurora DSQL（distributed SQL）：

• MySQL + Vitess：自管 sharding、operational 重、跨雲可用
• Spanner / CockroachDB / Aurora DSQL：分散式 SQL、跨 region 強一致、transparent sharding
• 選 MySQL + Vitess：已有 MySQL 投資、有能力管 Vitess、預算敏感
• 選 distributed SQL：需要 multi-region 強一致、不想自管 sharding
• 詳見 1.11 全球分散式 OLTP

vs MongoDB（document 替代）：

• MySQL：SQL + JSON column 補充
• MongoDB：document 為主、aggregation pipeline 強、schema-flexible
• 選 MySQL：主要結構化、少量半結構化
• 選 MongoDB：document 占主要 schema、aggregation 工作負載

容量規劃要點

1. Sharding 是 MySQL 大規模的核心：

• 單一 MySQL primary 寫吞吐有上限
• Vitess / PlanetScale 用 keyspace + shard 切分
• shard key 設計類似 DynamoDB partition key — 必須均勻
• 大規模案例：Shopify（多 shard 分散）、Slack（per-team sharding）

2. Online schema change 是必備：

• ALTER TABLE 直接跑會 lock 整個 table
• gh-ost（GitHub）/ pt-online-schema-change（Percona）/ Vitess online DDL 用 ghost table 漸進 migrate
• 大表 schema change 可能跑 hours / days、要排程

3. Replication 跟 GTID：

• GTID-based replication 比 binlog position 容易管 topology
• semi-sync replication 保證至少一個 standby ack 才 commit
• async replication 高吞吐但 lag 較大

4. Connection management：

• ProxySQL 是 MySQL 生態的 connection pool 標準
• 提供 query routing（讀 → replica、寫 → primary）
• 對應 9.C29 Lemino case — RDB connection limit 議題對 MySQL 同樣適用

5. InnoDB tuning：

• innodb_buffer_pool_size：dedicated server 70-75%、shared server 30-50%（詳見 InnoDB Tuning）
• innodb_flush_log_at_trx_commit：1（durable）vs 2（faster）vs 0（fastest, 不安全）
• innodb_io_capacity：依 storage 類型調整

Anti-recommendation 與升級路由

MySQL 的成熟生態容易讓讀者過早引入重工具。這一段補上 deep article audit 提到的 anti-recommendation 缺口：先說何時維持簡單 MySQL 路徑，再說何時升級到 ProxySQL、Orchestrator、gh-ost、Vitess、PlanetScale 或 distributed SQL。

Replication 的簡單路徑是 GTID + async replica + 明確 read routing。當 failover 仍靠人工判斷、replica re-pointing 反覆出錯、或 semi-sync fallback 沒有被監控時，才需要把 Orchestrator、ProxySQL 與 incident runbook 放進同一條 HA 路徑。

Online schema change 的簡單路徑是先判斷 MySQL 8.0 instant / inplace DDL 能否 cover。只有大表 rewrite、長時間 metadata lock、FK / trigger 複雜互動或 maintenance window 不足時，才讓 gh-ost / pt-online-schema-change 成為主線工具。

Sharding 的簡單路徑是延後到資料形狀穩定後再做。Vitess 能把 MySQL 推到超大規模，但它也引入 VTGate、VTTablet、VReplication、VSchema、resharding workflow 與跨 shard transaction 邊界；shard key 還沒穩定時，應先用 schema、index、read replica、partition 與容量治理延長單 primary 壽命。

Managed sharding 的簡單路徑是先確認團隊想轉移哪一層責任。PlanetScale 解的是 Vitess operation、branch-based schema workflow 與 managed failover；FK、cross-shard query、connection pool 與 cost model 仍要在 migration playbook 中驗證。

Deep article + Migration playbook（已完成）

補充正文路由

當前 deep article、migration playbook、補充正文與 hands-on 已 cover ops / schema / failover / tuning / SQL features / sharding / backup / migration / security / audit / document / OLAP / memory / metadata lock 等維度。下列補充正文用來承接 overview 中提到的延伸議題：

• Encryption at rest + TLS in transit + key management：對應 PG TLS-mTLS 議題
• Audit log + SIEM 整合：MySQL Enterprise Audit Plugin 跟 Splunk / Elastic Security 整合
• MySQL Document Store（X-Protocol）：少用但對特定 use case 有興趣
• Multi-source replication topology：1 個 replica 從 N 個 primary 拉、用於 sharded environment 整合
• HeatWave（MySQL OLAP add-on）：Oracle 推的 HTAP solution、跟 ClickHouse / Snowflake 對比
• Cross-buffer memory contention deep dive：buffer pool / connection thread / temp table / sort buffer 之間的 RAM 競爭、跟 OS swap 互動
• Metadata lock deep dive：DDL / long-running SELECT / FK 互動造成的 stalls

上述補充篇已完成正文，並保留既有路由。Encryption / TLS / key management 接 TLS / mTLS 與 Secret Management；audit log 接 Audit Log 與 07 資安資料保護；Document Store 接 MongoDB vendor 與 1.10 KV / Document DB 容量規劃；multi-source replication 接 Replication Topology；HeatWave 接 OLAP 替代路由；memory contention 接 InnoDB Tuning；metadata lock 接 Lock Contention 與 Online Schema Change Tools。

已知 limitation（多輪 audit 結論）

17 篇 batch 跑過 4-reviewer audit（寫作規範 / 跨檔一致性 / 技術準確性 / 結構性質疑）後留下的 limitation：

• Framework bias：5 篇 migration playbook 全落在 Type A / C / E、沒一篇 Type B / D / F。這反映 MySQL 領域 migration 的本質（多數情境是 schema 差 / operational 轉手 / paradigm shift）、也可能反映 6 type framework 的覆蓋限制
• Anti-recommendation 已補 overview 路由：本頁新增「Anti-recommendation 與升級路由」作為總入口；各 deep article 之後仍可逐篇補「何時維持簡單設計」段。
• Real case anchor 已下沉：本頁「真實案例 anchor」把 Shopify、Slack、GitHub gh-ost、YouTube / Vitess 與既有 09 case 串回 deep article；Shopify CDC、gh-ost workflow、YouTube / Vitess 與 Netflix Aurora consolidation 已補到對應 deep article 的 production case 段。
• PG 對比 narrative：對比段公允度尚可、但 PG 弱點（vacuum ops 開銷 / connection-per-process model / replication slot 治理）較少在 MySQL 視角展開、單方面對比偶有偏 MySQL 不利

案例對照

MySQL 沒有直接的 09 case（大規模 MySQL 多在 engineering blog、不在 vendor case study）、但作為 baseline / 遷移源 在多處出現：

真實案例 anchor

MySQL 真實案例的責任是把大規模 OLTP 的機制壓力放回正文。案例不只證明「某公司使用 MySQL」，而是提供 schema change、CDC、sharding、connection、queue 整合或 managed migration 的壓力來源。

案例下沉規則是先放 overview，再進 deep article。當某個案例只支撐服務定位，留在本頁；當案例提供具體操作訊號，例如 Shopify 的 Debezium connector scaling、GitHub 的 gh-ost workflow 或 YouTube 的 Vitess topology，對應 deep article 要保留 production case 段、讓讀者能從機制直接跳到案例。

常見陷阱

• 直接 ALTER TABLE 大表：lock 表 hours、production 停擺、必須用 online schema change
• 不用 GTID：replication topology 變更困難、recover from failure 容易出錯
• buffer pool 太小：cache miss 高、IOPS 飆升
• shard key 選錯：hot shard 出現、整體吞吐達不到名義
• connection 沒 pool：跟 PostgreSQL 同樣問題、用 ProxySQL
• semi-sync 對高吞吐 workload：每次 commit 等 ack、寫吞吐降一半

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：PostgreSQL vendor、Aurora vendor（managed MySQL）
• 操作：MySQL Hands-on（local lab、ProxySQL、OSC、replication failover、backup restore、Vitess sandbox）
• 上游：1.1 高併發資料存取、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（MySQL 不適用時的替代）
• 跨模組：9.5 瓶頸定位流程 — connection / replication / lock contention 常見 MySQL bottleneck
• 官方：MySQL Documentation、Vitess、PlanetScale

本章從業務邊界切分開始、進入 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 的影響）

教學路線：Document shape 與 schema governance

MongoDB 服務頁的教學目標是把 document model、schema flexibility、index、aggregation pipeline 與 sharding 放回資料形狀治理。讀者讀完後要能判斷資料是否適合 aggregate root，並知道 schema governance 如何影響長期維護成本。

定位：JSON document + 跨雲彈性

MongoDB 是以 document model 為主體的 DB。PostgreSQL JSONB 適合「SQL 為主、少量半結構化欄位」；MongoDB 則把 BSON document、aggregation pipeline、database sharding 與 schema governance 放在核心設計裡。近年版本加入 time series、change streams、queryable encryption、CSFLE 等能力。

選 MongoDB 的核心訴求：document model 是主要 use case、需要跨雲 managed（Atlas）、想避免 vendor lock-in（也可自管）。

容量特性

單一 instance 吞吐：

• 一般 m5.4xlarge：5K-15K WPS（依 doc size、index）
• 高階 instance + tuning：30K-50K WPS
• 超過此級別 → sharding

Sharding：

• MongoDB 原生支援 sharded cluster
• mongos router + config servers + shard
• MongoDB sharding 要主動設計 shard key，並和 Hot Partition 風險一起看

Replication：

• Replica set（primary + secondary、async）
• 跨 region 通常 async
• 自動 failover < 30 秒（mongod 內建）

Storage：

• 單一 collection 沒有官方上限、但 shard key resharding 過去版本是大手術（4.4+ 支援 reshardCollection）

適用場景

1. Document model 主要 workload：

• schema 變化頻繁的早期產品
• nested document 自然表達領域模型（訂單含多個 item、用戶含多個 preference）
• 對應案例：9.C30 Microsoft 365 — 從 MongoDB 遷移到 Cosmos DB MongoDB API、保留 document model

2. Aggregation pipeline 重 workload：

• 複雜的 $group / $match / $project chain
• 報表、analytics、ETL prep
• 比 RDBMS 寫複雜 query 更直觀（對某些 team）

3. 跨雲 managed（Atlas）：

• MongoDB Atlas 跨 AWS / GCP / Azure
• 跟 DynamoDB（AWS only）、Cosmos DB（Azure only）、Spanner（GCP only）相反
• 適合多雲策略、避免單一 vendor lock-in

4. Time series workload（6.0+）：

• time series collection 專屬優化
• 不過 InfluxDB / TimescaleDB 仍是更專業選擇

5. 已有 MongoDB 生態 + 想轉移操作責任：

• Atlas 提供 backup、failover、monitoring、auto-scale
• 想把 MongoDB DBA / SRE 操作責任交給 Atlas

不適用場景

1. 強 ACID multi-document transaction：

• MongoDB Transaction 支援多 document、但跨 shard 有性能影響
• 高頻金融交易仍建議 SQL 系統
• 替代：PostgreSQL、Aurora、Spanner

2. 複雜 JOIN：

• MongoDB $lookup 適合少量相鄰資料，JOIN-heavy workload 應回 SQL 系統
• schema design 階段要把常用讀取路徑 denormalize 成 document shape
• 替代：SQL 系統做 JOIN-heavy workload

3. 純 KV + sub-ms latency：

• MongoDB document model 比 KV 多一層 BSON parsing
• 替代：Redis、DynamoDB、Bigtable

4. 大規模 OLAP：

• aggregation 對中等資料量還行、TB 級不適合
• 替代：ClickHouse、BigQuery、Spark on Delta Lake

5. 嚴格資料模型 + schema enforcement：

• MongoDB schema flexibility 可能導致 production data inconsistency
• 替代：SQL DB（schema 強制）+ JSONB column 處理半結構化

跟其他 vendor 的取捨

vs Cosmos DB MongoDB API：

• MongoDB Atlas：跨雲、原生 MongoDB 行為
• Cosmos DB MongoDB API：Azure-only、global distribution + 5 consistency levels
• 選 MongoDB Atlas：跨雲、需要原生 MongoDB features
• 選 Cosmos DB：Azure 生態、需要更好 global distribution
• 對應案例：9.C30 Microsoft 365 — 從 MongoDB 遷到 Cosmos DB MongoDB API，主要保留 document model

vs DynamoDB：

• MongoDB：document model、aggregation 強、跨雲
• DynamoDB：KV / single-table design、AWS 整合、5 個 9 SLA
• 選 MongoDB：document 為主、跨雲
• 選 DynamoDB：KV 為主、AWS 生態
• 詳見 DynamoDB vendor page 對比段

vs PostgreSQL JSONB：

• MongoDB：document 為主、schema-less
• PostgreSQL：SQL 為主、JSONB 補充
• 選 MongoDB：document 占主要 schema
• 選 PostgreSQL JSONB：主要結構化、少量半結構化欄位

vs Couchbase / Couchdb / Firestore：

• Couchbase：MongoDB 替代、有 N1QL（SQL-like）
• CouchDB：偏小規模、master-master replication
• Firestore：GCP-only、realtime updates
• MongoDB 在這群裡是生態最廣的

vs Elasticsearch 作為 search 替代：

• 兩者分屬不同類別：MongoDB 是 OLTP / document、Elasticsearch 是 search + analytics
• 通常搭配用：MongoDB 主、Elasticsearch 處理 full-text search

容量規劃要點

1. Shard key 設計是命脈：

• 跟 DynamoDB partition key 同樣關鍵
• 不均勻 → hot shard、實際容量達不到名義
• 4.4+ 可以 reshard、但仍是大手術

2. Replica set 是 HA 基礎：

• 至少 3 個 member（1 primary + 2 secondary）
• secondary 可 read（read preference）但要注意 lag
• failover 通常 < 30 秒

3. Atlas managed 服務：

• 提供 auto-scaling、auto-backup、跨雲部署
• Tier 從 M0（free）到 M700（高階）
• Atlas Online Archive 自動把舊資料移到便宜 storage

4. Index 限制：

• 單 collection 最多 64 個 index
• compound index 有順序敏感（{a:1, b:1} 跟 {b:1, a:1} 不同）
• TTL index 自動 expire 過期 document

5. Change streams（CDC）：

• 4.0+ 提供原生 change streams
• 對接 Kafka / event bus 做 event sourcing

Anti-recommendation 與升級路由

MongoDB 的 schema flexibility 會降低早期建模成本，也會把 schema governance 延後到 production。這一段先說何時維持 document model，再說何時升級 Atlas、sharding、Cosmos DB、DynamoDB 或 SQL。

MongoDB 的簡單路徑是先把 document boundary 寫清楚。資料可以彈性演進，但 application 仍要知道哪些欄位是正式契約、哪些欄位只是相容期，並用 validation、migration 與 data quality check 管住版本漂移。

Sharding 的升級路徑要等 shard key 與 query shape 足夠穩定。過早切 shard 會把 aggregation、transaction 與 index 成本提前放大；過晚切 shard 則會讓 resharding、chunk migration 與 balancer 壓力進入 production 高峰期。

Deep article（已完成）

本批 6 篇 deep article 已完成、覆蓋 MongoDB 從 schema 設計到 production 跨層架構的核心 production 議題：

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

後續擴充（仍待補）

• Index 設計跟覆蓋
• 從自管 MongoDB 遷到 Atlas
• 從 MongoDB 遷到 Cosmos DB MongoDB API（保留 document model）
• 從 MongoDB 遷到 DynamoDB（access pattern 需要重設計）
• Queryable encryption（CSFLE）

案例對照

MongoDB case 的讀法分三組：

• 作為 production 主角持續演進（Coinbase、Toyota Connected）：document model 撐住核心 OLTP / IoT、配 connection proxy / cache / event-driven 處理擴展周邊。
• 自管 → managed 遷移（Forbes）：同 document model、換託管模式、ROI 集中在 DBA 責任轉移跟跨雲彈性、不是性能改善。
• 遷出 MongoDB 保留 API（Microsoft 365）：document model 保留、底層換到 Cosmos DB MongoDB API、換取 Azure global distribution。

讀 case 時要區分 MongoDB 在「主角 / 遷入 / 遷出」三種位置的差異，三種位置揭露的工程議題完全不同。

常見陷阱

• schema 長期 schema-less：production 出現 data inconsistency、難 query
• shard key 用 _id（自增）：寫入全集中在最後一個 shard
• $lookup 過度使用：跨 collection JOIN-heavy workload 應在 schema design 時 denormalize 或回 SQL
• index 太多：寫吞吐被拖垮、定期 review 未用 index
• secondary read 不檢查 lag：用戶讀到 stale data
• 不規劃 Atlas tier upgrade 路徑：流量上來才發現 tier 跟不上、緊急升級費用高

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Cosmos DB vendor（MongoDB API replacement）、DynamoDB vendor（KV alternative）
• 上游：1.2 schema design、1.10 KV / Document DB 容量規劃
• 下游：1.12 大規模 DB 遷移實戰（MongoDB 遷出範例）
• 跨模組：9.6 容量規劃模型、9.4 Saturation Discovery（shard key 跟 hot shard）
• 官方：MongoDB Manual、MongoDB Atlas

升級前的相容性評估

大版本升級不只是換一個二進位檔——新版本可能改變 SQL 行為、儲存格式、認證方式與預設值。在動任何生產資源之前，先在本地或測試環境把相容性問題找出來。

MySQL 5.7 → 8.0 的常見破壞性變更

PostgreSQL 大版本升級的檢查點

PostgreSQL 的大版本升級相對穩定，但仍有需要確認的項目：extension 版本是否跟新 PostgreSQL 版本相容（特別是 PostGIS、pg_partman、timescaledb 這類複雜 extension）、pg_upgrade 的 --check 模式可以在不實際升級的前提下驗證相容性。

1# PostgreSQL: 升級前 dry-run 檢查
2pg_upgrade --old-datadir /var/lib/postgresql/13/main \
3           --new-datadir /var/lib/postgresql/16/main \
4           --old-bindir /usr/lib/postgresql/13/bin \
5           --new-bindir /usr/lib/postgresql/16/bin \
6           --check

應用程式層的查詢相容性

把應用程式的所有 SQL 查詢（ORM 產生的也算）對新版本跑一遍。重點是行為變更而非語法錯誤——語法錯誤會立刻報錯、容易抓；行為變更（排序結果不同、型別轉換規則不同）不會報錯、但結果錯誤。

1# MySQL 升級前檢查工具
2mysqlcheck --all-databases --check-upgrade
3mysql_upgrade --upgrade-system-tables --dry-run

ORM 和 database driver 也要確認版本支援。PHP 的 mysqli 在 PHP 7.4+ 預設支援 caching_sha2_password、但舊版不支援。Node.js 的 mysql2 原生支援、但 mysql（舊套件）不支援。Python 的 mysqlclient 1.4+ 支援。

備份：升級前的保險

升級前的備份不是日常備份——它是一份明確的、經過驗證的、標記為「升級前保險點」的快照。

備份操作

1# MySQL: 完整 dump（InnoDB 用 --single-transaction 避免鎖表）
2mysqldump --all-databases --single-transaction --routines --triggers \
3  --set-gtid-purged=OFF > pre-upgrade-$(date +%Y%m%d-%H%M).sql
4
5# PostgreSQL: 完整 dump
6pg_dumpall > pre-upgrade-$(date +%Y%m%d-%H%M).sql

RDS 環境：在升級操作前手動建立 snapshot，而非依賴自動備份。自動備份在升級過程中可能被新的快照覆蓋，手動 snapshot 不會被自動清除。

1aws rds create-db-snapshot \
2  --db-instance-identifier mydb-prod \
3  --db-snapshot-identifier pre-upgrade-$(date +%Y%m%d)

備份驗證

備份存在不等於備份可用。驗證方式是把備份還原到一台獨立的測試實例、確認資料完整：

1# 還原到測試實例
2mysql -h test-instance -u admin -p < pre-upgrade-20260626-1400.sql
3
4# 驗證關鍵表的 row count
5mysql -h test-instance -e "SELECT COUNT(*) FROM orders; SELECT COUNT(*) FROM users;"

記錄還原時間：「從這份備份還原到可服務狀態需要 N 分鐘/小時」。這個數字是升級失敗時的停機時間下限——管理層需要這個數字來評估升級的風險。

平行驗證策略

在生產環境切換之前，先在新版本的平行環境上跑完所有驗證。平行驗證的目標是讓切換那一刻的風險降到最低——切換時已經知道新版本在相同資料和相同負載下的行為。

建立平行環境

驗證項目

平行驗證至少跑一週。時間越長、覆蓋到的邊界情境越多——月結批次、週期性報表、低頻排程任務都可能觸發只在特定條件下才出現的相容性問題。

切換策略

切換策略的選擇取決於三個變數的取捨：操作複雜度、停機時間、回退速度。

In-place 升級

直接在原實例上升級版本。RDS 的操作是修改 engine version、等待升級完成。

• 停機：升級期間實例不可用（MySQL 5.7→8.0 在 RDS 上約 10-30 分鐘，視資料量而定）
• 回退：從 pre-upgrade snapshot 還原，需要 snapshot restore 時間（分鐘到小時級）
• 適用：可接受計畫性停機的環境、資料量不大

Blue-green 切換

在新版本上建立獨立實例、透過 replication 同步資料、切換應用程式的連線端點。

• 停機：接近零（DNS TTL 或 endpoint 切換的傳播時間）
• 回退：把連線端點切回舊實例，舊實例持續運行
• 複雜度：需要維護兩個實例的同步、切換時要處理複寫延遲
• 適用：不能接受停機的 production 環境

RDS 從 2022 年開始提供原生的 Blue/Green Deployments 功能，簡化了同步與切換的操作：

1aws rds create-blue-green-deployment \
2  --blue-green-deployment-name mydb-upgrade \
3  --source arn:aws:rds:ap-northeast-1:123456789012:db:mydb-prod \
4  --target-engine-version 8.0.35

Read replica 升級後提升

建立指定新版本的 read replica，replica 同步完成後提升為獨立實例，應用程式切換連線。

• 停機：提升 replica 的幾秒 + 連線切換
• 回退：舊 primary 仍在，切回即可
• 限制：不是所有版本組合都支援跨版本 replica

選型判準

升級後的驗證與監控

切換完成後的 48-72 小時是觀察期。這段時間舊實例保持可用狀態，直到確認新版本穩定才退役。

切換後立即驗證

1. 應用程式的所有關鍵路徑可正常操作（登入、查詢、寫入、交易）
2. 連線池行為正常（沒有持續的 authentication failure 或 connection reset）
3. 排程任務（cron job、背景 worker）正常連線並執行

效能監控

比較升級前後的關鍵指標：

1# 觀察升級後的 slow query 數量
2mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"
3
4# 比較 p99 延遲（需要 application-level metrics）
5# CloudWatch: DBInstanceIdentifier → ReadLatency, WriteLatency

升級後效能退化的常見原因：optimizer 行為改變（新版本選了不同的執行計畫）、buffer pool 冷啟動（升級後快取是空的、前幾小時延遲偏高是正常的）。如果 48 小時後延遲仍未回到基線，檢查 slow query log 找出退化的具體查詢。

舊實例退役

觀察期結束、新版本確認穩定後：

1. 停止舊實例的 replication（如果仍在同步）
2. 保留舊實例的 final snapshot
3. 刪除舊實例（先確認 deletion protection 關閉是刻意的、不是誤操作）
4. 更新文件：記錄升級日期、版本號、升級過程中遇到的問題

時程與管理層溝通

向管理層說明時的關鍵框架：資料是不可重建的，升級策略是「在旁邊建一個新版本的資料庫、驗證它在相同資料和相同負載下行為正確、然後切過去」。多出來的時間買的是「切換那一刻的信心」和「出問題時能快速回退」——兩者對生產服務都是必要的保險。

跨分類引用

• → 升級的共通操作框架：四階段模型的通用說明
• → Stateful 資源保護與依賴表達：multi-AZ、備份、deletion protection 的 IaC 描述
• → 無 SSH 環境的資料庫備份與變更管理：接手環境的資料庫備份策略

本章從 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 取捨）

教學路線：Distributed SQL 與跨雲一致性

CockroachDB 服務頁的教學目標是把 PostgreSQL-like 介面背後的 range sharding、Raft replication、serializable transaction、leaseholder 與 region placement 說清楚。讀者讀完後要能判斷 distributed SQL 何時能取代自管 sharding，何時會把 latency 與 retry 壓力推回應用層。

定位：Spanner 的開源 / 跨雲替代

CockroachDB 跟 Spanner 解決同一個問題（跨 region 強一致 SQL）、但定位不同：

• Spanner：GCP managed service、用 TrueTime hardware
• CockroachDB：開源（雙授權）、可自管 + Cockroach Cloud、跨 AWS / GCP / Azure / on-prem、用 HLC + Raft

選 CockroachDB 的核心訴求：需要跨 region 強一致 SQL + 想避免雲商 lock-in、想自管或跨雲部署。

詳見 1.11 全球分散式 OLTP 的 CockroachDB 段。

容量特性

節點即容量單位：

• 跟 Spanner 同樣設計、節點數量決定容量
• 每節點承擔 query + storage + replication
• 線性擴展（理論）、實際依 query pattern

跨 region 配置：

• multi-region survival goal（zone-level / region-level）
• 跨 region quorum 必要、決定 latency
• 跟 Spanner 同樣的物理限制（跨洲 100ms+）

Replication：

• Raft consensus per range
• 預設 3-replica
• 可配置每個 region 不同 replica count（Survival Goals）

適用場景

1. 需要跨 region 強一致 SQL + 跨雲：

• multi-region active-active write
• GCP-only（Spanner）或 AWS-only（Aurora DSQL）和部署策略不合
• 對應 1.11 全球分散式 OLTP 的選型決策

2. PostgreSQL wire protocol 相容路徑：

• 既有 PostgreSQL 應用想升級到分散式
• 應用層改動小（保留 PostgreSQL driver / ORM）
• 注意：PostgreSQL 相容要以實際 query、extension 與 migration test 驗證

3. 自管 on-prem / hybrid：

• 金融 / 受監管產業需要 on-prem
• Spanner / Aurora DSQL 以 cloud service 為主
• CockroachDB 可自管

4. 想避免單一 vendor 全球分散式 lock-in：

• 開源 + 跨雲、可遷移性高
• 但企業版功能要付費（CockroachDB Cloud 或 Enterprise license）

不適用場景

1. single-region OLTP 夠用：

• 90% 場景 PostgreSQL / Aurora 已夠
• CockroachDB 有分散式 overhead（每個寫經 Raft）
• 替代：PostgreSQL、Aurora、MySQL

2. 極端高吞吐 single-query：

• CockroachDB 寫入有 Raft 開銷、單機吞吐 < PostgreSQL
• 整體吞吐靠 scale-out 達成、單一 query latency 較高

3. 跨洲低延遲（< 50ms）：

• 跟 Spanner 同樣物理限制
• 跨洲 quorum 100ms+ 是物理成本

4. 預算極敏感的小 workload：

• CockroachDB 至少 3 個節點（Raft quorum）
• 跟 single-instance PostgreSQL 比較貴

5. 需要 PostgreSQL 進階特性：

• 部分 PostgreSQL extension 或行為需要替代方案
• partial index、exclusion constraint 等可能缺

跟其他 vendor 的取捨

vs Spanner（GCP）：

• CockroachDB：開源、跨雲、可自管
• Spanner：GCP-only、TrueTime hardware、Google 規模驗證
• 選 CockroachDB：跨雲 / on-prem 需求
• 選 Spanner：GCP 生態 + managed operation + Google 規模驗證的成熟度

vs Aurora DSQL（AWS 2024）：

• CockroachDB：跨雲、生產驗證較久
• Aurora DSQL：AWS-only、serverless、新（2024）
• 選 CockroachDB：跨雲、想避免 AWS lock-in
• 選 Aurora DSQL：AWS 生態 + 已用 PostgreSQL + serverless 訴求

vs TiDB：

• CockroachDB：PostgreSQL wire、英語 / 歐美生態深
• TiDB：MySQL wire、亞洲生態深、HTAP（OLTP + OLAP 同庫）
• 選 CockroachDB：PostgreSQL 應用、跨雲
• 選 TiDB：MySQL 應用、需要 OLAP 整合、亞洲市場

vs PostgreSQL（傳統）：

• CockroachDB：分散式、跨 region 強一致
• PostgreSQL：single-primary、跨 region 是 async replication
• 選 CockroachDB：需要跨 region 強一致
• 選 PostgreSQL：single-region 夠用（90% 場景）

vs Aurora（single-region scaling）：

• CockroachDB：multi-region 強一致
• Aurora：single-region scaling、跨 region 是 async Global Database
• 選 CockroachDB：需要 multi-region write
• 選 Aurora：single-region scaling + AWS 生態

vs MySQL + Vitess（self-managed distributed MySQL）：

• CockroachDB：PostgreSQL wire、transparent sharding（range-based）、跨 region 強一致內建
• MySQL + Vitess：MySQL wire、application 層配 keyspace + shard key、跨 region 靠 application + async replication
• 選 CockroachDB：PostgreSQL 應用 + transparent multi-region + 想避開 Vitess operation burden
• 選 MySQL + Vitess：MySQL 應用 + 有 DBA 養 Vitess + 已是 YouTube / Slack 規模

容量規劃要點

1. Node count + zone / region 配置：

• 至少 3 個節點（Raft quorum）
• multi-region 通常 9+ 節點（3 region × 3 replica）
• Survival Goals 配置決定每 region 復原能力

2. Range（CockroachDB 的 partition）：

• 跟 DynamoDB partition、Spanner split 同類
• CockroachDB 自動 split 大 range
• application 主要管理 query locality、transaction retry 與 region placement

3. Locality 配置：

• 跟 Spanner 一樣可以指定 voting region
• 寫入 locality 影響跨 region latency

4. Backup / restore：

• CockroachDB 原生 backup 支援 cluster-level snapshot
• 增量 backup 支援
• 注意：incremental backup chain 可能很長、定期 full backup

5. Self-managed vs Cockroach Cloud：

• Self-managed：需要 ops team、可跨雲 / on-prem
• Cockroach Cloud：managed、跨 cloud（AWS / GCP / Azure）、可考慮 serverless tier

Deep article（已完成）

本批 deep article 覆蓋 CockroachDB 從 consensus 機制、multi-region 配置到 managed 形態選型的核心 production 議題：

DB4 cross-vendor entry：先看 aurora-dsql-spanner-decision-tree 識別 driver path、再進個別 vendor 深度。

multi-region-table-config 與 locality-aware-schema 切分：前者主寫「三種 table locality 怎麼選 + 選錯重配代價」、後者主寫「schema 怎麼配合 locality 設計（合規 boundary、跨州業務邏輯、Outposts 拓樸）」、兩者互補、survival goal 機制以 survival-goals 為 SSoT。

後續擴充（仍待補）

• PostgreSQL 相容性 audit（partial index / extension / SQL 行為 gap 清單）
• Backup / restore 與 PITR 操作（incremental chain 管理、restore 演練）
• Changefeed / CDC 配置（CockroachDB 原生 CDC 到 Kafka / sink）

「從 PostgreSQL 遷到 CockroachDB（playbook）」已由 PostgreSQL → CockroachDB migration 涵蓋、不再列為待補。

Anti-recommendation 與升級路由

CockroachDB 的 PostgreSQL-like 介面會降低導入門檻，但 distributed SQL 的成本會出現在 transaction retry、range lease、multi-region latency 與操作拓樸。這一段先說何時維持 PostgreSQL / Aurora，再說何時升級 CockroachDB、Cockroach Cloud、Spanner、Aurora DSQL 或 Vitess。

CockroachDB 的簡單路徑是先證明 distributed SQL 的價值大於 retry 與 latency 成本。若 workload 仍是 single-region OLTP，PostgreSQL / Aurora 通常提供更低成本；若跨 region 寫入與一致性是產品承諾，CockroachDB 才成為主要候選。

Transaction retry 的升級路徑要進入 application contract。Serializable default 能保護一致性，但 retry 會把 idempotency、timeout、user-visible latency 與 workflow compensation 帶回應用層；這些條件要在 migration playbook 前先盤點。

已知 limitation 與後續路由

CockroachDB overview 目前完成 distributed SQL 判斷。下一輪 deep article / playbook 應補 HLC + Raft、range / leaseholder、multi-region table locality、transaction retry pattern、PostgreSQL compatibility audit、Cockroach Cloud operation 與 PostgreSQL → CockroachDB migration。

案例對照

CockroachDB 在 09 案例庫已有三條直接 case 軸線（OLTP 寫入擴展、polyglot 補位、合規邊界），另外兩條對比參考軸線（Spanner 設計理念、受監管金融）一併保留。

Direct case（CockroachDB 為主角）

對比參考案例

CockroachDB direct case 的讀法是「寫入擴展（DoorDash）→ polyglot 補位（Netflix）→ 合規邊界（Hard Rock Digital）」三條軸線；對比案例則提醒讀者：Spanner 提供 global consistency 的成熟對照，受監管金融類案例提醒部署位置、合規邊界與自管能力常和一致性需求同時決定 vendor。

反向 sibling 路由

CockroachDB 的反向 sibling 路由用來把 PostgreSQL 相容性和 distributed SQL 責任拆開。若讀者從 PostgreSQL 章節過來，先讀 PostgreSQL → CockroachDB migration；若只是要 managed SQL 與 storage autoscale，先回 Aurora vendor；若要 Google Cloud 原生 external consistency 與 fully managed control plane，再對照 Spanner vendor。

這條路由的判準是「應用是否能承擔 distributed transaction 的語意差異」。SQL dialect 相近只降低 migration entry cost，真正的交付風險在 transaction retry、hot range、survival goal、backup restore 與 locality design。

常見陷阱

• single-region 用 CockroachDB：浪費分散式開銷、PostgreSQL 便宜很多
• 跨洲 active-active 期待低延遲：物理限制、跨洲 quorum 100ms+
• PostgreSQL extension 假設：部分 extension 或 SQL 行為需要替代方案，應用要驗證
• 不規劃 Survival Goals：default 配置可能不符合 RTO / RPO 需求
• backup chain 過長：incremental 不 full、recovery time 變長

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Spanner vendor、Aurora vendor、PostgreSQL vendor
• 上游：1.11 全球分散式 OLTP — 完整選型對比
• 跨模組：9.6 容量規劃模型、9.12 SLO 與 Performance Budget
• Last reviewed：2026-05-22（PostgreSQL compatibility / survival goal / managed offering 屬時間敏感 claim）
• 官方：CockroachDB Documentation

本章聚焦在 資料層（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

教學路線：Access pattern 與 partition capacity

DynamoDB 服務頁的教學目標是把 access pattern 轉成 partition key、sort key、GSI、capacity mode 與 global tables 的設計判斷。讀者讀完後要能從查詢路徑反推資料模型，並估算 hot partition、成本與 consistency trade-off。

定位：partition-based KV scale

DynamoDB 的核心設計是「partition 透明、capacity 抽象化」。不像 MongoDB 要主動 shard、不像 Cassandra 要管 ring topology、不像 PostgreSQL 要選 instance type — DynamoDB 把所有底層 scaling 隱藏在 RCU / WCU 抽象層後。

容量單位：

• 1 RCU（Read Capacity Unit）= 1 strongly consistent read of 4KB / sec、2 eventually consistent reads
• 1 WCU（Write Capacity Unit）= 1 write of 1KB / sec
• 每個 partition 上限：3000 RCU / 1000 WCU
• 總容量 = partition 數量 × 每 partition 上限（partition 數量透明、vendor 自動管理）

延遲特性：

• single-digit millisecond p99 latency（read / write）
• 同 region 跨 AZ replication 內建、預設 eventually consistent reads
• strongly consistent reads 依 region 內 quorum 成立，跨 region 讀寫要看 Global Tables 語意

詳見 1.10 KV / Document DB 容量規劃 跟 9.4 Saturation Discovery 的 partition 設計章節。

適用場景

按公開 case 提煉的典型適用場景：

1. KV / single-table design 為主的查詢：

• 用 partition key + sort key 設計、單筆 / 範圍查詢
• 查詢路徑固定，JOIN / ad-hoc query 需求低
• 對應案例：9.C5 Amazon Ads — 9000 萬 reads/sec + 500 萬 writes/sec、99.999% 可用

2. 可預測 sub-10ms p99 latency 需求：

• 遊戲後端（玩家狀態、戰績）
• 內容平台 metadata（watchlist、播放進度）
• 對應案例：9.C19 Capcom（billions of requests / single-digit ms）、9.C27 Disney+（每日數十億 actions）

3. 流量 spiky 或 surge 場景：

• on-demand capacity 自動吸收 burst
• 不需 connection pool（HTTP API、無 stateful connection）
• 對應案例：9.C18 Zoom（COVID 1000 萬 → 3 億 DAU）、9.C15 Tixcraft（IOPS 20 → 135K、售票搶購）、9.C29 Lemino（RDB connection limit → 改 DynamoDB）

4. 大規模通知 / 訊息系統：

• TTL 自動清理過期 records
• partition key 用 user_id / message_id 天然均勻
• 對應案例：9.C26 PayPay（行動支付每日 3 億訊息）

5. 5 個 9 可用性 B2B SaaS：

• multi-region Global Tables active-active
• 對應案例：9.C24 Genesys（99.999% 跨 15 region）

6. 高吞吐 budget 敏感：

• on-demand 適合突發、provisioned 適合 sustained
• 對應案例：9.C20 Zomato — TiDB over-provision 壓力轉成 DynamoDB on-demand pay-per-use，成本下降 50%

不適用場景

1. 複雜 ad-hoc query / JOIN：

• DynamoDB query 以 partition key + sort key 為主，JOIN-heavy workload 交給 SQL 系統
• PartiQL 提供 SQL-like 語法但底層還是 KV、複雜 query 會 scan 全表
• 替代：用 Aurora / PostgreSQL / Spanner

2. 強一致 multi-row transaction：

• DynamoDB Transaction 支援 25 個 item 的 ACID
• 超過 25 個 item 或跨 region 的 transaction 要改用 workflow / SQL / distributed SQL 設計
• 替代：Spanner / Aurora DSQL / CockroachDB

3. 跨雲需求：

• DynamoDB only on AWS、vendor lock-in
• 替代：Cosmos DB（Azure global NoSQL）、自管 ScyllaDB

4. 大物件 / 文件儲存：

• 單一 item 最大 400KB
• 大物件用 S3、metadata 用 DynamoDB

5. 預算極度敏感 + 流量穩定：

• 流量高度 predictable 的 sustained workload，自管 PostgreSQL / MySQL 可能更便宜
• DynamoDB 的 managed 跟 elastic 是有溢價的

跟其他 vendor 的取捨

vs MongoDB（自管或 Atlas）：

• DynamoDB：managed、partition 透明、application 主要管理 partition key，有 5 個 9 SLA
• MongoDB：彈性高、可自管、aggregation pipeline 強、跨雲可用
• 選 DynamoDB：AWS-only、想轉移 operation、partition 設計簡單可預測
• 選 MongoDB：跨雲、複雜 query、ad-hoc analysis

vs Aurora（同 AWS）：

• DynamoDB：KV、partition 擴展、無 connection pool 限制
• Aurora：SQL（PostgreSQL / MySQL）、有 transaction、ad-hoc query
• 詳見 1.10 KV / Document DB 容量規劃 跟 9.C29 Lemino case — connection limit 是 RDB vs DynamoDB 的關鍵差異

vs Redis（含 ElastiCache）作為 KV 替代：

• DynamoDB：持久化、單 item 持久查得到、有 TTL 但物件不會自動失蹤
• Redis：純記憶體、預設不持久（MemoryDB 例外）、快但易失
• 選 DynamoDB：data 是 source of truth，需要持久保存
• 選 Redis：data 是 cache、丟了能 recompute

vs Cosmos DB（cross-cloud）：

• DynamoDB：AWS-only、KV 為主、無 multi-model
• Cosmos DB：Azure-only、multi-model（SQL / Mongo / Cassandra / Gremlin / Table）、5 個 consistency levels
• 選 DynamoDB：AWS 生態、KV 純粹
• 選 Cosmos DB：Azure 生態、需要 multi-model、需要 multi-region active-active write

vs Cassandra / ScyllaDB（self-managed）：

• DynamoDB：managed、5 個 9 SLA、無 ops 負擔
• Cassandra / ScyllaDB：可自管、更深 tuning、跨雲可用
• 選 DynamoDB：團隊想把 DBA / SRE 操作責任交給 AWS
• 選 Cassandra / ScyllaDB：有 DBA、想 lock-in 風險低、需要極限 throughput tuning

vs PostgreSQL（SQL baseline）：

• 詳見 PostgreSQL vendor page 取捨段、跟 1.10 KV / Document DB 容量規劃 的 connection model 對比
• 摘要：DynamoDB 是 access pattern 固定 + 需要避免 connection-bound 的選項；ad-hoc query / 複雜 transaction 留 PostgreSQL

容量規劃要點

從 09 案例庫提煉的 DynamoDB 容量規劃實踐：

1. partition key 設計是命脈：

• partition key 不均 → hot partition → 名義容量達不到
• composite key（event_id + user_id_hash）強制分散
• 對應 9.C5 Amazon Ads 9000 萬 RPS 靠 partition 均勻、9.C15 Tixcraft 用 composite key 分散售票流量
• 詳見 Hot Partition 卡片

2. on-demand vs provisioned 選型：

• 流量 peak/avg > 5x → on-demand
• sustained predictable → provisioned + auto-scaling
• 知名大事件（Black Friday）→ provisioned baseline + scheduled scale-up
• 對應 9.C20 Zomato — on-demand 解放 over-provisioning

3. Global Tables（multi-region active-active）：

• 每個 region 都能寫、conflict resolution 用 LWW
• 容量在每個 region 獨立配置，全球總和要按 region 分別估算
• 對應 9.C24 Genesys — 15 region 達 5 個 9 可用

4. DAX（DynamoDB Accelerator）：

• DynamoDB 前置 in-memory cache
• 從 single-digit ms 降到 microsecond
• 適合超高 read 重複的 workload（同樣 key 大量讀）
• 對應 9.C29 Lemino 用 DAX 加速

5. Streams + Lambda：

• DynamoDB 寫入 → Stream event → Lambda 處理
• 適合 CDC、event-driven 工作流
• 對應 9.C15 Tixcraft 用 Stream 把 DynamoDB 當 durable queue 給 legacy server 消費

Anti-recommendation 與升級路由

DynamoDB 的 managed elasticity 會讓團隊忽略 access pattern 的前置成本。這一段先說何時維持單純 table / index，再說何時升級到 Global Tables、DAX、Streams、或改回 SQL / document DB。

DynamoDB 的簡單路徑是先把每個 query path 寫成契約。table、partition key、sort key、GSI 與 TTL 都應從 access pattern 反推；如果需求仍在探索期，PostgreSQL 或 MongoDB 可能提供更低的變更成本。

Global Tables 的升級路徑要先處理 conflict 與讀寫語意。它提供 multi-region availability，但 LWW conflict resolution、region-local capacity 與跨 region reconciliation 仍要由 application contract 承擔。

Deep article（已完成）

本 vendor 現有 deep article 覆蓋 DynamoDB 從 access pattern 反推到寫一致性、讀加速、事件驅動與資料生命週期的核心 production 議題：

Migration playbook：從 RDS / MongoDB 遷移到 DynamoDB（Type E paradigm shift、access-pattern-first 重建模 + 混合架構 + Zomato cost crossover）。

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

後續擴充（仍待補）

• DynamoDB Streams 進階 lab：Kinesis Data Streams for DynamoDB 多消費者 fan-out 與長 retention 重播（Lambda vs Kinesis 比較層已在 streams-lambda-event-driven 覆蓋、此處指可操作的深度 hands-on lab）
• Export to S3 / point-in-time export 做離線分析
• DynamoDB → SQL / search / analytics split（遷出方向 playbook）
• Backup / PITR restore drill（hands-on lab）

案例對照

DynamoDB case 的讀法是先分類 access pattern，再看容量模式。Amazon Ads / Capcom / Disney+ 說明高吞吐 KV，Zoom / Tixcraft / Lemino 說明 surge 與 connection-free scaling，Zomato 則說明 on-demand cost model 如何改變 over-provision 壓力。

反向 sibling 路由

DynamoDB 的反向 sibling 路由用來把 RDBMS 退場條件寫清楚。若讀者從 PostgreSQL / MySQL 的 connection bottleneck 過來，先讀 Lemino case 與 1.10 KV / Document DB 容量規劃；若需求仍需要 ad hoc SQL、join 與 transaction report，回 Aurora vendor 或 PostgreSQL vendor；若需求是 global document model 與 Azure 生態，再對照 Cosmos DB vendor。

這條路由的判準是 access pattern 是否穩定到可以先設計 key。DynamoDB 擅長固定 lookup、寫入尖峰、connection-free scaling 與 TTL 類生命週期；資料探索、報表 join 與多條件查詢仍應留在 SQL / search / analytics service。

常見陷阱

從公開 incident 跟 case 提煉：

• partition key 集中：event_id 一個演唱會、bot user 大量同 user_id 寫入 → 用 composite key 或 write sharding
• 單一 partition 達 3000 RCU / 1000 WCU 上限：throttling event 出現、即使整體 capacity 還沒滿
• Scan 全表：scan 會吃光 capacity，正式讀取路徑應回到 query / index design
• DAX 跟 DynamoDB 直連混用：寫入直連 DynamoDB、讀經過 DAX → cache 一致性問題
• Global Tables conflict：跨 region 同 key 同時被寫、LWW 可能丟失寫入、要設計 idempotency

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Aurora vendor page（SQL 對比）
• 上游：1.10 KV / Document DB 容量規劃
• 下游：1.12 大規模 DB 遷移實戰（從 RDBMS 遷 DynamoDB 案例）
• 跨模組：9.4 Saturation Discovery、9.6 容量規劃模型
• Last reviewed：2026-05-22（capacity mode / Global Tables / best practices 屬時間敏感 claim）
• 官方：Amazon DynamoDB Customers、DynamoDB 設計 best practices

本章跟 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。

教學路線：單檔正式狀態與 local-first

SQLite 服務頁的教學目標是把單機、單檔案、edge、desktop、test fixture 的正式狀態責任說清楚。讀者讀完後要能判斷 SQLite 何時是 production state，何時要轉向 server database、edge KV 或分散式 SQLite 變體。

定位：單檔案 embedded + 新興分散式 SQLite 生態

SQLite 跟 PostgreSQL / MySQL 承擔不同層級的資料責任：

• 以 function-call API 使用，省掉 server process
• 單一檔案（含 schema、data、index、metadata）
• 無 user / role / connection 概念
• 同 process 同時 read / write 受 file lock 限制

傳統定位：test fixture、CLI tool data store、mobile app（iOS / Android 內建）、edge device。

新興定位：edge serverless（Cloudflare D1）、distributed SQLite（Turso、rqlite）、replicated SQLite（Litestream）。

容量特性

單檔案上限：

• DB 最大 281 TB（理論）
• 實務上單表 > 100 GB 開始有 vacuum / index 問題

並發寫：

• WAL mode：可同時多 reader + 1 writer
• 寫入仍由 single writer boundary 控制
• 寫吞吐受 disk fsync 限制（通常 < 1K WPS）

並發讀：

• WAL mode 多 reader 可同時跑
• read-only workload 可以撐高吞吐

Cross-process / cross-instance：

• 多個 process / instance 同時寫同一檔案會破壞 single writer boundary
• 需要分散時用 Litestream（replication）或 Turso（distributed）

適用場景

1. Test fixture / CI 用 DB：

• 整合測試需要的 fixed DB
• 比 spin up PostgreSQL container 快
• 對應 1.4 Repository Adapter 的 contract test 模式

2. CLI tool / desktop app 內建 store：

• Chrome / Firefox（cookies、history、bookmark）、Fossil SCM、iOS app
• 省掉 server、單檔案攜帶

3. Mobile app（iOS / Android）：

• iOS Core Data 底層用 SQLite
• Android 自帶 SQLite API
• offline-first app 的標準

4. Single-instance backend（特殊場景）：

• 流量小 + HA 由備份 / restore / redeploy 流程承擔
• 例：Sidekick / 個人 SaaS / family-scale app
• 配合 Litestream 做 backup / DR

5. Edge / serverless（新興）：

• Cloudflare D1：edge SQLite、跟 Workers 整合
• Turso：distributed SQLite、跨 region replication
• 跟傳統 SQLite 不同等級、是 新的 product

6. Embedded device / IoT：

• 沒網路或要降低 server 依賴
• SQLite 內建、無 external dependency

不適用場景

1. 多 instance / 多 region web service：

• SQLite 的單檔模型以單 instance writer 為主要邊界
• 替代：PostgreSQL、Aurora、Spanner、CockroachDB

2. 高寫入吞吐（> 1K WPS）：

• fsync 限制
• 替代：任何 server-based RDBMS

3. Multi-user 權限管理：

• 無 user / role 概念
• 替代：PostgreSQL / MySQL

4. 跨機器 transaction：

• SQLite 是 single-machine
• 替代：分散式 SQL

5. 大規模 production OLTP：

• 大規模 production OLTP 需要 server database 的 HA、replica、權限與操作邊界
• 替代：MySQL / PostgreSQL / Aurora

跟其他 vendor 的取捨

vs PostgreSQL（作為 test DB）：

• SQLite：快 spin up、SQL dialect 接近但有差異
• PostgreSQL：跟 production 一致、發現的 bug 真實
• 選 SQLite：speed of iteration、簡單 query
• 選 PostgreSQL：catch production-like bug、PostgreSQL-specific 特性測試

vs Cloudflare D1：

• SQLite（local）：單機、自管
• D1：edge serverless、跟 Workers 整合
• 選 SQLite：embedded / CLI / app 場景
• 選 D1：edge web service、跟 Cloudflare 生態整合

vs Turso（distributed SQLite）：

• SQLite：單機、單檔案
• Turso：distributed、跨 region replication、SQLite-compatible
• 選 SQLite：simple use case
• 選 Turso：需要 SQLite simplicity + 全球分散

vs Litestream（replicated SQLite）：

• SQLite：單檔案
• Litestream：把 SQLite 變成 streaming replicated 到 S3
• 選 Litestream：想要 SQLite simplicity + DR

vs Firebase / Firestore（mobile app）：

• SQLite：embedded、offline-first、無 sync
• Firestore：realtime、自動 sync、雲端 store
• 選 SQLite：offline-first、單機
• 選 Firestore：multi-device sync、realtime

容量規劃要點

1. WAL mode 是 production baseline：

• default journal mode 是 rollback journal（每寫都 lock）
• WAL（Write-Ahead Log）讓多 reader 可同時跑
• PRAGMA journal_mode = WAL

2. fsync 配置：

• PRAGMA synchronous = FULL（durable、慢）
• PRAGMA synchronous = NORMAL（faster、少數情況可能掉資料）
• PRAGMA synchronous = OFF（最快、不安全）

3. mmap 加速 read：

• PRAGMA mmap_size = 268435456（256 MB）
• 把 DB 部分內容 mmap 進 RAM、加速 read

4. Cache size：

• PRAGMA cache_size = -64000（64 MB cache）
• 大 cache 對 read-heavy workload 有幫助

5. Auto-vacuum：

• 預設 off、delete 後檔案不縮小
• PRAGMA auto_vacuum = INCREMENTAL + 定期 PRAGMA incremental_vacuum

章節群結構

SQLite 章節群的責任是把單檔正式狀態、embedded process、writer boundary、backup / restore、test fixture、local-first 與 edge SQLite 變體拆成可教學路線。完整結構見 SQLite Teaching Structure；下表列出目前已建立的 deep article、hands-on 與 migration route。

章節群的讀法是先讀 file lifecycle，再按壓力選 deep article。若問題是 write contention，讀 WAL locking；若問題是測試，讀 test fixture；若問題是 edge / serverless，讀 D1 / Turso comparison；若問題是服務長大，讀 SQLite to PostgreSQL migration。

Anti-recommendation 與升級路由

SQLite 的低操作成本容易讓團隊忽略它的 writer boundary。這一段先說何時維持 SQLite，再說何時升級到 server SQL、edge SQLite 變體或 managed KV。

SQLite 的簡單路徑是讓檔案生命週期成為正式操作流程。只要單一 writer、備份、restore、migration 與 file ownership 都能被 runbook 控制，SQLite 可以是正式狀態，而非臨時 cache。

升級到 server SQL 的訊號是操作責任超過檔案邊界。當團隊需要資料庫帳號、權限分層、read replica、線上 schema migration、集中 audit 或跨 instance failover 時，PostgreSQL / MySQL / Aurora 會比繼續包裝 SQLite 更清楚。

已知 limitation 與後續路由

SQLite overview 目前已完成服務判斷與章節群正文路由。File lifecycle、WAL locking、PRAGMA tuning、schema migration、test fixture、local-first sync、edge product 差異、observability、hands-on 與 migration route 都已有對應正文；下一輪審查可集中在案例補強、引用精度與跨章重複整理。

案例對照

SQLite 不在 09 case 庫的「規模化 vendor」類別、但作為 embedded 跟 test 廣泛使用：

• iOS Core Data：所有 iOS app 的 default DB
• Chrome / Firefox：cookie、history、bookmark
• Fossil SCM：repository metadata 與 application-file use case
• Cloudflare D1：edge serverless（新興 production 場景）
• Turso：distributed SQLite（新興 production 場景）

常見陷阱

• default journal mode 不改 WAL：read 跟 write 互相 block、performance 差
• 多 process / instance 同時寫同檔：corruption
• delete 後檔案沒縮小：忘了 vacuum
• synchronous=OFF 給 production：power loss 可能掉資料
• SQLite 跟 PostgreSQL 行為差異測試不足：SQLite test 過、PostgreSQL production 出 bug（特別是 date / time、NULL 處理、type coercion）

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：PostgreSQL vendor / MySQL vendor（production server-based RDBMS）
• 上游：1.4 Repository Adapter（test fixture 模式）
• 結構：SQLite Teaching Structure（完整章節群與寫作順序）
• 操作：SQLite Hands-on（local file、backup restore、WAL busy reproduction、migration fixture、D1 / Turso preview）
• 深入：SQLite file lifecycle 與 backup boundary（WAL、backup、restore、file ownership）
• 官方：SQLite Documentation、Litestream、Turso、Cloudflare D1

教學路線：Managed SQL 與平台責任轉移

Aurora 服務頁的教學目標是把 PostgreSQL / MySQL 語意延伸到 AWS managed storage / compute 分離模型。讀者讀完後要能判斷哪些責任交給 Aurora，哪些責任仍留在 schema、query、maintenance window、region 與成本治理。

定位：storage / compute 分離的 SQL

Aurora 跟傳統 PostgreSQL / MySQL primary 最大差異是 storage layer 重寫。傳統 SQL primary 把 storage 跟 CPU / RAM 綁定、storage 擴容要換 instance、replication lag 受 compute 影響。Aurora 把 storage 拉到分散式 log service、跨 6 個 storage node（3 AZ × 2 node）、storage 跟 compute 獨立擴。

容量特性：

• 單一 cluster 最高 storage：128 TB
• 最多 15 個 read replica（單 region 內）
• read replica replication lag：10-30ms（vs 傳統 PostgreSQL 跨 AZ 可能秒級）
• 跨 AZ failover：< 30 秒（promote read replica）
• Aurora Global Database 跨 region replication：< 1 秒典型 lag

為什麼這個分離很重要：

• 傳統 PostgreSQL primary 上的 read replica 都靠 logical replication、會跟著 primary write load 走慢
• Aurora storage 直接複製到 6 個 storage node、read replica 從 storage 讀、不靠 primary
• → read replica 大幅減少 lag、可以撐更多 OLTP read traffic
• 對應 9.C23 Netflix +75% 效能改善的關鍵原因

適用場景

按公開 case 提煉的典型適用場景：

1. 既有 PostgreSQL / MySQL 應用想要 managed：

• wire protocol 相容，應用層改動通常集中在連線、參數與操作流程
• ORM / driver / SQL 多數可保留，但 migration plan 仍要驗證 dialect 與 extension
• 對應案例：9.C23 Netflix — 多套 RDBMS（PostgreSQL、MySQL、Oracle）統一到 Aurora、+75% 效能、-28% 成本

2. 金融交易 / 體育博彩 OLTP：

• 強 ACID transaction
• 多 read replica 處理 query traffic、不影響寫
• 對應案例：9.C4 DraftKings — 每分鐘 100 萬 ops、200 個獨立資料庫、Super Bowl 流量 +50% 無影響

3. 受監管產業跨市場部署：

• 每個市場一個獨立 cluster、合規分割
• 對應案例：9.C14 Standard Chartered — 7 個受監管市場、各自獨立 Aurora、總吞吐 4000 TPS、10x 提升

4. 高峰流量 + 多 read replica 擴容：

• read 高峰用 read replica 接、write 走 primary
• 對應案例：9.C28 FanDuel — 5-10x Super Bowl 峰值、直播 + 投注雙工作負載

5. Aurora Serverless v2 適用場景：

• 流量 unpredictable + sustained workload
• 自動 scale CPU / RAM，降低 instance class 管理負擔
• 適合：dev / test 環境、流量稀疏的多 tenant SaaS

6. Aurora Global Database：

• 跨 region async replication（< 1 秒 typical）
• DR + 跨地理 read（write 在 primary region、read 可從 secondary region）
• Global Database 是跨 region DR / read route，multi-region active-active write 要改看 Aurora DSQL

不適用場景

1. 跨雲需求：

• Aurora 是 AWS-only、wire protocol 相容但 storage 是 AWS 專屬
• 替代：自管 PostgreSQL / MySQL on Kubernetes

2. 需要最新 upstream PostgreSQL / MySQL 特性：

• Aurora 通常落後 upstream 1-2 個 major version
• 替代：RDS PostgreSQL（更接近 upstream）

3. 極端寫入吞吐：

• 單一 primary 寫入受 storage 設計限制（雖然比 PostgreSQL 快）

• 100K WPS 級別、考慮 sharding、CockroachDB、或 DynamoDB

• 對應 9.C29 Lemino — RDB connection limit 是 bottleneck、改 DynamoDB

4. 全球 multi-region active-active write：

• Aurora Global Database 是 async、有 lag，write 仍集中在 primary region
• 替代：Aurora DSQL（2024 推出）、Spanner、Cosmos DB

5. 預算敏感的小 workload：

• Aurora 比 self-managed PostgreSQL 貴 20-30%
• 小流量場景、自管 PostgreSQL on EC2 或 RDS 更便宜

跟其他 vendor 的取捨

vs RDS PostgreSQL / MySQL（同 AWS）：

• Aurora：storage / compute 分離、更多 read replica、更快 failover、跨 AZ 自動 replication
• RDS：純 managed PostgreSQL / MySQL、不重寫 storage、更接近 upstream
• 選 Aurora：需要 scale read replica 或 cross-AZ failover < 30 秒
• 選 RDS：需要最新 upstream 特性、預算更敏感

vs 自管 PostgreSQL / MySQL：

• Aurora：託管、自動 backup / failover，降低日常 database operation
• 自管：彈性高、可自己 tuning、跨雲可用、預算可控
• 選 Aurora：團隊想把 DBA / SRE 操作責任轉交 AWS、AWS 生態深
• 選自管：跨雲需求、需要客製化、預算極敏感

vs CockroachDB：

• Aurora：single-region scaling（一個 region 內擴）、AWS-only
• CockroachDB：multi-region 強一致、跨雲可用、PostgreSQL wire protocol
• 選 Aurora：AWS-only + single-region OLTP
• 選 CockroachDB：需要 multi-region 強一致 + 跨雲 / on-prem 彈性

vs Aurora DSQL（2024-12 preview / 2025-05 GA）：

• Aurora：single-region scaling、傳統 OLTP
• Aurora DSQL：multi-region active-active write、serverless、強一致
• 選 Aurora：流量集中在一個 region
• 選 Aurora DSQL：需要全球 active-active
• 從 PG / Aurora PG 遷 DSQL 的完整 playbook 見 PG → Aurora DSQL Migration

vs DynamoDB：

• 詳見 DynamoDB vendor page 對比段。Aurora 是 SQL、DynamoDB 是 KV、適用場景不同。

vs Azure SQL Hyperscale：

• 設計理念類似（storage / compute 分離）
• Aurora 在 AWS、Hyperscale 在 Azure
• 對應案例：9.C32 Clearent — Azure 生態的同類設計、5 億 payment txn / 年

容量規劃要點

從 09 案例庫提煉的 Aurora 容量規劃實踐：

1. read replica 是擴 read traffic 的主要工具：

• 最多 15 個 read replica、replication lag 10-30ms
• read replica autoscaler 按 CPU / connection 自動加減
• 對應 9.C4 DraftKings 用多個 read replica 處理「比賽期間用戶查 balance」流量

2. 200 個獨立 cluster 模式：

• Aurora 的實務設計通常用多個 bounded cluster 控制 blast radius
• 按業務切多個小 cluster（9.C4 DraftKings 200 個）、降低 blast radius
• 對應 microservice 私有 store（9.C23 Netflix 同樣思維）

3. Aurora I/O-Optimized：

• 2023-05 推出的 storage 配置
• 適合 I/O-heavy workload（write 多、scan 多）
• 比 standard storage 貴、但少 I/O 收費
• 對應 9.C4 DraftKings 用 I/O-Optimized 加速

4. Aurora Serverless v2：

• ACU（Aurora Capacity Unit）為單位、自動 scale 0.5-128 ACU
• 適合 dev / test、稀疏 workload、unpredictable burst
• 不適合：sustained predictable high workload（provisioned 便宜）

5. Cross-region Global Database：

• < 1 秒 typical replication lag、但是 async
• secondary region 可 read，write 仍回 primary region
• DR 切換通常 1-2 分鐘
• 對應 9.C14 Standard Chartered — 跨市場各自獨立 Aurora，合規邊界優先於 Global Database

6. Connection pool 仍是隱性限制：

• Aurora 跟傳統 PostgreSQL 一樣有 connection pool 上限
• 應用層 + Aurora 之間建議用 RDS Proxy 做 pool 共享
• 對應 9.C29 Lemino — RDB connection limit 是 surge 場景的 bottleneck；Lemino 案例發生在 RDS，但 connection-bound 機制同樣適用 Aurora

Deep article（已完成）

本 vendor 現有 deep article 覆蓋 Aurora 從 storage architecture、fleet 治理到容量彈性、連線管理與 distributed 升級門檻的核心 production 議題：

I/O-Optimized vs Standard 成本對比由 Aurora PostgreSQL I/O-Optimized Cost 主寫（storage I/O 成本模型 SSoT），本 vendor 各篇提到 storage 成本時 cross-link 它、不重複展開。

跨 vendor entry：先看 CockroachDB vs Aurora DSQL vs Spanner 決策樹（distributed SQL 三選一 + 撞牆訊號分型），再決定是否進 Aurora overview。

後續擴充（仍待補）

• Aurora Global Database write forwarding 深入
• Babelfish（SQL Server 相容層）適用判斷
• Blue/Green deployment 做 major version 升級
• Backup / PITR restore drill（hands-on lab）

Anti-recommendation 與升級路由

Aurora 的 managed SQL 能把大量操作責任交給 AWS，但它仍保留 single-primary SQL 的資料模型與交易邊界。這一段先說何時維持 RDS / Aurora，再說何時升級 Global Database、Serverless v2、RDS Proxy、Aurora DSQL 或 DynamoDB。

Aurora 的簡單路徑是先把 operation transfer 寫清楚。Backup、minor upgrade、storage growth、failover 與 read replica lag 交給平台後，schema design、query shape、transaction boundary、connection pool 與 cost guardrail 仍由 application / SRE 共同承擔。

Global Database 的升級路徑要先定義讀寫方向。它適合 DR 與跨地理 read，若業務需要多 region 同時寫入並保持強一致，應直接進入 Aurora DSQL、Spanner 或 CockroachDB 的 distributed SQL 比較。

已知 limitation 與後續路由

Aurora overview 目前完成 managed SQL 判斷。下一輪 deep article / playbook 應補 storage architecture、RDS Proxy、Global Database、Serverless v2、I/O-Optimized cost、PostgreSQL / MySQL → Aurora migration 與 Aurora → Aurora DSQL 的分歧路徑。

案例對照

Aurora case 的讀法是看 operation transfer 如何變成容量與成本結果。DraftKings 與 FanDuel 提供 peak OLTP 訊號，Standard Chartered 提供合規分區訊號，Netflix 則提供多套 RDBMS 整併到 managed SQL 的組織與成本訊號。

反向 sibling 路由

Aurora 的反向 sibling 路由用來避免把 managed SQL 誤讀成唯一升級方向。若讀者從 PostgreSQL / MySQL 章節過來，先對照 PostgreSQL → Aurora 與 MySQL → Aurora；若核心需求是 connection surge，補讀 DynamoDB vendor 與 Lemino case；若核心需求是 multi-region active-active write，轉到 Spanner vendor 或 CockroachDB vendor。

這條路由的判準是先問「保留 SQL + 轉移 operation」是否足夠。答案成立時，Aurora 是 RDS / 自管 MySQL / 自管 PostgreSQL 的 managed endpoint；答案需要改成 global quorum、partition-key access pattern 或 document API 時，Aurora 應退到對照組，而非成為最後選項。

常見陷阱

• 誤以為 Aurora 等於無限擴：寫吞吐仍受 primary 限制，容量曲線和 distributed SQL 不同
• 忽略 read replica：把所有 query 打 primary，會浪費 read replica scaling 能力
• 跨 region 強一致誤解：Global Database 是 async 複製，multi-region active-active 要看 Aurora DSQL / Spanner / CockroachDB
• connection pool 忽略：Aurora 仍是 PostgreSQL / MySQL、connection 上限有效
• 單一巨大 cluster：把所有業務塞進一個 cluster 會放大 blast radius，通常要按業務切

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：DynamoDB vendor page（NoSQL 對比）
• 上游：1.3 Transaction Boundary / 1.11 全球分散式 OLTP
• 下游：1.12 大規模 DB 遷移實戰（從 RDS / 自管遷到 Aurora）
• 跨模組：9.5 瓶頸定位流程、9.6 容量規劃模型
• Last reviewed：2026-05-22（Aurora storage / Serverless / Global Database / I/O-Optimized 屬時間敏感 claim）
• 官方：Amazon Aurora、Aurora storage architecture

服務路徑與狀態責任

這條服務路徑是 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;