【Day 19】Azure Cosmos DB：全球分散式 NoSQL 的一致性取捨 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆（本篇為架構精選加強版）
今日任務：深入拆解 Azure Cosmos DB 的全受控架構底層，從多模型 API、五種資料一致性層級光譜、邏輯與實體分割區（Partitioning）機制到 RU 容量計費模型，建立對標 AWS DynamoDB 的雙雲架構選型與防禦性設計思維。

🎯 前言與今日目標

Day 18 我們替 Titan 科技拆解了 Azure SQL 家族的三層抽象（Azure SQL Database、SQL Managed Instance、SQL on Azure VM），為關聯式系統、強交易 ACID 與跨資料庫相容性奠定了選型標準。

然而，新的一天帶來了全新的架構挑戰：Titan 科技全球大作「星際遠征（Starry Expedition）」即將在全球各大洲同步公測。CTO 走進架構會議室，攤開一份令人頭痛的存取特徵清單：

1. 資料綱要劇烈變動：全球數百萬玩家的裝備屬性、遊戲即時事件、好友推薦清單，資料欄位每天因應活動頻繁增減（非固定 Schema 的 JSON 文件）。
2. 跨洲極致低延遲：東京、法蘭克福、維吉尼亞的玩家，都必須在本地資料中心獲得個位數毫秒（Single-digit millisecond）的讀寫回應。
3. 拒絕自架叢集與複雜維運：不希望維運團隊半夜被跨國網路複寫中斷、磁碟空間爆滿或主從節點容錯移轉（Failover）警報喚醒。

若將這套高併發、全球化、彈性結構的資料硬塞進傳統關聯式資料庫，跨洲光纖傳輸的物理延遲（RTT 150～250ms）將直接拖垮分散式交易兩階段提交（2PC），死鎖與頻繁的 DDL 遷移更會引發全球性雪崩。

今天不是單純背出「Cosmos DB 是 NoSQL」這句口號。身為 Chief Cloud Architect，你要掌握 資料模型 ➔ Partition Key ➔ 多區域拓撲（Regions）➔ 一致性層級（Consistency Levels）➔ RU 容量配置 的完整推理鏈。選錯 Partition Key 會引發熱點吞吐量耗盡；在跨區多寫時誤用強一致性更會直接撞上平台架構限制。

本篇加強版同樣導入 🧒 ELI13（Explain Like I'm 13）生活化比喻，將分散式系統最抽象的一致性光譜與計費黑盒徹底解構！

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 Cosmos DB 全球資料路徑與複寫架構圖

┌──────────────────────────────────────────────────────────────────┐
│ Titan 科技全球客戶端（Web / Mobile App）讀寫請求                 │
└──────────────────────────────────────────────────────────────────┘
                                 ▼                                  
┌──────────────────────────────────────────────────────────────────┐
│ Azure Cosmos DB Account：選定 API、Partition Key 與一致性層級    │
│ • 全球資料庫帳戶 (全受控 PaaS) ➔ 掌管多區域拓撲與資料複寫契約    │
└──────────────────────────────────────────────────────────────────┘
                ▼                                ▼                  
┌───────────────────────────────┐  ┌───────────────────────────────┐
│ East Asia Region (亞太區)     │  │ West Europe Region (西歐區)   │
│ 本地讀取與寫入                │  │ 本地讀取與寫入                │
│ 邏輯分割區 ➔ 實體叢集         │  │ 邏輯分割區 ➔ 實體叢集         │
└───────────────────────────────┘  └───────────────────────────────┘
                │                                  │                
                └──────── 雙向背景自動複寫 ────────┘                
   (依一致性協議：Session / Bounded Staleness / Eventual)           

💡 架構師重點筆記：Cosmos DB 的「全球分散（Global Distribution）」並非由應用程式層手動寫迴圈同步。在 Cosmos DB Account 層級，架構師定義好資料庫 API、複寫區域（Regions）、多區域寫入（Multi-region Writes）與一致性契約；微軟底層儲存引擎會自動以毫秒級延遲在背景處理資料複寫與同步。

1. Why：為什麼關聯式資料庫在全球擴展時會撞牆？（NoSQL 哲學與 PACELC 定理）

