在上一篇文章，我們建立了一個簡單的 DynamoDB Table。今天要深入探討「單表設計 (Single Table Design)」，這是 DynamoDB 最常被討論也最容易誤解的主題。與其一開始就講抽象的 Query-centric vs Data-centric，我們先從大家熟悉的 SQL 關聯模型 開始。
在 SQL 中，常見的例子：
在 SQL 裡，要拿到「某個使用者的所有任務」：
JOIN Users → UserTasks → Tasks
DynamoDB 拋棄 Join 是因為靠Foreign Key 將不同表格關聯起來會產生額外的計算成本，不便於水平擴展 (Scale out)
來自Creating a single-table design with Amazon DynamoDB
| PK | SK | Data |
|---|---|---|
| USER#123 | PROFILE | {name: Tom} |
| USER#123 | PROJECT#A | {title: X} |
| USER#123 | PROJECT#B | {title: Y} |
| PROJECT#A | TASK#1 | {desc: ...} |
| PROJECT#A | TASK#2 | {desc: ...} |
PK=USER#123
PK=PROJECT#A
這樣就省去了 JOIN。
當業務需求變複雜，光靠 PK/SK 還不夠，我們會用到 索引：
| 工具 | 特點 | 適合場景 |
|---|---|---|
| PK (Partition Key) | 水平切分資料，保證分散性 | 定位單一實體 |
| SK (Sort Key) | 在 Partition 裡排序與篩選 | 一對多關係 |
| LSI | 與主表共享 PK，不同 SK | 單一實體的多種排序 |
| GSI | 全新 PK/SK，跨分區查詢 | 不同維度的查詢 |
接下來我們會設計一個 Table 並展示如何透過 PK、SK、LSI、GSI 實現不同查詢需求：
| PK | SK | Data | 說明 |
|---|---|---|---|
| USER#123 | PROFILE | {name: Tom} | 使用者基本資訊 |
| USER#123 | PROJECT#A | {title: X} | 使用者專案列表 |
| USER#123 | PROJECT#B | {title: Y} | 使用者專案列表 |
| PROJECT#A | TASK#1 | {desc: ...} | 專案任務列表 |
| PROJECT#A | TASK#2 | {desc: ...} | 專案任務列表 |
今天展示了單表設計的概念 + LSI/GSI 的實際運用，下篇將進一步把完整業務邏輯整合進表格，形成可操作的多人協作平台資料模型
iThome鐵人賽
看影片追技術