本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
本節藉由檢驗兩種類型的資料表設計來介紹基礎層:單一資料表和多資料表。

單一資料表設計基礎
在我們 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角色或政策
使用情況
如果您的應用程式的存取模式不需要一併查詢多個實體或資料表,那麼多資料表設計會是良好且足夠的方法。