本文 不 展開 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 的概念入口

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

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

定位：multi-model + multi-region write

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

5 個 API：

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

5 個 consistency levels（從強到弱）：

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

容量特性：

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

適用場景

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

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

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

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

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

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

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

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

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

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

不適用場景

1. 跨雲需求：

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

2. Linearizable 全球 OLTP：

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

3. 預算極敏感的小 workload：

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

4. 純 OLAP 分析：

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

5. 嚴格 ACID 跨 partition transaction：

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

跟其他 vendor 的取捨

vs DynamoDB（AWS）：

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

vs Spanner（GCP）：

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

vs MongoDB Atlas：

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

vs Cassandra / ScyllaDB：

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

vs Azure SQL Hyperscale：

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

vs PostgreSQL（SQL baseline）：

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

vs Aurora（AWS managed SQL）：

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

vs CockroachDB（cross-cloud distributed SQL）：

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

容量規劃要點

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

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

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

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

3. multi-region 配置：

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

4. Consistency level 影響成本：

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

5. Autoscale provisioned throughput：

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

6. Serverless mode：

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

Deep article（已完成）

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

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

Migration playbook：

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

後續擴充（仍待補）

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

Anti-recommendation 與升級路由

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

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

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

已知 limitation 與後續路由

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

案例對照

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

反向 sibling 路由

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

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

常見陷阱

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

下一步路由

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

本文不是 Cosmos DB overview（請看 Cosmos DB vendor 頁）— 而是 選型決策 + 遷移實作 的深度展開。Case anchor 是 9.C30 Microsoft 365 — Microsoft 自家 dogfood、MongoDB → Cosmos DB MongoDB API 的 planet-scale 分析平台、提供四層 framing 的證據錨點。

問題情境：選型問題不是「兩個 API 哪個快」

典型觸發場景：團隊已用 MongoDB（自管 或 Atlas）、評估遷到 Azure；Cosmos DB 提供 MongoDB API（wire protocol 相容）跟 native SQL API 兩條路；文件講「MongoDB API 是 wire compat、SQL API 是 native」、但這個敘述沒回答真實決策問題。

讀者實際在問：

• 「MongoDB API 我們的 aggregation pipeline 跑得起來嗎」
• 「$lookup 在 Cosmos DB MongoDB API 支援嗎」
• 「change stream 跟 Change Feed 是同一回事嗎」
• 「為什麼有人說 MongoDB API 只是過渡、最終要遷 SQL API」
• 「Microsoft 自己選了 MongoDB API、是不是代表 MongoDB API 才是對的選擇」

這些問題背後的 真實壓力 是 vendor selection：團隊已選 Azure、要決定「留 Atlas 還是進 Cosmos DB、進了 Cosmos DB 用哪個 API」、選錯的成本是 年級的工程遷移 — 不是 config 改不改 等級。Microsoft 365 案例（9.C30）從 MongoDB 遷到 Cosmos DB MongoDB API 是 dogfood、但 case 自承「沒有提具體 throughput、latency、cost 數字」— 引用時不能拿這個案例的「成功」當 benchmark、只能取它的 framing。

四層 framing：vendor selection 的真實決策軸

Framing 1：document model 三型遷移路徑對照（本章合成 frame）

「MongoDB → Cosmos DB」是 一種 遷移、不是 全部 遷移。document model 的遷移路徑在 case 庫至少呈現三型、風險跟 ROI 完全不同：

三型 frame 是本章合成、case 原文沒有此分類。引用時要明示：Forbes 6 個月遷移成功 不代表 Microsoft 365 也是 6 個月、底層架構換的工程複雜度遠高於託管換。讀者開頭要先問「我屬於哪一型」、再進兩個 API 比較 — 「保留 + 補周邊」根本不需要進 Cosmos DB selection、「同 DB 換託管」的主要 trade-off 是 Atlas vs Cosmos DB 跨雲問題（Framing 4）、「同 model 換 vendor」才是本文聚焦的決策。

把三型混淆的後果是：拿 Forbes 6 個月時程當 baseline 估 Microsoft 365 型遷移、實際工程複雜度高 3-5 倍、project plan 從第一天就 over-commit。

Framing 2：dogfood 是高權重 selection signal、但案例數字常不公開

Microsoft 365 案例揭露的核心 signal 是「Microsoft 自家旗艦產品 dogfood Cosmos DB」— 跟 Amazon Prime Day 用 DynamoDB、Google 自家用 Spanner 一樣、雲商旗艦 DB 都用在自家旗艦產品上、這個 signal 在 vendor selection 的權重高、因為「雲商自己賭身家」。讀者該把這當 選型訊號、不是當 production benchmark。

但 9.C30 case 自承的警示必須明示：

• 「沒有提具體 throughput、latency、cost 數字。Microsoft 內部數字通常不公開、跟 AWS / GCP 案例的數字密度差很多」
• 「『MongoDB 不夠用』是行銷話術。實際是 MongoDB 在某些 workload pattern 下不夠用、不是普遍結論」

兩條警示直接影響寫作紀律：

• 不能拿「Microsoft 365 遷成功」當「我們也會成功」的證據 — 規模 / workload pattern / 團隊能力都不同
• 不能拿「Microsoft 從 MongoDB 遷出」當「MongoDB 不行」的結論 — Microsoft 自己也有大量 MongoDB / Cosmos DB / SQL Server 並用、不是全部遷出

dogfood signal 的 正確用法 是當 frame 借鑑（multi-model 差異化、planet-scale 抽象單位、API compatibility 層）、不是當數字 benchmark。

Framing 3：multi-model 是 Cosmos DB 的差異化價值、不總是真用上

Cosmos DB 的差異化價值不是「比 Atlas 更會跑 MongoDB」、是 單一服務支援 5 個 API（SQL / MongoDB / Cassandra / Gremlin / Table）。跨雲對照揭露這個差異化的稀有度：

• AWS：DynamoDB（KV）+ DocumentDB（MongoDB-compatible）+ Neptune（graph）+ Keyspaces（Cassandra）— 各 use case 一個產品
• GCP：Firestore（document）+ Bigtable（KV）+ Spanner（SQL）— 各 use case 一個產品
• Azure Cosmos DB：5 個 API 在 同一個服務 內、partition + RU + region 治理共用

對 selection 的意義：若團隊預期同一系統會用 document + KV + graph 混合、Cosmos DB 的 multi-model 是 運維單一服務 的 unique value、不是只看「MongoDB 替代品」就能 ROI 評估。但 anti-pattern 也明確：若團隊只用 MongoDB API、不會用其他 4 個 API、multi-model 差異化價值對該團隊 不成立、不該變成 selection 理由。

判讀時要把 multi-model 當「條件性價值」、不是「普遍優勢」 — 條件是「現在或可預見未來會用到第二個 API」。9.C30 Microsoft 365 case 策略段直接揭露「Multi-model 是 Cosmos DB 的差異化價值」、但這個價值對「只用 MongoDB API」的團隊不成立、不能套到所有讀者。

Framing 4：跨雲 hedging vs 單雲 lock-in 的 trade-off

選 Cosmos DB（單雲、Azure-only）跟選 MongoDB Atlas（跨雲、AWS / GCP / Azure 都能跑）的核心 trade-off 不是「哪個技術更強」、是 未來不確定性的對沖價值 — 對應 vendor lock-in 的退出成本評估：

• Atlas：跨雲部署能力、未來換雲商不用換 DB、9.C37 Forbes 用 GCP 但保留跨雲彈性
• Cosmos DB / DynamoDB / Spanner：三大雲商各自的單雲 DB、選一個就綁該雲商生態

對 未來雲商策略尚未底定 的團隊、Atlas 的 hedging 價值 高、即使當下單雲就夠用 — 因為 5 年後換雲商的工程成本可能遠高於每月多付的 hosting 費用。對 已綁 Azure 生態 的團隊（Microsoft 365 dogfood、企業 AAD / Office / Power Platform 整合）、Cosmos DB 的 Azure-only 是 整合延伸、不是 lock-in 損失 — 雲商已綁、再加一個 lock-in 不增邊際成本。

引用時必須明示這是 未來不確定性 vs 當下整合 的 hedging trade-off、不是「跨雲一定比較好」。讀者該問自己：「我們未來 5 年雲商策略是已定還是未定」、答案會直接決定 Atlas vs Cosmos DB 的選擇方向。

兩個 API 的機制差異

四層 framing 講完、再進 API 機制 — 不是為了「哪個快」、是為了讓 selection 後的實作不踩坑。

兩個 API 的關係：底層是同一個 Cosmos DB 分散式 document store、API layer 翻譯不同 wire protocol。MongoDB API 把 MongoDB 操作翻譯成 Cosmos DB internal、實際跑 Cosmos DB 自身 engine、不執行 MongoDB engine；SQL API 直接操作 Cosmos DB native query language。

MongoDB API：

• 相容 MongoDB wire protocol（時間敏感 claim、查 最新支援版本、目前對齊 6.0 / 7.0 但仍落後 native MongoDB）
• Driver 不變：直接用 mongo-go-driver / pymongo / mongoose
• 翻譯層有 overhead、相同 query 的 Request Unit 通常比 SQL API 多 10-20%（屬通用工程估算、Microsoft 公開文件未列具體比例、case 也未直接量化、實際 overhead 依 query shape / driver 版本 / region 而異、應該以自家 workload benchmark 校正）

SQL API：

• Cosmos DB native query language（SQL-like、不是標準 SQL、不支援 JOIN）
• 直接操作 JSON document、ARRAY / nested field native 支援
• 完整 Cosmos DB feature 支援（Change Feed、stored procedure、trigger）

關鍵差異點：

• $lookup（join）：MongoDB API 支援度有限、跨 partition 性能差；SQL API 沒 JOIN（document model 哲學）
• Aggregation pipeline：部分 stage 不支援或行為不同（時間敏感、查 支援列表）
• Index：MongoDB API hint / explain 行為跟 native MongoDB 不同
• Change stream：MongoDB API 提供 change stream wire compat、但底層是 Cosmos DB Change Feed（語義 / ordering / retention 有差）
• Transaction：兩邊都限同 partition、跨 partition transaction 都要改 workflow

API kind 是 account 層設定、建 account 時選擇、無法事後切換。MongoDB API → SQL API 的「升級」是 export → recreate account → import + 重寫 application 的全量遷移、不是 in-place 切換。

Migration playbook：MongoDB → Cosmos DB MongoDB API

「同 model 換 vendor」型遷移（Framing 1 第三型）的 6 規格面 audit：

規格面 1：Driver

• 主要 driver：Azure 生態整合、需要更好的 global distribution、Atlas 跨雲成本不必要（單雲團隊）
• 對應 Framing 4 的「已綁 Azure 生態」條件

規格面 2：No-go condition

• 跨雲需求（Framing 4、Atlas 仍是首選、Forbes 案例證據）
• 需要 native MongoDB latest feature（MongoDB API server version 落後 native MongoDB）
• 未來雲商策略未定（hedging 價值喪失）
• 純 MongoDB 投資、無 Azure 生態其他服務整合（Framing 3 multi-model 不成立）

規格面 3：Diff audit（6 維度）

• Schema：document shape 不變（wire compat）；但 _id 行為跟 Cosmos DB partition key 綁定方式要審
• Operational：自管 MongoDB → managed Cosmos DB、replica set / sharding 變成 partition + region、備份 / monitoring 全換
• Paradigm：不變（仍 document model）
• Components：MongoDB driver 保留、aggregation pipeline 部分需重寫
• Application change：connection string、authentication mechanism（SCRAM → Azure key / AAD）、read preference 對應 consistency level
• Topology：replica set → multi-region replication、shard key → partition key

遷移類型判定：Type B drop-in（partial）、wire compat 但有相容性 gap、必須 dual-write per query pattern 驗證、不是一次切換。

規格面 4：Phase plan

• Phase 0：相容性 audit、列 unsupported aggregation stage、production query corpus 對齊
• Phase 1：partition key 設計（從 shard key 翻譯）、見 partition-key-design
• Phase 2：bulk export-import（mongodump → Cosmos DB Data Migration Tool）
• Phase 3：CDC sync（MongoDB oplog → Azure Data Factory / 自寫 connector）
• Phase 4：shadow read 驗證 query 一致性、量 RU consumption baseline
• Phase 5：read cutover（讀切 Cosmos、寫仍 MongoDB）
• Phase 6：write cutover
• Phase 7：cleanup、退役 MongoDB cluster、保留 dump 90 天

規格面 5：Evidence

• query 一致性 diff log、aggregation result checksum、RU consumption baseline、replication lag
• 對應 schema-migration-rollout-evidence 的 dual-write 驗證

規格面 6：Cutover + cleanup

• read-only window < 10 min、aggregation result 對齊驗證
• Rollback 條件：query error rate > 1% 或 RU consumption 異常偏高（翻譯層 cost 高於估算）

失敗模式

Failure 1：假設 wire compat = 100% 行為相同

「100% wire compat」是 vendor 行銷話術、實際是「在某些 query pattern 下相容」— aggregation pipeline 跑出不同結果、上 production 才發現。9.C30 case 揭露的「『MongoDB 不夠用』是行銷話術。實際是 MongoDB 在某些 workload pattern 下不夠用」同模型反向適用 — 相容性 也是「在某些 query pattern 下相容」、不是普遍相容。

修法：production query corpus dual-write 跑一遍、case-by-case 驗證每個 query pattern、不能假設 wire compat = 行為 100% 一致。Phase 4 shadow read 不是「跑一些 test」、是 把所有 production query 跑一遍、對 checksum。

Failure 2：_id 當 partition key

MongoDB 的 _id 預設 ObjectId、跟 Cosmos DB partition key 邏輯不同；直接拿 _id 當 partition key 容易在 high-cardinality 但低均勻度的 access pattern 下 hot partition（VIP 用戶、機器人帳號）。要審 application 的真實 query pattern、選會均勻散佈的欄位、見 partition-key-design。

Failure 3：Change stream resume token 跨 API 不可用

MongoDB API 提供 change stream wire compat、但 resume token 格式跟 native MongoDB 不同、跨環境 resume 會失敗。CDC pipeline 在遷移期間需要分兩段：MongoDB 端用原生 resume token、Cosmos DB 端用 Change Feed continuation token、不能 把 token 從 MongoDB 帶到 Cosmos DB 繼續。

Failure 4：評估時只測 happy path

unsupported aggregation stage 在 dev 環境的 sample data 看不出、production 才爆。常見漏的 stage：$graphLookup / $facet / $bucket / 部分 $lookup pattern / window function。Phase 0 audit 要把 production aggregation pipeline 拉出來、對照 Cosmos DB MongoDB API feature support 清單。

Failure 5：把 dogfood 案例數字當 benchmark

9.C30 Microsoft 365 case 自承沒提具體 throughput / latency / cost 數字、不能拿 dogfood 案例的「成功」推論「我們團隊遷過去也會成功」— 規模 / workload pattern / 團隊能力都不同。寫 sizing 計畫時要回到 ru-cost-model-sizing 用自己的 query corpus 量、不是抄 dogfood case。

Failure 6：選 MongoDB API 後想升級 native MongoDB feature

MongoDB API server version 升級節奏跟 native MongoDB 不同步、新 feature 等待時間長。選 MongoDB API 等於放棄「拿到 native MongoDB 最新 feature」、若團隊 long-term commit Cosmos DB、SQL API 反而是更穩的選擇（feature 自己決定、不等翻譯層）。這條 trade-off 在 selection 階段就要決定、不能 phase 6 才發現。

容量與觀測

• 必看 metric：MongoDB API 特有 MongoRequests / MongoRequestCharge、diagnostic log 看 aggregation stage 是否被翻譯成 cross-partition query
• 容量規劃：MongoDB API 翻譯層有 overhead、相同 query SQL API 通常便宜 10-20% — 但這個差距通常不足以驅動 API 切換（切換成本太高、見 Failure 6）
• RU baseline：Phase 4 shadow read 階段量每個 query pattern 的 x-ms-request-charge、進 ru-cost-model-sizing 的 capacity forecast
• 回 9.6 容量規劃模型：API kind 選擇進 cost forecast、不是 sizing 後才補

Cosmos DB unique selection value 整合（四層 framing 收束）

讀者讀完本篇要能回答：「我該選 Cosmos DB MongoDB API、Cosmos DB SQL API、還是留 Atlas」 — 答案的四層判讀（對應 Framing 1-4）：

• 遷移路徑（Framing 1）：你是要保留 + 補周邊、換託管、還是換 vendor？三型風險不同、Forbes 時程不代表 Microsoft 365 時程
• dogfood signal（Framing 2）：你能用 frame 借鑑 Microsoft 365、但避免拿 dogfood 數字當 benchmark
• multi-model 是否真用上（Framing 3）：你的系統未來會不會用 graph / Cassandra / Table API？只用一個 API 時 multi-model unique value 不成立
• 跨雲 hedging vs Azure 整合（Framing 4）：你的雲商策略是已定還是未定？已綁 Azure 時 lock-in 是整合延伸、未定時 lock-in 是 hedging 損失

四層回答完、selection 才能落地、不是「Azure 上要不要用 Cosmos DB」單一問題。

Anti-recommendation

