本文是 DynamoDB overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。

single-table design 上線後第三個月、PM 提了三個新 query 需求：「依商品分類查訂單」、「依 status 查 user」、「依時間 range 取最近活動」。team 第一反應是加 GSI、結果 GSI 從 1 個變 6 個、cost 跟 latency 一起上升。打開 AWS Cost Explorer 一看、GSI 的 storage + WCU 合計已經超過 base table。這時 team 開始懷疑「single-table 是不是錯了」— 那是 誤判。GSI 多到 cost 超過 base table 通常是 主 PK 沒設計好、不是 single-table 錯。本文展開 GSI / LSI 的正確補位、projection 的三型選擇、sparse index、以及 DAX 作為讀峰值補位的觸發條件。

DynamoDB workload 適配判讀（基本 4 軸）：PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定 — 判讀軸詳見 single-table-design-pattern 開頭 4 軸前置判讀。本文聚焦 GSI / LSI 補位操作層、是 已選 DynamoDB + access pattern 已穩定 的 schema 設計議題。

核心機制：GSI vs LSI 的工程差異

DynamoDB 的兩種 secondary index 解的問題不同：

Scope warning：「LSI 數量上限 5 個」、「GSI 數量上限 20」這些具體數字屬 vendor 規格、需在實作時 cross-verify AWS doc 當前數字、本文 case（Disney+ / Capcom / Lemino）沒揭露具體 index 數量。

Projection type 決定 GSI 儲存哪些 attribute：

• KEYS_ONLY：只存 PK + SK + base key、最省 storage、但讀取後通常還要回 base table 撈 attribute
• INCLUDE：除了 key、再存指定的 attribute；常用 sweet spot、storage 跟 query 效率平衡
• ALL：複製 base table 所有 attribute；最方便、最貴

讀路徑差異：

• GSI eventual read：跨 partition、不支援 strong；base table write → GSI replication 通常 < 1s 但無 SLA
• LSI strong read：同 partition quorum 內成立、read-your-write 場景適用

對應 knowledge card：hot partition、consistency level。

DAX 作為讀峰值補位

DAX（DynamoDB Accelerator）不是 GSI / LSI 同層方案、不是 DynamoDB 預設配置、是「讀峰值持續高時的補位」。寫進你的設計前先看觸發條件：

9.C29 Lemino 揭露（case fact）：「DAX 是 DynamoDB 讀 cache 的標準解法」、觸發條件是「當讀峰值持續高、加 DAX 減少 DynamoDB 讀次數、降低成本」（熱門節目首播時段、共用 metadata）。Lemino 是 case 直接揭露使用 DAX。

9.C19 Capcom 是判讀層 derive、不是 case fact：原 finding 從「single-digit ms」latency 反推 Capcom 必須用 sub-region cache + DynamoDB DAX、不能單靠 DynamoDB；但 9.C19 case 沒有公開揭露 使用 DAX。引用 Capcom 時要明示「DAX 是作者判讀層推論、Capcom 沒公開使用」、避免把推論寫成 case 揭露。

跟 GSI / LSI 的職責分離：

• GSI / LSI 解「無法用主 PK 查」的問題（access pattern 補位）
• DAX 解「同 query 重複打 DynamoDB 太貴或太慢」的問題（讀路徑加速）
• 兩者不互斥、但解不同問題；不要把 DAX 當 GSI 替代品

DAX 適用觸發條件：

• 讀峰值持續高（熱門節目 / 共用 leaderboard / 全平台共享 metadata / read:write ratio > 10:1）
• cache 命中率可預期高（重複讀同一組 key）

DAX 不適用情境：

• 寫密集 workload（cache invalidation 開銷 > cache 收益）
• 每次讀都不同 key（cache hit rate < 30%、加 DAX 等於白花錢）
• read-your-write 場景（DAX 仍是 eventual cache、staleness 視 cache TTL 而定）

設計流程

從 access pattern 補位到 DAX 評估的 6 步流程。

Step 1：標記最小成本路徑

每個 access pattern 標記能用最便宜路徑解：

• 能用主表 PK/SK 直接 GetItem / Query → 主表（最便宜）
• 同 PK 內不同 SK 排序 + 需要 strong read → LSI（同 partition、strong）
• 跨 PK 或 base table 已建好 → GSI（額外 storage + WCU）

