在上一篇文章,我們建立了一個簡單的 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 的實際運用,下篇將進一步把完整業務邏輯整合進表格,形成可操作的多人協作平台資料模型