在雲端架構中，傳統關聯式資料庫（RDBMS）的設計哲學是追求 ACID（原子性、一致性、隔離性、持久性）。為了維持絕對的資料正確，任何寫入都必須透過鎖定（Locking）或嚴格日誌同步來確保沒有任何用戶看到衝突。

然而，當系統走向「全球跨大洲分散」時，物理定律成了無法跨越的障礙：光纖傳輸在歐亞大陸與太平洋之間的光速傳播往返時間（RTT）約需 150～250ms。若在多個區域同時維護 ACID 強交易，每次寫入都必須等待跨洲多節點完成兩階段確認，回應時間會從 5ms 暴增至 300ms 以上，系統吞吐量呈現斷崖式下跌。

這正是 CAP 定理 與 PACELC 定理 的核心意涵：

• CAP 定理：當分散式系統遭遇網路分割（Partition）時，你必須在 一致性（Consistency）與 可用性（Availability）之間做出權衡。
• PACELC 定理：即便沒有網路故障（Else），系統在平時也必須在 延遲（Latency）與 一致性（Consistency）之間取捨。

NoSQL 的誕生，正是為了解開這道鎖鏈。Azure Cosmos DB 採用全受控的 Atom-Record-Sequence (ARS) 底層儲存引擎，將資料解構為多版本的鍵值與序列，並在表面提供多種通訊協定相容的 API：

1. API for NoSQL（核心/Core）：微軟原生文件模型，支援 SQL 查詢語法與 JSON 階層文件，是 AZ-900 考點的核心主角。
2. API for MongoDB：線路通訊協定與 MongoDB 驅動程式相容，適合現有 MongoDB 應用零痛遷移。
3. API for Apache Cassandra：適合寬欄位（Wide-column）高寫入量之 Cassandra 應用。
4. API for Apache Gremlin：圖形資料庫（Graph Database），專門處理高度關聯之社交網路與詐欺偵測。
5. API for Table：輕量級鍵值（Key-Value）模型，相容於既有 Azure Table Storage。

⚠️ 關鍵觀念：多模型 API（Multi-model APIs）只是開發者的存取語言協定，底層皆運行在同一套分散式 ARS 引擎之上。你不能在同一個容器（Container）內任意混用兩種 API，建立帳戶時就必須明確選定。

🧒 ELI13 比喻：關聯式資料庫就像「一本嚴格裝訂的公文大帳簿」，全公司只有一本；任何人要修改其中一頁，走廊上的其他人都必須排隊乾等他蓋章。Cosmos DB 則像「各分公司即時連動的電子白板」：東京、歐洲、美國分公司各有一塊白板，大家可以立刻在白板上貼便利貼（即時寫入），系統在背後悄悄把更新同步到全球其他白板，誰也不必在走廊上乾等。

2. 深入核心：五種一致性層級（Consistency Levels）光譜與折衷取捨

一般資料庫通常只有「強一致性（Strong）」與「最終一致性（Eventual）」兩種極端二分法；但 Azure Cosmos DB 的創舉在於提供了完整的 五種一致性層級光譜，讓架構師依據商業價值與延遲容忍度進行細緻的旋鈕調節：

┌──────────────────────────────────────────────────────────────────┐
│ Cosmos DB 五種一致性層級光譜 (Consistency Spectrum)              │
├────────────┬─────────────┬────────────┬─────────────┬────────────┤
│ Strong     │ Bounded     │ Session    │ Consistent  │ Eventual   │
│ (強一致性) │ Staleness   │ (工作階段) │ Prefix      │ (最終)     │
├────────────┼─────────────┼────────────┼─────────────┼────────────┤
│ 讀最新寫入 │ 容忍落後K/T │ 讀己之寫入 │ 讀取不逆轉  │ 最終收斂   │
│ 延遲最高   │ 跨區多寫強  │ 預設最佳解 │ 順序保證    │ 延遲最低   │
│ 吞吐量最低 │ 延遲吞吐平  │ 吞吐延遲佳 │ 吞吐極高    │ 吞吐最高   │
└────────────┴─────────────┴────────────┴─────────────┴────────────┘

五大一致性層級深入解析：