Step 2：選 LSI 還是 GSI

LSI 只能在 create table 時定義、不能後加。team 經常踩雷：上線後想加 strongly consistent 索引、發現只能重建 table。建 table 前列完 access pattern、不確定走 GSI 不走 LSI 是保守選擇（GSI 隨時可加可移）。

Step 3：projection 設計

每個 GSI 單獨設 projection、不要全用 ALL：

• query 只要回 key → KEYS_ONLY
• query 需要常見 3-5 個欄位 → INCLUDE（列出實際 column、storage 跟 query 效率平衡）
• 用 GSI 直接顯示資料（不回 base table） → ALL（storage 跟 WCU 都翻倍、慎用）

Step 4：sparse index pattern

GSI PK 只在某 attribute 存在時填、自動「只索引子集」、節省 storage：

1def write_order(order_id: str, status: str):
2    item = {"PK": f"ORDER#{order_id}", "SK": "META", "status": status}
3    # sparse index: 只有 active order 進 GSI
4    if status == "active":
5        item["GSI1PK"] = "STATUS#active"
6        item["GSI1SK"] = order_id
7    table.put_item(Item=item)

GSI1 只索引 active order、archive order 不進 GSI。當 active order 是 10%、storage 節省約 90%。

Scope warning：「50-90% storage 節省」具體節省比例屬通用工程估算、依 active subset 比例變動、case 未揭露 sparse index 具體數字。

Step 5：驗證點

1response = table.query(
2    KeyConditionExpression=Key("GSI1PK").eq("STATUS#active"),
3    IndexName="GSI1",
4    ReturnConsumedCapacity="INDEXES"  # 看每個 query 走 GSI 還是主表
5)
6print(response["ConsumedCapacity"])

CloudWatch GSI metric：看每個 GSI 的 WCU usage 跟主表的比例；GSI WCU > base table WCU 通常是設計訊號。

Step 6：DAX 評估

讀峰值持續高 + cache hit rate 可預期、才加 DAX；不要把 DAX 當預設配置（Lemino 揭露的觸發條件）。先觀察 base 路徑的 read pattern、判斷 cache hit rate 預期值、再決定加 DAX。

Rollback boundary：GSI 可隨時刪、但 deletion 是 async 且不可逆；建議先 application 切回 base table query、觀察 1 週再刪 GSI。DAX 可隨時 detach、application 端把 DAX endpoint 換回 DynamoDB endpoint 即可。

失敗模式

7 個 production 常見踩雷：

Case 1：GSI 寫入 throttle 拖累主表 write

GSI 用了集中型 PK（如 STATUS#active 所有 active order 集中）、單 partition 上限 1000 WCU 撞牆、GSI replication 失敗、主表 write retry、整體 latency 上升。修法：GSI PK 設計獨立 review、不可繼承主表 PK 的均勻假設（base PK 均勻 ≠ GSI PK 均勻）；GSI PK 也要做 partition key 均勻度判讀。

Case 2：GSI eventual read 餵錯資料

application 用 GSI 讀「user 最新 status」、code 假設 strong 一致；實際 100-500ms staleness 導致 UI 顯示舊狀態。修法：read-your-write 場景改回主表 query（主表支援 strong）、或加 application-side write-through cache。

Scope warning：「100-500ms staleness」具體數字屬通用工程估算、case 未揭露 GSI replication latency 具體 p99 數字。

Case 3：projection ALL 把 cost 翻倍

圖省事所有 GSI 用 ALL、實際 query 只需要 3 個 column；storage + WCU 都浪費。修法：每個 GSI 單獨設 projection、INCLUDE 列出實際 column；只在「用 GSI 直接顯示資料、不回主表」場景才用 ALL。

Scope warning：「cost 翻 3 倍」具體數字屬通用工程估算、case 未揭露具體 cost ratio。

Case 4：LSI 用完了才發現要的是 GSI

LSI 上限受 vendor 規格限制（建議 cross-verify AWS doc 當前數字）且建 table 時定、半年後想加 strongly consistent 索引發現要重建 table。修法：建 table 前列完 access pattern、不確定就走 GSI（隨時可加可移）；LSI 留給「明確需要同 PK + strong read」場景。

