Enter your search text in the box above

Select a result to preview

DynamoDB 鍵值資料庫 (DynamoDB)

#database #dynamodb #nosql #system-design
一句話定位

DynamoDB = AWS 全託管、高度可擴展的鍵值（兼文件）NoSQL。幾乎涵蓋面試裡所有持久化需求，現在還支援交易 —— 「NoSQL 沒交易」的舊批評已經過時。
關鍵能力是選對資料模型：partition key、sort key、次要索引。

三個賣點

賣點 含義
全託管 AWS 管硬體、設定、修補、擴展；開發者只管應用程式
高度可擴展 自動上下擴展，無停機、無效能下降
鍵值模型 不用關聯模型，schema-less，儲存/取得更有彈性
面試能不能用 DynamoDB？

問你的面試官。 有人歡迎、期待你會用；有人想避開供應商鎖定、期待開源替代。永遠直接問。

資料模型

分區鍵與排序鍵

主鍵由一或兩個屬性組成：

鍵 角色
Partition Key（必） 值被 hash → 決定 item 存哪個物理分區
Sort Key（選） 同分區鍵下對 item 排序 → 分區內高效範圍查詢

面試介紹 DynamoDB 一定要指定 partition key（視情況加 sort key）。選能優化最常見查詢、且讓資料均勻分散的鍵。
例：群組聊天用 chat_id（PK）+ message_id（SK），高效查某群所有訊息並排序。

底層：Hash 分區 + B-tree

查詢 → 用 partition key 的 hash 找到正確儲存節點（概念類似 consistent hashing，
        但 DynamoDB 用中心化的分區 metadata 服務，非 P2P hash ring）
     → 分區內用 sort key 為索引的 B-tree 找到 item

兩層架構 → 同時達到水平擴展（分區） + 分區內高效查詢（B-tree）。

次要索引：GSI vs LSI

用「非 partition key 的屬性」查詢時需要次要索引。

維度 GSI（全域） LSI（本地）
分區鍵 與主表不同 與主表相同，但不同 sort key
物理儲存 獨立分區、獨立複製（像獨立表） 與被索引 item 共址
使用時機 用非主鍵屬性做全域查詢 同 partition key 下用額外 sort key
大小限制 無限制 每 partition key 最多 10GB
吞吐量 與基表分開計算讀寫容量 與基表共用讀寫容量
一致性 僅最終一致 最終一致（預設）+ 強一致讀取
建立時機 可隨時新增/移除 只能建表時定義，無法移除
數量上限 每表最多 20 個 每表最多 5 個

例：聊天表 PK=chat_id。想查「某用戶在所有聊天室發的訊息」→ 建 GSI（PK=user_id, SK=message_id）。想查「某群附件最多的訊息」→ 在 num_attachments 建 LSI。

存取資料：Scan vs Query

操作 行為 效率
Scan 讀整張表/索引每個 item，分頁回傳 大表非常低效，盡量避免
Query 依主鍵/次要索引鍵取 item，可對 sort key 範圍查詢 高效（只讀符合的）
ProjectionExpression ≠ SQL 欄位選取

它只減少網路傳輸，底層仍讀整個 item，仍按完整大小算讀取費用。大型 item 要適當正規化，避免每次讀回超過所需。
介面是 AWS SDK / 控制台，也支援 PartiQL（SQL 相容語法層，底層仍轉成 DynamoDB 操作）。

CAP：每請求選一致性

DynamoDB 的一致性不是表級設定，而是每個讀取請求指定（ConsistentRead）：

模式 行為 成本（每 4KB） 限制
最終一致（預設） 任一副本服務；最高可用、最低延遲；表現為 AP/BASE 0.5 RCU 可能讀到稍舊資料
強一致（ConsistentRead=true） 路由到 leader，反映所有先前成功寫入 1 RCU（兩倍） 不支援 GSI
強一致只支援基表 + LSI，GSI 只有最終一致

設計需要強一致的存取模式時要牢記這點。
靈活性：訂位等場景用強一致；讀多、延遲敏感路徑用最終一致。

架構與可擴展性

定價模型（帶出架構限制）

兩種模式：隨需（on-demand） 按請求計費（流量不可預測）；預置容量（provisioned） 指定 RCU/WCU 按小時計費（可預測流量更划算）。

單位 定義
1 RCU 每秒讀 ≤4KB（強一致）；最終一致只耗 0.5 RCU
1 WCU 每秒寫 ≤1KB（無條件進位到 1KB）

每分區上限 3,000 RCU / 1,000 WCU → 單分區約 12MB/s 讀、1MB/s 寫。

進階功能

面試：何時用 / 何時不用

✅ 用：幾乎任何持久化需求；高可擴展、持久、支援交易、個位數毫秒延遲（DAX 更達微秒）。

❌ 不用：

理由 說明
成本效益 高流量（數十萬寫/秒）下可能很貴
複雜查詢 JOIN、ad-hoc 聚合力不從心（缺 SQL 靈活查詢）
資料建模限制 頻繁用 GSI/LSI → 可能 PostgreSQL 更合適
供應商鎖定 綁 AWS；面試官想雲端中立時考慮開源替代

自我測驗重點

問題 重點
PK vs SK 作用 PK hash 定分區；SK 分區內範圍查詢
GSI vs LSI 最大差異 GSI 不同 PK/獨立/可隨時建/僅最終一致；LSI 同 PK/共址/建表時定/可強一致
Scan vs Query Scan 掃全表（避免）；Query 走鍵（高效）
強一致限制 不支援 GSI；耗 2 倍 RCU
每分區吞吐上限 3,000 RCU / 1,000 WCU
DAX 不快取什麼 強一致讀取；繞過 DAX 的寫入不自動失效
Streams 用途 CDC → 同步 ES / 即時分析 / 觸發 Lambda