Amazon DynamoDB 深入解析

DynamoDB 資料建模可說是 AWS 認證開發者助理 DVA-C02 考試中份量最重的單一主題。雖然考試涵蓋廣泛的 AWS 開發者服務，但 DynamoDB 資料建模的題目密度最高，原因在於 DynamoDB 是 AWS 旗艦級的 NoSQL 基礎服務，也是 serverless 架構中預設的狀態儲存層。一位無法清楚推論分區鍵、排序鍵、單一資料表設計、LSI 與 GSI 差異、RCU 與 WCU 數學計算、Streams、交易及 PITR 的開發者，即便背熟其他所有服務，仍然會在 DynamoDB 資料建模的情境題上失分。本深度解析將逐一拆解 DVA-C02 藍圖中所有 DynamoDB 資料建模的知識點，為每個概念搭配白話類比，在 callout 中標記常見陷阱與提示，最後以考試風格的 FAQ 作結，讓你反覆練習直到這些模式成為直覺反應。

什麼是 DynamoDB 資料建模？

DynamoDB 資料建模是在 Amazon DynamoDB 中設計資料表、鍵值、索引與容量設定的方法論，目標是讓應用程式的每一種存取模式都能以可預測的個位數毫秒延遲在任意規模下執行。關聯式資料建模從正規化的實體出發，依賴 JOIN 來回答臨時查詢；DynamoDB 資料建模則反其道而行，從一份存取模式清單出發——「依訂單 ID 取得訂單」、「列出某位顧客在特定日期區間的訂單」、「找出購物車 X 中的所有品項」——再逆向推導出能滿足這些模式的資料表結構，無需掃描整張表。

DynamoDB 資料建模是區分初階 DynamoDB 使用者與 serverless 架構師的核心技能。DVA-C02 考試指南在 Domain 1（使用 AWS 服務進行開發）中明確點名 DynamoDB 資料建模，因為針對 DynamoDB 撰寫的資料存取層是 AWS Lambda、Amazon API Gateway 和 AWS AppSync 應用程式的核心狀態原語。把 DynamoDB 資料建模做對，應用程式就能從零流量無縫擴展至數百萬次請求，無需重新架構。做錯了，就會面臨熱分區（hot partition）、意外帳單、寫入限流，以及代價高昂的全表掃描。

關聯式資料庫開發者為何覺得 DynamoDB 資料建模違反直覺

來自 PostgreSQL、MySQL 或 Oracle 背景的考生，往往覺得 DynamoDB 資料建模不符合直覺。關聯式建模推崇正規化、參照完整性，並將存取模式的決策延後到查詢時才處理。DynamoDB 資料建模則顛覆了以上每一項直覺：你要積極地去正規化、嵌入相關實體，而且必須在建立第一張資料表之前就列舉所有存取模式。DVA-C02 的考題不斷利用這種顛覆性：許多 DynamoDB 資料建模情境的正確答案，若未內化 NoSQL 思維就會感到反直覺。

DynamoDB 資料建模在 DVA-C02 藍圖中的位置

Domain 1（使用 AWS 服務進行開發，佔 DVA-C02 考試 32%）是 DynamoDB 資料建模得分最集中的地方，但 DynamoDB 也出現在 Domain 2（安全性）——透過分區鍵上的 IAM 條件鍵；Domain 3（部署）——透過資料表與索引的基礎設施即程式碼；以及 Domain 4（疑難排解與最佳化）——透過容量調校、DAX 快取和 CloudWatch 指標。預計 65 道 DVA-C02 計分題中，DynamoDB 資料建模相關題目約佔 10 到 15 題。

白話文解釋 DynamoDB Data Modeling

如果 DynamoDB 資料建模的正式說明仍然讓你感到抽象，可以用以下三種日常類比來重新理解。挑一個最容易記住的，在考試時召喚它。

類比一：演唱會寄物間

把 DynamoDB 資料建模想像成在大型演唱會場館管理一間龐大的寄物間。分區鍵就是你票根上的掛鉤號碼——拿著 42 號票根的人，立刻就能取回 42 號的物品，完全不用掃描整個架子。排序鍵則是同一個掛鉤上多件物品的排列順序：外套、包包、雨傘、帽子，全都掛在 42 號票根下，但可依照可預測的順序取回。單一資料表設計的洞見是：一間用顏色編碼票根（USER#、ORDER#、ITEM#）的超大寄物間，比開設十間獨立的小寄物間更便宜、更快速。GSI（全域二級索引）是第二個售票窗口，依照不同的屬性排序物品，例如「所有紅色外套」橫跨所有掛鉤。DynamoDB Streams 是每個掛鉤動作（放入、修改、取出）的 CCTV 即時錄影，廣播給任何監聽者。交易則是一位保全，確保「交外套 AND 歸還押金」要嘛兩件事都完成，要嘛都不發生。DAX 是入口處的快速通道，因為已記住你的臉，直接跳過查詢流程。

類比二：圖書館卡片目錄

把 DynamoDB 資料建模想成整理一間公共圖書館的卡片目錄。分區鍵是主抽屜——以 ISBN 為索引。排序鍵是抽屜內的排序方式——版本年份。LSI（本地二級索引）是同一個抽屜內的第二組索引標籤，讓你改用作者姓名而非版本年份來查找；由於抽屜相同，必須在建立抽屜時就決定是否加入作者標籤。GSI（全域二級索引）是一整組獨立的目錄櫃，按主題或語言重新索引整個圖書館；新的 GSI 目錄櫃可以隨時建立，但內容是非同步更新的，並非立即同步。強一致性讀取就像去流通台查主副本——較慢但永遠是最新狀態。最終一致性讀取就像查分館目錄——費用減半，但剛歸還的書可能有一、兩秒鐘還沒出現。交易讀寫則是圖書館員的蓋章程序，確保多步驟借閱作業中的每本書都以原子方式更新，費用是平常的兩倍。PITR 是縮微膠卷存檔，讓你可以把目錄倒回過去 35 天內的任何時刻。