Case 5：GSI 反向 scan 取代 query

application 用 GSI 做 Scan 而非 Query、全 GSI 掃過去、cost 跟 latency 都炸。修法：Scan 是 程式碼錯誤訊號、不是 capacity 不夠；review code 看 GSI 為什麼沒被當 query 路徑用、通常是 GSI PK 設計沒對齊 access pattern。

Case 6：把 DAX 當預設配置

寫密集 workload / cache hit rate 低的場景加 DAX、cache invalidation 成本超過 cache 收益、cost 上升 latency 沒降。修法：DAX 是「讀峰值持續高」的補位、不是預設（Lemino 揭露的觸發條件、Capcom 是 derive 不是 case fact）；先觀察 read pattern + 評估 cache hit rate 預期、再決定。

Case 7：GSI capacity mode 跟 base table 不一致

GSI 的 capacity mode 跟 base table 是 獨立 設定、不會自動繼承 — base table 是 provisioned + auto-scaling、開新 GSI 預設仍是 provisioned 但 WCU / RCU 預設值跟 base table 不同步、或誤把某個 GSI 切 on-demand 而 base table 維持 provisioned、實際 production 寫入 throttle / 成本失衡都會出現。屬通用工程議題、case 未直接揭露具體 mode 錯配狀況。

徵兆：

• Base table ConsumedWriteCapacityUnits 健康、卻看到 GSI WriteThrottleEvents 持續觸發、application 端寫入 latency p99 拉高
• GSI 切 on-demand 後成本「不知為何」翻 X 倍、查 Cost Explorer 才發現 GSI WCU 計費跟 base table 的 provisioned 是完全不同帳單路徑
• Auto-scaling policy 只設了 base table、GSI 沒設、流量上來時 base table 自動擴、GSI 卻 throttle

修法：

• 建 GSI 時把 capacity mode 當成獨立決策、不要假設「base 怎麼設、GSI 跟著走」
• 流量穩定 workload 同時把 base + GSI 都設 provisioned + auto-scaling、auto-scaling target 對齊
• Spiky workload 改 on-demand 時整批切（base table + 全部 GSI 同時切）、避免單側切換造成 partial throttle
• CloudWatch alarm 對每個 GSI 獨立設 WriteThrottleEvents / ReadThrottleEvents、不要只盯 base table
• 詳細 mode 切換時機看 sibling on-demand vs provisioned

Anti-recommendation：access pattern < 3 個、主表 PK 已能覆蓋 → 不要預先建 GSI；GSI 從少到多容易、從多到少要 application 端配合 cutover。

容量與觀測

CloudWatch metric：

• 每個 GSI 獨立 ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits
• ReplicationLatency：GSI async replication 延遲、p99 通常 < 1s（無 SLA）
• DAX：CacheHits / CacheMisses / CacheHitRate、ItemCacheHits / QueryCacheHits

ReturnConsumedCapacity flag：query 時帶 INDEXES 看 GSI consumption；TOTAL 看 base + GSI 合計、debug 時切換用。

Cost monitoring：

• 每個 GSI 都重複收 storage + WCU；GSI 多時 cost 容易超過 base table
• 用 AWS Cost Explorer 按 GSI 維度看、不是只看 table-level 總 cost
• DAX cost 是 instance-hour 計、不是 per-request；只在 read peak 持續高才划算

Scope warning：「GSI 多時 cost 超過 base table」屬通用工程知識、9.C27 Disney+ / 9.C19 Capcom case 沒揭露具體 GSI cost ratio。

DAX 觀測重點（新增）：

• CacheHitRate < 70% 應重新評估 DAX 是否該存在
• cache size utilization 看 DAX instance class 是否足夠
• 觀察 cache miss 後 fallback 到 DynamoDB 的 latency、確認 DAX 真的減少 base 路徑壓力

Scope warning：「70% hit rate 閾值」屬通用工程估算、case 未揭露具體閾值。

接回 9.6 容量規劃模型 的 NoSQL index cost section、4.20 Observability Evidence Package。

邊界與整合

Disney+ / Capcom 的 access pattern 對照

9.C27 Disney+ 跟 9.C19 Capcom 是兩種 GSI 用法：