• 純 MongoDB 投資、未來不會綁 Azure、應留在 Atlas — 跨雲彈性的長期價值高於每月 hosting 差價
• MongoDB API 是「Azure 上的 MongoDB 替代品」、不是 MongoDB 升級版 — 想要 native MongoDB latest feature 應留在 Atlas / 自管 MongoDB
• 跨雲 hedging 是 selection 主 driver 時、Cosmos DB（單雲）+ DynamoDB（單雲）+ Spanner（單雲）都不該進候選名單
• 只用 document model、不用其他 4 個 API 時、multi-model 不該變成 selection 理由 — 此時 Atlas managed 服務的 MongoDB 原生行為通常更穩

相關連結

• Cosmos DB vendor overview — 本文是該頁尾「MongoDB API vs native SQL API trade-off」backlog 的深度展開
• 9.C30 Microsoft 365 dogfood case — 本文主案例、四層 framing 的證據錨點
• 9.C36 Coinbase — 三型遷移路徑「保留 + 補周邊」對照
• 9.C37 Forbes — 三型遷移路徑「同 DB 換託管」對照
• partition-key-design — Phase 1 partition key 從 shard key 翻譯
• ru-cost-model-sizing — Phase 4 RU consumption baseline
• consistency-levels-engineering — read preference 對應 consistency level
• MongoDB vendor — Atlas 對照
• 1.12 大規模 DB 遷移實戰 — 跨 vendor 遷移共通模型
• Database 卡片 / Change Data Capture 卡片 — 概念基底
• 官方：Cosmos DB MongoDB API feature support

本文不是 Cosmos DB overview（請看 Cosmos DB vendor 頁）— 而是 RU 成本模型 + sizing 的深度展開。Case anchor 是 9.C21 ASOS（24h 1.67 億 request、autoscale + RU budgeting）+ 9.C11 Minecraft Earth（測試到 1M RU/s、RU 抽象單位定義）。

Cosmos DB 適用度前置判讀：本篇假設 workload 已通過 Cosmos DB 適用度四層 framing（API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in）— 詳見 mongodb-api-vs-sql-api 開頭四層 framing、本篇不重複展開。RU sizing + 容量模式選擇是 已選 Cosmos DB 後 的成本決策；若 workload 不適用 Cosmos DB、RU sizing 無法救回 vendor 選錯的成本結構落差。

問題情境：RU 思維的學習曲線

典型觸發場景：團隊原本用 MongoDB 自管 / PostgreSQL、把容量規劃成「CPU + IOPS + working set RAM」三軸；遷到 Cosmos DB 後第一個問題是「我們的 query 要設多少 RU/s」 — 文件回答「估每個操作的 RU × 操作頻率」、但工程師沒有 RU 的直覺、不知道「200 RU 是貴還是便宜」。

讀者徵兆：

• 「為什麼這個 query 吃 200 RU」
• 「payload 從 1KB 變 10KB、cost 怎麼變」
• 「Autoscale vs Provisioned 怎麼選」
• 「Serverless 跟 Provisioned 的 break-even 在哪」
• 「Index policy 改了一個欄位、write RU 漲 30%」

真實壓力：Black Friday 流量 10x、autoscale 跟不上 throttle；dev 環境 24/7 跑、付 provisioned 月費卻只用 1 小時；team 估 RU 估到一半發現「不知道怎麼估」、回去問 PM「我們的 access pattern 是什麼」、PM 給不出答案。

從 CPU + IOPS 思維轉到 RU 思維

9.C11 Minecraft Earth 案例的平台特性段揭露的 RU 對照：

• 1 RU = 1 KB document 的 strong-consistent read 成本
• 寫成本約 5 RU
• 複雜 query 可達數百 RU

這個對照看起來簡單、但 容量規劃變成「估每個操作多少 RU × 操作頻率」、跟傳統 RDB「估 CPU / IOPS / working set RAM」是完全不同的思維。具體差異：

• 用 RU 思考、不是用 CPU 思考 — 不需要估「query 跑多久」、要估「query 吃多少 RU」
• 量單一 query 的 x-ms-request-charge header、不是看 slow query log — 監控位置從 server 端移到 SDK response
• 拆 query 為 RU budget、不是調 indexing strategy — Cosmos DB index policy 影響 RU、但 改 index 不改 query 速度、改的是 cost

跨 vendor 的 capacity 抽象差距（本章合成 frame、跨 vendor case 比對）：

• MongoDB 用 CPU + IOPS + working set 三軸
• DynamoDB 用 WCU / RCU 二軸 + on-demand vs provisioned 模式選擇 + adaptive capacity
• Cosmos DB 用 RU 單軸 + 5 consistency level

思維遷移成本可能高過 vendor 廣告的價格差距 — 工程師需要 4-6 週才會建立 RU 直覺、selection 評估時不能只看 monthly bill 就做 ROI 結論。對中型團隊、這個學習曲線可能直接決定遷移成功率。

Scope warning：9.C11 揭露「100 萬 RU/s 壓測通過」 — 壓測通過數字、不是 production 持續跑（case 自己警示）。引用 1M RU/s 時必須帶 scope：壓測 vs 持續、case 明示「實際營運要看 partition key 設計是否均勻」。把壓測數字當 production capacity 推算的後果是 sizing 嚴重低估 hot partition 風險。

RU 的核心機制

RU 基準

1 RU = strong-consistent read of 1KB document、用 CPU + memory + IOPS 綜合抽象。每個操作的 RU charge 從 SDK response 的 x-ms-request-charge header 拿、不是事後估算。

操作 RU 對照（rule of thumb、實際以 x-ms-request-charge 為準）：

• Read 1KB（point read）：1 RU（eventual / session 更便宜、strong / bounded staleness 約 2x）
• Write 1KB：5-10 RU（含 index 更新）
• Replace 1KB：10-15 RU
• Query：跟 query plan + result count + index hit 強相關、可從 5 RU 到 1000+ RU

Payload size 的影響

每多 1 KB payload、write RU 線性增加；read 同 partition 多個 doc 用 query / feed 比多次 point read 更便宜。常見誤區是「拆小 doc 比較便宜」 — 不一定、要看 read pattern：若每次 read 都拿 10 個小 doc、不如合成一個大 doc 一次 read。

Index policy 的影響

預設 indexing 全欄位（auto-indexing）、降 query cost 但提 write cost；customize index policy（exclude path / include path）可降 write RU 30-50%。判讀時：write-heavy collection 通常該 exclude 不查的欄位、read-heavy collection 通常該 include 常用 query 欄位。

1{
2  "indexingMode": "consistent",
3  "includedPaths": [{"path": "/userId/?"}, {"path": "/orderDate/?"}],
4  "excludedPaths": [{"path": "/*"}]
5}

三種容量模式

• Provisioned throughput：訂死 RU/s、不用也付、適合穩定流量
• Autoscale provisioned：訂 max、實際用多少算多少（10% min ceiling）、適合 unpredictable
• Serverless：完全按 request 計、小流量 / dev / 稀疏負載

模式選擇不是「哪個便宜」、是「負載形狀適配哪個」— 下節展開。

操作流程：依負載形狀選容量模式

量測單一 query RU

SDK response header x-ms-request-charge、或 portal Query Stats。Phase 0 audit 一定要 把 production query corpus 跑一遍量 RU、不是估算 — 估算誤差通常 5-10x。

量測 container baseline RU

az cosmosdb sql container show-throughput、portal Metrics > Normalized RU Consumption。

設定 autoscale

1az cosmosdb sql container update \
2  --max-throughput 40000 \
3  --resource-group myrg --account-name mycosmos \
4  --database-name mydb --name mycontainer

依負載形狀對應容量模式

不同負載形狀的容量決策完全不同、不能用同一個模板：

持續高峰（24h 整天高） — Provisioned + scheduled scaling

• Trigger 訊號：峰值 / 平均 < 2x、預測性高
• Case anchor：9.C21 ASOS Black Friday — 24h 1.67 億 request、峰值 / 平均 = 1.81、整天高
• 為什麼選 provisioned：autoscale 的 reactive trigger 在持續高峰時仍會被拖累 p99、provisioned 鎖定 RU 反而平穩
• Scheduled scaling 在 event 前 30-60 分鐘 pre-warm、避免事件開始 trigger autoscale

隨機 surge（不可預測 timing） — Autoscale + reactive safety net

• Trigger 訊號：不規則尖峰、預測訊號弱、流量曲線無規律
• 為什麼選 autoscale：成本不浪費（10% min ceiling）、reactive 雖然有延遲但比 over-provisioned 划算
• Case anchor 屬本章合成 frame、case 庫未直接揭露純「隨機 surge」的 Cosmos DB 案例

預測性 surge（外部訊號可預測） — Pre-provision + scheduled scaling

• Trigger 訊號：賽事 / 上線 / 季節 peak、有外部訊號可學
• Case anchor：9.C36 Coinbase predictive scaling 模型對 KV / document 同適用 — ML 預測 60 分鐘領先窗、改善的是 trigger 提前、不是擴容本身變快
• Coinbase case 是 MongoDB 場景、模型可借鑑、但 Cosmos DB 沒有直接對應 ML 預測整合、需要自建

稀疏 / dev / 低流量 — Serverless

• Trigger 訊號：< 1000 RU/s 預期、長時間閒置（如 dev / test / 內部工具）
• Serverless 是建 account 時選、不能事後轉 provisioned、要在 Phase 0 決定
• 屬本章合成 frame、case 庫未直接揭露 serverless 場景（多數案例都是 production 流量）

本章合成 frame 警示：上表是跨 4 個 case 合成（9.C21 ASOS 提供「持續高峰」明確 anchor、9.C36 Coinbase 提供「預測性 surge」模型）、其他兩格屬 outline knowledge — 引用時必須明示「對照表是本章合成、case 原文沒有此分類」。

切換 provisioned ↔ autoscale

portal / CLI 支援、不需停機；但 Serverless 是建 account 時選、不能轉 provisioned。Phase 0 決定 mode 後若要切 serverless ↔ provisioned 等於重建 account + 資料遷移。

驗證點

• autoscale min ceiling = 10% max；若 traffic 預測 baseline > 25% peak、autoscale 不划算（baseline 已經超過 min ceiling、autoscale 的彈性沒用上）
• p99 query RU < provisioned / 100（給 burst 留 100x buffer 是 rule of thumb、實際視 query 分布）
• 每個 query pattern 的 x-ms-request-charge < SLA budget

Rollback boundary

throughput 可即時改、index policy 改完背景 rebuild（rebuild 期間 query 用舊 index、性能可能下降但不中斷）；mode（serverless ↔ provisioned）不可改。

失敗模式

Failure 1：用 point read 取代 query

要拿同 partition 100 個 doc、做 100 次 point read（100 RU）vs 一次 query（可能 10-20 RU）— point read 雖然每次便宜、總成本反高。這個 anti-pattern 在 application code 很常見 — 「每次 read 一個 doc 比較簡單」是 application 角度、不是 RU 角度。

修：拉 access pattern audit、把 N+1 read pattern 改 batch query；用 query 拿同 partition 多 doc、用 cross-partition query 拿不同 partition（成本高、但比 N+1 point read 通常還便宜）。

Failure 2：Index 全開不審

所有欄位 auto-index、write 大表時 RU 暴漲；徵兆是 Total RU consumption 寫入路徑佔 80%、read 只佔 20%、但 application 明明 read-heavy。原因是 index 維護成本太高。

修：customize index policy、exclude 不查的欄位（特別是 array / nested object 等高成本欄位）、include 常用 query 路徑。改完背景 rebuild、不中斷服務。

Failure 3：Autoscale min 沒考慮

max 40000、min 4000（10% max ceiling）、實際 baseline 是 500、付 8x baseline 費；應該降 max 或改 serverless。autoscale 的 min ceiling 是常見的隱性成本來源 — 訂太高 max 就被 min 綁住、autoscale 反而比 provisioned 貴。

修：先量 baseline 跟 peak、算 peak / baseline ratio；ratio > 10x 用 autoscale 划算、ratio < 4x 用 provisioned 划算（autoscale min ceiling 吃掉彈性）。

Failure 4：Autoscale 撐不住預測性流量、必須 scheduled scaling 或 pre-provision

autoscale 的 min ceiling = 10% max、實際擴容仍是 reactive（看到 throttle 才往上推）。對預測性流量（季節 peak / 賽事 / 上線日）、autoscale 跟不上、必須 scheduled scaling 或 pre-provision。

9.C21 ASOS Black Friday 是「持續高峰」、整天高 — 用 provisioned + scheduled 比 autoscale 划算（autoscale 仍會被 reactive trigger 拖累 p99）。9.C36 Coinbase 模型雖然是 MongoDB case、可借鑑：cluster 擴容 70 分鐘、reactive 來不及、ML 預測 60 分鐘領先窗、改善的是 trigger 提前、不是擴容本身變快 — Cosmos DB autoscale 的 10% ceiling 同樣是 reactive 限制。

修：預測性 event 前 30-60 分鐘 pre-warm RU/s、事件結束後降回；用 scheduled scaling pipeline（Azure Function trigger + ARM template）自動化。

Failure 5：Provisioned 沒退場

dev / staging container 全開 provisioned、月費 $300+ × N 個 environment；應切 serverless 或共用 shared throughput（多個 container 共享一個 RU pool）。dev 環境的 cost waste 是長尾、月底帳單才發現。

修：dev / staging 改 serverless、production 才 provisioned；或用 shared database throughput、多個 container 共用 400-1000 RU pool。

Failure 6：跨 partition query 浪費

query 沒包含 partition key 條件、fan-out 全 partition、RU × partition 數；徵兆是 RetrievedDocumentCount 跟 OutputDocumentCount 比例 > 10（拿了 10x doc 才篩出要的）。

修：query 強制帶 partition key 條件、改 access pattern 讓 query 自然帶 partition key；若必須跨 partition、用 Change Feed 把投影預先寫到另一個 container 用單一 partition 查。

Failure 7：沒設 budget alert

cost 失控直到月底帳單才發現。Cosmos DB 的成本可以在幾天內飆 10x（hot partition + index 全開 + autoscale max 設太高 互相加乘）、月底才看是災難。

修：Azure Cost Management 設 daily budget alert（超預算 1.5x trigger）、portal Insights > Cost insights 每週 review。

Failure 8：TTL 自動刪除把 RU 偷走

Cosmos DB 容器層的 TTL（Time To Live）會在 background 持續掃描過期文件、跑 delete 操作消耗 RU、但不會出現在 application driver 的 RU 統計、容易在 sizing 階段被忽略。屬通用工程議題、case 未直接量化 TTL 對 RU 的佔比。

徵兆：

• Provisioned RU 估算「query + write」流量明明很穩、實際 NormalizedRUConsumption 卻偏高、找不到對應 application call
• 高寫入率 container 開啟 TTL 後、Total Request Units 持續高於預期、portal Insights 「Background operations」段非零
• TTL 設過短（例：分鐘級）、background delete 跟 application write 競爭同 partition、寫入 latency p99 變高

修：

• 估 RU 容量時把 TTL delete 當第三類流量（除了 user read / write 外）、用「過期 doc / 秒 × 平均 doc delete RU」估算
• 設定 TTL 不要過短、避免 delete 壓力跟 application write 撞 partition
• 對高 TTL volume 的 container 開啟 analytical store、避免歷史資料保留在 transactional store 持續耗 RU
• 監控 Background operations 跟 NormalizedRUConsumption 的 ratio、把 TTL 對 RU 的影響可視化

容量與觀測

• 必看 metric：NormalizedRUConsumption（peak）、TotalRequestUnits（cumulative）、MetadataRequests、UserErrors（for 429 throttle）
• 成本分析：Azure Cost Management 按 container / region tag；portal Insights > Cost insights
• 容量公式：peak RPS × avg RU per request × peak duration factor = required RU/s
• 回 9.6 容量規劃模型 把 RU 當主要 capacity 軸（不只 storage / CPU）
• 對應 9.4 Saturation Discovery：把 429 throttle 當 saturation 訊號
• Alert：429 rate > 0.1%、RU consumption > 80% provisioned 持續 5 min、daily cost 超預算 1.5x

Latency budget 拆解：vendor SLA vs end-to-end 實測

9.C21 ASOS 觀察「48ms 平均響應」段揭露：48ms 包含 網路 + DB + 應用層、DB 本身可能只佔 5-10ms。引用時不能把 vendor 廣告的 5-10ms p99 當「使用者體驗」 — 詳細拆解見 partition-key-design 的 latency budget 段。

跟其他 vendor capacity 抽象的對照

對照表是本章合成 frame、case 庫沒有單一案例橫跨多 vendor。判讀時要明示「思維遷移成本是 selection 評估的隱性軸、不是只看 monthly bill」。

邊界與整合

• Sibling deep articles：partition-key-design（partition skew 讓 RU 失效、hot partition 是 sizing 假設失敗的主因）、consistency-levels-engineering（Strong / Bounded 對 read RU 2x）、multi-region-write-conflict（multi-region RU × region 數）、mongodb-api-vs-sql-api（MongoDB API 翻譯層多 10-20% RU）
• 跟 1.x 章節：1.10 KV / Document DB 容量規劃
• 跟 9.x 章節：9.4 Saturation Discovery（429 throttle 當 saturation 訊號）
• Knowledge cards：Peak Forecast / Hot Partition
• Anti-recommendation：流量 < 1000 RU/s 不需 autoscale tuning、用 serverless 或 400 RU/s shared throughput；過度 sizing 比 under-sizing 更常見、特別是 dev / staging

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 RU/s cost model backlog 的深度展開
• 9.C21 ASOS Black Friday case — 持續高峰 + RU budgeting 主案例
• 9.C11 Minecraft Earth case — RU 抽象單位定義 + 1M RU/s 壓測（scope warning：壓測非持續）
• 9.C36 Coinbase predictive scaling case — 預測性 surge 模型借鑑（跨 vendor）
• Peak Forecast 卡片 / Hot Partition 卡片 — 概念基底
• 官方：Cosmos DB Request Units / Provisioned throughput vs autoscale vs serverless