類比三：開書考試的小抄

把 DynamoDB 資料建模想成將所有課程筆記壓縮到一張開書考試小抄上。你無法把所有內容都寫進去，所以只寫你預期會被問到的題目的答案。分區鍵是每個章節頂端的標題——你直接翻到「ORDERS」或「USERS」，不用掃描整張紙。排序鍵負責排列一個章節內的筆記——依時間、字母或優先順序。複合主鍵讓單一章節可以包含許多相關條目。覆載鍵值（在同一張表中同時使用 USER#123 和 ORDER#456）讓你把兩個主題塞在同一張紙上。如果你預期小抄印好後會出現新題型，可以在後面釘上 GSI 影本——一份以不同屬性重新排序的小抄副本。LSI 無法在印好後才貼上，因為 LSI 存在於原始分區章節之內。DAX 是你的短期記憶——你已經把前 100 個重要知識點背熟，根本不需要翻小抄。交易是老師的規定：第 (a)、(b)、(c) 小題要一起作答，否則整題留白。TTL 是橡皮擦，在設定的時間後自動抹去過期的筆記。

DynamoDB 資料建模的核心操作原則

每一個 DynamoDB 資料建模的決策都可以歸結到少數幾個原則。把這些原則內化，後續的考試內容自然而然就會串聯在一起。

原則一：以存取模式為設計起點

關聯式設計是先將實體正規化，再延後規劃查詢設計。DynamoDB 資料建模則相反，你必須先列舉所有存取模式——「依 ID 取得使用者」、「依日期列出使用者的訂單」、「依 session 找出購物車品項」、「依房間統計訊息數量」——然後反向推導出能用一次查詢（而非掃描）滿足每個模式的分區鍵、排序鍵及二級索引。

原則二：在正式環境的路徑中避免 Scan 與 Filter

DynamoDB 的 Scan 操作會讀取資料表中每一筆資料，每 4 KB 消耗一個 RCU。對於一張 10 GB 的資料表，單次 Scan 可能消耗數千個 RCU。設計良好的 DynamoDB 資料建模意味著正式環境的每一次請求都是 Query（依分區鍵範圍查詢）或 GetItem（單一鍵值取回），而不是 Scan。Filter 是在從磁碟讀取後才套用的，所以只能減少回傳的資料量，並不能降低費用。

原則三：將負載分散到各個分區

DynamoDB 依據分區鍵的雜湊值，將資料項目分散到各個實體分區。如果一個分區鍵值佔據了 90% 的流量（即「熱分區」），無論資料表擁有多少總容量，都會觸及每個分區的吞吐量上限。良好的 DynamoDB 資料建模會選擇高基數（high cardinality）的分區鍵（使用者 ID、裝置 ID、session ID），避免低基數的鍵（status=ACTIVE、country=US、yyyy-mm-dd）。

原則四：積極地去正規化

將總是一起讀取的相關資料嵌入到同一個資料項目中（例如，將訂單明細嵌入訂單記錄），而不是分散到多張資料表。代價是項目較大、資料重複，但好處是一次查詢取代多次查詢。DynamoDB 的資料項目最大可達 400 KB，對於大多數嵌入模式而言空間充裕。

原則五：依工作負載形狀選擇容量模式

隨需（On-Demand）模式可以吸收難以預測的流量尖峰，無需事先規劃容量。預置（Provisioned）模式搭配 Auto Scaling 則對穩定的工作負載更為划算。DynamoDB 資料建模包含容量規劃，因為選錯模式可能讓帳單膨脹 5 到 10 倍。

DynamoDB 資料建模中的主鍵

每張 DynamoDB 資料表都有一個主鍵，用來唯一識別每個資料項目。DynamoDB 資料建模提供兩種主鍵形式，這個選擇決定了後續所有設計方向。

僅分區鍵（簡單主鍵）

簡單主鍵只有一個屬性——分區鍵。DynamoDB 對分區鍵值進行雜湊運算，並將資料項目路由到擁有對應雜湊範圍的實體分區。依分區鍵執行 GetItem 是一個 O(1) 操作，回傳時間在個位數毫秒以內。當你只需要依唯一 ID（例如使用者 ID、訂單 ID 或 session token）查詢資料項目，且不需要查詢共享某個共同屬性的多個項目時，使用簡單主鍵。

分區鍵 + 排序鍵（複合主鍵）

複合主鍵結合了分區鍵與排序鍵。共享相同分區鍵的資料項目在實體上儲存在一起，並依排序鍵值排序。這開啟了範圍查詢的可能性，例如「使用者 U42 在 2026-01-01 到 2026-03-31 之間的所有訂單」或「聊天室 R7 在時間戳記 T 之後的所有訊息」。DynamoDB 資料建模利用複合鍵，讓你在單一資料表中編碼階層式關係（一個使用者對應多筆訂單、一個聊天室對應多則訊息）。排序鍵也是本指南後續介紹的單一資料表設計模式的基石。

唯一性規則

在簡單鍵資料表中，每個分區鍵值必須是唯一的。在複合鍵資料表中，必須是（分區鍵、排序鍵）這個組合是唯一的——只要排序鍵不同，兩個擁有相同分區鍵的資料項目是被允許的。這條規則正是複合鍵能自然地建模一對多關係的原因。

單一資料表設計模式

單一資料表設計是 DynamoDB 資料建模模式中，與進階 serverless 架構關聯最深的一種，在 DVA-C02 多道情境題中都有出現。這個概念刻意顛覆直覺：不是為每種實體建立一張獨立的資料表（Users 表、Orders 表、Products 表），而是把多種實體類型打包進單一 DynamoDB 資料表，使用覆載（overloaded）的鍵屬性來區分它們。

覆載的分區鍵與排序鍵

在單一資料表設計中，分區鍵屬性通常命名為 PK，排序鍵屬性命名為 SK。它們的值帶有實體前綴，用來識別每個資料項目所屬的實體類型。