• Disney+ watchlist + 播放進度 + cross-device sync 全用主表 + 少量 GSI、避免 GSI 爆炸；cross-device sync 透過 Global Tables 處理、不是 GSI
• Capcom 玩家 leaderboard / 戰績用 GSI 反向查詢（跨遊戲共用平台、player_id 為 base PK、game_id 為 GSI PK）；leaderboard 是否該走 GSI 還是 Redis sorted set 是另一個取捨

兩個 case 都 沒有公開揭露 具體 GSI 數量、projection 配置、DAX 是否使用。引用 case 時要分層 — 概念是 case 揭露、實作數字是通用工程估算。

Sibling 與 cross-link

• single-table-design-pattern — GSI 是 single-table 沒覆蓋的 access pattern 補位
• partition-key-antipatterns — GSI 自己也會 hot partition、GSI PK 設計獨立 review
• consistency-model-optimization — GSI 強制 eventual、對應 consistency 軸
• on-demand-vs-provisioned — GSI 多時 cost 跟 mode 互動
• 替代路由：access pattern 變動頻繁 → 考慮 OpenSearch / Aurora、單純 search 不要拿 GSI 當 inverted index
• 跟 Capcom 9.C19 互引：leaderboard 用 GSI vs Redis sorted set 的選擇；DAX 是 derive 不是 case fact、引用要明示
• 跟 Lemino 9.C29 互引：DAX 作為讀峰值補位的 case 揭露

本文是 DynamoDB overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。

熱門節目首播時段、application 對同一批 metadata item 的讀取 latency p99 從 5ms 尖到 40ms、下游 timeout 連鎖。team 加了 DAX、p99 壓回個位數毫秒。三個月後另一個 service 也「照抄」加 DAX、結果 cost 上升、latency 沒降 — 那個 service 是寫密集、每次讀的 key 都不同、cache hit rate 不到 20%。同一個工具、在一個 workload 壓回 p99 延遲、在另一個只增加成本卻不降延遲。DAX 的價值取決於 read pattern 跟一致性需求是否匹配。本文展開 DAX 的 cluster 架構、兩種快取的不同失效語意、以及 write-through 跟 strongly consistent read 的邊界。

DAX 觸發條件 SSoT：DAX 「該不該存在」的觸發條件（讀峰值持續高 / cache hit rate 可預期 / read:write ratio 高）主寫於 gsi-lsi-design 的 DAX 段、含 9.C29 Lemino case fact 跟 9.C19 Capcom derive 分層。本文承接「已決定要用 DAX」之後的機制、配置與失效邊界、不重複展開觸發判讀。

核心機制：DAX cluster 與兩種快取

DAX（DynamoDB Accelerator）是 DynamoDB 前面的 in-memory write-through cache、提供 microsecond 級讀取（DynamoDB 本身是 single-digit ms）。它 API 相容 — application 把 DynamoDB client 換成 DAX client、API call 不變、讀寫自動經過 cache 層。

cluster 拓樸：

• 一個 DAX cluster 由多個 node 組成、一個 primary（接受寫）+ 多個 read replica
• 跨多 AZ 部署、primary 故障時 replica 接手
• application 透過 DAX endpoint 連 cluster、SDK 自動分散讀取到 replica

兩種快取、不同生命週期：

這張表的第二列是 DAX 最常被誤解的點：query cache 不會因為底層某筆 item 被改而失效。item cache 走 write-through、寫入時會更新；但 query cache 存的是「整個結果集」、DAX 無法知道某筆新寫入是否該進某個已快取的 query 結果、所以 query cache 只靠 TTL 過期。這代表 query 結果可能 stale 到一個 TTL 週期。

Scope warning：「item cache 預設 TTL 5 分鐘」、「query cache 預設 TTL 5 分鐘」這些預設值屬 AWS vendor 規格、可在 cluster 設定調整、實作時 cross-verify 官方 doc。本文不含 production case 揭露的 DAX TTL 配置數字。

對應 knowledge card：cache-invalidation、write-through-cache、ttl、cache-hit-rate。

一致性與 invalidation 邊界

DAX 的一致性語意是它跟「一般 cache-aside」最大的差別、也是踩雷集中區。

write-through 的保證範圍：