本文是 Cosmos DB vendor 頁 的深度展開、也是 Strong + multi-region 互斥 議題的 SSoT 主寫位置（consistency-levels-engineering cross-link 過來、不展開）。Case anchor 是 9.C11 Minecraft Earth（AR 遊戲跨 region 寫入、5 consistency level + multi-region SLA）+ 9.C21 ASOS（Black Friday 全球零售）+ 9.C38 Toyota Connected（鏈路 SLA 拆解、跨 vendor 適用做 frame anchor）。

Cosmos DB 適用度前置判讀：本篇假設 workload 已通過 Cosmos DB 適用度四層 framing（API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in）— 詳見 mongodb-api-vs-sql-api 開頭四層 framing、本篇不重複展開。Multi-region write + conflict resolution 是 已選 Cosmos DB 後 的拓樸決策；strong global consistency 必要的 workload 應走 Spanner 或 Cosmos DB Strong（單一 write region）、不是用 LWW 補。

問題情境：active-active 的 conflict 是必然代價

典型觸發場景：產品要 global active-active（每個 region 都能寫、低延遲）、Cosmos DB 是 AP 系統、不像 Spanner 用 quorum 強一致；跨 region 寫同一筆 document 必然有 conflict、團隊不知道「conflict 真的發生時、誰贏 / 怎麼處理 / 業務語義保不保得住」。

讀者徵兆：

• 「multi-region write 開了、user 在 A region 寫『加入購物車』、B region 寫『移除購物車』、最後哪個贏」
• 「LWW 用 timestamp 決定、client clock skew 不就破壞了嗎」
• 「conflict feed 是什麼、要不要消費」
• 「multi-region write 開了之後 consistency level 還能設 Strong 嗎」
• 「廣告寫 99.999%、為什麼實測只有 99%」

真實壓力：購物車跨 region 寫入丟失、遊戲玩家狀態跨 region 衝突回滾、IoT device 跨 region 寫 telemetry 後消失。這些事故的根因不是 bug、是 multi-region write 的 設計取捨、需要在 selection 階段就決定 conflict resolution policy。

核心機制

AP 取捨的硬約束：為什麼 Strong + multi-region write 互斥

Cosmos DB 是 AP 系統（在 partition 的情況下選 availability 跟 partition tolerance、放棄 cross-region linearizability）。multi-region write 的兩個前置條件：

• account 開啟 enableMultipleWriteLocations = true
• consistency level 不能設 Strong（multi-region write 跟 Strong 互斥、時間敏感 claim、查 最新文件）

為什麼互斥（CAP 三選二的硬約束）：

• Strong consistency 在 Cosmos DB 的實作是 quorum-based linearizable read — 確保 read 拿到最新 commit、需要 單一 write region 來保證寫入順序
• Multi-region write 是 active-active、每個 region 都能寫 — 不存在「單一 write region」、寫入是 LWW-based eventual consistency
• 兩者在技術上 不能同時成立 — 不是 Microsoft 工程選擇問題、是 distributed system 的基本限制（跟 Spanner 用 Paxos quorum + TrueTime 不同的設計路徑）

對 selection 的意義：產品要「全球都能寫」就接受 eventual consistency；產品要「全球 linearizable」就轉 Spanner / Aurora DSQL、Cosmos DB 不是替代品。把 Cosmos DB Strong 跟 Spanner external consistency 等同視之是 常見的選型誤判。

consistency-levels-engineering 的 Strong 段只 cross-link 過來、不展開 conflict resolution 細節 — 本篇是 SSoT 主寫位置。

Conflict 偵測

同一 document（partition key + id）在多 region 並發寫入、Cosmos DB 偵測為 conflict。偵測機制基於 LSN（log sequence number）、不是 timestamp — 兩個 region 對同一 document 寫入時、replication 過程比對 LSN 發現分歧、進 resolution。

三種 conflict resolution policy

LWW（Last-Writer-Wins、預設）

• 機制：用 _ts（system timestamp）或自訂 numeric property、value 大的贏
• 副作用：clock skew 在 ms 級就能讓「先寫的反而贏」、業務邏輯破洞
• 適合：純覆寫場景（如玩家位置最新值、IoT 最新讀數）— write 順序不影響業務語義

1"conflictResolutionPolicy": {
2  "mode": "LastWriterWins",
3  "conflictResolutionPath": "/customTimestamp"
4}

Custom merge stored procedure

• 機制：寫一個 JavaScript stored proc、conflict 時 Cosmos DB 呼叫、proc 回傳 merge 結果
• 適合：要保留業務語義的場景（購物車 merge = union 兩邊 items、計數器 merge = sum、status 機器 merge = 狀態圖規則）
• 風險：stored proc 在 Cosmos DB JavaScript runtime 跑、有 timeout / RU 限制；複雜 merge 邏輯難 debug

1"conflictResolutionPolicy": {
2  "mode": "Custom",
3  "conflictResolutionProcedure": "dbs/mydb/colls/mycoll/sprocs/resolveCart"
4}

Conflict feed manual reconciliation

• 機制：Cosmos DB 把 conflict 寫入 conflict feed、不自動解決、app 自行消費並 reconcile
• 適合：conflict 需要人工 / 業務流程判斷、不能 auto-resolve（如金融交易、合規場景）
• 風險：feed 不消費就累積、後續分析失準；app 需要實作 reconcile 流程

1"conflictResolutionPolicy": { "mode": "Custom" }

（沒指 procedure、conflict 全進 feed、app 用 SDK ReadConflictsAsync() / Change Feed Processor pattern 消費）

跟其他 vendor 對比

• DynamoDB Global Tables：也是 LWW、無 custom merge、無 conflict feed — 行為比 Cosmos DB 簡單但彈性少
• Spanner：用 Paxos quorum、不會有 conflict（CP 系統、可用性換一致性）— 跨 region write 需 quorum、latency 100-200ms
• Aurora Global Database：single-primary（一個 region 寫、其他 region 讀）、不是真 multi-region write、無 conflict

對應 knowledge cards：stale-read、rpo、rto。

操作流程

開啟 multi-region write

1az cosmosdb update --name mycosmos --resource-group myrg \
2  --enable-multiple-write-locations true \
3  --locations regionName=eastus failoverPriority=0 \
4  --locations regionName=westeurope failoverPriority=1

開啟後 不能直接關回、要 disable + 改 region 配置 + re-enable、有停機窗口。

設定 LWW policy（container 層）

建 container 時指定、可事後改但 conflict 行為以新 policy 為準（既有 conflict 不會重 resolve）。預設用 _ts 比較；改成 customTimestamp 時要保證 application 寫入時 用單調遞增 的 timestamp source（不能用 client clock）。

設定 custom merge

建 stored proc：

1function resolveCart(incomingItem, existingItem, isTombstone, conflictingItems) {
2  // 範例：merge 購物車 items（取 union）
3  var merged = existingItem;
4  merged.items = mergeArrays(existingItem.items, incomingItem.items);
5  merged._ts = Math.max(existingItem._ts, incomingItem._ts);
6  __.response.setBody(merged);
7}

1"conflictResolutionPolicy": {
2  "mode": "Custom",
3  "conflictResolutionProcedure": "dbs/mydb/colls/mycoll/sprocs/resolveCart"
4}

驗證：proc 內處理 timeout / exception；測 edge case（空 array / null / 並發 3+ region 寫入）。

消費 conflict feed

1// .NET SDK
2var iterator = container.GetItemQueryIterator<ConflictProperties>(
3    "SELECT * FROM c");
4while (iterator.HasMoreResults) {
5    var response = await iterator.ReadNextAsync();
6    foreach (var conflict in response) {
7        await ProcessConflict(conflict);
8    }
9}

用 Change Feed Processor pattern 把 conflict feed 當 stream 消費、寫到 reconcile queue、由業務流程處理。

驗證點

• 跨 region 並發寫測試（synthetic load）、觀察 conflict count / resolution result
• Custom merge stored proc 跑過 edge case（exception / null / 並發 3+）
• Conflict feed 不積壓（lag < 5 min）
• Region 故障時 application 仍能寫（active-active 設計、不需 manual failover）

失敗模式

Failure 1：全用 LWW + 用 server timestamp

clock skew 在 ms 級可能讓「先寫的反而贏」、業務邏輯破洞。常見徵兆：使用者反映「我明明先按確認、後來改的反而是舊的」、debug 才發現是跨 region clock skew。

修：

• 用 customTimestamp 從 application 端 monotonic source 取（如 Snowflake ID、HLC、Lamport clock）
• 或改用 custom merge stored proc、用業務邏輯而非 timestamp 決勝
• 或拆 collection、把 conflict 高的 collection 用 stored proc、低的用 LWW

Failure 2：業務語義不適合 LWW

購物車（要 union）、計數器（要 sum）、status 機器（要狀態圖）全用 LWW = 資料丟失。LWW 的設計假設是「最新 write 就是正確答案」、但很多業務語義不是覆寫關係。

修：盤點 collection 的業務語義、選對應 resolution policy：

• 覆寫關係 → LWW
• 累積關係 → custom merge stored proc（union / sum / set 合併）
• 狀態機 → custom merge stored proc（按狀態圖規則 resolve）
• 需要人工裁決 → conflict feed

Failure 3：Custom merge stored proc 沒測 edge case

proc throw exception 時 Cosmos DB 行為：conflict 留 feed、不會自動 retry。團隊以為 proc 跑了就沒事、實際 conflict 累積在 feed、後續分析失準。

修：proc 內部 try-catch、log exception、確保 任何輸入都能 return 一個合理結果（即使是 fallback 到 LWW）；定期掃 conflict feed 檢查積壓。

Failure 4：不消費 conflict feed

選 manual mode 後忘記實作 feed consumer、conflict 累積、後續分析失準。常見徵兆：feed lag metric alert、或業務反映「資料對不上」、最後發現 conflict feed 裡躺著一堆未處理的 conflict。

修：選 conflict feed mode 前先實作 consumer pipeline（Azure Function trigger on Change Feed / 自建 worker）；設 alert：feed lag > 5 min 通知。

Failure 5：期待 multi-region write 還有 Strong consistency

兩者互斥、開啟 multi-region write 後 Strong 自動 downgrade（或拒絕設定、時間敏感、查最新文件）。團隊以為「multi-region + Strong = 全球 linearizable」、底層是設計 incompatibility。

修：在 selection 階段就決定「要 active-active write 還是要 Strong」 — 兩者只能擇一。要全球 linearizable 轉 Spanner / Aurora DSQL、要 active-active 就接受 eventual / session / bounded staleness。

Failure 6：跨 region 寫入後立即同 session read 看不到

session token 沒跨 region 傳遞、看似 inconsistency 其實是 session 沒對齊。典型 anti-pattern：service A 在 region 1 寫、用 region 1 session token；service B 在 region 2 讀、沒拿到 A 的 token、看不到 A 的寫。

修：session token 隨 request 傳遞（通常進 HTTP header）；或改 account 層 Bounded staleness（提供跨 session 的 K/T bound）；見 consistency-levels-engineering 的 session token 管理段。

Failure 7：Region 故障時的 failover 邏輯誤判

multi-region write 已是 active-active、不需要 manual failover — 一個 region 掛、其他 region 自動承接寫入。但若用了 failoverPriority 配置、failover 邏輯仍要審 — priority 是 當 multi-region read 切到哪個 region 為 primary、不是 active-active 的 routing。

修：multi-region write 場景不用依賴 failoverPriority、用 Traffic Manager / Front Door 做 region routing；application 端 SDK 配置 PreferredLocations 讓 SDK 自己選 nearest region。

容量與觀測

• 必看 metric：ConflictCount、ReplicationLatency per region pair、conflict feed lag
• Conflict rate 監控：正常 < 0.01%、突增代表 hot key 或 region 同步異常
• Cost 影響：multi-region write 開啟後、寫入成本 × region 數（每個 region 都 replicate）— 3 region active-active = 3x write Request Unit cost
• 對應 9.6 容量規劃模型：multi-region write multiplier 進 sizing
• 對應 4.20 Observability Evidence Package：conflict rate 當 reliability evidence
• Alert：conflict rate > 0.1%、conflict feed lag > 5 min、cross-region replication lag > SLA

廣告 SLA vs 實測可用性鏈路拆解（本章合成 frame）

9.C11 Minecraft Earth 平台揭露的 Cosmos DB SLA：

• single-region 99.99%
• multi-region 99.999%

這是 DB 端 SLA、不是 端到端系統 SLA。真實 production 系統的可用性是鏈路乘積：

1實測可用性 = DB SLA × 網路 SLA × 應用層 SLA × 客戶端可達性

9.C38 Toyota Connected 揭露「99.99% target vs 99% 實測」段的觀察：兩個 9 的差距 不是 MongoDB / Atlas 自身問題、是 end-to-end 鏈路（車輛無線網路 / cellular tower / cloud network / event bus / microservice / DB cluster 任一環節掉都會打掉可用性）。Cosmos DB multi-region write 同模型：

• 多 region active-active 可解 DB 端可用性、但網路 / 應用層任一掉、實測仍 < 99.99%
• 廣告 99.999% 是 multi-region availability zone 級、不是 「使用者 request 成功率」

引用時必須明示：Cosmos DB multi-region 廣告 99.999% 是 DB 端、要算實測可用性必須補網路 / 應用層 SLA 乘積、Toyota case 的「99% 實測」揭露的就是這個鏈路問題、跨 vendor 都適用。

跟 conflict resolution 的關係：多 region 高可用性 買來 的代價是 conflict、conflict rate 是 reliability 的暗稅 — 廣告 SLA 不計 conflict 處理成本。production 設計要把「conflict resolution 的工程成本」加進 multi-region write 的 ROI 評估。

邊界與整合

• Sibling deep articles：consistency-levels-engineering（multi-region write 跟 Strong 互斥的 cross-link 來源）、partition-key-design（hot partition 會放大 conflict）、ru-cost-model-sizing（multi-region cost × region 數）
• 跟 Spanner vendor 對比：CP vs AP、無 conflict vs LWW / custom
• 跟 DynamoDB Global Tables 對比：兩者都 LWW、Cosmos DB 多 custom merge + conflict feed
• 跟 1.x 章節：1.11 全球分散式 OLTP 把 multi-region write 模式並陳
• Knowledge cards：stale-read / rpo / rto
• Anti-recommendation：single-region write + cross-region read replica 在大多數情況更便宜、更易推理；只有 write residency 是產品契約（合規 / latency / 業務需求）時才升 multi-region write

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 multi-region write + conflict resolution backlog 的深度展開
• 9.C11 Minecraft Earth case — multi-region 99.999% / single-region 99.99% SLA 來源
• 9.C21 ASOS case — 全球零售 multi-region 補充
• 9.C38 Toyota Connected case — 鏈路 SLA 拆解 frame anchor（跨 vendor 適用）
• consistency-levels-engineering — Strong + multi-region 互斥的 cross-link 目的地
• Stale Read 卡片 / RPO 卡片 / RTO 卡片 — 概念基底
• 官方：Cosmos DB conflict resolution / Multi-region writes

本文不是 Cosmos DB overview（請看 Cosmos DB vendor 頁）— 而是 partition key 設計 + 故障演練的深度展開。Case anchor 是 9.C11 Minecraft Earth（synthetic partition key 強制分散、AR 遊戲玩家位置）+ 9.C21 ASOS（Black Friday 流量分散 + latency budget 拆解）。

Cosmos DB 適用度前置判讀：本篇假設 workload 已通過 Cosmos DB 適用度四層 framing（API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in）— 詳見 mongodb-api-vs-sql-api 開頭四層 framing、本篇不重複展開。Partition key 設計是 已選 Cosmos DB 後 的硬約束議題；若 workload 不適用 Cosmos DB、partition key 設計無法救回 vendor 選錯的不可逆性風險。

問題情境

典型觸發場景：團隊用 user_id 當 partition key 上 production、平常正常、Black Friday 或 VIP 大客戶上線當天 — application 收到 429 TooManyRequests、p99 從 50ms 飆到 5s；查 portal Metrics 發現 整體 RU 使用率才 30% 但少數 partition 100% 滿、其他 partition 閒置。Cosmos DB 設了 10000 RU/s、實際只能用 2000 就 throttle。

讀者徵兆：

• 「Cosmos DB throughput 我設了 10000 RU、但寫入只有 2000 就 throttle」
• 「user_id 當 partition key 結果 VIP 用戶全卡在一個 partition」
• 「Hierarchical partition key 是 2023 後才有的、跟 composite 差在哪」
• 「partition key 選錯能改嗎」

真實壓力：

• 遊戲玩家位置（同伺服器集中同 partition、Minecraft Earth 場景）
• IoT 裝置遙測（單一裝置高頻寫入、device_id 不均）
• SaaS 多租戶（大客戶 vs 小客戶不均、tenant_id 直接當 partition key 會 hot）
• 零售商品 catalog（熱門 SKU vs 冷門 SKU 不均）