• 使用者項目的 PK = USER#u42，SK = PROFILE。
• 同一位使用者的訂單項目的 PK = USER#u42，SK = ORDER#2026-04-20#o987。
• 該訂單中的明細項目的 PK = ORDER#o987，SK = LINE#1。
• 商品項目的 PK = PRODUCT#p123，SK = METADATA。

這四個項目都存在同一張資料表。對 PK = USER#u42 執行 Query，會回傳該使用者的個人資料加上所有訂單，並依訂單排序鍵排序。這一次查詢取代了跨三張關聯式資料表的 JOIN。

實體前綴作為類型識別符

實體前綴（USER#、ORDER#、PRODUCT#）既是人類可讀的類型標籤，也是一種排序技巧。由於 DynamoDB 依排序鍵字串排序，以 ORDER# 開頭的項目會群聚在 PROFILE 開頭的項目之前。前綴也讓你可以查詢分區內的某個切片——SK begins_with "ORDER#2026" 可以取回所有 2026 年的訂單，而不會掃描到其他實體類型的項目。

單一資料表設計勝出的情境

在以下情況下，單一資料表設計是最佳選擇：

• 你的存取模式頻繁地混合不同實體（一次取回使用者 + 訂單 + 訂單明細）。
• 將寫入與讀取的吞吐量視為一個整體數字更容易推算。
• 你希望只維護一個 CloudFormation 資源、一個 IAM 政策和一份備份，而非許多個。
• 你在建構 serverless 應用程式，希望盡量減少往返次數（round trips）。

多資料表設計勝出的情境

當實體彼此之間完全無關、容量需求差異懸殊（某個實體的寫入頻率是另一個的 1000 倍），或必須由不同的 IAM 主體（principal）擁有時，多資料表設計仍然合適。對於典型的 DVA-C02 情境題（涉及相關實體），考試偏向單一資料表設計。

LSI（本地二級索引）與 GSI（全域二級索引）

二級索引是 DynamoDB 資料建模中，讓你無需自行複製資料就能以不同鍵值查詢相同項目的功能。DynamoDB 提供兩種二級索引，DVA-C02 考試非常喜歡測試兩者的差異。

LSI 核心知識

本地二級索引與基礎資料表共享相同的分區鍵，但使用不同的排序鍵。LSI 之所以是「本地」，是因為它只在同一個分區內重新排列項目。

DynamoDB 資料建模中，LSI 的關鍵事實：

• 與基礎資料表共享相同的分區鍵。
• 排序鍵不同於基礎資料表。
• 必須在建立資料表時同時建立——建立資料表後無法新增 LSI，否則就必須重建資料表並遷移資料。
• 每張資料表最多 5 個 LSI。
• 支援強一致性讀取（因為 LSI 與基礎資料表分區共享）。
• LSI 儲存空間計入每個分區集合 10 GB 的上限。
• LSI 消耗的 RCU 與 WCU 來自基礎資料表——沒有獨立容量。

GSI 核心知識

全域二級索引擁有自己的分區鍵與可選的排序鍵，獨立於基礎資料表之外。GSI 之所以是「全域」，是因為它在所有分區上重新分佈資料。

DynamoDB 資料建模中，GSI 的關鍵事實：

• 分區鍵與排序鍵均不同於基礎資料表。
• 可以隨時新增、修改或刪除——不限於建立資料表時。
• 每張資料表最多 20 個 GSI（軟性上限——可透過 AWS Support 申請提高）。
• 僅支援最終一致性讀取。
• GSI 擁有獨立的預置容量（或共用資料表的隨需計費）。
• GSI 寫入會消耗額外的 WCU——每次觸及到索引屬性的基礎資料表寫入，都會同時寫入所有受影響的 GSI。

單一資料表設計中的 GSI 覆載

進階的單一資料表設計也會對 GSI 進行覆載：GSI1PK 與 GSI1SK 屬性帶有實體前綴的值，用來支援不同的存取模式，例如「依狀態列出訂單」或「依 email 尋找使用者」。只要前綴選擇得當，一個 GSI 就能服務多種存取模式。

LSI 與 GSI 比較矩陣

RCU 與 WCU 數學計算

容量數學計算是 DVA-C02 考試中 DynamoDB 資料建模題目的常態考點。把這些公式背到反射動作的程度。

寫入容量單位（WCU）

一個 WCU 代表每秒對大小不超過 1 KB 的項目執行一次標準寫入。

• 項目 ≤ 1 KB：每次寫入消耗 1 WCU。
• 項目 > 1 KB：向上取整到最近的整數 KB，再以每 KB 1 WCU 計算。一個 3.2 KB 的項目每次寫入消耗 4 WCU。
• 交易寫入費用為標準 WCU 的 2 倍。一個 1 KB 的交易寫入消耗 2 WCU。

讀取容量單位（RCU）

一個 RCU 代表每秒對大小不超過 4 KB 的項目執行一次強一致性讀取。

• 強一致性讀取，項目 ≤ 4 KB：1 RCU。
• 最終一致性讀取，項目 ≤ 4 KB：0.5 RCU（費用減半）。
• 交易讀取，項目 ≤ 4 KB：2 RCU（強一致性費用的兩倍）。
• 項目 > 4 KB：套用乘數前先向上取整到最近的整數倍 4 KB。一個 11 KB 的項目需要 ceil(11/4) = 3 個基礎單位；強一致性為 3 RCU，最終一致性為 1.5 RCU，交易讀取為 6 RCU。

DynamoDB 資料建模計算範例

• 每秒 100 次最終一致性讀取，項目大小 8 KB：100 × ceil(8/4) × 0.5 = 100 × 2 × 0.5 = 100 RCU。
• 每秒 200 次強一致性讀取，項目大小 2 KB：200 × 1 = 200 RCU。
• 每秒 500 次寫入，項目大小 1.5 KB：500 × ceil(1.5/1) = 500 × 2 = 1000 WCU。
• 每秒 50 次交易寫入，項目大小 500 B：50 × 1 × 2 = 100 WCU。

