本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
DynamoDB 中的資料建模基礎
本節藉由檢驗兩種類型的資料表設計來介紹基礎層：單一資料表和多資料表。
單一資料表設計基礎
在我們 DynamoDB 結構描述的基礎上，其中一個選擇是單一資料表設計。單一資料表設計是一種模式，可讓您將多種資料類型 (實體) 儲存在單一 DynamoDB 資料表中。它旨在透過消除維護多個資料表和它們之間複雜關係的需要，來最佳化資料存取模式，提高效能並降低成本。這是有可能的，因為 DynamoDB 會將具有相同分割區索引鍵 (稱為項目集合) 的項目儲存在彼此相同的分割區上。在此設計中，不同類型的資料會以項目的形式儲存在同一個資料表中，並且每個項目由一個唯一的排序索引鍵來識別。
優點
-
資料位置性，可在單一資料庫呼叫中支援多個實體類型的查詢
-
降低讀取的整體財務和延遲成本：
-
兩個項目總計小於 4KB 的單一查詢RCU最終一致為 0.5
-
兩個項目的兩個查詢總計小於 4KB，RCU最終一致 1 個 (RCU每個 0.5 個）
-
傳回兩個個別資料庫呼叫的時間平均會高於單一呼叫
-
-
減少要管理的資料表數量：
-
不需要跨多個IAM角色或政策維護許可
-
資料表的容量管理會在所有實體中進行平均，通常會產生更可預測的取用模式
-
監控需要更少的警示
-
客戶管理的加密金鑰只需在一個資料表上進行輪換
-
-
資料表的平滑流量：
-
透過將多種使用模式彙總到同一個資料表，整體使用量往往更平滑 (股票指數的績效往往比任何個股表現更平滑)，這對於透過佈建模式資料表達到更高的使用率有更好的效果
-
缺點
-
與關聯式資料庫相比，由於矛盾的設計，學習曲線可能會很陡峭
-
所有實體類型的資料需求必須一致
-
備份是全部或完全不重要，因此如果某些資料不是關鍵任務，請考慮將其保存在單獨的資料表中
-
資料表加密會在所有項目之間共用。對於具有個別租戶加密需求的多租戶應用程式，將需要用戶端加密
-
混合了歷史資料和操作資料的資料表，不會因啟用不常存取的儲存類別而獲得更多優勢。如需詳細資訊，請參閱 DynamoDB 資料表類別
-
-
所有變更的資料都會傳播到 DynamoDB Streams，即使只需要處理一部分的實體。
-
由於有 Lambda 事件篩選條件，這在使用 Lambda 時不會影響您的帳單，但在使用 Kinesis Consumer Library 時會增加成本
-
-
使用 GraphQL 時，單一資料表設計將更加難以實現
-
使用 Java DynamoDBMapper或增強型用戶端等高階SDK用戶端時，處理結果可能更困難，因為相同回應中的項目可能與不同類別相關聯
使用情況
除非您的使用案例會受到上述其中一個缺點的嚴重影響，否則單一資料表設計是 DynamoDB 的建議設計模式。對於大多數客戶而言，長期利益會超過以這種方式設計資料表的短期挑戰。
多資料表設計基礎
在我們 DynamoDB 結構描述的基礎上，第二個選擇是多資料表設計 。多資料表設計是一種模式，更像是傳統資料庫設計，您可以在每個 DynamoDB 資料表中儲存單一類型 (實體) 資料。每個資料表中的資料仍會依據分割索引鍵進行組織，因此單一實體類型內的效能會針對可擴展性和效能進行最佳化，但是跨多資料表的查詢必須獨立完成。
優點
-
對於那些不習慣使用單一資料表設計的人來說，該設計更簡單
-
由於每個解析程式會對應到單一實體 (資料表)，因此 GraphQL 解析程式的實現更容易
-
允許跨不同實體類型的唯一資料需求：
-
可為關鍵任務的單一資料表進行備份
-
可以每個資料表進行管理的資料表加密。對於具有個別租戶加密需求的多租戶應用程式，不同的租戶資料表可讓每個客戶擁有自己的加密金鑰
-
不常存取的儲存類別只能在具有歷史資料的資料表上啟用，以實現完整的成本節省優勢。如需詳細資訊，請參閱 DynamoDB 資料表類別
-
-
每個資料表都有自己的變更資料串流，允許針對每種類型的項目 (而非單一整合式處理器) 設計專用的 Lambda 函數
缺點
-
對於需要跨多資料表資料的存取模式，則需要從 DynamoDB 進行多次讀取，而且可能需要在用戶端程式碼上處理/加入資料。
-
操作和監控多個資料表需要更多 CloudWatch 警示，且每個資料表都必須獨立擴展
-
每個資料表的許可都需要單獨管理。未來新增資料表將需要變更任何必要的IAM角色或政策
使用情況
如果您的應用程式的存取模式不需要一併查詢多個實體或資料表，那麼多資料表設計會是良好且足夠的方法。
