在 DynamoDB 表中管理多对多关系的最佳实践

相邻列表是一种在 Amazon DynamoDB 中建模多对多关系的设计模式。一般地说，它们提供在 DynamoDB 中表示图表数据（节点和边缘）的方式。

相邻列表设计模式

如果应用程序的不同实体之间具有多对多关系，可以将关系建模为相邻列表。在此模式下，所有顶级实体（与图表模型中的节点同义）都使用分区键表示。将排序键值设置为目标实体 ID（目标节点），可以将与其他实体（图表中的边缘）的任何关系表示为分区内的项目。

此模式的优点包括数据重复率最低，简化查询模式查找与目标实体（边缘作为目标节点）相关的所有实体（节点）。

包含多个账单的开票系统是此模式的一个真实示例。一个账单可以属于多个发票。此示例中的分区键为 InvoiceID 或 BillID。BillID 分区的所有属性特定于账单。InvoiceID 分区的一个项目存储发票特定属性，一个项目保存汇总到发票的每个 BillID。

架构如下所示。

从上述架构可以看到，可以使用表主键查询发票的所有账单。要查找包含一部分账单的所有发票，请对表的排序键创建全局二级索引。

全局二级索引的投影如下所示。

具体化图表模式

很多应用程序需要了解跨对等排名、实体间关系和相邻实体状态。如果您的应用程序使用这些类型的图表样式工作流，请考虑以下架构设计模式。

以真实情况为例，请考虑一个社交网络应用程序。在此应用程序中，每个人拥有技能、生活在某个地方并有相关的日期（例如出生日期），还会与其他人建立关系。每个人都是图表中的一个节点。人与人之间的联系，例如友谊，是边缘。人员与其属性（技能、地点、日期）之间的关联也是边缘。

使用实体化图表模式，您可以将节点和边缘存储在单个 DynamoDB 表中，并高效地遍历关系。下图展示如何对此社交网络图进行建模。第一张图显示主表结构。随后的图表显示全局二级索引投影。

该表使用以下键结构：

边缘项目包含 Target 和 Type 属性。这些属性构成复合键“TypeTarget”，标识主表中的项目和第二个全局二级索引中的项目。例如，“Person-1 is friends with Person-2”会生成 Type=Friend、Target=Person-2 和 TypeTarget=Friend-Person-2。

第一个全局二级索引基于 Data 属性生成。此属性使用全局二级索引重载，来对同一索引中的多个属性类型编制索引：

您可以使用这个单一的全局二级索引来查询在特定日期出生的所有人、位于某个地点的所有人或具有特定技能的所有人。

第二个全局二级索引使用 TypeTarget 作为分区键，用于反向查找。例如，您可以通过查询 TypeTarget=Friend-Person-2 来查找所有将 Person-2 列为好友的人。

将项目插入表时，可以使用智能分片策略，在全局二级索引上所需数量的逻辑分区之间，分配包含大型聚合（生日、技能）的项目集，避免热门读取/写入问题。

通过这种设计模式组合，您可以为高效的实时图表工作流打造出可靠的数据存储区。您可以使用它为推荐引擎、社交网络应用程序、节点排名、子树聚合和其他常见图表使用案例，构建高性能相邻实体状态和边缘聚合查询。

如果使用案例对实时数据一致性不敏感，可以使用计划的 Amazon EMR 流程，用工作流相关图表摘要聚合填充边缘。如果将边缘添加到图表后，应用程序不需要立即知道，则可以使用计划流程聚合结果。

要保持一定程度的一致性，此设计可以加入 Amazon DynamoDB Streams 和 AWS Lambda 以处理边缘更新。还可以定期使用 Amazon EMR 任务验证结果。下图说明此方法。常用于社交网络应用程序，实时查询成本高，对立刻知道各个用户更新的需求低。

IT 服务管理 (ITSM) 和安全应用程序通常需要实时响应包含复杂边缘聚合的实体状态更改。此类应用程序需要系统可以支持二级和三级关系的实时多个节点聚合或复杂边缘遍历。如果使用案例需要这类实时图表查询工作流，建议考虑使用 Amazon Neptune 管理工作流。