突發容量與自適應容量

DynamoDB 最多保留 5 分鐘的未使用容量作為突發儲備，可以吸收短暫的流量尖峰。自適應容量則會自動將吞吐量從冷分區重新分配到熱分區，無需開發者介入即可緩解輕微的不均衡狀況。但這兩種機制都無法拯救一個設計不良的分區鍵；當單一分區鍵吸收了過多流量時，熱分區限流依然會發生。

隨需容量與預置容量

DynamoDB 資料建模包含容量模式的選擇。兩種模式有不同的計費結構、不同的限流行為，以及對不同工作負載形狀的適配性。

隨需容量模式

隨需（On-Demand）計費方式是依請求收費——每百萬個讀取請求單位和每百萬個寫入請求單位各有固定費率。無需佈建容量，無需設定 Auto Scaling，只要流量是平穩上升的就不會發生限流。代價是每單位費率高於最佳化預置容量，因此隨需模式最適合以下情境：

• 新的應用程式，你還不清楚流量形狀。
• 流量不穩定，尖峰比穩態高出 10 倍以上。
• 開發與測試環境，使用頻率零散。
• Serverless 事件驅動模式，流量與上游突發事件連動。

預置容量模式搭配 Auto Scaling

預置容量要求你事先宣告 WCU 和 RCU。無論是否使用，你都要付費，但每單位費率更低。Auto Scaling 根據 CloudWatch 消耗容量指標，在最小值到最大值的區間內調整預置容量，通常以 70% 使用率為目標。以下情境適合選擇預置 + Auto Scaling：

• 流量可預測且持續穩定。
• 對成本敏感度高於吸收不可預測尖峰的需求。
• 你已有完善的可觀測性，可以調校最小值到最大值的區間。

容量模式切換

每張資料表每 24 小時可以在隨需與預置之間切換一次。許多團隊在初期使用隨需模式來了解流量形狀，等模式穩定後再切換為預置模式。也有些團隊反過來——平時使用預置模式以控制成本，在已知的流量尖峰前（產品上線、行銷活動）暫時切換為隨需模式。

DynamoDB Streams

DynamoDB Streams 是變更資料捕獲（Change Data Capture）功能，讓 DynamoDB 成為一個事件來源。基礎資料表中每一次項目層級的修改，都會被捕獲為一筆串流記錄，下游消費者可以依序讀取。DynamoDB Streams 是事件驅動 DynamoDB 資料建模模式的基礎。

串流記錄內容

在資料表上啟用 DynamoDB Streams 時，你需要選擇每筆串流記錄攜帶的資訊：

• KEYS_ONLY — 僅包含被修改項目的鍵屬性。
• NEW_IMAGE — 修改後的項目。
• OLD_IMAGE — 修改前的項目。
• NEW_AND_OLD_IMAGES — 修改前後都包含，最適合審計與基於差異的下游邏輯。

串流保留時間與排序

DynamoDB Streams 的記錄保留 24 小時，之後會被清除。記錄在單一分片（shard）內依分區鍵嚴格排序，提供每個項目的排序保證。24 小時的保留窗口意味著消費者必須可靠——如果 Lambda 消費者故障超過一天，記錄將永久遺失。

Lambda 觸發整合

DynamoDB Streams 最常見的消費者是 AWS Lambda。你可以將串流設定為 Lambda 函數的事件來源，Lambda 會代你輪詢串流。Lambda 會重試失敗的批次，並在達到可設定的最大嘗試次數後報告到死信佇列（dead-letter queue）。Lambda 接 Streams 的典型模式包括：

• 將項目複製到搜尋索引（Amazon OpenSearch）。
• 向 Amazon SNS 或 Amazon SQS 發布通知。
• 在第二張 DynamoDB 資料表中維護彙總計數器。
• 在 AWS Step Functions 中觸發下游工作流程。

DynamoDB 整合 Kinesis Data Streams

對於高吞吐量、更長保留期或扇出（fan-out）的使用情境，DynamoDB 可以將變更事件傳送到 Amazon Kinesis Data Streams，作為原生 DynamoDB Streams 端點的替代或補充。Kinesis Data Streams 的資料保留時間最長可達 365 天，並透過 Enhanced Fan-Out 支援每個分片多個並行消費者。以下情況使用 DynamoDB 整合 Kinesis Data Streams：

• 需要超過 24 小時的保留期。
• 多個獨立消費者需要讀取相同的變更串流。
• 希望將 DynamoDB 變更資料與其他 Kinesis 來源合併到同一條串流處理管道。

DynamoDB 交易

在 DynamoDB 加入原生交易支援之前，開發者必須手動透過條件式寫入和重試迴圈來實現多項目原子性。原生交易讓 DynamoDB 資料建模在需要「全部成功或全部失敗」的模式下大幅簡化——例如從一個帳戶扣款並存入另一個帳戶。

TransactWriteItems

TransactWriteItems 將最多 100 個寫入操作（Put、Update、Delete、ConditionCheck）組合成一個原子性單元。所有操作要嘛全部成功，要嘛一個都不套用。截至 2022 年，每次交易的項目上限從 25 個提升至 100 個，但舊版考題內容可能仍引用 25 個的限制——DVA-C02 考試指南截至 2026 年同時認可這兩個數字，因此如果你在舊題庫中看到 25 作為選項，它仍可能是正確的。交易寫入費用為標準 WCU 的 2 倍。

TransactGetItems

TransactGetItems 將最多 100 個讀取操作組合成一個一致性快照，確保群組中的任何項目在讀取之間都不會發生變更。這對於核對餘額、庫存，或任何項目之間的讀取偏斜（read-skew）會損壞下游邏輯的情境都非常有用。交易讀取費用為強一致性 RCU 的 2 倍。

何時使用交易

當兩個或更多項目必須以嚴格的全有或全無語意一起變更時，使用 DynamoDB 交易——金融轉帳、庫存預留、涉及多種實體類型的冪等工作流程。不要把交易當作仔細鍵值設計的通用替代品；2 倍的費用乘數累積起來相當可觀。