1. Strong（強一致性）：
   • 保證：線性化一致性（Linearizability）。讀取操作保證能讀到最新已認可的寫入版本。所有客戶端在所有區域看到的狀態完全同步。
   • 折衷：延遲最高（需等待跨區域多數節點確認 Quorum）、吞吐量最低。
   • ⚠️ 致命限制：當 Cosmos DB 帳戶啟用多區域寫入（Multi-region writes）時，平台不支援 Strong 一致性！因為跨洲多點同時強寫入會導致分散式鎖定風暴。
2. Bounded Staleness（界限性過期）：
   • 保證：讀取到的資料最多只落後最新寫入特定界限——落後不超過 $K$ 個版本（Updates） 或 $T$ 秒時間差。只要在界限內，讀取保證有序。
   • 適用：多區域寫入帳戶下能提供的最強一致性保證。適合即時比分看板、庫存提示。
3. Session（工作階段一致性，預設值）：
   • 保證：以用戶端的工作階段識別項（Session Token）為邊界。保證單一使用者在自己的 Session 內擁有「讀己之寫入（Read-your-writes）」、「寫後讀（Write-follows-reads）」與「單調讀寫（Monotonic reads/writes）」。
   • 優勢：在單一使用者體驗上呈現出完美的強一致性，而跨使用者之間則享有低延遲與高擴展性。是絕大多數 Web 與手機 App 的性價比首選。
4. Consistent Prefix（一致前置詞）：
   • 保證：讀取者看到的更新順序絕對與寫入順序一致，絕不跳序或倒退。例如發送 A ➔ B ➔ C，讀取者可能只看到 A 與 B（有延遲），但絕對不會先看到 C 再看到 A。
   • 適用：社群留言對話串、金融流水帳更新。
5. Eventual（最終一致性）：
   • 保證：最弱的一致性保證。在沒有進一步寫入的情況下，所有複本最終都會收斂至一致狀態。讀取沒有保證順序或時限。
   • 優勢：延遲最低（< 10ms）、吞吐量最高、可用性最高。
   • 適用：玩家好友線上人數統計、YouTube 影片觀看次數、商品評論評分統計。

五種一致性層級特性全景矩陣：

🧒 ELI13 比喻：五種一致性就像 5 種「考試成績公布方式」：

• Strong：校長必須等全國所有考場的試卷全部改完、電話連線全部確認OK，才准許任何人查成績，任何人查都是最新、最正確，但等得最痛苦。
• Bounded Staleness：校長規定「各班成績公佈最多只能比總部慢 5 分鐘或 3 題的差距」，超過這個時間就先不准看，等追上才開放。
• Session：你自己交卷後，老師立刻把成績單塞給你（你看得到自己的最新分數）；但隔壁同學走過來問你分數時，系統可能還沒同步給他。你自己永遠不會感到錯亂！
• Consistent Prefix：老師依序公布第 1、2、3 名。可能目前只公布到前兩名，但絕對不會先念出第 3 名再念第 1 名。
• Eventual：園遊會趣味競賽，大家各玩各的，等晚上活動結束熄燈後，大家聚在一起核算，分數總會算清楚的。

3. Partition Key（分割區索引鍵）：擴展性與爆炸半徑的共同開關

在 Cosmos DB 中，資料不會自動無限制地神奇擴展。其無限擴展的核心引擎建立在 水平分割（Horizontal Partitioning） 機制之上：

┌──────────────────────────────────────────────────────────────────┐
│ Titan 寫入：{ playerId: "TW_1082", score: 9850, item: "劍" }     │
└──────────────────────────────────────────────────────────────────┘
                                 ▼                                  
┌──────────────────────────────────────────────────────────────────┐
│ Cosmos DB 路由：Hash(Partition Key: "TW_1082") ➔ 導向實體分割區  │
│ • 依雜湊範圍決定落點，確保跨分割區的資料儲存與流量均勻分攤       │
└──────────────────────────────────────────────────────────────────┘
                ▼                                ▼                  
┌───────────────────────────────┐  ┌───────────────────────────────┐
│ Physical Partition 1 (實體區) │  │ Physical Partition 2 (實體區) │
│ ---------------------------   │  │ ---------------------------   │
│ Logical Partition: TW_1082    │  │ Logical Partition: JP_4401    │
│   • 邏輯分割區上限: 20 GB     │  │   • 邏輯分割區上限: 20 GB     │
│   • 包含該玩家所有歷史紀錄    │  │   • 包含該玩家所有歷史紀錄    │
│ ---------------------------   │  │ ---------------------------   │
│ 實體分割區上限: 10,000 RU/s   │  │ 實體分割區上限: 10,000 RU/s   │
└───────────────────────────────┘  └───────────────────────────────┘

