View a markdown version of this page

管理 DynamoDB 資料表中多對多關係的最佳實務 - Amazon DynamoDB
相鄰清單具體化圖形

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

管理 DynamoDB 資料表中多對多關係的最佳實務

相鄰清單是一設計模式，在 Amazon DynamoDB 中建立多對多關係的模型時非常有用。整體來說，它們提供在 DynamoDB 中呈現圖形資料 (節點和邊緣) 的方式。

相鄰清單設計模式

當應用程式的不同實體彼此有多對多關係時，關係可以建立為相鄰清單的模型。在此模式中，所有頂層實體 (相當於圖形模型的節點) 會使用分割區索引鍵來呈現。任何具其他實體的關係 (圖形中的邊緣) 會透過將排序索引鍵值設為目標實體 ID (目標節點) 來以分割區中項目的形式呈現。

此模式的優點包含可將資料複製降到最低並簡化查詢模式，以尋找與目標實體相關 (有目標節點的邊緣) 的所有實體 (節點)。

此模式的實用實際範例為可開立多帳單發票的發票系統。一個帳單可屬於多個發票。此範例中的分割區索引鍵是 InvoiceID 或 BillID。BillID​ 分割區擁有專屬於帳單的所有屬性。InvoiceID​ 分割區有儲存特定發票屬性的項目，且擁有累計至發票的每個 BillID​ 項目。

結構描述看起來類似如下。

帳單相鄰清單範例的資料表結構描述。

使用上述結構描述，您會發現可使用資料表上的主索引鍵來查詢發票的所有帳單。若要查詢包含部分帳單的所有發票，針對資料表的排序索引鍵建立全域次要索引。

全域次要索引的投影看起來類似如下。

帳單相鄰清單範例的 GSI 投影。

具體化圖形模式

許多應用程式需要了解對等、實體之間的關係和鄰實體狀態之間的排名。如果您的應用程式使用這些類型的圖形樣式工作流程，請考慮下列結構描述設計模式。

作為實際範例，請考慮社交網路應用程式。在此應用程式中，人們與其他人建立關係、擁有技能、居住於地方，以及有關聯的日期 （例如出生日期）。每個人都是圖形中的節點。人們之間的關聯，例如友誼，是邊緣。人員與其屬性 （技能、地點、日期） 之間的關聯也是邊緣。

透過具體化圖形模式，您可以將節點和邊緣存放在單一 DynamoDB 資料表中，並有效率地周遊關係。下圖顯示如何建立此社交網路圖表的模型。第一個圖表顯示主要資料表結構。後續圖表顯示全域次要索引投影。

DynamoDB 中具體化圖形模式的主要資料表結構描述，顯示人員作為分割區索引鍵，其邊緣作為每個分割區中的項目。
DynamoDB 中的第一個全域次要索引投影，建立在依日期、名稱、位置和技能查詢的超載資料屬性上。
DynamoDB 中的第二個全域次要索引投影，建置在反向查詢的 TypeTarget 複合索引鍵上。

資料表使用下列金鑰結構：

  • 分割區索引鍵 – 實體 ID （例如，Person-1、Person-2)。每個分割區包含一個節點項目和多個邊緣項目。

  • 排序索引鍵 – 對於節點項目，則為實體自己的 ID。對於邊緣項目，則為邊緣類型和目標的複合 （例如， Friend-Person-2或 Skill-DynamoDB)。

邊緣項目包含 Target 和 Type 屬性。這些組成複合索引鍵 "TypeTarget"，用於識別主資料表和第二個全域次要索引中的項目。例如，「Person-1 是有 Person-2 的朋友」會產生 Type=Friend、 Target=Person-2和 TypeTarget=Friend-Person-2。

第一個全域次要索引會根據 Data 屬性建置。此屬性使用全域次要索引超載來為相同索引中的數個屬性類型編製索引：

  • Dates – 出生日期、加入日期 （例如 1971-12-21)

  • Names – 顯示名稱 （例如 Ana Carolina Silva)

  • Places – 位置 （例如 Seattle)

  • Skills – 能力 （例如 DynamoDB)

您可以使用此單一全域次要索引，查詢特定日期所生的所有人、某個位置的所有人員，或具有特定技能的所有人員。

第二個全域次要索引使用 TypeTarget做為反向查詢的分割區索引鍵。例如，您可以透過查詢 來尋找所有Person-2列為朋友的人TypeTarget=Friend-Person-2。

隨著您將項目插入資料表，您可以使用智慧碎片策略來使用大型彙總 (生日、技能)，在避免經常性讀取/寫入問題時所需的許多邏輯分割區中，對全域次要索引散佈項目。

透過這種設計模式的組合，您可以取得可靠的資料存放區，以實現高效率的即時圖形工作流程。您可以使用它來建置建議引擎、社交網路應用程式、節點排名、子樹彙總和其他常見圖形使用案例的高效能鄰近實體狀態和邊緣彙總查詢。

如果您的使用案例對即時資料一致性並不敏感，您可以使用已排定的 Amazon EMR 程序，將適用於流程的相關圖形摘要彙總填入邊緣。如果您的應用程式不需要立即知道邊緣新增至圖形的時間，您可以使用排定的程序來彙總結果。

若要維持一定程度的一致性，設計可以包含 Amazon DynamoDB Streams 與 AWS Lambda 來處理邊緣更新。其可以使用 Amazon EMR 任務來驗證定期間隔的結果。下圖說明此方法。在社交應用程式會常常用到此方法，其中即時查詢的成本相當高，且立即知道個別使用者更新的需求很低。

說明圖形工作流程的圖表。

IT 服務管理 (ITSM) 和安全性應用程式通常需要對由複雜邊際彙總構成的實體狀態變更回應做出即時回應。此類應用程式需要可以支援第二和第三層級關係之即時多節點彙總或複雜邊際尋訪的系統。若您的使用案例需要這些類型的即時圖形查詢工作流程，我們建議您使用 Amazon Neptune 來管理這些工作流程。

注意

如果您需要查詢高度連線的資料集，或以毫秒延遲周遊多個節點 （多躍點查詢），請考慮使用 Amazon Neptune。Amazon Neptune 是專門建置的高效能圖形資料庫引擎。它經過最佳化，可儲存數十億個關係，並以毫秒延遲查詢圖形。