條件式寫入

條件式寫入讓單一的 PutItem、UpdateItem 或 DeleteItem 僅在條件表達式評估為 true 時才成功。條件可以參照屬性的存在性（attribute_not_exists(pk)）、屬性值（#status = :pending）或複合的布林邏輯。條件式寫入不會產生額外費用——但條件評估失敗時仍然會消耗 WCU，因為 DynamoDB 需要讀取項目來評估條件。

使用版本屬性進行樂觀鎖定

樂觀鎖定是一種 DynamoDB 資料建模模式，使用 version 屬性來偵測並行更新，而無需採用悲觀鎖定（pessimistic lock）。流程如下：

1. 客戶端讀取項目並記錄當前版本，假設 version = 7。
2. 客戶端計算出更新內容，並以條件 version = 7 加上 SET version = 8 發出 UpdateItem 請求。
3. 如果另一個客戶端在此期間已將 version 寫為 8，條件就會失敗，更新被拒絕。客戶端讀取最新狀態後重試。

樂觀鎖定費用低（每次成功寫入 1 WCU）、可擴展至大量並行寫入者，是 DynamoDB 慣用的並行控制模式，取代了關聯式資料庫中的 SELECT FOR UPDATE 寫法。

DynamoDB Accelerator（DAX）實現微秒級讀取

DynamoDB Accelerator（DAX）是一個記憶體內（in-memory）的貫穿式寫入（write-through）快取，位於 DynamoDB 資料表前方，提供微秒級讀取延遲——約比 DynamoDB 基礎個位數毫秒延遲快 10 倍。DAX 是專為 DynamoDB 設計的快取；它不是 ElastiCache，並且使用 DynamoDB API，因此你的現有 SDK 程式碼只要改指向 DAX 端點就能直接運作，不需任何修改。

DAX 架構

DAX 叢集由一個或多個節點組成（每個叢集最多 11 個節點），部署在 VPC 內部。叢集對外暴露單一端點。你的 DynamoDB SDK 客戶端連接到 DAX 而非一般的 DynamoDB 端點；DAX 直接回應快取命中，並將快取未命中代理到 DynamoDB。

DAX 快取行為

• 項目快取（Item Cache）——依主鍵快取 GetItem 和 BatchGetItem 的回應。預設 TTL 為 5 分鐘。
• 查詢快取（Query Cache）——依參數雜湊快取 Query 和 Scan 的結果。預設 TTL 為 5 分鐘。
• 貫穿式寫入（Write-Through）——寫入會同步穿過 DAX 到達 DynamoDB；DAX 在寫入成功後更新自身快取，確保後續讀取與最後一次寫入一致。

何時使用 DAX

當你需要對讀取密集、基於鍵值存取模式的工作負載提供微秒級讀取時，使用 DAX——商品目錄、排行榜、廣告技術決策、遊戲 session。以下情況 DAX 幫助有限：

• 寫入密集的工作負載（每次寫入仍然會打到 DynamoDB）。
• 對大型結果集進行高基數的 Scan 和 Filter。
• 需要強一致性讀取的工作負載（DAX 本質上是最終一致性）。

DAX 與 ElastiCache 的比較

在 DVA-C02 考試中，如果情境要求在 DynamoDB 前方快取且對應用程式程式碼改動最少，DAX 是正確答案，因為它原生支援 DynamoDB API。如果情境需要跨異質來源進行快取（DynamoDB 加上 RDS 加上 API 回應），ElastiCache 才是正確答案——但代價是應用程式程式碼中需要明確管理快取鍵。

DynamoDB Time to Live（TTL）

DynamoDB TTL 是一個背景功能，會自動刪除 TTL 屬性已過期的資料項目。TTL 是免費的——刪除操作不消耗 WCU——使其成為 DynamoDB 資料建模中管理暫時性資料的慣用方式。

TTL 的運作方式

1. 在資料表上啟用 TTL，並指定哪個屬性存放過期時間戳記（常見名稱：ttl 或 expiresAt）。
2. 將屬性值設為項目應過期的 Unix epoch 時間（秒）。
3. DynamoDB 非同步掃描過期項目並將其刪除。刪除通常在過期時間後 48 小時內完成。
4. 刪除操作會出現在 DynamoDB Streams 中，帶有特殊的 userIdentity：principalId 為 dynamodb.amazonaws.com，讓下游消費者能區分 TTL 刪除與使用者主動刪除。

TTL 使用情境

• 在 N 小時後過期的 session token。
• 臨時性一次性密碼。
• 有固定生命周期的快取條目。
• 應在保留期後淘汰的事件資料。

TTL 注意事項

• 刪除是最終一致性的，並非立即執行——在時間戳記過期後的最多 48 小時內，查詢仍可能回傳已過期的項目。如果時效性很重要，請在應用程式中一律以 TTL 值進行過濾。
• TTL 是盡力而為（best-effort）的機制。對於有合規要求的刪除，應使用明確的 DeleteItem 呼叫。

DynamoDB Global Tables

DynamoDB Global Tables 可跨多個 AWS 區域複製資料表，並具備完整的主動-主動多主（active-active multi-master）語意。每個區域都可以接受讀取和寫入；DynamoDB 以非同步方式將變更傳播到其他區域，通常在一秒內完成。

Global Tables 核心特性

• 跨任意受支援區域的主動-主動多主架構。
• 以伺服器端時間戳記為基礎的最後寫入者獲勝（last-writer-wins）衝突解決。
• 複製延遲通常 < 1 秒，SLA 為 99.9%。
• 需要在資料表上啟用 DynamoDB Streams。
• 在每個區域本地使用相同的 RCU 和 WCU 單位；複製會額外產生複製寫入請求單位（rWRU）。

何時使用 Global Tables

• 全球分布的應用程式，需要為各地理位置的使用者提供本地區域延遲。
• 跨區域的災難復原，讀取的 RTO 為零。
• 每個區域都接受寫入的多區域主動-主動架構。