邏輯分割區 vs 實體分割區：

1. 邏輯分割區（Logical Partition）：
   • 定義：具有相同 partitionKey 值的項目集合。
   • ⚠️ 硬性限制：單一邏輯分割區的儲存空間上限為 20 GB！
   • 若架構師選了一個低基數（Low Cardinality）的鍵（例如選用 tenantType = "enterprise" 或 gender = "M"），單一分割區迅速超過 20 GB，Cosmos DB 將直接回傳錯誤拒絕寫入！
2. 實體分割區（Physical Partition）：
   • 定義：Cosmos DB 底層配置的實體運算與 SSD 叢集節點。
   • 規格：單一實體分割區上限約為 50 GB 儲存空間 與 10,000 RU/s 吞吐量。
   • 一個實體分割區可容納成千上萬個邏輯分割區。當資料量突破 50 GB 或 RU 超出限制時，Cosmos DB 會自動進行 分割區分裂（Partition Split），將邏輯分割區重新調配至新的實體節點。

分割區設計的三大黃金守則：

• 守則一：高基數（High Cardinality）：選取擁有數萬至數百萬種可能值的屬性（例如 userId、deviceId、orderId）。
• 守則二：請求負載均勻分佈（Uniform Request Distribution）：避免產生 熱點分割區（Hot Partition）。若將 creationDate 作為鍵，今天所有寫入全衝向同一個實體分區，即便買了 100,000 RU 也會因為單一分區達 10,000 RU 上限而被 HTTP 429（Too Many Requests）限流！
• 守則三：存取模式對齊（Query Pattern Alignment）：
  • 單一分割區查詢（In-partition Query）：查詢條件包含 Partition Key（例如 WHERE c.playerId = 'TW_1082'）。路由直達單一實體分區，消耗極少 RU。
  • 跨分割區查詢（Cross-partition Query / Fan-out）：查詢條件不包含 Partition Key。查詢引擎必須向所有實體分區平行廣播（Fan-out）並在記憶體聚合，RU 消耗呈爆炸性成長。

4. RU（Request Unit）與容量模式：拒絕憑感覺付費

在 Cosmos DB 中，計費與容量不再綁定 VM 的 CPU 或記憶體，而是標準化為 Request Unit（RU，要求單位）：

• 1 個 RU 是什麼概念？
  微軟官方基準量化：透過項目 ID 與 Partition Key 執行一次點讀取（Point Read），取得一份大小為 1 KB 的 JSON 文件 所需的運算、記憶體與 I/O 綜合成本。
• 寫入與查詢的 RU 代價：
  • 寫入 1 KB 項目：約需 5～10 RU（因為需要寫入多個 Quorum 複本並建立自動索引）。
  • 跨分區複雜查詢：可能單次查詢耗費數百至數千 RU。

Cosmos DB 三大容量計算模式：

1. 佈建吞吐量（Provisioned Throughput）：
   • 以每秒 RU（RU/s）為單位手動設定，最低 400 RU/s，以 100 RU/s 遞增。
   • 適合：流量穩定、可預測的生產環境。不論有無請求，皆按佈建量按時計費。
2. 自動調整規模吞吐量（Autoscale Throughput）：
   • 設定最高上限 $RU_{max}$（例如 4,000 RU/s）。
   • 系統會根據即時請求，自動在 $0.1 \times RU_{max}$ 至 $RU_{max}$ 之間瞬間彈性擴縮（400～4,000 RU/s）。
   • 適合：流量波峰波谷難以預測、具備突發流量但對可用性要求極高之核心系統。
3. 無伺服器模式（Serverless）：
   • 完全按實際執行的 RU 消耗總量與儲存 GB 計費。
   • 零流量 = 零運算費用！無最低基本費。
   • 規格限制：單一容器上限 5,000 RU/s，儲存上限 1 TB。
   • 適合：開發測試環境、間歇性排程工作負載、初期輕量應用。