partition key 選錯的隱性成本：要改就是 export → recreate container with new partition key → import、無 in-place migration、production 等於停機窗口 + 全量資料搬移。selection 階段就要決定、不能 phase 後補。

核心機制

Partition 模型

每個 container 有 N 個 physical partition、每個 physical 上有多個 logical partition。同 partition key value 的所有 document 落到同一個 logical partition。Cosmos DB 動態調整 physical partition 數量（透明 split）、但 logical partition 的歸屬 永遠不變（同 PK value 永遠在同 logical）。

9.C11 Minecraft Earth 案例的平台特性段揭露「partition 動態分裂：透明」 — physical partition 的 split 對 application 透明、不需要 application 重連 / 重新 hash。但這個透明 只解 physical partition 容量 問題、不解 logical partition 熱點 — logical partition 由 PK value 決定、application 必須自己均勻散佈 value。

Logical partition 上限

10,000 RU/s + 20 GB storage、達 limit 後即使 container 還有總 RU、單一 partition key 一樣 throttle。這是 硬上限、不是 soft limit、不能調高。

20 GB storage 限制在小用戶通常碰不到、但對「以 tenant_id 為 PK 的大客戶」、storage 也可能先到上限（單一大客戶 50GB 資料、塞不進一個 logical partition）。

Partition key 設計三種模式

Synthetic（人工合成 key）

機制：用 {userId}_{random_0_to_99} 把單一 user 的寫入散到 100 個 logical partition。application 端 hash userId + random suffix、寫入時組合成 partition key。

副作用：read 需 fan-out 100 個 partition、單一 query RU 暴漲 100x。適合 write-heavy + 不需精準 read 場景（如 IoT telemetry、log）。

9.C11 Minecraft Earth 用 synthetic partition key 強制分散 — AR 遊戲玩家位置寫入頻繁、partition 分散讓單一玩家不會打爆一個 partition。但 case 沒揭露具體 schema、synthetic 細節屬 outline knowledge 推論。

Composite（多欄位合成）

機制：用 {tenantId}_{deviceId} 兩個欄位合成（Composite Partition Key 通用樣式）、避免單一 high-cardinality 欄位 hot。適合 多租戶 SaaS、單一 tenant 內又有多個 device、避免大 tenant 把所有寫入集中。

副作用：read 必須帶兩個欄位、否則 cross-partition query；query API 設計要強制帶 tenant + device。

Hierarchical（2023+ 原生支援）

機制：原生支援多層 key（最多 3 層、如 tenantId / deviceId / sessionId）、不用手動合成；query 可指定前綴做 partition scope query（如「拿 tenant X 的所有 device」單一 partition scope）。

適合：多層業務 hierarchy 場景（tenant → user → session、organization → team → project）。比 composite 優勢是 支援 prefix query、composite key 只能完整匹配。

1az cosmosdb sql container create \
2  --partition-key-paths "/tenantId" "/deviceId" \
3  --partition-key-kind "MultiHash" \
4  ...

設計順序要從 低 cardinality 到 高 cardinality（tenant 少、device 多、session 最多）— 反序會讓 prefix query 無意義。

跟其他 vendor 的可逆性對照（本章合成 frame）

跨 vendor 可逆性對照 SSoT：MongoDB / DynamoDB / Cosmos DB 三家 partition key 可逆性不在同一光譜（Cosmos DB 屬不可改、不可逆性最高）、跨 vendor 對照 SSoT 主寫位置在 DB3 entry — 三 vendor 對比 10 軸 + 對應的軸的延伸子段。本段聚焦 Cosmos DB 不可改特性對 selection 階段 access pattern audit 嚴格度的影響、不重複展開三 vendor 全光譜比較。

partition / shard key 的可逆性在 vendor 間差異懸殊：

對照表是本章合成 frame、9.C11 Minecraft Earth 沒直接揭露此對比、是從 outline knowledge 跟 MongoDB shard-key-selection 對照得出。引用時必須明示：Cosmos DB partition key 不可改是 設計選型的硬約束、不是「先選錯再改」可承擔的風險 — 這個約束直接決定 selection 階段的 partition key audit 嚴格度該多高。

對 selection 的意義：若團隊對 access pattern 不確定、不能用「先上 Cosmos DB 再說、不行再改」的心態、要先用 MongoDB / DynamoDB 試 access pattern、確定後再評估 Cosmos DB。

跟 DynamoDB partition key 對比

• DynamoDB：partition key + optional sort key、無 hierarchical key、adaptive capacity 自動補 hot partition（部分減緩、不完全解決）
• Cosmos DB：hierarchical key 是 原生功能、不靠 adaptive；單 logical partition 限制嚴格、必須前期設計

Cosmos DB 的 硬上限 + 不可逆性 跟 DynamoDB 的 adaptive + 可遷移 是兩種設計哲學 — selection 時要評估團隊能不能負擔前期 design effort。

對應 knowledge cards：hot-partition / database-sharding。

操作流程

設定 partition key

建 container 時指定、無法事後修改：

1az cosmosdb sql container create \
2  --account-name mycosmos --database-name mydb \
3  --name mycontainer --resource-group myrg \
4  --partition-key-path "/userId" \
5  --partition-key-version 2 \
6  --throughput 10000

Hierarchical key 設定（C# SDK 範例）

 1var properties = new ContainerProperties("mycontainer",
 2    new[] { "/tenantId", "/deviceId" });
 3properties.PartitionKeyDefinitionVersion = PartitionKeyDefinitionVersion.V2;
 4var container = await database.CreateContainerAsync(properties);
 5
 6// 寫入時帶完整 hierarchical key
 7var pk = new PartitionKeyBuilder()
 8    .Add("tenant-123")
 9    .Add("device-456")
10    .Build();
11await container.CreateItemAsync(item, pk);
12
13// Prefix query：拿 tenant-123 的所有 device
14var prefixPk = new PartitionKeyBuilder()
15    .Add("tenant-123")
16    .Build();
17var iterator = container.GetItemQueryIterator<Item>(
18    "SELECT * FROM c",
19    requestOptions: new QueryRequestOptions { PartitionKey = prefixPk });

Synthetic key 寫入

application 端 hash + random suffix、寫入時組合成 partition key：

 1import hashlib
 2import random
 3
 4def get_partition_key(user_id, fanout=100):
 5    suffix = random.randint(0, fanout - 1)
 6    return f"{user_id}_{suffix}"
 7
 8# Read 時 fan-out 所有可能 suffix
 9def read_user_data(user_id, fanout=100):
10    results = []
11    for suffix in range(fanout):
12        pk = f"{user_id}_{suffix}"
13        results.extend(query_partition(pk))
14    return results

注意 fanout 的 trade-off：fanout = 100 等於 read 成本 × 100；要在 write 分散 跟 read 效率 間平衡、通常 fanout 10-100 之間。

查 partition 分布

portal Metrics > Storage by partition key、看分布是否均勻；或用 SELECT * FROM c WHERE c.partitionKey = "specific-value" query + diagnostic log 看 RU 分布。

驗證點

• 每個 logical partition 的 RU 消耗 < 80% limit（給 burst 留 20% buffer）
• 單一 partition 的 storage < 16 GB（給成長預留 4 GB buffer）
• p99 latency 在 hot partition 不退化
• 跨 partition query 比例 < 5%（多數 query 帶 partition key 條件）

Rollback boundary

partition key 選錯只能 export → recreate container with new partition key → import；無 in-place migration、生產系統等於停機窗口 + dual-write cutover 流程。對應 1.12 大規模 DB 遷移實戰 的遷移模型。

失敗模式

Failure 1：user_id 直接當 partition key

高活躍用戶（VIP / bot / 大客戶）超過 10,000 RU/s、全 container 被 throttle；徵兆是 429 TooManyRequests 集中在少數 partition、整體 RU 利用率才 30%。

修：

• 短期：把 hot user 拉到獨立 container（合規上有時要這樣做、把 VIP / 企業客戶獨立治理）
• 長期：換 synthetic key（user_id + random suffix）或 composite key（tenant + user）
• selection 階段 audit：access pattern 是否會有「少數 user 主導流量」現象（B2B SaaS、VIP 用戶都有）

Failure 2：時間當 partition key

/createdDate 或 /yyyyMM、新資料全寫入最新 partition、舊 partition 冷掉浪費 — write hot + read 不均。徵兆：最新月份 partition throttle、其他月份 partition 閒置。

修：時間 + 業務維度組合（如 /yyyyMM-userId、/userId-yyyy）、避免純時間維度。time-series workload 該考慮 Azure Time Series Insights 或 Cosmos DB time-series 專屬模式。

Failure 3：Synthetic key 沒考慮 read 路徑

寫入散開但 read 必須 fan-out 100 partition、單一 query RU 暴漲 100x。徵兆：read 成本遠高於估算、RetrievedDocumentCount 跟 OutputDocumentCount 比例 > 50。

修：

• 用 Change Feed 把投影預先寫到 read-optimized container（partition key 用 user_id）、read 走投影
• 或調 fanout（10 而非 100）、平衡 write 分散跟 read 成本
• 或重新評估「真的需要 synthetic key 嗎」 — 多數場景用 composite 就夠

Failure 4：Hierarchical key 設計順序顛倒

把 high-cardinality 放第一層、prefix query 變得無意義。如 /userId/tenantId 而非 /tenantId/userId — 想拿「tenant X 的所有 user」變成 cross-partition query、完全失去 hierarchical 優勢。

修：設計順序從 低 cardinality 到 高 cardinality、跟業務 query pattern 對齊。建 container 前畫 access pattern 表、列每個 query 的 hierarchy 順序、再決定 partition key path。

Failure 5：不監控 partition 分布

partition skew 累積幾個月、直到事故才發現。production 上線初期 access pattern 還不明顯、半年後 VIP 客戶開始用、partition 失衡 — 來不及改 partition key、只能在 throttle 中應急。

修：上線第一天就設 alert：

• 單 partition RU 利用 > 80% 持續 5 min
• 單 partition storage > 16 GB
• 429 error rate 突增

每週看 portal Insights > Top contributors > Partition key range、early detect skew。

Failure 6：Container 之間 partition 設計不一致

跨 container query 需要 fan-out、cross-partition query 成本爆炸。常見 anti-pattern：訂單 container 用 user_id、商品 container 用 product_id、join 訂單 + 商品時兩邊都 cross-partition。

修：跨 container 的 access pattern 在 selection 階段就要設計、不能各 container 各自決定 partition key。或者用 Change Feed 把跨 container 資料合成 single container 的 materialized view。

容量與觀測

• 必看 metric：PhysicalPartitionThroughputInfo、NormalizedRUConsumption per partition、StorageDistributionPerPartition
• Hot partition 偵測：portal Insights > Top contributors > Partition key range
• 容量估算公式：peak RU per partition × partition 數 + 預留 buffer（一般 30%）= total RU/s
• 回 9.4 Saturation Discovery：把 partition skew 當 saturation signal
• Alert：單 partition RU 利用 > 80% 持續 5 min；429 error rate 突增

Latency budget 拆解：vendor SLA vs end-to-end 實測

9.C21 ASOS 觀察「48ms 平均響應 = 全球分散下 Cosmos DB 的代表性數字」段揭露：48ms 包含 網路 + DB + 應用層、DB 本身可能只佔 5-10ms、其他是網路與應用層。引用時不能把 vendor 廣告的 5-10ms p99 當「使用者體驗」、要明示「48ms 是 9.C21 ASOS 案例的 end-to-end 觀察、Cosmos DB 自身可能只佔 5-10ms（case 揭露的拆解推論、不是 case fact）」。

操作上要把 end-to-end latency 拆 budget：

• DB 端 latency（vendor SLA、p99 < 10ms 地區內讀、9.C11 揭露）
• 跨 region replication latency（multi-region read 從就近 region 拿、不會跨洲、但 cross-region write 不同、見 multi-region-write-conflict）
• 應用層 latency（serialize / business logic / HTTP overhead）
• 客戶端網路 latency（mobile / 跨洲）

跟 partition skew 的關係：partition 失衡時即使 vendor 端 SLA 達標、實測 p99 仍會被 hot partition 拉高 — 單一 partition 的 RU consumption 飽和 → 429 retry → 應用層 latency 暴漲 → end-to-end 從 48ms 變 500ms。partition 設計直接影響 end-to-end SLA 鏈路。

邊界與整合

• Sibling deep articles：ru-cost-model-sizing（partition skew 直接影響 RU sizing）、consistency-levels-engineering（partition 失衡時即使設 Strong 也看到 throttle）、multi-region-write-conflict（partition key 影響 conflict 分布）、mongodb-api-vs-sql-api（MongoDB shard key → Cosmos DB partition key 翻譯）
• 跟 DynamoDB vendor 對比：partition key + adaptive capacity vs 不可逆 + hierarchical
• 跟 MongoDB vendor 對比：reshardCollection 可逆 vs 不可逆
• 跟 1.x 章節：1.10 KV / Document DB 容量規劃 / 1.12 大規模 DB 遷移實戰
• Knowledge cards：Hot Partition / Database Sharding
• Anti-recommendation：小流量（< 1000 RU/s 預期）不必過度設計 synthetic key、Cosmos DB autoscale + 簡單 partition key 即可；過度 design 比 under-design 更常見的成本浪費

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 partition key design backlog 的深度展開
• 9.C11 Minecraft Earth case — synthetic partition key 主案例
• 9.C21 ASOS case — latency budget 拆解 + 全球零售流量分散
• Hot Partition 卡片 / Database Sharding 卡片 — 概念基底
• 官方：Cosmos DB partitioning / Hierarchical partition keys

本文不是 Cosmos DB overview（請看 Cosmos DB vendor 頁）— 而是 consistency level 工程選擇邏輯 的深度展開。Case anchor 是 9.C11 Minecraft Earth（用 session consistency 撐 AR 全球同步、5 level 跨 collection 分流）+ 9.C21 ASOS（Black Friday 用較弱 consistency 換 throughput）。

Cosmos DB workload 適配判讀（四層 framing）：API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in — 判讀軸詳見 mongodb-api-vs-sql-api 開頭四層 framing。本文聚焦 consistency level 選擇操作層、是 已選 Cosmos DB 後 的 read / write 語義決策；若 workload 不適用 Cosmos DB、level 選擇無法救回 vendor 選錯的取捨。

問題情境

典型觸發場景：team 啟動 Cosmos DB account、setup wizard 問「預設 consistency level」 — 5 個選項、文件講概念、不知道實際業務該選哪個。production 上線後使用者反映「加入購物車後立刻看『我的購物車』讀到舊狀態」、「跨 region 看到玩家瞬移回舊位置」 — debug 發現是 consistency level 沒選對。

讀者徵兆：

• 「Session 跟 Eventual 看起來差不多、為什麼 Session 是預設」
• 「Bounded staleness 的 K 跟 T 該設多少」
• 「Strong 在 multi-region account 為什麼有額外限制」
• 「跨 region read 拿到舊版本、是 consistency 設錯還是 partition key 問題」

真實壓力：

• 購物車場景：加入購物車後立刻看「我的購物車」、結果讀到舊狀態（user 體驗破洞）
• 遊戲場景：玩家位置同步、跨 region 看到「玩家瞬移」回舊位置（遊戲體驗 bug）
• 金融場景：跨服務寫入後立即 read confirm、看不到剛寫的 — 業務邏輯誤判「沒寫進去」、重試 / rollback

consistency level 選錯不是 config 問題、是 影響 user-facing 行為 的 selection 決策、必須在 selection 階段釐清。

核心機制：5 個 level 的精確語義

Strong

• 機制：read 拿到最新 commit、提供 linearizable read
• 限制：single-write region 限制；multi-region write 不可同時用 Strong（時間敏感 claim、查 最新文件）；跨 region 配 Strong 還要付 Cross-Region Quorum 的物理 latency tax（跨洲 100-200ms）
• 適合：金融交易、庫存扣減、status 機器寫後 read confirm
• 為什麼互斥：詳見 multi-region-write-conflict 的 AP 取捨段、本篇不展開

Bounded staleness

• 機制：read 落後 不超過 K 個 version 或 T 秒（取較嚴格者）；單 region 內 linearizable、跨 region 有 bounded lag、跟 Freshness Token 是兩種「跨層 read-after-write」協議的選擇（前者 vendor 內建、後者 application-level）
• 設定：K（version 上限）+ T（時間上限）兩個參數
• 適合：multi-region 但需要「有 bound 的 staleness 保證」、如 trading system 跨 region read with SLA

Session（預設、最常用）

• 機制：同一 session token 內讀寫一致；session 之外 eventual
• 適合：多數互動式產品的甜蜜點 — 使用者寫入後自己立刻讀得到、其他 session 可接受 eventual
• 為什麼是預設：cost 接近 eventual（不像 Strong 多 2x RU）、體驗接近 Strong（自己讀寫一致）— 是 trade-off 的甜蜜點

Consistent prefix

• 機制：read 不會看到亂序的寫入（看到 A→B→C、不會看到 A→C→B）、但可能落後
• 適合：時序敏感但可 stale 的場景（如新聞 feed 不能跳序、但可以晚幾秒）
• 風險：常被誤用為 Session 替代、跨 session 一樣 stale、但比 Eventual 多保證 順序

Eventual

• 機制：最便宜、無順序保證
• 適合：完全可 stale + 不需順序的場景（分析、log 聚合、推薦系統）

跟 Cosmos DB account / container 的關係

