amazon-web-services - DynamoDB 一对多和多对多结构

Question

我对 DynamoDB 非常陌生，并试图了解关系。

我有一个包含用户、列表和项目的待办事项应用程序。

我创建了 3 个 dynamoDB 表，一张用于用户，一张用于列表，一张用于项目。

为简单起见，以用户/列表为例。用户的主键是 userId。列表主键是 listId。用户可以拥有多个列表。列表可以在用户之间共享，因此列表可以有很多用户。

那么列表应该作为一个 listId 数组保存在用户项中吗？然后当我得到一个用户时，我遍历 listId 的数组并获取所有列表？

用户可以有很多列表，而这些列表又可以有很多项目，所以我不想将整个列表保存在用户项目中。此外，该列表可以由许多用户共享。

我试图搜索关系，但它们似乎都是从假设读者对 NOSQL 数据库有广泛的了解而我没有的假设开始的。

Answer 1

在我看来，一对多关系是 DynamoDB 的优势之一。在您的示例中，列表与其项目之间存在一对多关系。为了在 Dynamo 中建模，假设您有一个如下所示的 Item 架构

{
  itemId: String,
  listId: String,
  name: String
}

您可以创建一个哈希键为 itemId 的 Item 表。这将允许您对单个项目执行所有标准 CRUD 操作。

如果我们还创建一个全局二级索引，其哈希键为 listId ，排序键为 itemId ，这将允许我们对给定列表中的所有项目进行 Query 。

在这种情况下，全局二级索引为我们提供了列表与其项目之间的一对多关系。您也可以将其视为按 listId 对 Item 进行分组。

多对多关系是艰难的。通常，它们要求您在进行多次查询和复制数据之间做出决定。在任何一种情况下，一个好的开始方法可能是创建一个 UserList 表，其中包含一个简单的架构，如下所示

{
  userId: String,
  listId: String
}

使用 userId 作为您的哈希键和 listId 作为您的排序键。您可以将此表视为按用户 ID 分组的列表 ID。然后，您可以使用 listId 作为哈希键和 userId 作为排序键来创建全局二级索引。这将为您提供按列表 ID 分组的用户 ID。该表与其 GSI 相结合，可为您提供多对多关系。

当然，如果您将这种方法用于多对多关系，您将需要向 User 和/或 List 表发出请求以获取这些对象的实际数据。为了优化这一点，您需要将用户和/或列表数据复制到用户列表表中。

在 Dynamo 中还有其他处理多对多关系的方法，但这是一个很好的起点。