🧒 ELI13 比喻：RU 就像去湯姆熊遊樂場的「代幣」：投 1 枚代幣可以玩一次打地鼠（讀取 1 KB 檔案）；玩豪華賽車模擬器一次要吃 10 枚代幣（寫入一份資料）。佈建模式就像包下整間遊樂場一整年；無伺服器模式則是走進去投多少算多少，不玩就不花錢。

5. 防禦性架構設計與資安最佳實踐（Zero Trust 原則）

身為雲端架構師，絕不能只看功能而忽略資安與爆炸半徑控制：

1. 身分驗證防禦：全面廢棄 Master Key 硬編碼
   • Cosmos DB 具備一組權限至高的主金鑰（Master Key/Account Key），握有主金鑰等同取得該帳戶下所有資料庫與容器的完全控制權。
   • 原廠最佳實踐：在應用程式中禁止使用 Master Key。全面啟用 Microsoft Entra ID 受控身分（Managed Identity），並綁定 Cosmos DB 內建資料平面 RBAC（Cosmos DB Built-in Data Reader / Contributor），落實最小權限原則。
2. 網路隔離邊界：封鎖公網與 Private Endpoint
   • 預設情況下 Cosmos DB 具備公用 IP 端點。
   • 防禦性設計：在生產環境中關閉 Public Network Access，透過 Azure Private Endpoint（專用端點），在虛擬網路（VNet）子網內部配置一組私人 IP 地址（Private IP），搭配 Private DNS Zone 實現完全不出公網的私密通訊。
3. 多區域寫入之衝突解決策略（Conflict Resolution Policy）：
   • 當啟用 Multi-region Writes 時，兩個大洲可能在同一毫秒修改同一筆資料。
   • Last-Write-Wins (LWW，預設)：系統根據項目的時間戳記 _ts（或自訂數值屬性）判定，晚發生者覆蓋早發生者。
   • 自訂衝突解決（Custom）：透過註冊一段 JavaScript 預存程序（Stored Procedure），或將衝突推送至 Conflicts Feed，由後端服務依照業務規則手動合併。

6. Azure Cosmos DB ↔ AWS DynamoDB 雙雲深度對照

對於具備 AWS 背景的架構師而言，將 Cosmos DB 直接等同於 DynamoDB 容易忽略兩者在設計抽象上的深層差異：

┌──────────────────────────────────────────────────────────────────┐
│ 無伺服器事件驅動資料庫架構對比 (Serverless NoSQL)                │
├────────────────────────────────┬─────────────────────────────────┤
│ AWS 架構 (cxcxc-io diagram_05) │ Azure 對應原生現代架構          │
├────────────────────────────────┼─────────────────────────────────┤
│ API Gateway (REST API 端點)    │ Azure API Management (APIM 入口)│
│         │                      │         │                       │
│         ▼                      │         ▼                       │
│ AWS Lambda (事件處理運算)      │ Azure Functions (無伺服器函式)  │
│         │                      │         │                       │
│         ▼ (Gateway Endpoint)   │         ▼ (Private Endpoint)    │
│ Amazon DynamoDB (NoSQL 資料表) │ Azure Cosmos DB (多模型 NoSQL)  │
│   • Hash / Sort Key 路由       │   • Partition Key 邏輯分割路由  │
│   • Global Tables 雙區多寫     │   • Multi-region Writes 多區多寫│
└────────────────────────────────┴─────────────────────────────────┘

💡 來源：改編自 cxcxc-io diagram_05（AWS Serverless 架構圖），已對照 Azure 原生服務調整。展示現代無伺服器架構中，入口流量、無伺服器計算與 NoSQL 資料庫的完整端到端拓撲。

雙雲核心機制多維度深度對照表：

📖 AZ-900 核心名詞解釋與速查

1. Azure Cosmos DB
   • 定義：微軟旗艦級全受控、全球分散式（Globally Distributed）的多模型 NoSQL 資料庫服務。
   • AWS 對照：Amazon DynamoDB（若涉及多區域主動複寫則對標 DynamoDB Global Tables）。
   • 考點線索：題目出現「全球分佈（Global distribution）」、「個位數毫秒低延遲」、「非關聯式/JSON 文件」、「多模型 API」時，唯一正解。
2. Partition Key（分割區索引鍵）
   • 定義：用於將容器內項目邏輯分組與路由的屬性鍵，決定資料如何分散到各實體節點。
   • 考點線索：單一邏輯分割區上限為 20 GB；必須選擇高基數且分佈均勻的屬性以避免熱點（Hot Partition）。