Global Tables 注意事項

• 衝突解決採用最後寫入者獲勝，當不同區域同時更新同一個項目時，可能會靜默覆蓋其中一方。若應用程式無法容忍跨區域的更新遺失，需加入應用程式層級的衝突解決邏輯（例如，合併陣列而非直接覆寫）。
• PITR 必須逐個區域單獨設定。
• 費用除了本地 WCU 外，還包含跨區域複製寫入請求單位。

備份策略：隨需備份與 PITR

DynamoDB 提供兩種互補的備份機制，兩者都出現在 DVA-C02 的 DynamoDB 資料建模情境題中。

隨需備份

隨需（On-Demand）備份是你手動觸發或透過排程（例如 AWS Backup）執行的完整快照。快照無限期保存，按快照儲存空間的 GB 計費。適合以下使用情境：

• 在高風險的 schema 變更前進行部署前檢查點備份。
• 需要保存超過 35 天備份的法規要求。
• 透過 AWS Backup 進行跨帳號或跨區域的封存。

時間點復原（PITR）

PITR 是持續備份功能，讓你可以將資料表還原至過去 35 天內的任意秒。PITR 是防止意外寫入和刪除的 DynamoDB 資料建模慣用答案。PITR 核心知識：

• 35 天的滾動窗口（請在考試中精確記住這個數字）。
• 還原會建立一張新的資料表；原始資料表保持不變。你需要還原到新的資料表名稱，再在應用程式層切換。
• PITR 是資料表層級的設定，必須明確啟用。
• PITR 費用按資料表大小的 GB-月計費。

如何選擇

• 過去 35 天內意外執行 UpdateItem 或 DeleteItem → PITR。
• 跨區域的完整資料表災難復原 → 隨需備份 + AWS Backup 跨區域複製。
• 保留期超過 35 天的法規要求 → 長期保存的隨需備份。
• 應用程式部署出問題後的時間點還原 → PITR。

DynamoDB 資料建模常見考試陷阱

DVA-C02 題庫可靠地反覆考以下 DynamoDB 資料建模陷阱。將每個陷阱練習到反射動作的程度。

陷阱一：以為 Scan 在正式環境中是可接受的

Scan 會讀取每個項目，並按每 4 KB 掃描量支付完整 RCU。在考試中，任何用 Scan 來解決查詢模式的答案幾乎都是錯的，除非情境明確允許大量離線批次處理。正確的 DynamoDB 資料建模答案通常是針對 GSI 的 Query，或是帶有排序鍵條件的複合鍵 Query。

陷阱二：需要執行時彈性時卻選擇了 LSI

LSI 只能在建立資料表時設定。如果情境描述的是一張既有的正式資料表，並詢問如何在不停機的情況下新增新的查詢模式，答案是 GSI，而非 LSI。

陷阱三：在最終一致性就足夠的地方使用強一致性

強一致性讀取的費用是最終一致性讀取的 2 倍。許多 DynamoDB 資料建模的考試情境描述的是可以容忍一秒鐘延遲的讀取（個人資料讀取、目錄查詢、排行榜瀏覽）——這些應該使用最終一致性讀取，以減少一半的費用。

陷阱四：遺漏交易的 2 倍乘數

交易讀取和寫入的費用是雙倍的。如果考試要求你為包含交易的工作負載計算容量，在比較答案選項之前，務必先套用 2 倍乘數。

陷阱五：低基數鍵導致的熱分區

情境中使用 date、status、country 或 category 作為分區鍵的題目，都在測試對熱分區的認知。正確答案是將鍵重新設計，加入高基數的組成部分（使用者 ID、session ID、請求 ID），或加入隨機後綴（寫入分片，write sharding）來分散負載。

陷阱六：忘記 DynamoDB Streams 只保留 24 小時

如果情境要求在多天中斷後重放變更事件，單靠 DynamoDB Streams 是不夠的——正確答案需要整合 Kinesis Data Streams（保留期最長 365 天）以提供更長的重放窗口。

陷阱七：DAX 不等於 ElastiCache

DAX 是專為 DynamoDB 設計並原生支援 DynamoDB API 的快取。ElastiCache（Redis 或 Memcached）是在應用程式層快取任意值的通用記憶體快取。當情境說「在 DynamoDB 前方快取、程式碼改動最少且需要貫穿式一致性」，答案是 DAX。

陷阱八：以為 Global Tables 能解決所有多區域問題

Global Tables 提供主動-主動複製，採用最後寫入者獲勝的衝突解決機制。如果情境要求跨區域嚴格的單一寫入者語意（例如金融帳本），正確答案是指定一個區域作為主要寫入者，並僅將 Global Tables 用於其他區域的唯讀副本——或者改用其他服務。

陷阱九：以為 TTL 會立即刪除項目

TTL 刪除是在過期時間戳記後 48 小時內盡力完成的。需要精確時效性的應用程式，必須在每次查詢中都以 TTL 屬性值進行過濾。

陷阱十：忘記處理 ProvisionedThroughputExceededException

當預置模式的資料表發生限流時，SDK 會拋出 ProvisionedThroughputExceededException。關於錯誤處理的 DynamoDB 資料建模考試情境，預期答案是指數退避（exponential backoff，AWS SDK 預設已實作）加上容量擴展或鍵值重新設計作為長期修正方案。

DynamoDB 資料建模實戰模式：訂單與購物車

以下是一個電商平台的單一資料表 DynamoDB 資料建模實際範例：

• 資料表名稱：retail-app。
• 基礎鍵：PK、SK。
• GSI1 鍵：GSI1PK、GSI1SK。

資料項目：

• 使用者個人資料：PK=USER#u42，SK=PROFILE，email=...，GSI1PK=EMAIL#[email protected]，GSI1SK=USER#u42。
• 購物車：PK=USER#u42，SK=CART#c001，status=ACTIVE，updatedAt=...。
• 購物車明細：PK=CART#c001，SK=ITEM#p123，quantity=2。
• 訂單：PK=USER#u42，SK=ORDER#2026-04-20#o987，status=PAID，GSI1PK=ORDER#STATUS#PAID，GSI1SK=2026-04-20#o987。