寫入經過 DAX 時、DAX 先寫 DynamoDB、成功後更新自己的 item cache。所以「寫完馬上用 GetItem 讀同一筆」、在 同一個 DAX node 上能讀到新值。但這不是 strong consistency — 多 node cluster 下、寫入只更新 primary 與被路由到的 node、其他 read replica 的 item cache 仍可能 stale 到 TTL。

strongly consistent read 繞過 cache：

DAX 只服務 eventually consistent read。application 若要求 strongly consistent read（ConsistentRead=True）、DAX 直接 pass through 到 DynamoDB、不經 cache、也享受不到 microsecond latency。這是設計上的取捨 — DAX 換 latency 的代價是放棄 strong consistency。read-your-write 嚴格場景不能靠 DAX。

query cache stale 的真實後果：

application 用 Query 列「某 user 的 active order」、結果被 query cache 快取；user 新建一筆 order、item cache 更新了該筆 item、但 列表 query 的 cache 沒失效、user 重整頁面在 TTL 內看不到新訂單。修法不是調 DAX、是判斷「這個 query 能不能接受 TTL 內 stale」— 不能接受的、該 query 不要走 DAX（直接打 DynamoDB）、或縮短該類 query 的 TTL。

Scope warning：上述一致性語意屬 DAX vendor 規格 + 通用 cache 工程知識、非 production case 揭露；實際 staleness 視 cluster node 數、TTL 配置與讀寫分布而定。

操作流程

從 read pattern 評估到上線的 6 步流程。

Step 1：確認 read pattern 適配

在加 DAX 前、用 CloudWatch 看目標 table 的 read:write ratio 跟 read 的 key 重複度：

• read:write 高（讀遠多於寫）+ 重複讀同一組 key → 適合
• 寫密集 / 每次讀不同 key / 大量 strongly consistent read → 不適合（回頭看 gsi-lsi-design DAX 觸發條件）

Step 2：cluster sizing

1node 數 = 讀峰值 throughput / 單 node 容量 + 1（容錯餘量）
2node class = 依 working set 大小選（cache 要能裝下熱資料）

跨至少 2 個 AZ、確保 primary 故障有 replica 接手。

Step 3：application 切換 client

1import amazondax
2# 原本：dynamodb = boto3.resource("dynamodb")
3dax = amazondax.AmazonDaxClient.resource(endpoint_url="dax://my-cluster.xxx.dax-clusters.region.amazonaws.com")
4table = dax.Table("orders")
5# API 不變、讀寫自動經過 DAX
6response = table.get_item(Key={"PK": "ORDER#123", "SK": "META"})

Step 4：分流 strongly consistent read

1# 需要 strong 的讀直接走 DynamoDB、不要走 DAX
2ddb_table.get_item(Key=..., ConsistentRead=True)   # 繞過 cache
3# 可接受 eventual 的讀走 DAX
4dax_table.get_item(Key=...)                          # 走 cache

application 要明確區分哪些讀路徑能接受 stale、哪些不能；不能接受的不走 DAX。

Step 5：設定 TTL 與監控 hit rate

依資料變動頻率設 item / query cache TTL：變動慢的 metadata 可設長 TTL、變動快的設短或不快取。上線後盯 CacheHitRate。

Step 6：驗證點

1# 驗證 hit rate 達預期、確認 DAX 真的減少 DynamoDB 讀
2# CloudWatch: DAX CacheHits / (CacheHits + CacheMisses)
3# 同時看 DynamoDB ConsumedReadCapacityUnits 是否下降

Rollback boundary：DAX 可隨時 detach — application 端把 DAX endpoint 換回 DynamoDB endpoint 即可、無資料遷移；DAX 只是讀路徑加速層、不持有唯一資料。

失敗模式

production 常見的 5 個踩雷：

Case 1：把 DAX 當預設配置

寫密集 / 低 hit rate workload 加 DAX、invalidation 開銷 + cluster 成本 > cache 收益。修法：先確認 read pattern 適配（Step 1）、DAX 是讀峰值補位不是預設（觸發條件 SSoT 在 gsi-lsi-design）。

Case 2：以為 query cache 會即時反映寫入