3. Request Unit (RU，要求單位)
   • 定義：Cosmos DB 量化資料庫所有資料庫作業（讀、寫、查詢）所需吞吐量與效能成本的標準化貨幣。
   • 考點線索：1 RU 代表以 Point Read 讀取 1 KB JSON 文件的資源量；提供 Provisioned、Autoscale 與 Serverless 三種模式。
4. Consistency Levels（資料一致性層級）
   • 定義：定義資料在多複本之間複寫時，讀取操作對資料新鮮度、順序性與可用性的契約承諾。
   • 考點線索：支援 5 種層級（Strong ➔ Bounded Staleness ➔ Session ➔ Consistent Prefix ➔ Eventual）；預設為 Session；啟用多區寫入時不支援 Strong。
5. Multi-region Writes（多區域寫入）
   • 定義：允許全球多個 Azure Region 的資料庫複本同時具備本地讀取與直接寫入能力，大幅壓低全球寫入延遲。
   • AWS 對照：DynamoDB Global Tables。
6. Logical vs Physical Partition（邏輯與實體分割區）
   • 定義：邏輯分割區由相同 Partition Key 的項目組成（上限 20 GB）；實體分割區為平台背後的硬體節點叢集（上限約 50 GB 與 10,000 RU/s），由平台自動管理擴縮。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的全球玩家檔案選型

Titan 科技備受矚目的跨平台大型多人連線遊戲「星際遠征（Starry Expedition）」即將在全球三大洲（東亞、西歐、美東）展開不刪檔封測。

前端架構師與首席資料工程師來到架構審查會，提出資料庫選型痛點：

「架構師，我們這款遊戲的玩家檔案包含自訂外觀、成就徽章、即時裝備數值與社群社交樹。這些資料每天配合營運活動增加欄位（JSON 彈性綱要），且玩家跨國連線時，本地讀寫必須在 10 毫秒內回應。最重要的是，玩家在商城購買裝備後，點回背包介面必須立刻看到剛買到的道具（讀己之寫入）；但其他大洲的好友看他的成就展示，稍微延遲個幾秒完全能接受。CTO 特別交代：維運團隊人手吃緊，嚴禁自己組裝 VM 叢集來搞跨洲資料同步！」

🧩 決策任務

身為 Chief Cloud Architect，哪一個 Azure 資料庫架構方案最符合 Titan 科技的需求？

• A：部署 Azure SQL Managed Instance，因為它是全託管的關聯式資料庫，且具備最高等級的 ACID 強一致性保證。
• B：採用 Azure Cosmos DB（API for NoSQL），以高基數的 playerId 作為 Partition Key，啟用多區域分散，並將一致性層級設定為預設的 Session。
• C：選用 Azure Table Storage，因為它的儲存價格是全 Azure 最便宜的，能以最低成本解決全球玩家資料存取。
• D：在單一 Azure Region 部署 Ubuntu 虛擬機器（VM）並自建 MongoDB 分片叢集（Sharded Cluster），讓開發團隊保留最完整的底層作業系統控制權。

🎯 解題拆解與解析

✅ 正解：B。

• 需求完全吻合：
  1. 「JSON 彈性綱要」➔ 指向 NoSQL 文件資料庫；
  2. 「全球三大洲毫秒級讀寫」➔ 指向 Cosmos DB 的全域分散與多區域寫入架構；
  3. 「玩家看自己背包要即時（讀己之寫入），其他人看可接受微小延遲」➔ 完美命中 Session 一致性 的保證；
  4. 「高基數 playerId 作為 Partition Key」➔ 確保請求均勻分散，消除單點熱點並避免單一分區觸碰 20 GB 上限；
  5. 「全受控 PaaS」➔ 完全免除底層硬體與叢集維護負擔。

❌ A 的陷阱（Azure SQL Managed Instance）：

• 關聯式資料庫強制要求預先定義結構嚴謹的 Table Schema，面對每天欄位變動的遊戲道具將面臨頻繁的 ALTER TABLE 鎖表停機風險。此外，關聯式資料庫主要設計於單一主節點寫入架構，跨洲多寫入會導致延遲暴增，不符合全球分散式彈性文件的業務特徵。

❌ C 的陷阱（Azure Table Storage）：

