選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

DynamoDB 中的資料建模基礎

焦點模式
DynamoDB 中的資料建模基礎 - Amazon DynamoDB

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

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

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

此圖顯示資料間的概念關係、位於其下方的區塊,以及區塊下方的基礎。強調基礎。

單一資料表設計基礎

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

本圖顯示資料表,以及如何使用排序索引鍵,透過相同 userID 項目集合中的實體類型來區分每個項目。

優點

  • 資料位置性,可在單一資料庫呼叫中支援多個實體類型的查詢

  • 降低讀取的整體財務和延遲成本:

    • 兩個項目總計小於 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角色或政策

使用情況

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

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。