• account 預設一個 level
• 單一 request 可以 降級（讀更弱 level）、不可升級（讀更強）
• container 層 無法獨立設定 consistency level（時間敏感、查最新文件）— 分流靠 collection 切分 + per-request override

RU 成本差異

• Strong / Bounded read ≈ 2x Session / Eventual 的 Request Unit
• write 成本不直接受 read level 影響、但 multi-region replication 開銷會（每多一個 region、寫成本 ×N）
• selection 階段要把 consistency level 當「RU 倍數」進入容量公式、見 ru-cost-model-sizing

跟通用 consistency 卡片的對應

Cosmos DB 是 少數把 5 level 都商品化 的服務、其他系統通常只給 2-3 級（MongoDB read concern majority / local / linearizable、DynamoDB strong / eventual）。對應 consistency-level 卡片的概念分層。

跟 linearizability 的關係：Cosmos DB Strong = single-region linearizable、不是 跨 region external consistency（跟 Spanner 的 TrueTime + Paxos 不同）。這個區別是 selection 階段的常見誤判 — 別把 Cosmos DB Strong 當成 Spanner 替代品。

對應 knowledge cards：consistency-level / linearizability / stale-read。

進階設計策略：同一 application 內不同操作選不同 level

9.C11 Minecraft Earth 案例的平台特性段揭露「一致性是 spectrum、不是 binary」 — AR 遊戲玩家位置稍 stale OK（用 session / eventual）、庫存交易需要 strong；同一 application 內不同 collection / container 配不同 consistency 是進階策略、不一定是 account 一刀切。

container 層無法獨立設定 consistency level（時間敏感、查最新文件）、所以分流靠：

• Collection / container 切分：高一致需求的資料放獨立 account、預設 Strong；低一致需求放另一 account、預設 Session
• Per-request override：account 預設 Session、特定「寫入後立即讀」場景升 Bounded、批次分析降 Eventual；用 SDK 的 RequestOptions.ConsistencyLevel

Per-request override 範例（C# SDK）

 1// account 預設 Session
 2// 但這個 read 需要 Bounded staleness
 3var response = await container.ReadItemAsync<Item>(
 4    id: "item-123",
 5    partitionKey: new PartitionKey("user-456"),
 6    requestOptions: new ItemRequestOptions {
 7        ConsistencyLevel = ConsistencyLevel.BoundedStaleness
 8    });
 9
10// 批次分析、降到 Eventual 換成本
11var queryOptions = new QueryRequestOptions {
12    ConsistencyLevel = ConsistencyLevel.Eventual
13};
14var iterator = container.GetItemQueryIterator<Item>(query, requestOptions: queryOptions);

注意 不可升級 的限制：account 預設 Eventual、per-request 不能升 Strong（會 error）。要保留升級彈性、account 預設應該是 最強需要的 level、再 per-request 降級。

跟 partition-key-design 的關係

partition 失衡時即使設 Strong consistency 也看到 throttle、application 看到的是 429 retry 後的高 latency、不是 stale data — consistency level 跟 partition key 共同決定 真實一致性體驗。partition skew 把 Strong 的 SLA 拉到比 Session 還差、見 partition-key-design 的 latency budget 拆解段。

操作流程

account 層設定

1# Portal / ARM template / CLI
2az cosmosdb update --name mycosmos --resource-group myrg \
3  --default-consistency-level Session

切換 level 是即時生效、但 production 切換需要 audit 所有 client 的 session 邏輯（特別是 Strong → Session 的降級會讓「跨 session read 變 stale」）。

Request 層 override

SDK 傳 RequestOptions.ConsistencyLevel（C# / Java / Node SDK 行為一致）。注意 只能降級、升級會 reject。

Session token 管理

每個 read response 帶 session token、client 下次 read 帶回去；跨 service 共享 token 需要顯式傳遞（不然每個 service 自己一個 session）。

 1// 拿到 session token
 2var response = await container.ReadItemAsync<Item>(id, pk);
 3var sessionToken = response.Headers["x-ms-session-token"];
 4
 5// 跨 service 傳遞（如 HTTP header）
 6httpClient.DefaultRequestHeaders.Add("X-Cosmos-Session-Token", sessionToken);
 7
 8// 下游 service 取得 token、用在 SDK request
 9var requestOptions = new ItemRequestOptions { SessionToken = sessionToken };
10var downstreamResponse = await container.ReadItemAsync<Item>(id, pk, requestOptions);

驗證 level 行為

寫入後立即 read 同 partition key、量 staleness window。用 Cosmos DB Diagnostic Log 看 request 的實際 consistency level；對照 SDK 設定確認沒被預設 override。

Rollback boundary

account 預設可改、但 production 切換 level 需要 audit 所有 client 的 session 邏輯；container 層無法獨立設定（時間敏感、查最新文件）。

失敗模式

Failure 1：全用 Strong consistency

互動式產品 Session 即足夠、用 Strong 浪費 2x RU + 限制 multi-region write、cost 暴漲且 multi-region 配置受限。徵兆是「RU consumption 明顯偏高、且 multi-region write 開不起來」 — 才發現預設選 Strong。

修：

• 盤點業務需求、絕大多數讀寫場景 Session 就夠
• 把需要 Strong 的少數 collection 拆獨立 account、其他 default Session
• 計算 cost：Session vs Strong 在多數 workload 差距 1.5-2x、長期成本顯著

Failure 2：Session token 沒回傳

read 後拿 token、下次 read 沒帶、實際變 Eventual；徵兆是「自己的寫立刻 read 看不到」、debug 才發現 SDK 設定漏。SDK 預設會自動管理 session token、但跨 service 傳遞時容易漏。

修：

• 同一 service 內用 SDK 預設行為、不要關 session token cache
• 跨 service 通信時把 session token 隨 HTTP header 傳遞
• 或改 account 層 Bounded staleness（提供跨 session 的 K/T bound、不依賴 token）

Failure 3：跨 service 共享 session 假設

service A 寫、service B 讀、B 沒拿到 A 的 session token → 看不到 A 的寫。常見場景：order service 寫訂單、notification service 立刻 read 訂單寄通知 — notification 沒拿到 order 的 token、讀到舊狀態（或讀不到）。

修：

• service A 寫完、把 session token 進 message（Kafka event / HTTP response）傳給 B
• B 用 token 做 read、保證讀到 A 的寫
• 或業務上接受 eventual、design notification 有 retry / reconcile 機制

Failure 4：Bounded staleness 設太鬆

K = 100,000、T = 1 hour、實際等於 Eventual、team 以為自己有保護。bounded staleness 的 K/T 要對應業務 SLA、不是 vendor 預設值。

修：

• 根據業務 read-after-write SLA 設 T（如「5 秒內必須讀到」設 T=5）
• K 通常設成「peak QPS × T」的合理倍數
• 量測：production 觀察實際 staleness 分布、調整 K/T

Failure 5：multi-region write 配 Strong

文件不允許 / 行為退化（時間敏感、查最新）— 必須改 Bounded / Session。這是 AP 取捨的硬約束、不是 config 問題；詳見 multi-region-write-conflict 的 AP 取捨段。

修：在 selection 階段就決定「要 active-active write 還是要 Strong」、不能事後補；要全球 linearizable 轉 Spanner / Aurora DSQL、要 active-active 接受 eventual / session / bounded。

Failure 6：Consistent prefix 誤用

把它當 Session 用、跨 session read 還是 stale、但比 Eventual 多一個順序保證；用錯地方等於浪費。常見誤判：「我要『順序對』、所以選 Consistent prefix」 — 但實際業務需求是「自己讀到自己寫的」、應該是 Session 而非 Consistent prefix。

修：

• Consistent prefix 適合 時序敏感但可跨 session stale 場景（新聞 feed、event log）
• 「自己讀到自己寫的」場景用 Session
• 跨 session 也要強一致用 Bounded / Strong

容量與觀測

• 必看 metric：NormalizedRUConsumption、TotalRequestUnits、ReplicationLatency（跨 region lag）
• Diagnostic Log：每個 request 的實際 consistency level、確認沒被預設 override
• 成本計算：Strong / Bounded read 算 2x RU；multi-region 開後寫入成本 × region 數；level 跟 region 數的 cost matrix 是規劃必算
• 回 9.6 容量規劃模型：consistency level 當「RU 倍數」進入容量公式
• Alert：
  • ReplicationLatency 突增（跨 region 同步異常）
  • Diagnostic log 偵測 Strong read 突增（成本失控）
  • 跨 service session token 缺失導致 stale read 比例上升

邊界與整合

• Sibling deep articles：partition-key-design（partition key 跟 consistency 共同決定真實一致性體驗）、ru-cost-model-sizing（RU 倍數量化）、multi-region-write-conflict（multi-region 下 consistency 的特殊行為、Strong + multi-region 互斥的 SSoT 主寫位置）、mongodb-api-vs-sql-api（MongoDB read concern → Cosmos DB consistency level 對應）
• 跟 Spanner vendor 對比：external consistency vs Cosmos DB Strong 不是同一個 thing
• 跟 DynamoDB vendor 對比：DynamoDB 只 strong / eventual 兩級、Cosmos DB 5 級提供細粒度
• 跟 1.x 章節：1.11 全球分散式 OLTP（Cosmos DB 5 level 跟 Spanner external consistency 並陳）
• Knowledge cards：consistency-level / linearizability / stale-read
• Anti-recommendation：別把 Cosmos DB Strong 跟 Spanner external consistency 等同視之；產品需要真正全球 linearizable transaction 時、Cosmos DB 不是替代品 — 轉 Spanner / Aurora DSQL

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 5 consistency levels backlog 的深度展開
• 9.C11 Minecraft Earth case — session consistency + 跨 collection 分流主案例
• 9.C21 ASOS case — 高 throughput + 較弱 level 補充
• multi-region-write-conflict — Strong + multi-region 互斥的 SSoT 主寫位置
• Consistency Level 卡片 / Linearizability 卡片 / Stale Read 卡片 — 概念基底
• 官方：Cosmos DB consistency levels / Consistency level overrides

Case anchor 是 9.C21 ASOS（85,000 SKU、每週新增 5,000 件的高更新頻率 catalog、寫入後需要 search index / 推薦排序投影）。ASOS case 本身沒有揭露 Change Feed 的實作細節、本文只取它的 catalog 寫入投影壓力當情境 anchor、機制以 Azure vendor 規格與通用工程展開。

問題情境

典型觸發場景：catalog 寫入 Cosmos DB 後、下游還有一連串工作要做 — 把商品同步到 search index、刷新推薦排序、讓 cache 失效、發 event 給庫存服務。團隊一開始把這些工作塞進寫入 API 的同步路徑、寫一筆商品要等 search index 更新完才返回、寫入 latency 被下游拖垮；高峰時下游 search service 變慢、整條寫入鏈一起阻塞。

讀者徵兆：

• 「寫入 API latency 被下游投影工作拖高、想把它非同步化」
• 「下游 consumer 掛掉一段時間、重啟後要怎麼補回漏掉的變更」
• 「同一筆 document 在短時間內改三次、下游只需要最終狀態還是每次都要」
• 「要做 audit / 要知道刪除事件、但 Change Feed 預設讀不到 delete」

真實壓力：寫入路徑與下游處理耦合會讓寫入 SLA 受制於最不穩的 consumer；而把投影改成「掃全表」的 batch job 又有延遲與成本問題。Change Feed 提供的是 持久、可重讀、按 partition 有序 的變更來源、讓下游用 pull 或 trigger 模式按自己的進度消費。

核心機制：partition-scoped persistent change log

Change Feed 是 container 的內建能力、把每個 logical partition 內的寫入按發生順序記錄成一條持久序列。它的關鍵語義有幾個面向。

順序保證是 per logical partition、不是 container 全域。同一 partition key 內的變更嚴格有序、跨 partition 之間沒有全域順序 — 這跟 partition-key-design 的設計直接相關、consumer 必須假設不同 partition 的事件可能交錯到達。

進度由 continuation token 表達。consumer 讀到哪裡、用一個 continuation token 標記；下次帶 token 回來、從上次的位置繼續。token 是 per partition range 的、container 做 partition split 時 token 要能跟著 range 拆分 — 這是 change feed processor 幫忙處理的部分。

讀取是 pull-based 持久來源、不是 push 通知。Change Feed 不主動推、是 consumer 主動拉。Azure Functions 的 Cosmos DB trigger 看起來像 push、底層仍是 trigger runtime 持續 poll Change Feed。

兩種模式：latest-version vs all-versions-and-deletes

Change Feed 有兩種模式、語義差很大、選錯會在 audit / 補償場景出問題（模式名稱與可用性屬時間敏感、查 最新文件）。

Latest-version 模式（過去稱 incremental feed）只給每個 document 的 最新狀態。同一 document 在兩次消費之間改了三次、consumer 只會看到最後一個版本、中間版本看不到；delete 也看不到（document 消失、feed 裡沒有對應的 tombstone）。這個模式適合「我只要把最終狀態投影到下游」的場景 — search index 同步、cache 刷新、物化視圖更新。

All-versions-and-deletes 模式給 每一次 變更、包含中間版本與 delete / TTL 過期事件。同一 document 改三次、feed 給三筆；刪掉給一筆刪除事件。這個模式適合需要完整變更歷史的場景 — audit log、event sourcing、需要對 delete 做反應的跨 store 同步。代價是事件量更大、且這個模式對 retention 與 partition 行為有額外約束（時間敏感、查文件）。

選擇判準：問「我需要中間版本與刪除事件嗎」。投影類工作（只要最終狀態）用 latest-version；audit 與需要對刪除反應的同步用 all-versions-and-deletes。預設選 latest-version、只有明確需要歷史與 delete 時才升級。

change feed processor 的角色

直接讀 Change Feed 要自己管 partition range、lease、continuation token、failover — 這些 plumbing 用 change feed processor library 處理。它的核心元件是 lease container：一個獨立的 Cosmos DB container、記錄每個 partition range 由哪個 consumer instance 處理、處理到哪個 continuation token。多個 consumer instance 共用同一個 lease container 時、processor 自動把 partition range 分配到不同 instance、達成水平擴展與 failover。

操作流程

啟用與確認

Change Feed 對 SQL API container 是預設啟用的、不需要額外開關（latest-version 模式）。all-versions-and-deletes 模式需要在 container 層設定、且要設 retention window。

1# 確認 container 存在、Change Feed 自動可用（latest-version）
2az cosmosdb sql container show \
3  --account-name mycosmos --resource-group myrg \
4  --database-name catalog --name products \
5  --query "resource.id"

驗證：container 存在即可讀 latest-version feed。要用 all-versions-and-deletes、先確認 account / SDK 版本支援（時間敏感、查文件）並設好 retention。

change feed processor（C# SDK）

 1// lease container 獨立於 monitored container
 2Container monitored = client.GetContainer("catalog", "products");
 3Container leases = client.GetContainer("catalog", "leases");
 4
 5ChangeFeedProcessor processor = monitored
 6    .GetChangeFeedProcessorBuilder<Product>(
 7        processorName: "search-index-sync",
 8        onChangesDelegate: HandleChangesAsync)
 9    .WithInstanceName(Environment.MachineName)  // 每個 instance 唯一
10    .WithLeaseContainer(leases)
11    .Build();
12
13await processor.StartAsync();
14
15async Task HandleChangesAsync(
16    IReadOnlyCollection<Product> changes,
17    CancellationToken ct)
18{
19    foreach (var product in changes)
20    {
21        // 投影到 search index — 必須 idempotent
22        await searchIndex.UpsertAsync(product);
23    }
24    // delegate 正常返回 = processor 自動推進 lease 的 continuation token
25}

驗證：lease container 內會出現每個 partition range 的 lease document、ContinuationToken 欄位隨消費推進；多開一個 instance、觀察 lease 被重新分配到兩個 instance。失敗時 delegate 拋例外、processor 不推進該 range 的 token、下次重讀同一批（at-least-once、所以 handler 要 idempotent）。

Azure Functions trigger（消費端最省維運的形態）

 1[FunctionName("SyncSearchIndex")]
 2public static async Task Run(
 3    [CosmosDBTrigger(
 4        databaseName: "catalog",
 5        containerName: "products",
 6        Connection = "CosmosConnection",
 7        LeaseContainerName = "leases",
 8        CreateLeaseContainerIfNotExists = true)]
 9    IReadOnlyList<Product> changes,
10    ILogger log)
11{
12    foreach (var p in changes)
13        await searchIndex.UpsertAsync(p);  // idempotent
14}

Functions trigger 底層就是 change feed processor、lease 與 scale-out 由 Functions runtime 管。驗證：function 的 invocation count 隨寫入增加、Application Insights 看 changes batch size 與 lag。

Rollback boundary

Change Feed 是讀取側機制、停掉 consumer 不影響寫入。要重放：刪掉 lease container 的對應 lease（或建新 processor name）會從 container 起點或指定時間點重讀。重放前確認下游投影是 idempotent、否則重放會重複寫。

失敗模式

把 handler 寫成非 idempotent

Change Feed 是 at-least-once。consumer 在處理一批後、推進 token 前 crash、重啟會重讀同一批。handler 若是「append 一筆 audit row」這種非 idempotent 操作、重放會產生重複。徵兆是下游出現重複事件、且重複數對應 consumer 重啟次數。修法是讓投影用 upsert（以 document id + version 為 key）、audit 用 dedup key、發 event 帶 idempotency key 讓下游去重 — 對應 idempotency 的設計。