• Table Storage 雖然也是輕量 NoSQL 鍵值儲存且費用低廉，但它屬於 Azure Storage 帳戶下的基礎服務，不具備 Cosmos DB 的多區域主動讀寫能力、無毫秒級低延遲 SLA 保證、亦無五種一致性層級的彈性微調能力。以「單純便宜」偷換架構核心效能需求是典型的架構陷阱。

❌ D 的陷阱（單一 Region VM 自建 MongoDB 叢集）：

• 將架構拉回 IaaS（基礎設施即服務）。單一區域部署無法解決跨洲遠距離網路傳輸延遲；更嚴重的是，自建 MongoDB 叢集必須由團隊自行承擔 OS 弱點修補、備份、跨國複寫網路中斷處理與高可用性設計，徹底違背 CTO「不自行維護資料庫叢集」的前提指令。

🎯 Part 3：AZ-900 精選高頻真題解析

本節精選題目全部依據官方考綱情境改寫為 Titan 科技實戰背景，絕不複製受版權保護之題庫原文。所有技術答案與干擾項排除邏輯，均經 Microsoft Learn 現行官方文件逐字交叉驗證。

📝 真題 1：全球多區域並行寫入與 JSON 文件儲存（ExamTopics Q112 考點改寫）

Titan 科技正在規劃一項全球性的行動物聯網（IoT）車聯網解決方案。車載設備會以非固定欄位的 JSON 格式上傳遙測數據，且架構必須能夠同時在東亞、美東與北歐等多個 Azure 區域並行新增資料（Concurrent writes），並提供個位數毫秒的延遲。請問應推薦哪一項 Azure 服務？

• A：Azure SQL Database
• B：Azure Cosmos DB
• C：Azure Files
• D：Azure Blob Storage

答案：B。

• 架構師思維推理鏈：
  • 關鍵字識別：「非固定欄位 JSON 文件」、「多個區域並行新增資料（Concurrent writes）」、「個位數毫秒延遲」。
  • 核心考點定位：考查候選人對 Azure 核心資料服務特徵的精準辨別。全球分散式、原生支援多區域寫入（Multi-region writes）且專為 JSON/NoSQL 設計的 PaaS 資料庫即為 Azure Cosmos DB。
  • 逐一排除干擾項：
    • A（Azure SQL Database）：雖然支援 JSON 函式，但本質上是關聯式資料庫，主要為單區域寫入架構，跨區主要為容錯移轉（Active Geo-Replication），無法原生支援全球多區同時並行寫入。
    • C（Azure Files）：提供 SMB/NFS 檔案共享協定，非資料庫服務。
    • D（Azure Blob Storage）：為非結構化物件儲存（Object Storage），雖然可存放 JSON 檔案，但不具備資料庫之結構化索引、即時查詢與交易處理能力。
• 來源與驗證：改寫自 ExamTopics AZ-900 高頻真題 Q112 考點；經官方現行文件交叉驗證確認，參見 Microsoft Learn：Azure Cosmos DB 簡介。

📝 真題 2：服務模型識別：Cosmos DB 作為全受控 PaaS vs IaaS VM（ExamTopics Q71 / Q413 考點改寫）

關於 Azure Cosmos DB 的雲端服務模型分類與維運責任，下列哪一項敘述是正確的？

• A：Azure Cosmos DB 屬於基礎設施即服務（IaaS），因為客戶可以透過 API 調配 CPU 核心與記憶體。
• B：Azure Cosmos DB 屬於平台即服務（PaaS），微軟負責底層硬體、作業系統修補、資料庫引擎維護與跨區資料複寫。
• C：Azure Cosmos DB 屬於軟體即服務（SaaS），因為它像 Microsoft 365 一樣可以直接供終端使用者透過瀏覽器使用。
• D：在 Azure 虛擬機器（VM）上安裝 MongoDB 與使用 Azure Cosmos DB 屬於相同的雲端服務模型。

答案：B。