寫入後列表 query 在 TTL 內看不到新資料、被當成 bug 長時間誤查。修法：理解 query cache 只靠 TTL 失效（不是 bug 是設計）；強一致列表需求的 query 不走 DAX、或縮短 TTL。

Case 3：strongly consistent read 全走 DAX 還抱怨不快

application 全程 ConsistentRead=True、DAX 全部 pass through、等於沒裝 DAX 還多付 cluster 錢。修法：分流 — strong read 直接打 DynamoDB、eventual read 才走 DAX。

Case 4：cluster 單 AZ / 單 node

省成本只開單 node、primary 故障時讀路徑整個失效、回退到 DynamoDB 瞬間流量尖峰。修法：跨 2+ AZ、primary + replica；DAX 故障的 fallback 路徑（直連 DynamoDB）要先測過。這個 Case 的失敗代價跟其他 Case 不對稱 — 其餘 Case 多是成本浪費或延遲沒降、detach DAX 即可回復；單 AZ / 單 node 故障是讀路徑硬中斷、回退瞬間把原本被 cache 吸收的讀峰值全打回 DynamoDB、若 base table 的 RCU 或 on-demand burst 餘量沒預留、會引發 throttling 連鎖。回退路徑要按「DAX 全失效時的讀峰值」預估 DynamoDB 側容量、而非平時被 cache 削減後的讀量。

Case 5：working set 超過 cache 容量

熱資料超過 node memory、cache 不斷 evict、hit rate 掉到沒意義。修法：依 working set 選 node class、或縮小快取範圍（只快取真正熱的 access pattern）。

Anti-recommendation：read:write ratio 低、或 cache hit rate 預期 < 50% 的 workload、不要上 DAX；application 端的 request-level cache 或根本不快取可能更划算。DAX 是 cluster 常駐成本（instance-hour 計）、只在讀峰值持續高才回本。

容量與觀測

CloudWatch metric：

• CacheHits / CacheMisses / 算出 CacheHitRate — 核心健康指標
• ItemCacheHits / QueryCacheHits — 分辨兩種快取各自的命中
• CPUUtilization / EvictedSize — node 是否過載、cache 是否頻繁 evict
• DynamoDB 端 ConsumedReadCapacityUnits — 確認 DAX 真的削減了 base 讀取

判讀：

• CacheHitRate < 70% — 重新評估 DAX 是否該存在、或快取範圍是否該收窄
• EvictedSize 持續高 — working set 超過 cache 容量、要加大 node class
• DynamoDB read capacity 沒因 DAX 下降 — read pattern 不適配、DAX 沒發揮作用

Scope warning：「70% hit rate 閾值」屬通用工程估算、非 case 揭露；實際閾值依 cost 結構與 latency 目標調整。

接回 9.6 容量規劃模型、4.20 Observability Evidence Package。

邊界與整合

DAX vs application-side cache vs ElastiCache

DAX 不是唯一的 DynamoDB 讀加速方案。三者責任不同：

• DAX：DynamoDB 專屬、API 相容、write-through、零 application cache 邏輯；綁 DynamoDB
• application-side cache（如 in-process LRU）：最低延遲、但每個 instance 各自一份、一致性難管
• ElastiCache（Redis / Valkey）：通用 cache、可跨資料源、但要自己寫 cache-aside 邏輯與 invalidation

當快取需求超出單一 DynamoDB table（跨資料源聚合 / 需要 Redis 資料結構如 sorted set leaderboard）、回 02 快取模組 評估 ElastiCache；DAX 最適配的情境是「純 DynamoDB 讀加速、且不想自行維護 cache 邏輯」。

Sibling 與 cross-link

• gsi-lsi-design — DAX 觸發條件 SSoT（讀峰值補位 / Lemino case fact / Capcom derive）在該篇、本篇承接機制層
• on-demand-vs-provisioned — DAX 削減 base 讀取後、provisioned RCU 規劃要重算
• consistency-model-optimization — strongly consistent read 繞過 DAX、對應 read 一致性軸
• partition-key-antipatterns — DAX 不解 hot partition、寫熱點仍打到 DynamoDB
• 替代路由：跨資料源快取 / Redis 資料結構需求 → 02 快取模組 ElastiCache
• 跟 Lemino 9.C29 互引：DAX 讀峰值補位的 case fact