DynoTable
免費工具

DynamoDB 單一資料表設計工具

輸入你的實體，以及你需要如何讀取它們 — 規劃工具會建議以實體為前綴的 PK/SK 鍵範本、預覽項目集合，並只在基礎資料表無法服務某個模式時才加入 GSI。

實體
存取模式
建議的鍵結構
實體PKSK
UserUSER#<userId>USER#<userId>
Order
在 User 項目集合中
USER#<userId>ORDER#<orderDate>#<orderId>
GetItem · 基礎資料表以 ID 取得 User
PK = USER#<userId> AND SK = USER#<userId>
Query · 基礎資料表列出 User 下的 Order
PK = USER#<userId> AND begins_with(SK, 'ORDER#') ScanIndexForward: false
  • 排序索引鍵以字串方式比較 — 請以可排序的格式儲存排序屬性（ISO-8601 日期、補零的數字）。
Query · GSI1以 email 尋找 User
GSI1PK = USER#EMAIL#<email>
  • GSI 不會強制唯一性 — 請在寫入時以基礎項目上的條件表達式防範重複。
全域次要索引
GSI1為 User 項目建立索引
GSI1PK = USER#EMAIL#<email> GSI1SK = USER#EMAIL#<email>
  • GSI 不會強制唯一性 — 請在寫入時以基礎項目上的條件表達式防範重複。
範例項目
實體PKSKGSI1屬性
UserUSER#user-1USER#user-1USER#EMAIL#user-1@example.com USER#EMAIL#user-1@example.comuserId: user-1, email: user-1@example.com
OrderUSER#user-1ORDER#2025-06-01#order-1—orderId: order-1, orderDate: 2025-06-01, userId: user-1
OrderUSER#user-1ORDER#2025-06-02#order-2—orderId: order-2, orderDate: 2025-06-02, userId: user-1
資料表定義（CreateTable JSON）
{
  "TableName": "AppTable",
  "BillingMode": "PAY_PER_REQUEST",
  "AttributeDefinitions": [
    {
      "AttributeName": "PK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "SK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "GSI1PK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "GSI1SK",
      "AttributeType": "S"
    }
  ],
  "KeySchema": [
    {
      "AttributeName": "PK",
      "KeyType": "HASH"
    },
    {
      "AttributeName": "SK",
      "KeyType": "RANGE"
    }
  ],
  "GlobalSecondaryIndexes": [
    {
      "IndexName": "GSI1",
      "KeySchema": [
        {
          "AttributeName": "GSI1PK",
          "KeyType": "HASH"
        },
        {
          "AttributeName": "GSI1SK",
          "KeyType": "RANGE"
        }
      ],
      "Projection": {
        "ProjectionType": "ALL"
      }
    }
  ]
}

供 aws dynamodb create-table --cli-input-json 使用的純 JSON — 通用的字串型別 PK/SK 屬性、GSI 投影 ALL、隨需計費。

成本提示
每個項目的讀取單位（最終一致）
0.5 RCU
每個項目的寫入單位
1 WCU
每月隨需估算（us-east-1）— 僅基礎資料表
US$4.93
包含 GSI 寫入複寫（×1）
US$8.21

每個 GSI 都會儲存每個項目的一份自有投影副本，因此一次資料表寫入也會消耗每個 GSI 的寫入容量。這項估算假設完整投影，並採用與我們的定價與項目大小計算機相同的 4 KB 讀取 / 1 KB 寫入捨入方式。

從存取模式到鍵結構

單一資料表設計從讀取出發，而非從實體出發：你不是把資料表正規化再於查詢時 join，而是列出應用程式需要取得資料的每一種方式 — 以 ID 取得使用者、由新到舊列出使用者的訂單、以電子郵件尋找帳戶 — 然後塑造鍵，使每一種方式都是單一的 GetItem 或 Query。基礎資料表無法回答的每個模式都會讓你付出一個索引的代價，而這項取捨應該在你建立資料表之前就清楚可見。

這個規劃工具讓取捨變得明確。它以決定性的方式套用標準的單一資料表規則 — 以實體為前綴的複合鍵、用於一對多模式的項目集合、其餘則採用反轉或屬性範圍的 GSI — 而在某個模式無法乾淨地被服務時，它會如實說明，而不會假裝。範例項目資料表會顯示所產生的資料列實際上如何在分割區內彼此相鄰。

輸出是一份純粹的 CreateTable JSON 文件，具有通用的字串型別鍵屬性 — 日後沒有任何工具專屬的東西需要拆解 — 再加上成本提示，重複使用我們的定價與項目大小計算機所採用的、確切的 4 KB 讀取 / 1 KB 寫入捨入方式。

初次接觸這些概念，或不確定這套方法是否適合你的工作負載？ 我們的單一資料表設計指南 從基本原理說明這個概念，而 何時不該使用它 則誠實地涵蓋了反面案例。鍵結構確定之後， 在 DynamoDB 查詢建構器中組合實際的請求 或用以下工具估算完整的每月帳單： DynamoDB 定價計算機.

常見問題

什麼是 DynamoDB 中的單一資料表設計？

一種建模方法，讓應用程式的所有實體型別共用同一張資料表，並使用通用的分割區索引鍵與排序索引鍵屬性（PK/SK）。相關項目共用同一個分割區索引鍵，因此單一 Query 就能一併取得它們 — 這種設計由你的存取模式驅動，而非由正規化的實體結構決定。

這個規劃工具如何決定鍵的設計？

依循固定、公開的規則 — 具決定性，而非生成式。每個實體一開始都是自身項目集合的根，並使用以實體為前綴的鍵；第一個列出子項的模式會把子項移入其父項的分割區，並置於一個複合排序索引鍵上；以其他屬性查找、第二個父項，以及列出全部的模式則成為 GSI 建議；而規則無法乾淨地服務的模式會被標記為不支援，而不是給出一個憑空捏造的設計。

存取模式何時需要全域次要索引？

當基礎資料表的鍵配置無法回答它時：以子項自身的 ID 取得已重新歸屬的子項、在第二個父項下列出相同的項目、以非鍵屬性（例如電子郵件）尋找項目，或列出某一型別的每一個項目。這些都是對相同資料重新設鍵，而這只有索引能做到 — 規劃工具會為每一種鍵形狀建議一個索引，並在共用相同形狀的模式之間重複使用它。

GSI 如何影響 DynamoDB 成本？

每個 GSI 都會維護它所涵蓋項目的一份自有投影副本，因此每一次資料表寫入也會消耗每個投影該項目的 GSI 的寫入容量，而儲存則按副本計費。成本卡會顯示基礎資料表的估算值，以及一份納入 GSI 寫入複寫的估算值，採用與我們的定價與項目大小計算機相同的 4 KB 讀取 / 1 KB 寫入捨入方式。

這個規劃工具會把我的資料模型上傳到任何地方嗎？

不會。這個頁面是靜態的，設計完全在你的瀏覽器中運算 — 實體名稱、ID 屬性與存取模式絕不會傳到伺服器。設計唯一離開頁面的途徑是「複製連結」URL，它會把設計打包進連結裡，因此分享始終是一個刻意的動作。

不必透過主控台就能操作 DynamoDB

DynoTable 是一款快速的 DynamoDB 桌面用戶端 — 瀏覽表格、執行 SQL 風格的查詢，並在本機編輯項目。

下載查看定價