無需掃描即可服務的存取模式：

1. 取得使用者個人資料 → GetItem PK=USER#u42，SK=PROFILE。
2. 列出某位使用者依日期排序的所有訂單 → Query PK=USER#u42，SK begins_with "ORDER#"。
3. 列出購物車中的所有品項 → Query PK=CART#c001，SK begins_with "ITEM#"。
4. 依 email 尋找使用者 → Query GSI1，GSI1PK=EMAIL#[email protected]。
5. 列出所有使用者中已付款的訂單用於報表 → Query GSI1，GSI1PK=ORDER#STATUS#PAID，依日期排序。

每一種存取模式都是 Query 或 GetItem。沒有 Scan，沒有跨資料表 JOIN，一張資料表，兩個索引。

DynamoDB 資料建模的安全性與可觀測性

DynamoDB 整合 AWS IAM 進行細粒度存取控制、AWS KMS 進行靜態加密、AWS CloudTrail 進行 API 審計，以及 Amazon CloudWatch 進行指標與警報。IAM 條件鍵可以依分區鍵前綴、屬性名稱或返回屬性列表來限制存取——例如，允許租戶只讀取分區鍵以其租戶 ID 為前綴的項目。DynamoDB 的 Amazon CloudWatch 指標包括 ConsumedReadCapacityUnits、ConsumedWriteCapacityUnits、ThrottledRequests、SystemErrors 和 UserErrors。多租戶應用程式的 DynamoDB 資料建模，大量依賴 IAM 條件鍵來實現租戶隔離。

DynamoDB 資料建模的成本控制槓桿

• 選擇正確的容量模式（隨需 vs. 預置 + Auto Scaling）。
• 在可接受延遲的地方使用最終一致性讀取——費用減半。
• 在正式環境中避免 Scan；一律透過分區鍵範圍的 Query 或 GetItem 來服務請求。
• 只將需要的屬性投影到 GSI（使用 KEYS_ONLY 或 INCLUDE 投影），以降低 GSI 儲存費用和寫入費用。
• 對讀取密集的工作負載啟用 DAX——一次快取命中可以節省許多基礎資料表 RCU。
• 使用 TTL 自動淘汰資料，而非支付永久儲存費用。
• 調整項目大小——大型項目消耗更多 WCU 和 RCU；如有必要，可將鮮少存取的屬性拆分到獨立的項目。

DynamoDB 資料建模必背數字與關鍵事實

• 最大項目大小：400 KB。
• 分區鍵長度：最多 2048 bytes。
• 排序鍵長度：最多 1024 bytes。
• 每張資料表 LSI 數量：5 個，且只能在建立時設定。
• 每張資料表 GSI 數量：20 個（軟性上限）。
• TransactWriteItems 最多項目數：100 個（舊版 25 個）。
• TransactGetItems 最多項目數：100 個（舊版 25 個）。
• BatchWriteItem 最多項目數：25 個，最多 16 MB。
• BatchGetItem 最多項目數：100 個，最多 16 MB。
• DynamoDB Streams 保留期：24 小時。
• DynamoDB 整合 Kinesis Data Streams 保留期：最長 365 天。
• PITR 保留期：35 天。
• 隨需容量預設突發能力：新資料表可立即服務 4000 WCU 和 12000 RCU。
• 寫入 1 KB = 1 WCU；強一致性讀取 4 KB = 1 RCU。
• 最終一致性讀取 = 0.5 RCU；交易讀取或寫入 = 正常費用的 2 倍。
• DAX 延遲：微秒級（vs. 基礎 DynamoDB 的個位數毫秒）。
• Global Tables 複製延遲：通常 < 1 秒，採用最後寫入者獲勝。

FAQ — DynamoDB 資料建模常見問題

1. 在 DynamoDB 資料建模中，如何選擇 LSI 與 GSI？

當你必須以不同的排序鍵查詢共享相同分區鍵的項目、在建立資料表時就已知道次要存取模式，且需要在索引上進行強一致性讀取時，選擇 LSI。當你需要不同的分區鍵、存取模式在資料表上線後才出現、願意接受最終一致性讀取，或次要存取模式需要跨分區時，選擇 GSI。請記住 DVA-C02 最重要的規則：LSI 必須在建立資料表時同時建立；GSI 可以隨時新增、修改或刪除。

2. 什麼是單一資料表設計，何時應在 DynamoDB 資料建模中使用它？

單一資料表設計將多種實體類型（使用者、訂單、商品）打包進一張 DynamoDB 資料表，透過帶有實體前綴的覆載分區鍵與排序鍵（如 USER#、ORDER#、PRODUCT#）加以區分。它讓單一 Query 就能回答在關聯式資料庫中需要多資料表 JOIN 的存取模式，同時將基礎設施規模縮減為一張資料表、一個 IAM 政策和一份備份。當你的應用程式有需要一起取回的相關實體，且希望達到 serverless 友善的最少往返次數時，使用單一資料表設計。只有在實體彼此真正無關、容量需求差異懸殊，或必須由不同 IAM 主體擁有時，才堅持使用多資料表設計。

3. 如何計算指定工作負載的 DynamoDB 容量？

對於寫入，一個 WCU 每秒服務一次不超過 1 KB 項目的標準寫入——將項目大小向上取整到下一個整數 KB，乘以每秒請求數，再對交易寫入乘以 2。對於讀取，一個 RCU 每秒服務一次不超過 4 KB 項目的強一致性讀取——將項目大小向上取整到下一個整數倍 4 KB，最終一致性讀取除以 2，交易讀取乘以 2。計算範例：每秒 500 次強一致性讀取，項目大小 8 KB = 500 × ceil(8/4) = 1000 RCU。務必為交易套用 2 倍乘數，為最終一致性讀取套用 0.5 倍。

