本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# DynamoDB 中的資料建模基礎
<a name="data-modeling-foundations"></a>

本節藉由檢驗兩種類型的資料表設計來介紹基礎層：單一資料表和多資料表。

![\[此圖顯示資料間的概念關係、位於其下方的區塊，以及區塊下方的基礎。強調基礎。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/DataModeling/SchemaDesignFoundation.png)


## 單一資料表設計基礎
<a name="data-modeling-foundations-single"></a>

在我們 DynamoDB 結構描述的基礎上，其中一個選擇是**單一資料表設計**。單一資料表設計是一種模式，可讓您將多種資料類型 (實體) 儲存在單一 DynamoDB 資料表中。它旨在透過消除維護多個資料表和它們之間複雜關係的需要，來最佳化資料存取模式，提高效能並降低成本。這是有可能的，因為 DynamoDB 會將具有相同分割區索引鍵 (稱為項目集合) 的項目儲存在彼此相同的分割區上。在此設計中，不同類型的資料會以項目的形式儲存在同一個資料表中，並且每個項目由一個唯一的排序索引鍵來識別。

![\[本圖顯示資料表，以及如何使用排序索引鍵，透過相同 UserID 項目集合中的實體類型來區分每個項目。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/DataModeling/SingleTableSchema.png)


**優點**
+ 資料位置性，可在單一資料庫呼叫中支援多個實體類型的查詢
+ 降低讀取的整體財務和延遲成本：
  + 對總計小於 4KB 的兩個項目的單一查詢是 0.5 RCU 最終一致
  + 對總計小於 4KB 的兩個項目的兩個查詢是 1 RCU 最終一致 (每個 0.5 RCU)
  + 傳回兩個單獨資料庫呼叫的平均時間將高於單一呼叫
+ 減少要管理的資料表數量：
  + 不需要跨多個 IAM 角色或政策維護許可 
  + 資料表的容量管理會在所有實體中進行平均，通常會產生更可預測的取用模式
  + 監控需要更少的警示
  + 客戶管理的加密金鑰只需在一個資料表上進行輪換
+ 資料表的平滑流量：
  + 透過將多種使用模式彙總到同一個資料表，整體使用量往往更平滑 (股票指數的績效往往比任何個股表現更平滑)，這對於透過佈建模式資料表達到更高的使用率有更好的效果

**缺點**
+ 與關聯式資料庫相比，由於矛盾的設計，學習曲線可能會很陡峭
+ 所有實體類型的資料需求必須一致
  + 備份是採用全有或全無原則，因此如果資料不是關鍵任務資料，請考慮將其保存在單獨的資料表中
  + 資料表加密會在所有項目之間共用。對於具有個別租戶加密需求的多租戶應用程式，將需要用戶端加密
  + 混合了歷史資料和操作資料的資料表，不會因啟用不常存取的儲存類別而獲得更多優勢。如需詳細資訊，請參閱[DynamoDB 資料表類別](HowItWorks.TableClasses.md) 
+ 即使只需處理一部分實體，所有變更的資料都會傳送至 DynamoDB Streams。
  + 由於有 Lambda 事件篩選條件，這在使用 Lambda 時不會影響您的帳單，但在使用 Kinesis Consumer Library 時會增加成本 
+ 使用 GraphQL 時，單一資料表設計將更加難以實現
+ 如果您使用更高層級的 SDK 客戶端 (如 Java 的 [`DynamoDBMapper`](DynamoDBMapper.md) 或[增強型用戶端](DynamoDBEnhanced.md))，那處理結果會比較困難，因為同一回應中的項目可能與不同的類別有關

**使用情況**

單一資料表設計非常適合經常同時查詢多個實體類型的應用程式，或需要維護不同資料類型之間關係的應用程式。如果您的存取模式受益於資料地區性，且您想要盡可能減少管理多資料表的額外負荷，這種設計就特別有效。

## 多資料表設計基礎
<a name="data-modeling-foundations-multi"></a>

在我們 DynamoDB 結構描述的基礎上，第二個選擇是多資料表設計****。多資料表設計是一種模式，更像是傳統資料庫設計，您可以在每個 DynamoDB 資料表中儲存單一類型 (實體) 資料。每個資料表中的資料仍會依據分割索引鍵進行組織，因此單一實體類型內的效能會針對可擴展性和效能進行最佳化，但是跨多資料表的查詢必須獨立完成。

![\[本圖顯示包含論壇清單的論壇資料表和一些彙整資料。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/DataModeling/MultipleTable1.png)


![\[本圖顯示討論串資料表，其中包含由它們所屬的特定論壇分割區的討論串清單。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/DataModeling/MultipleTable2.png)


**優點**
+ 對於那些不習慣使用單一資料表設計的人來說，該設計更簡單 
+ 由於每個解析程式會對應到單一實體 (資料表)，因此 GraphQL 解析程式的實現更容易
+ 允許跨不同實體類型的唯一資料需求：
  + 可為關鍵任務的單一資料表進行備份 
  + 可以每個資料表進行管理的資料表加密。對於具有個別租戶加密需求的多租戶應用程式，不同的租戶資料表可讓每個客戶擁有自己的加密金鑰
  + 不常存取的儲存類別只能在具有歷史資料的資料表上啟用，以實現完整的成本節省優勢。如需詳細資訊，請參閱[DynamoDB 資料表類別](HowItWorks.TableClasses.md)
+ 每個資料表都有自己的變更資料串流，允許針對每種類型的項目 (而非單一整合式處理器) 設計專用的 Lambda 函式

**缺點**
+ 對於需要跨多資料表資料的存取模式，則需要從 DynamoDB 進行多次讀取，而且可能需要在用戶端程式碼上處理/加入資料。
+ 對多資料表進行操作和監控需要更多 CloudWatch 警示，並且每個資料表必須獨立進行擴展
+ 每個資料表的許可都需要單獨管理。未來新增資料表都將需要變更任何必要的 IAM 角色或政策

**使用情況**

如果您的應用程式的存取模式不需要一併查詢多個實體或資料表，那麼多資料表設計會是良好且足夠的方法。