用 latest-version 模式卻期待看到 delete

team 用預設 latest-version feed 做跨 store 同步、上線後發現「source 刪掉的 document、target 還在」。latest-version 模式不發 delete 事件、刪除在 feed 裡是「該 document 不再出現」、consumer 無從得知。修法是 audit / 需要刪除反應的場景改 all-versions-and-deletes 模式；或在 application 層用 soft delete（寫一個 deleted: true 的版本、latest-version feed 就看得到這次寫入）。

lease container 配置不足成為瓶頸

lease container 自己也吃 RU、且 processor 對它有頻繁讀寫。lease container RU 配太低、processor 推進 token 被 throttle、表現成 Change Feed 消費 lag 升高、但 monitored container 看起來健康。徵兆是消費 lag 持續增長、診斷發現 429 來自 lease container 而非 source。修法是給 lease container 足夠 RU、把它跟 source container 的容量分開規劃、見 ru-cost-model-sizing。

假設 Change Feed 有跨 partition 全域順序

consumer 假設事件按全域時間到達、做了依賴順序的邏輯（例如「先建立帳號事件、後消費事件」）。Change Feed 只保證 per logical partition 有序、跨 partition 交錯。徵兆是偶發的「後續事件先到、依賴的前置事件後到」。修法是讓有順序依賴的 document 落在同一 partition key、或在 consumer 端用業務 timestamp / version 做排序與 buffer、不依賴 feed 到達順序。

Anti-recommendation：不是所有「寫入後工作」都要 Change Feed

寫入後若只是同一 request 內、同一 partition 的小量同步工作、直接在 application 寫入路徑處理、或用 stored procedure 在 partition 內做（見 stored-procedure-trigger）更簡單。Change Feed 的價值在 解耦下游、可重放、水平擴展 — 當下游處理慢、會失敗、需要重放、或要被多個獨立 consumer 各自消費時才成立。下游工作輕、不需要重放、強耦合在寫入語義內時、引入 Change Feed + lease container 是多一層維運成本。

容量與觀測

• 必看 metric：Change Feed 消費 lag（最新寫入時間 vs consumer 已處理位置）、processor 每批 changes 數量、lease container 的 NormalizedRUConsumption
• consumer 端 throughput 受 partition range 數限制 — 並行度上限約等於 physical partition 數；range 不夠多時加 consumer instance 不會更快
• 成本：Change Feed 讀取本身吃 RU、all-versions-and-deletes 模式事件量更大、lease container 額外 RU — 三項都進容量公式、見 ru-cost-model-sizing
• 回 9.6 容量規劃模型：把 Change Feed consumer 當獨立 throughput 單位、不要跟 OLTP 寫入共用同一個 RU budget 估算
• Alert：消費 lag 持續增長（consumer 跟不上寫入）、lease container 429、handler 例外率上升

邊界與整合

• Sibling deep articles：stored-procedure-trigger（partition 內同步邏輯 vs Change Feed 的非同步解耦）、synapse-link-federation（分析 workload 用 analytical store、不要用 Change Feed 自己搭 analytics pipeline）、partition-key-design（per-partition 順序的來源）、ru-cost-model-sizing（Change Feed + lease container 的 RU 成本）
• 跟 DynamoDB Streams 對照：兩者都是 partition-ordered 變更 log + at-least-once consumer。差異在 DynamoDB Streams 有固定 24 小時 retention、原生發 INSERT / MODIFY / REMOVE（含 delete）；Cosmos DB latest-version 模式預設不發 delete、要 all-versions-and-deletes 模式才有完整事件與 delete。從 DynamoDB Streams 思維過來的 team 容易假設「delete 一定看得到」、要先確認模式。對照 DynamoDB vendor
• Knowledge card：Change Data Capture / idempotency
• 回 overview：Cosmos DB vendor overview 的「忽略 Change Feed」常見陷阱

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 Change Feed backlog 的深度展開
• 9.C21 ASOS case — 高更新頻率 catalog 投影壓力的情境 anchor
• stored-procedure-trigger — partition 內同步邏輯的對照
• partition-key-design — per-partition 順序的設計來源
• DynamoDB vendor — DynamoDB Streams 對照
• Change Data Capture 卡片 / Idempotency 卡片 — 概念基底
• 官方：Change feed in Azure Cosmos DB / Change feed processor

本文沒有專屬 production case anchor：stored procedure 的設計取捨在公開 case 庫覆蓋稀薄、機制以 Azure vendor 規格與通用工程展開、情境用 partition 內原子交易這個具體需求驅動。

Scope warning：本文涉及的 script 大小上限、執行時間上限、bounded execution 行為等具體限制屬時間敏感、不同 account 配置可能不同、實作前以 Cosmos DB stored procedure 官方文件 cross-verify。

問題情境

典型觸發場景：業務需要「讀一筆庫存、檢查數量、扣減、寫一筆扣減記錄」這四步必須原子完成 — 中間不能被別的請求插入。用 application 層 SDK 做、四步是四個獨立 round-trip、中間有 race window；兩個請求同時扣同一筆庫存、可能都讀到 10、各扣 1、結果是 9 而非 8。這類 read-modify-write 在同一 partition 內、需要 server-side 原子性。

讀者徵兆：

• 「同一 partition 內的 read-modify-write 有 race、想要原子交易」
• 「想做批次 upsert、減少 round-trip 與 RU」
• 「想在寫入時自動加 timestamp / 算衍生欄位、用 pre-trigger 行不行」
• 「stored procedure 能不能跨 partition 做交易」（不行 — 這是常見誤解）

真實壓力：Cosmos DB 的 transaction 邊界是 single logical partition、跨 partition 沒有原生 ACID 交易。partition 內需要原子性時、SDK 多次 round-trip 無法保證、stored procedure 是 vendor 提供的 partition-scoped transaction 機制。但這個能力有強約束、且容易被濫用成「把業務邏輯都搬進 DB」。

核心機制：partition-scoped JavaScript execution

Cosmos DB 的 server-side 邏輯有三類、責任不同。

Stored procedure 是執行在單一 logical partition 內的 JavaScript 函式、它內部對該 partition 的所有 document 操作包在一個 隱式交易 裡 — 全部成功 commit、任一失敗整個 rollback。呼叫時必須指定 partition key、procedure 的所有操作都限定在那個 partition。

Trigger 分 pre-trigger 與 post-trigger、綁在 create / replace / delete 等操作上、但 不會自動觸發 — 必須在 request 明確指定要跑哪個 trigger（這跟關聯式 DB 的 trigger 自動執行不同）。pre-trigger 在操作前跑（常用來補欄位、驗證）、post-trigger 在操作後跑（常用來更新同 partition 的彙總 document）。

UDF（user-defined function）是 query 內可呼叫的純函式、用來在 query projection / filter 階段做自訂計算、沒有寫入能力。

交易邊界與 bounded execution

交易嚴格限 single logical partition。stored procedure 不能跨 partition 寫、傳不同 partition key 的操作會失敗。跨 partition 的原子需求要改 workflow（saga / 補償）或重新設計 partition key 讓相關資料同 partition、見 partition-key-design。

執行有 bounded execution 限制：每次呼叫有時間與 resource 上限（時間敏感、查文件）、跑太久 Cosmos DB 會中止。處理大量 document 的 stored procedure 必須自己檢查每個操作的回傳、發現「快到上限」時停下、回傳一個 continuation 標記、讓 client 帶著標記再呼叫一次 — 這個 continuation 模式是寫批次 stored procedure 的必備 pattern。

RU 成本

stored procedure 內每個 document 操作都吃 RU、整個 procedure 的 RU 是內部所有操作的總和、由 response header 回報。一個掃很多 document 的 procedure 可能很貴、且因為 bounded execution 要分多次呼叫、成本與複雜度都比想像高、見 ru-cost-model-sizing。

操作流程

寫一個 partition-scoped 原子扣減

 1// deductStock.js — 在單一 partition 內原子扣減庫存
 2function deductStock(productId, qty) {
 3    var context = getContext();
 4    var container = context.getCollection();
 5    var response = context.getResponse();
 6
 7    var query = "SELECT * FROM c WHERE c.id = '" + productId + "'";
 8    var accepted = container.queryDocuments(
 9        container.getSelfLink(), query,
10        function (err, docs) {
11            if (err) throw err;
12            if (!docs || docs.length === 0)
13                throw new Error("product not found");
14
15            var product = docs[0];
16            if (product.stock < qty)
17                throw new Error("insufficient stock");  // 整個交易 rollback
18
19            product.stock -= qty;
20            var ok = container.replaceDocument(
21                product._self, product,
22                function (e) { if (e) throw e; });
23            if (!ok) throw new Error("replace not accepted");
24            response.setBody({ remaining: product.stock });
25        });
26    if (!accepted) throw new Error("query not accepted");
27}

註冊與呼叫（C# SDK）：

1await container.Scripts.CreateStoredProcedureAsync(
2    new StoredProcedureProperties("deductStock", File.ReadAllText("deductStock.js")));
3
4var result = await container.Scripts.ExecuteStoredProcedureAsync<dynamic>(
5    "deductStock",
6    new PartitionKey(productId),   // 必須指定 partition key
7    new dynamic[] { productId, 1 });

驗證：兩個並行請求扣同一筆、總扣減量等於兩次之和、不會 lost update（交易原子性）。庫存不足時拋例外、整個 procedure rollback、stock 不變。回傳 header 的 x-ms-request-charge 是這次交易的總 RU。

批次操作的 continuation 模式

掃多筆 document 的 procedure 要在 callback 內檢查回傳的 accepted、為 false（快到上限）時停下並回傳已處理數量、由 client loop 呼叫直到全部處理完。驗證：對一個大 partition 跑、觀察需要多次呼叫、每次回傳的已處理數累加到總數。

pre-trigger 補欄位

1function addTimestamp() {
2    var doc = getContext().getRequest().getBody();
3    doc.createdAt = new Date().toISOString();
4    getContext().getRequest().setBody(doc);
5}

呼叫時要明確指定 trigger、否則不執行：

1await container.CreateItemAsync(item, new PartitionKey(item.pk),
2    new ItemRequestOptions { PreTriggers = new[] { "addTimestamp" } });

驗證：帶 trigger 的寫入有 createdAt、不帶 trigger 的寫入沒有 — 確認 trigger 非自動。

Rollback boundary

stored procedure 本身的交易是 all-or-nothing、procedure 內拋例外即整個 rollback。部署層面：stored procedure / trigger 是 container 內的 resource、replace 即更新、delete 即移除、不影響 data。

何時用、何時不用

這是本文的主判讀段：多數應用邏輯放在 application 層更好、stored procedure 只有少數場景值得。

值得用 stored procedure 的條件：

• partition 內的多步原子交易 — read-modify-write、需要 all-or-nothing、且相關資料確實在同一 partition。這是 stored procedure 不可替代的能力。
• 省 round-trip 的批次操作 — 一次寫入幾百筆同 partition document、用 stored procedure 比幾百次 SDK 呼叫省 latency 與部分 RU overhead。

讓 application 層處理的條件（多數情況）：

• 業務邏輯複雜、會頻繁變動 — JavaScript stored procedure 的版本管理、測試、debug、observability 都比 application 層差；邏輯放 DB 內、CI / 單元測試 / log / APM 都接不上。
• 不需要原子性、或跨 partition — 跨 partition 的協調用 application 層 workflow 或 saga、stored procedure 做不到。
• 寫入後的非同步工作（投影、通知、同步）— 用 Change Feed 解耦、不要塞進 stored procedure 拖長寫入路徑。
• 衍生欄位 / 計算 — 簡單的放 application 層或 pre-trigger、複雜的不要進 DB 邏輯。

判讀句：stored procedure 的正當理由幾乎只有「partition-scoped atomicity」與「批次 round-trip 縮減」。看到「想把業務規則集中到 DB」「想讓 DB 自動做某件事」這類動機、優先回 application 層 — server-side JavaScript 的維護成本長期高於它省下的東西。

失敗模式

期待跨 partition 交易

team 把多個不同 partition key 的寫入放進一個 stored procedure、期待原子性。procedure 對非當前 partition 的操作會失敗。徵兆是「跨用戶 / 跨類別的原子操作報錯或部分寫入」。修法是重新設計 partition key 讓相關資料同 partition（若業務允許）、或改用 application 層補償 / saga workflow 處理跨 partition 一致性。

沒處理 bounded execution

批次 stored procedure 假設「一次呼叫處理完所有 document」、資料量大時被中止、只處理了一部分、client 以為全做完。徵兆是大 partition 上批次操作結果不完整、且沒有錯誤（procedure 被 bounded execution 截斷但回傳了部分成功）。修法是實作 continuation 模式、每個操作檢查 accepted、回傳已處理數、client loop 直到完成。

把可變業務邏輯固化進 stored procedure

把定價規則、折扣計算、狀態機這類會變的邏輯寫進 JavaScript stored procedure、之後每次改規則都要改 DB resource、無法走正常 application CI / code review / 測試流程、且 production debug 缺 log。徵兆是「改一個業務規則要動 DB、且改完不確定對不對」。修法是把邏輯搬回 application 層、stored procedure 只保留無法在 application 層做的 partition-scoped atomicity。

依賴 trigger 自動執行

從關聯式 DB 過來的 team 假設 trigger 像 SQL trigger 一樣自動跑、寫了 audit / 補欄位的 trigger 卻發現大部分寫入沒觸發 — 因為 Cosmos DB trigger 必須 per-request 指定。徵兆是「trigger 有時跑有時不跑」、實際是只有明確帶 trigger 的 request 才跑。修法是確認所有相關寫入路徑都指定 trigger、或把「必須每次都做」的邏輯放 application 層 / pre-trigger 並在 SDK wrapper 統一帶上。

容量與觀測

• 必看 metric：stored procedure 執行的 x-ms-request-charge（整個交易的總 RU）、執行例外率、bounded execution 中止比例
• 成本：一個掃多 document 的 procedure 可能比等量單筆操作貴、且 continuation 多次呼叫累加 — 把它當「一個複合操作的總 RU」進容量公式、見 ru-cost-model-sizing
• observability gap：stored procedure 內部沒有 application APM / structured log、debug 靠回傳 body 與例外訊息 — 這個 gap 本身是「邏輯不該放這裡」的訊號之一
• 回 9.6 容量規劃模型：partition-scoped transaction 的 RU 要算進該 partition 的 budget、熱門 partition 上跑重 procedure 會放大 hot partition、見 Hot Partition
• Alert：stored procedure 例外率上升、執行 RU 異常偏高、bounded execution 截斷比例升高

邊界與整合

• Sibling deep articles：change-feed-cdc（寫入後的非同步工作走 Change Feed、不要塞 stored procedure）、partition-key-design（transaction 邊界 = partition 邊界、跨 partition 原子需求要重設計 partition key）、ru-cost-model-sizing（複合交易的 RU 估算）、consistency-levels-engineering（partition 內原子性 vs 跨 session consistency 是兩個不同議題）
• 跟 Spanner 對照：需要 跨 partition / 全域 ACID 交易時、Cosmos DB stored procedure 做不到 — 轉 Spanner vendor 或 Aurora DSQL
• 跟 DynamoDB 對照：DynamoDB 的 TransactWriteItems 提供跨 item（含跨 partition、有上限）的交易、語義跟 Cosmos DB 的 single-partition stored procedure 不同 — 從 DynamoDB transaction 過來的 team 要注意 Cosmos DB 沒有等價的開箱跨 partition 交易、見 DynamoDB vendor
• 回 overview：Cosmos DB vendor overview 的「跨 partition transaction 要改 workflow / stored procedure 邊界」

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 stored procedure / trigger backlog 的深度展開
• change-feed-cdc — 寫入後非同步工作的對照路徑
• partition-key-design — transaction 邊界 = partition 邊界
• ru-cost-model-sizing — 複合交易 RU 估算
• Spanner vendor / DynamoDB vendor — 跨 partition 交易能力對照
• Hot Partition 卡片 — 熱 partition 上的重交易放大效應
• 官方：Stored procedures, triggers, and UDFs

API 選擇判斷 本身（MongoDB API vs SQL API 的四層 framing、dogfood signal、multi-model、跨雲 hedging）由 mongodb-api-vs-sql-api 主寫、本文不重複展開那層對比；本文主寫 遷移流程 — 選定路徑後怎麼安全把資料與流量搬過去。

Case anchor：9.C30 Microsoft 365（MongoDB → Cosmos DB MongoDB API、planet-scale、dogfood）、9.C37 Forbes（自管 → Atlas、6 個月、同 DB 換託管的時程對照）、9.C36 Coinbase（保留 MongoDB 補周邊、對照「不一定要遷」）。Microsoft 365 case 自承沒揭露 throughput / latency / cost 數字、本文不拿它當 benchmark、只取遷移路徑 frame。

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

有效的遷移 driver 不是「Cosmos DB 比較好」、而是具體壓力：team 已綁 Azure 生態、需要 turnkey global distribution、自管 MongoDB / Cassandra cluster 的 ops 負擔要轉移、或需要 multi-model 把多個 NoSQL 集中治理。Microsoft 365 的 driver 是 planet-scale 全球分散 + Azure dogfood、不是 query 性能。

No-go condition（這些情況不該遷入 Cosmos DB）：