• 架構師思維推理鏈：
  • 關鍵字識別：「Cosmos DB 服務模型分類」、「共同責任模型」。
  • 核心考點定位：考查雲端概念（Cloud Concepts）與資料庫架構的交叉認知。Cosmos DB 是微軟完全託管的 平台即服務（PaaS）。
  • 逐一排除干擾項：
    • A：Cosmos DB 不分配實體 CPU 或記憶體，而是抽象為 RU（Request Units），且不屬於 IaaS。
    • C：Cosmos DB 是供應用程式開發者構建系統的資料庫平台，而非面對終端業務使用者的 SaaS 套裝應用。
    • D：在 VM 上自建資料庫屬於 IaaS，客戶需負責 OS 與資料庫軟體的安裝修補；Cosmos DB 則是全託管 PaaS，兩者管理責任截然不同。
• 來源與驗證：改寫自 ExamTopics AZ-900 考點 Q71 與 Q413；經官方現行文件交叉驗證確認，參見 Microsoft Learn：Azure Cosmos DB 常見問題集。

📝 真題 3：核心數據服務分類拖曳配對題（ExamTopics Q133 考點改寫）

Titan 科技正在整理雲端數據架構的服務目錄，架構師需要將各項 Azure 數據服務與其最核心的架構能力進行精確配對：

1. 全球分散式、多模型之 NoSQL 資料庫服務
2. 整合式巨量資料分析與企業級資料倉儲（Enterprise Data Warehouse）平台
3. 基於開源生態系統（Apache Hadoop、Spark）的受控叢集分析服務

請問上述 1～3 應分別對應哪一組 Azure 服務？

• A：1 ➔ Azure Cosmos DB；2 ➔ Azure Synapse Analytics；3 ➔ Azure HDInsight
• B：1 ➔ Azure SQL Database；2 ➔ Azure Databricks；3 ➔ Azure Data Factory
• C：1 ➔ Azure Cosmos DB；2 ➔ Azure Data Lake Storage；3 ➔ Azure Event Hubs
• D：1 ➔ Azure Table Storage；2 ➔ Azure Stream Analytics；3 ➔ Azure Synapse Analytics

答案：A。

• 架構師思維推理鏈：
  • 關鍵字識別：「全球分散式多模型 NoSQL」、「企業級資料倉儲」、「開源 Hadoop/Spark 叢集」。
  • 核心考點定位：AZ-900 經典服務特徵辨識拖曳題型。
  • 逐一排除干擾項：
    • 項目 1 指標特徵為「全球分散、多模型 NoSQL」，唯一對應 Azure Cosmos DB。
    • 項目 2 指標特徵為「企業資料倉儲與分析平台（原 SQL Data Warehouse）」，對應 Azure Synapse Analytics。
    • 項目 3 指標特徵為「開源 Hadoop / Spark 託管分析」，對應 Azure HDInsight。
    • B、C、D 均將關聯式資料庫、串流處理或儲存體工具混淆，配對錯誤。
• 來源與驗證：改寫自 ExamTopics AZ-900 拖曳題型 Q133；經官方現行文件交叉驗證確認，參見 Microsoft Learn：Azure 資料架構指南。

📝 真題 4：版本控制工具與資料庫服務邊界（2020 gratisexam 題庫 Q56 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫 Q56，屬歷史題庫層，已針對現行考綱與 Microsoft Learn 進行服務邊界校驗，剔除過期描述。

Titan 科技的軟體開發團隊需要一套具備 Git 存放庫管理、版本控制與分支合併審查的受控工具。部分實習工程師提議使用 Azure Cosmos DB 來儲存 Git 檔案。請問架構師應如何糾正並建議正確的 Azure 服務？

• A：建議正確，因為 Cosmos DB 是文件資料庫，可以儲存任何程式碼檔案。
• B：建議錯誤，因為版本控制屬於 Azure Repos 的功能邊界；Cosmos DB 是全球分散式 NoSQL 資料庫。
• C：建議錯誤，應該使用 Azure DevTest Labs 來管理程式碼版本。
• D：建議錯誤，應該改用 Azure Monitor Application Insights 來管理分支版本。

答案：B。

• 架構師思維推理鏈：
  • 關鍵字識別：「Git 存放庫與版本控制工具」、「Cosmos DB 服務邊界」。
  • 核心考點定位：考查候選人對 DevOps 工具鏈與 Database 服務邊界的基礎辨別。
  • 逐一排除干擾項：
    • A：Cosmos DB 雖可儲存 JSON，但不是版本控制系統，缺乏 Git 協作、PR 審查與 Commit 追蹤功能。
    • **C（Azure DevTest Labs