4. 何時應對 DynamoDB 使用 DynamoDB Streams，何時應使用 Kinesis Data Streams 進行變更資料捕獲？

DynamoDB Streams 是原生的、免費（只需支付讀取請求單位費用）的變更串流，保留期 24 小時，並具備嚴格的每項目排序。它非常適合 AWS Lambda 觸發器、小規模複製及輕量事件驅動模式。當你需要超過 24 小時的保留期（最長 365 天）、透過 Enhanced Fan-Out 讓每個分片有多個並行消費者，或需要整合到更廣泛的 Kinesis 分析管道時，DynamoDB 整合 Kinesis Data Streams 是正確選擇。有些團隊會同時啟用兩者——DynamoDB Streams 用於即時 Lambda 觸發，Kinesis Data Streams 用於長期重放和分析。

5. DynamoDB 的樂觀鎖定是如何運作的，何時應改用交易？

樂觀鎖定為每個項目新增一個 version 屬性。當客戶端想更新項目時，它讀取當前版本，執行更新，並以條件表達式 version = <上次讀取的版本> 加上 SET version = version + 1 發出 UpdateItem 請求。如果另一個寫入者在此期間已更新版本，條件就會失敗，更新被拒絕，客戶端需讀取最新狀態後重試。樂觀鎖定每次成功寫入消耗 1 WCU，可擴展至高並行度。當你必須原子性地同時更新兩個或更多項目時，改用 DynamoDB 交易（TransactWriteItems）——例如從一個帳戶扣款並存入另一個帳戶。交易費用為正常 WCU 的 2 倍，但保證最多 100 個項目的全有或全無語意。

6. DAX 與 ElastiCache 在 DynamoDB 快取方面有何差異？

DAX（DynamoDB Accelerator）是專為 DynamoDB 設計的貫穿式寫入快取，原生支援 DynamoDB API。你只需將現有的 DynamoDB SDK 客戶端指向 DAX 端點，SDK 程式碼無需任何修改；快取命中在微秒內回傳，比基礎資料表的個位數毫秒快得多。DAX 最適合讀取密集、基於鍵值的存取模式。ElastiCache（Redis 或 Memcached）是通用型記憶體快取，需要在應用程式程式碼中明確管理快取鍵；它可以快取來自 DynamoDB、RDS、外部 API 或任何其他來源的回應。當唯一的快取來源是 DynamoDB 且希望零程式碼改動時，選擇 DAX；當需要快取異質來源或需要 Redis 豐富的資料結構（例如有序集合或 Pub/Sub）時，選擇 ElastiCache。

7. 在 DynamoDB 資料建模中，如何防止熱分區？

熱分區發生在某個分區鍵值接收了不成比例的大量流量，導致擁有該雜湊範圍的實體分區發生限流，無論資料表的總容量有多充足。防止熱分區的方法：(a) 選擇高基數的分區鍵，如使用者 ID、裝置 ID 或 session ID，而非低基數的鍵如 status、country 或 date；(b) 對高流量的鍵進行分片，在其後附加隨機後綴（例如 CATEGORY#ELECTRONICS#01 到 #10），讀取時使用 scatter-gather 模式；(c) 使用寫入分片（write sharding）模式，將傳入的事件路由到 N 個合成分區鍵之一；(d) 利用 DynamoDB 內建的自適應容量來處理輕微的不均衡狀況。在 DVA-C02 考試中，描述「儘管總體使用率不高卻仍發生限流」的情境，始終是熱分區問題，正確的修正方式是重新設計分區鍵。

8. 透過 TTL 刪除項目時，DynamoDB Streams 的記錄會發生什麼？

TTL 刪除會以帶有特殊 userIdentity 物件的串流記錄的形式發出：principalId 為 dynamodb.amazonaws.com，記錄類型為 REMOVE。這讓下游消費者能夠區分 TTL 驅動的刪除與使用者主動刪除，從而應用不同的邏輯——例如，將過期的項目封存到 Amazon S3，而非視其為使用者刻意執行的刪除。TTL 刪除也會出現在 DynamoDB 整合 Kinesis Data Streams 的串流中。

9. 我可以將 DynamoDB 資料表還原到過去某個時間點嗎？可以回溯多久？

可以，前提是你已在資料表上啟用時間點復原（PITR）。PITR 會為過去 35 天維護持續備份，讓你可以還原到該窗口內的任意秒。還原操作會建立一張新的資料表，而不會覆蓋原始資料表，因此還原完成後，應用程式必須切換資料表名稱。隨需備份與 PITR 互補，用於超過 35 天的保留期，以及透過 AWS Backup 進行跨區域或跨帳號封存。

10. DynamoDB Global Tables 如何處理跨區域的寫入衝突？

DynamoDB Global Tables 採用以伺服器端時間戳記為基礎的最後寫入者獲勝衝突解決機制。當兩個區域同時對同一個項目進行寫入，時間戳記較晚的寫入最終會在所有區域覆蓋較早的寫入。這種機制簡單且對延遲友善，但如果應用程式無法容忍寫入衝突，可能會靜默地丟失更新。對於需要跨區域嚴格單一寫入者語意的情境，應指定一個區域作為主要寫入者，將所有寫入路由到該區域，並僅將 Global Tables 用於向其他區域複製唯讀副本——或者改用 Amazon Aurora Global Database 等提供強一致性單一寫入者語意的其他服務。

延伸閱讀

• Amazon DynamoDB Developer Guide: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html
• DynamoDB Best Practices: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
• NoSQL Design for DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html
• Secondary Indexes: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html
• Read/Write Capacity Modes: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
• DynamoDB Streams: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html
• DynamoDB Transactions: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html
• DynamoDB Accelerator (DAX): https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html
• DynamoDB TTL: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html
• DynamoDB Global Tables: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html
• Point-in-Time Recovery: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html
• AWS DVA-C02 Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-dev-associate/AWS-Certified-Developer-Associate_Exam-Guide.pdf