• 跨雲是核心需求 — Cosmos DB 只在 Azure；跨雲彈性高於 Azure 整合時、MongoDB 留 Atlas（Forbes 路徑、跨 AWS / GCP / Azure）、Cassandra 留自管或 ScyllaDB。
• 需要 native MongoDB / Cassandra 最新 feature — Cosmos DB 的 protocol-compat API server version 落後原生、且部分 feature 行為不同。
• 未來雲商策略未定 — hedging 價值高於當下整合、見 vendor lock-in 的退出成本。
• 現有 cluster 補周邊就夠用 — Coinbase 保留 MongoDB 加 proxy / cache / predictive scaling、沒遷出。遷移成本高、先確認「補周邊」解不了問題再遷。

Diff audit：6 維度分出兩條路徑

source（MongoDB / Cassandra）與 target（Cosmos DB）的差異按 6 維度盤點、兩條路徑的維度高低不同、這也是 type 判定的依據。

主導差異決定 type：

• protocol-compat 路徑 — 最大差異是 operational 與 data topology、paradigm 維持 Low、是 wire-compat 的 drop-in 但有相容 gap。對應 Type B drop-in（partial）：driver 不換、但每個 query pattern 要驗證相容性、不是無腦切換。
• native API 路徑 — paradigm High + application High、是 Type E paradigm shift：不只搬資料、要重寫 application 的整個 data access layer。

判讀句：protocol-compat 是「換底層儲存與運維、保留 query 介面」、native API 是「連 query 範式一起換」。多數遷移先走 protocol-compat 把資料與 ops 搬過去、native API 是後續若要拿完整 Cosmos feature（Change Feed、stored procedure 原生支援、SQL API query）才考慮的二次遷移 — 一次到位 native API 的工程複雜度與風險顯著更高。

Cassandra 路徑的專屬差異

Cassandra → Cosmos DB Cassandra API 跟 MongoDB 路徑有一個關鍵不同：Cassandra 的資料建模是 query-driven（partition key + clustering key 對應 access pattern）、這套建模思維跟 Cosmos DB 的 logical partition 概念部分對齊、但 Cosmos DB 的 per-partition RU 上限（目前約 10,000 RU/s、vendor 規格、實作時 cross-verify Azure doc 當前值）與 RU 計費會讓原本 Cassandra 上「寬 partition + 大量 clustering row」的設計變成 hot partition 風險。CQL 的 consistency level（QUORUM / LOCAL_ONE 等）要對應到 Cosmos DB 的 5 個 consistency level、語義不是一對一、見 consistency-levels-engineering。Cassandra 的 secondary index / materialized view 在 Cassandra API 的支援度要逐項驗證（時間敏感、查文件）。

Phase plan

兩條路徑共用大架構、protocol-compat 的相容 audit 較輕、native API 多一段 application 重寫。

protocol-compat 路徑（Type B drop-in）

• Phase 0：相容性 audit — 把 production query / aggregation pipeline（MongoDB）或 CQL statement（Cassandra）拉出來、逐條對照 Cosmos DB 對應 API 的 feature support 清單、列出 unsupported 與行為不同的部分。
• Phase 1：partition key 設計 — MongoDB shard key / Cassandra partition key 翻譯成 Cosmos logical partition key、檢查 10,000 RU/s 上限與 hot partition 風險、見 partition-key-design。
• Phase 2：bulk export-import — 初始資料用 Data Migration Tool / mongodump / sstable export 灌入。
• Phase 3：CDC sync — source 的持續變更（MongoDB oplog / Cassandra CDC）同步到 Cosmos DB、收斂初始 load 後的增量。
• Phase 4：shadow read — production query 在兩邊各跑一遍、對 result checksum、量 Cosmos 端 RU baseline、見 ru-cost-model-sizing。
• Phase 5：read cutover — 讀切 Cosmos、寫仍 source（可回退）。
• Phase 6：write cutover — 寫切 Cosmos。
• Phase 7：cleanup — 退役 source cluster、保留 export 與最終 checksum。

native API 路徑（Type E paradigm shift）多出的工作

native API 路徑在 Phase 0 與 Phase 1 之間插入 application 重寫 stream、與資料遷移 stream 並行：

• 重新建模 document（從 MongoDB document / Cassandra table 設計 Cosmos native shape、決定 embed vs reference）
• 重寫 data access layer（換掉 MongoDB driver / CQL、改用 Cosmos SQL API SDK、重寫所有 query）
• 重寫 aggregation（Cosmos SQL API 沒有 JOIN、aggregation 模型不同、部分邏輯移到 application 或用 stored procedure / Change Feed 物化）

這條 application stream 是 native API 路徑的主要風險與工期來源、必須跟資料遷移 stream 用獨立 owner 並行、shadow read 階段要對 重寫後的 query 與 原 query 的結果一致性、不只是資料一致性。

時程現實

Forbes 同 DB 換託管（自管 → Atlas、paradigm 不變）用 6 個月、中型團隊多 squad 並行。protocol-compat 遷入 Cosmos DB 的工程複雜度高於 Forbes 型（多了 RU / partition / region 範式與相容 gap）、native API 路徑再高一個量級（加 application 重寫）。拿 Forbes 6 個月當 native API 路徑 baseline 會從第一天 over-commit。

Evidence

每個 phase 用資料證明可前進、不靠感覺：

• Phase 0：unsupported feature 清單已窮舉、每條有對應策略（改寫 / 移 application 層 / 接受降級）
• Phase 2-3：row / document count 對齊、CDC replication lag 收斂到穩定
• Phase 4：query result checksum 一致（protocol-compat 比原 query 結果；native API 比重寫 query 與原 query 結果）、RU baseline 量到、aggregation result 逐條對齊
• Phase 5-6：error rate、p99 latency、RU consumption 在 cutover 後在預期範圍
• 對應 schema-migration-rollout-evidence 的 dual-write 驗證

Cutover

• read cutover window：先切讀、寫留 source、Cosmos 端 read error rate 與 latency 達標再進 write cutover
• write cutover window：read-only freeze < 10 分鐘、切寫、最終 checksum 對齊
• Rollback condition：query error rate 超過閾值（如 > 1%）、RU consumption 顯著高於估算（protocol-compat 翻譯層 overhead 比預期高）、或 result mismatch — 任一成立回退到 source、對應 rollback condition
• decision owner：cutover 期間誰有權回退要事前定、資料庫切流失敗代價高、不靠臨場判斷
• 不可逆點：API kind 是 account 層、建 account 時選定、無法事後切換 — protocol-compat 與 native API 是 兩個不同 account；選 protocol-compat 後想升 native API 是 export → 新 account → import + 重寫 application 的二次全量遷移、不是 in-place 升級。這個不可逆性要在 Phase 0 就決定方向、不能 cutover 後反悔

Cleanup

• 退役 source cluster 前確認最終 checksum、保留 export dump 90 天作為 rollback 後路
• 移除 dual-write writer、CDC connector、shadow read harness
• 保留 RU baseline 與 partition 分布觀測進 production dashboard、見 ru-cost-model-sizing
• incident write-back：把相容 gap 與翻譯層成本意外寫回 runbook、給未來同類遷移

失敗模式

假設 wire-compat = 100% 行為相同

protocol-compat API 是「在某些 query pattern 下相容」、不是普遍相容。MongoDB 的部分 aggregation stage（$graphLookup / $facet 等）、Cassandra 的部分 CQL feature 在對應 API 行為不同或不支援、dev 環境 sample data 看不出、production 才爆。修法是 Phase 0 把 所有 production query 拉出來逐條驗證、Phase 4 shadow read 對 checksum、不能假設相容。

shard key / partition key 直接照搬

MongoDB shard key 或 Cassandra partition key 直接當 Cosmos logical partition key、忽略 10,000 RU/s per partition 上限。原本 Cassandra 寬 partition 在 Cosmos 變 hot partition、throttle。修法是 Phase 1 按 Cosmos 的 partition 上限重新評估、必要時用 synthetic / composite key 強制分散、見 partition-key-design 與 Hot Partition。

把 native API 二次遷移當「升級」低估

選 protocol-compat 上線後、想拿 Change Feed / SQL query 等 native 能力、以為「升級到 SQL API」是改設定。實際是新 account + 全量資料遷 + application 重寫的第二次完整遷移。修法是 Phase 0 就決定終態方向 — 若終態確定要 native feature 且團隊能承擔重寫、直接走 native API 路徑、不要兩段遷。

consistency level 對應錯

CQL 的 QUORUM / MongoDB 的 read concern majority 直接假設等價於 Cosmos 某個 level、語義不是一對一。修法是按 consistency-levels-engineering 把 read-after-write 與順序需求逐場景對應、不照字面翻譯 consistency 名稱。

邊界與整合

• 主對比 SSoT：mongodb-api-vs-sql-api — API 選擇判斷 與三型遷移路徑分類在它主寫、本文主寫選定後的 遷移流程
• Sibling deep articles：partition-key-design（shard / partition key 翻譯）、ru-cost-model-sizing（翻譯層 RU overhead 與 baseline）、consistency-levels-engineering（read concern / CQL consistency 對應）、change-feed-cdc（native API 才有原生 Change Feed、是 native 路徑的 feature driver 之一）
• 不遷的對照：Coinbase 保留 MongoDB 補周邊 — 確認「補周邊」解不了再遷
• 跨雲對照：Forbes 留 Atlas 跨雲 — 跨雲需求是 Cosmos DB 的 no-go
• 共通遷移模型：1.12 大規模 DB 遷移實戰
• Knowledge card：vendor lock-in / Hot Partition
• 回 overview：Cosmos DB vendor overview 的「從 MongoDB / Cassandra 遷入」backlog

相關連結

• Cosmos DB vendor overview — 本文是該頁尾遷入 backlog 的深度展開
• mongodb-api-vs-sql-api — API 選擇判斷與三型遷移路徑 SSoT
• 9.C30 Microsoft 365 — MongoDB → Cosmos DB MongoDB API dogfood
• 9.C37 Forbes — 同 DB 換託管時程對照
• 9.C36 Coinbase — 保留 MongoDB 不遷的對照
• partition-key-design / ru-cost-model-sizing / consistency-levels-engineering — 遷移各 phase 的 sibling
• 1.12 大規模 DB 遷移實戰 — 跨 vendor 共通模型
• Vendor Lock-in 卡片 — 跨雲 no-go 判讀
• 官方：Migrate to Cosmos DB for MongoDB / Cosmos DB for Apache Cassandra

本文沒有專屬 production case anchor：Cosmos DB for PostgreSQL 的公開 case 覆蓋稀薄、機制以 Azure / Citus vendor 規格與分散式 PostgreSQL 通用工程展開、選型判準用「scale-out PG vs NoSQL vs single-node PG」這個具體決策驅動。

Scope warning：本文涉及的服務命名、node 規格上限、Citus 版本、PostgreSQL major version 支援屬時間敏感、Azure 服務命名歷史上有變動、實作前以 Cosmos DB for PostgreSQL 官方文件 cross-verify。

問題情境

典型觸發場景：team 在 Azure 上跑 PostgreSQL、單機 primary 撐到上限 — write throughput、資料量、或單表太大導致 index / vacuum / query 變慢。看到「Cosmos DB」以為是要把資料搬進 NoSQL、重寫 application 成 document model；或反過來、看到「Cosmos DB for PostgreSQL」以為它就是核心 Cosmos DB 的一個 PostgreSQL API、結果發現它是完全不同的東西。命名混淆讓選型從一開始就走偏。

讀者徵兆：

• 「單機 PostgreSQL 撐不住、但 application 是 SQL / JOIN / 交易重、不想重寫成 NoSQL」
• 「Cosmos DB for PostgreSQL 跟核心 Cosmos DB 是同一個東西嗎」
• 「它跟一般 Azure Database for PostgreSQL 差在哪、什麼時候才需要它」
• 「跟 CockroachDB / Aurora / Spanner 這些 distributed SQL 怎麼選」

真實壓力：SQL workload 撐到單機上限時、選錯方向的成本是年級的。誤以為要遷 NoSQL 而重寫 application 是浪費；誤以為核心 Cosmos DB 有「PostgreSQL 相容」而選錯產品也是浪費。正確的選型要先把這個服務放回它真正的分類 — 分散式 SQL、見 distributed SQL。

核心機制：Citus-based coordinator-worker 分散式 PostgreSQL

Cosmos DB for PostgreSQL 的底層是 Citus、把 PostgreSQL 從單機擴展成 coordinator + worker 的分散式叢集。它的關鍵概念有幾個。

它跑 真正的 PostgreSQL。不是 wire-compat、不是 PostgreSQL API on top of NoSQL — 是 PostgreSQL engine 加 Citus extension。標準 SQL、JOIN、ACID 交易、PostgreSQL extension 生態（含部分如 PostGIS）都在。這跟核心 Cosmos DB（自己的 query language、SQL-like 但無 JOIN、RU/s 計費）是根本不同的東西。

架構是 coordinator-worker。coordinator node 接 query、根據 distribution column 把 query 路由 / 拆分到 worker node、worker 存實際的 shard。application 連 coordinator、看起來像連一個 PostgreSQL。

distribution column 是核心設計決策、類比核心 Cosmos DB 的 partition key 之於 NoSQL、也類比 partition-key-design 講的分散原則。表按 distribution column 的值分片到 worker；同一 distribution column 值的 row 落在同一 shard。JOIN 與交易若在同一 distribution column 值內、可以下推到單一 worker 高效執行（co-location）；跨 distribution column 的 JOIN / 交易要跨 worker 協調、較貴。

表分三種：distributed table（按 distribution column 分片、大表用）、reference table（每個 worker 全複本、小的維度表用、讓 JOIN co-locate）、local table（只在 coordinator）。建模的關鍵是把常一起 JOIN 的大表用 同一 distribution column 分片、達成 co-location。

選型判準：三方對照

這是本文主判讀段。Cosmos DB for PostgreSQL 的正確位置是「single-node PG 不夠、但 workload 仍是 SQL 範式」的中間地帶。

選 Cosmos DB for PostgreSQL 的條件：

• workload 是 SQL 範式（關聯 schema、JOIN、交易）、不想 / 不能重寫成 NoSQL
• single-node PostgreSQL 已達上限（write throughput / 資料量 / 單表大小）、且資料有好的 distribution column（多租戶的 tenant_id、time-series 的某維度）
• 工作負載偏向多租戶 SaaS 或 real-time analytics over fresh data — Citus 的典型適配場景
• 想留在 PostgreSQL 生態（SQL、extension、既有 tooling）而非進 NoSQL

回核心 Cosmos DB（NoSQL）的條件：

• 資料形狀已是 document / KV、access pattern 固定、不需要 JOIN 與複雜 SQL
• 需要 multi-model（document + graph + KV）、5 個 consistency level、turnkey multi-region active-active write
• RU/s 容量抽象與 serverless 計費更符合 workload — 見 ru-cost-model-sizing

一般 Azure Database for PostgreSQL（single-node managed PG）就夠的條件：

• single-node 還沒到上限 — 多數 OLTP baseline 用 vertical scaling + read replica 就夠、不需要分散式
• 沒有好的 distribution column — 分散式 PostgreSQL 沒有均勻 distribution column 會 hot worker、好處拿不到、複雜度卻全付
• 不想承擔 distributed SQL 的複雜度（distribution column 設計、co-location 規劃、跨 shard query 成本）

判讀句：先確認 single-node PG 真的到上限、再確認 workload 是 SQL 範式（否則考慮 NoSQL）、最後確認有好的 distribution column。三個都成立、Cosmos DB for PostgreSQL 才是對的；缺任一個、回 single-node PG 或核心 Cosmos DB。

跟其他 distributed SQL 的位置

Cosmos DB for PostgreSQL 是 Azure 上、PostgreSQL-native、scale-out（co-location 設計驅動）的 distributed SQL。跟 Spanner（全球 external consistency、自己的 SQL 方言）、CockroachDB（跨雲、PostgreSQL wire、自動 range 分散）、Aurora DSQL（AWS、全球 active-active）位置不同：Cosmos DB for PostgreSQL 強在「真 PostgreSQL engine + extension 生態 + co-location 控制」、弱在它的分散需要 distribution column 設計（不像 CockroachDB / Spanner 自動分 range）、且綁 Azure。

操作流程

建叢集與設定 distribution column

 1-- 建 distributed table、按 tenant_id 分片（多租戶 SaaS 典型）
 2CREATE TABLE events (
 3    tenant_id   bigint NOT NULL,
 4    event_id    bigint NOT NULL,
 5    payload     jsonb,
 6    created_at  timestamptz DEFAULT now()
 7);
 8SELECT create_distributed_table('events', 'tenant_id');
 9
10-- 維度小表設 reference table、讓 JOIN co-locate
11CREATE TABLE tenants (tenant_id bigint PRIMARY KEY, name text);
12SELECT create_reference_table('tenants');

驗證：SELECT * FROM citus_tables; 看每張表的 distribution column 與 shard 分布；對 distributed table 的查詢若帶 distribution column filter、EXPLAIN 顯示下推到單一 shard、不帶則 fan-out 到所有 worker。

驗證 co-location

1-- 同 distribution column 的兩張 distributed table JOIN 應 co-located
2SELECT colocation_id, count(*)
3FROM citus_tables GROUP BY colocation_id;

驗證：常一起 JOIN 的大表落在同一 colocation group、JOIN 在 worker 本地完成、不跨 worker shuffle。

加 worker 擴容

加 worker node 後 rebalance shard。驗證：rebalance 後 shard 在新舊 worker 間分布均勻、單一 worker 不再是 hot spot。

Rollback boundary

Cosmos DB for PostgreSQL 是叢集級服務、scale worker 是運維操作、可逆（縮回去）。但 distribution column 一旦選定、改它要重建表 + 重灌資料 — 跟核心 Cosmos DB 的 partition key 不可改是同一類不可逆設計、見 partition-key-design。

失敗模式

把它跟核心 Cosmos DB 當同一產品選

選型時把「Cosmos DB for PostgreSQL」當成「核心 Cosmos DB 的 PostgreSQL 介面」、規劃用 RU/s、找 consistency level 設定、結果整套 mental model 對不上 — 因為它是分散式 PostgreSQL、用 node 規格計費、用 PostgreSQL 的交易隔離級別。修法是選型第一步就確認「這是分散式 SQL、不是 NoSQL」、規劃按 PostgreSQL + Citus 的模型走、不要套核心 Cosmos DB 的概念。

沒有好的 distribution column 硬上分散式

workload 沒有均勻的 distribution column（例如資料天然集中在少數 tenant）、硬分片後變 hot worker、分散式的好處拿不到、複雜度全付。徵兆是少數 worker CPU / IO 飽和、其他 worker 閒置。修法是選型階段就評估 distribution column 的 cardinality 與均勻度；不均勻時、要嘛留 single-node PG（垂直擴 + read replica）、要嘛重新設計 distribution column（如多租戶用 composite 或對 hot tenant 特殊處理）。

大量跨 shard query / 非 co-located JOIN

application query 大多不帶 distribution column filter、或常做跨 distribution column 的 JOIN、每個 query fan-out 到所有 worker + shuffle、latency 與成本都差。徵兆是 EXPLAIN 顯示 query 打所有 worker、p99 latency 高。修法是重新設計 schema 讓常一起查的表 co-located、把 distribution column 放進熱 query 的 filter；改不動時、這個 workload 可能不適合 scale-out PG、回 single-node 或考慮其他方案。

該用 NoSQL 卻選了分散式 PG（或反之）

document / KV、固定 access pattern、不需要 JOIN 的 workload 選了 Cosmos DB for PostgreSQL、付了 SQL / distribution column 設計的複雜度卻沒用到關聯能力 — 這類 workload 核心 Cosmos DB（NoSQL）更自然。反過來、SQL / JOIN / 交易重的 workload 被推去核心 Cosmos DB（NoSQL）要重寫成 document model 也是錯。修法是回到「workload 是 SQL 範式還是 document / KV 範式」的根本判斷、見本文選型判準段與 mongodb-api-vs-sql-api 的範式判讀。

Anti-recommendation：single-node PG 沒到上限不要上

分散式 PostgreSQL 帶來 distribution column 設計、co-location 規劃、跨 shard query 成本、rebalance 運維。single-node managed PostgreSQL 加 vertical scaling 與 read replica 能撐的 OLTP baseline 比多數團隊以為的大。沒有觸及 single-node 真實上限（write throughput 飽和、單表大到 maintenance 困難、資料量超出單機）就上分散式、是用複雜度換不存在的容量需求。

容量與觀測

• 必看 metric：各 worker node 的 CPU / IO / 連線（找 hot worker）、shard 在 worker 間的分布均勻度、跨 shard query 比例、coordinator 連線數
• 容量單位：node 規格（不是 RU/s）— 規劃是 coordinator + N worker 的 vCPU / memory / storage、跟核心 Cosmos DB 的 RU 思維完全不同、不要混用 ru-cost-model-sizing 的 RU 模型來估這個服務
• distribution column 均勻度是容量上限的真實決定因素 — 跟 Hot Partition 同模型、hot worker 讓名義叢集容量達不到
• 回 9.6 容量規劃模型：scale-out 的有效容量 = node 數 × 單 node 容量 × distribution 均勻度
• Alert：單一 worker 飽和（distribution skew）、跨 shard query 比例上升、rebalance 後仍不均

邊界與整合

• 定位釐清：本服務是 分散式 PostgreSQL、不是核心 Cosmos DB（NoSQL）— 共用品牌名稱、產品不同、選型不要混淆
• 跟核心 Cosmos DB 的分界：SQL / JOIN / 交易 + 到單機上限 → 本服務；document / KV / multi-model / multi-region active-active → 核心 Cosmos DB、見 mongodb-api-vs-sql-api
• 跟 PostgreSQL vendor 的分界：single-node 沒到上限 → Azure Database for PostgreSQL / 一般 PG；PostgreSQL 既有的 Specialized PostgreSQL Variants 段已把 Cosmos DB for PostgreSQL 列為 Citus-based 變體之一
• 跟其他 distributed SQL：Spanner（全球強一致）、CockroachDB（跨雲、自動 range）— 本服務強在真 PostgreSQL engine + co-location 控制、弱在需 distribution column 設計 + 綁 Azure
• distribution column 不可改：跟 partition-key-design 的 partition key 不可改是同類不可逆設計
• Knowledge card：distributed SQL / Hot Partition

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 Cosmos DB for PostgreSQL backlog 的深度展開
• mongodb-api-vs-sql-api — SQL 範式 vs document / KV 範式的根本判讀
• PostgreSQL vendor / Specialized PostgreSQL Variants — single-node PG 與 Citus 變體定位
• Spanner vendor / CockroachDB vendor — 其他 distributed SQL 對照
• partition-key-design — distribution column 不可改的同類設計
• Distributed SQL 卡片 / Hot Partition 卡片 — 概念基底
• 官方：Azure Cosmos DB for PostgreSQL / Citus distributed tables

Case anchor 是 9.C30 Microsoft 365 — Microsoft 自家把使用分析平台建在 Cosmos DB 上、planet-scale 全球分散式分析。case 自承沒揭露具體 throughput / latency / cost 數字、也沒明說用了 Synapse Link、本文只取「analytics workload 建在 Cosmos 上」這個情境 anchor、機制以 Azure vendor 規格與 HTAP / federation 通用工程展開。

問題情境

典型觸發場景：交易資料在 Cosmos DB、business 想跑分析 — 跨日期彙總、跨 partition 聚合、ad-hoc 報表、餵 ML。直接在 Cosmos OLTP container 上跑這些 query 有兩個問題：一是 NoSQL query 引擎不擅長大範圍掃描與聚合、二是 分析 query 吃掉 OLTP 的 RU、跑一個全表聚合可能把線上交易的 RU budget 耗光、造成 OLTP throttle（429）。團隊被迫在「分析準確性」與「OLTP 穩定性」之間二選一。

讀者徵兆：

• 「在 Cosmos OLTP container 跑分析 query、把線上交易的 RU 吃光、OLTP 開始 429」
• 「想做 analytics 但不想自己搭 ETL pipeline 把資料抽到 data warehouse」
• 「分析資料可以晚幾分鐘、但不想為了分析犧牲 OLTP 容量」
• 「什麼時候 Synapse Link 夠、什麼時候要把資料 ETL 到專用 OLAP（BigQuery / Snowflake）」

真實壓力：OLTP store 為點查與小範圍寫入最佳化、分析 query 為大範圍掃描與聚合最佳化、兩者對 storage layout 與資源的需求衝突。在同一個 store 同時服務兩者、不是 RU 互搶就是 query 形狀不對。Synapse Link 的價值是用 federation 把這個衝突拆開 — OLTP 與 OLAP 各有最佳化的 store、平台自動同步。

核心機制：analytical store + HTAP federation

Synapse Link 的核心是 Cosmos DB container 的 analytical store。

analytical store 是 column-oriented 的自動複本。在 container 啟用 analytical store 後、Cosmos DB 把 transactional store（row / document、為 OLTP 最佳化）的資料自動同步到一份 column-oriented 表示（為大範圍掃描與聚合最佳化）。兩份共存、同一份資料兩種 layout。

同步是 no-ETL、auto-sync。寫入 transactional store 後、平台在背景把變更同步到 analytical store（通常分鐘級延遲、時間敏感、查文件）。team 不寫 ETL、不維護 pipeline。

關鍵隔離：analytical store query 不消耗 OLTP 的 RU。Synapse engine 查 analytical store、走的是 analytical store 的計費與資源、跟 transactional store 的 provisioned RU 分離。這是 federation 對 OLTP 的核心保護 — 分析跑再重也不會 throttle 線上交易。

這是 HTAP（Hybrid Transactional/Analytical Processing）的一種實現：同一資料源、OLTP 與 OLAP 共存、不需要把資料搬到獨立 warehouse 就能做近即時分析。對應 federation 的「同一份資料、多個各自最佳化的存取路徑」概念。

跟自己搭 Change Feed pipeline 的差別

Change Feed 也能把資料同步到別處做分析、但那要自己寫 consumer、自己維護 target store、自己處理 schema 演進與 backfill。Synapse Link 是平台託管的 analytical store + auto-sync、省掉這整條 pipeline。判準：需求是「Cosmos 資料的近即時 column-oriented 分析」、Synapse Link 直接給；需求是「自訂 transform、餵特定下游、複雜 routing」、Change Feed 提供控制權但要自己搭。

操作流程

在 container 啟用 analytical store

1# 建 container 時開 analytical store TTL（-1 = 跟 transactional 同壽命）
2az cosmosdb sql container create \
3  --account-name mycosmos --resource-group myrg \
4  --database-name catalog --name orders \
5  --partition-key-path "/customerId" \
6  --analytical-storage-ttl -1

驗證：container 的 analyticalStorageTtl 已設；account 層的 Synapse Link feature 已啟用（account 設定、時間敏感、查文件）。注意 analytical store 通常需要 建 container 時 啟用、既有 container 的開啟支援度要查文件。

從 Synapse 查 analytical store

1-- Synapse serverless SQL pool 直接查 analytical store、不打 OLTP
2SELECT customerId, COUNT(*) AS orders, SUM(amount) AS revenue
3FROM OPENROWSET(
4    PROVIDER = 'CosmosDB',
5    CONNECTION = 'Account=mycosmos;Database=catalog',
6    OBJECT = 'orders',
7    SERVER_CREDENTIAL = 'cosmos-cred'
8) WITH (customerId varchar(64), amount float) AS orders
9GROUP BY customerId;

驗證：query 跑大範圍聚合期間、Cosmos OLTP container 的 NormalizedRUConsumption 不受影響（這是 federation 隔離生效的關鍵證據）。對照同樣 query 直接打 transactional store、會看到 RU 飆升甚至 429。

驗證同步延遲

寫一筆到 transactional store、隔一段時間在 analytical store 查到 — 量同步延遲（分鐘級）。驗證：延遲在業務可接受的分析新鮮度範圍內；要秒級新鮮度的分析、Synapse Link 不是對的工具。

Rollback boundary

Synapse Link 是讀取側 federation、停用不影響 transactional store 的 OLTP。analytical store 是衍生複本、刪掉重建可重新同步（從 transactional store）。OLTP 寫入路徑完全不受 analytical store 啟用與否影響。

何時分出去、何時 federate 到專用 OLAP

這是本文主判讀段。Synapse Link 在「OLTP 資料要近即時分析、但不想犧牲 OLTP 容量也不想搭 ETL」的場景成立；它不是所有分析需求的答案。

用 Synapse Link（在 Cosmos federation 內做分析）的條件：

• 分析的主資料源就是 Cosmos OLTP container、且分析可接受分鐘級新鮮度
• 主要痛點是「分析 query 搶 OLTP 的 RU」— federation 的 RU 隔離直接解這個
• 不想維護 ETL pipeline — no-ETL auto-sync 省掉這條
• 分析 query 形狀適合 column-oriented 掃描聚合（多數 BI / 報表 / 彙總）

把分析 workload federate 到專用 OLAP（BigQuery / Snowflake / 專用 warehouse）的條件：

• 分析要 跨多個資料源 join（Cosmos + 其他 DB + 外部資料）— 需要一個獨立的 warehouse 做集中、Synapse Link 只給 Cosmos 單源
• 分析是重型 data warehouse workload（複雜多表 join、長期歷史、大規模 transform）— 專用 OLAP 的引擎與成本模型更合適
• 已有成熟的 data platform（Snowflake / BigQuery / lakehouse）、Cosmos 只是其中一個 source — 把 Cosmos 資料用 Change Feed / connector 餵進既有 platform、不另起 Synapse Link

判讀句：Synapse Link 是 Cosmos 單源、近即時、column-oriented 分析的省力路徑；分析需求一旦跨源、變重型 warehouse、或已有集中 data platform、就 federate 到專用 OLAP。Cosmos DB overview 已標明「純 OLAP 分析」交給 Synapse / BigQuery / Snowflake — Synapse Link 是兩者之間的橋、不是把 Cosmos 變成 data warehouse。

失敗模式

不啟用 Synapse Link、直接在 OLTP 跑分析

team 在 OLTP container 直接跑全表聚合報表、分析 query 吃光 provisioned RU、線上交易 429。徵兆是「跑月報的時段、線上交易 latency 飆 / 出現 throttle」。修法是啟用 analytical store + Synapse Link、分析 query 改打 analytical store、RU 隔離後 OLTP 不再受影響；或退一步、把分析 query 移到離峰、但這只是緩解、根本解是 federation 隔離。

期待 analytical store 即時反映寫入

把 Synapse Link 當即時分析用、寫入後立刻在 analytical store 查、查不到剛寫的。analytical store 同步是分鐘級、不是即時。徵兆是「剛下的訂單在分析報表看不到」。修法是接受分析的分鐘級新鮮度、需要即時數字的場景（如即時庫存）走 OLTP 點查、不走 analytical store。

把 Synapse Link 當跨源 data warehouse

分析需要 join Cosmos 資料與其他系統的資料、期待 Synapse Link 解決、發現 analytical store 只有 Cosmos 單一 container / account 的資料。徵兆是「分析做到一半發現缺其他系統的維度資料、Synapse Link 帶不進來」。修法是跨源分析用獨立 warehouse（BigQuery / Snowflake / Synapse dedicated pool）集中、Cosmos 資料用 Synapse Link 或 Change Feed 餵進去當其中一個 source、不期待 Synapse Link 自己做跨源 join。

既有 container 才想開、發現要重建

analytical store 通常要建 container 時啟用、production 跑一陣子才想開、發現既有 container 的開啟有限制（時間敏感、查文件）、可能要新建 container + 遷資料。徵兆是「想開 analytical store 但介面不讓開 / 要重建」。修法是新 container 規劃時就評估未來是否需要分析、預先開 analytical store TTL（不用時成本影響有限）；既有 container 要開時、按文件評估是否需建新 container 遷移。

Anti-recommendation：分析需求很輕不要起 federation

分析只是偶爾跑、資料量小、OLTP RU 有餘裕扛、且新鮮度要求即時 — 這種場景直接在 OLTP 上 query 或加少量 read 容量更簡單、不需要 analytical store 的額外儲存與 Synapse 的接入。Synapse Link 的價值在「分析會搶 OLTP 容量」或「不想搭 ETL」這兩個痛點明確時才成立；痛點不存在就引入 federation 是多一層東西要管。

容量與觀測

• 必看 metric：OLTP container 的 NormalizedRUConsumption（驗證分析 query 沒污染它）、analytical store 同步延遲、Synapse 端 query 的掃描量與成本
• 成本模型分離：analytical store 有獨立的 storage + 寫入計費、Synapse query 有自己的計費（serverless 按掃描量、dedicated 按 pool）— 跟 OLTP 的 RU 完全分開、不要混進 ru-cost-model-sizing 的 RU 公式、那篇主寫 transactional store 的 RU
• federation 的隔離證據：跑重型分析時 OLTP RU 平穩、就是 federation 生效；若 OLTP RU 仍隨分析波動、表示分析 query 其實打到了 transactional store、要檢查 query 是否真的走 analytical store
• 回 9.6 容量規劃模型：OLTP 容量與 analytical 容量分兩條 budget 規劃、這正是 federation 的容量規劃價值 — 兩個 workload 不再互相競爭資源
• Alert：analytical store 同步延遲異常增長、OLTP RU 出現非預期的分析時段波動（隔離失效）

邊界與整合

• Sibling deep articles：change-feed-cdc（自訂 transform / 跨源 routing 用 Change Feed、近即時 Cosmos 單源分析用 Synapse Link）、ru-cost-model-sizing（analytical store 成本獨立於 OLTP RU、不混算）、consistency-levels-engineering（analytical store 是分鐘級延遲的衍生複本、不適用 OLTP 的 consistency level 語義）
• federation 概念：federation — OLTP / OLAP 各自最佳化 store + 平台同步
• 跨源 / 重型分析的升級路由：Synapse dedicated pool / BigQuery / Snowflake — Cosmos DB overview「純 OLAP 分析」段已標明
• 回 overview：Cosmos DB vendor overview 的「跟 Azure Synapse Link 整合（OLTP / OLAP federation）」backlog 與「純 OLAP 分析」不適用場景
• Microsoft 365 analytics 主 anchor：9.C30 — analytics workload 建在 Cosmos 上的情境

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 Synapse Link backlog 的深度展開
• 9.C30 Microsoft 365 case — Cosmos 上的全球分析平台情境 anchor
• change-feed-cdc — 自訂 pipeline 的對照路徑
• ru-cost-model-sizing — OLTP RU 與 analytical 成本的分離
• Federation 卡片 — OLTP / OLAP federation 概念基底
• 官方：Azure Synapse Link for Cosmos DB / Analytical store