amazon-web-services - 如何设计关键模式以使每个应用程序只有一个 DynamoDB 表？

Question

根据 DynamoDB 文档:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

“您应该在 DynamoDB 应用程序中维护尽可能少的表。大多数设计良好的应用程序只需要 一张表 。”

但根据我的经验，你总是 必须做相反的事情由于分区键设计。

让我们考虑下一种情况。我们有几个用户角色，例如“admin”、“manager”、“worker”。管理员通常的工作流程是 CRUD 管理器数据，其中读取操作不是获取一个管理器，而是获取所有管理器列表。经理也是如此——他的 CRUD worker 数据。
对于这两种情况，我们只有两种 key 使用场景:

获取所有项目的列表(项目 key 无关紧要)

使用其完整 key 处理特定项目。

自然地，我们应该有均匀分布的分区键(正如文档强调的那样)，所以我们不能为它选择用户角色，应该使用用户 ID。由于我们已经有一些随机 id 作为分区键，我们根本不需要排序键，因为它根本不起作用 - 我们已经通过仅使用分区键部分来访问一个用户。在这一点上，我们意识到用户 id 就像 CUD 操作的魅力一样，但是对于每个 R 操作，我们需要扫描所有表，然后按用户角色过滤结果，这是无效的。如何改进？很自然 - 让我们为每个用户类型拥有自己的表格!然后，我们将从管理 API 扫描经理列表，并从经理一号扫描 worker 列表。

我使用 DynamoDB 快一年了，仍然无法使用。对我来说，现实情况是，对于现实生活场景，排序键是你永远无法使用的(我唯一真实的情况是同时访问属于不同类型的两个用户的“协议(protocol)”之类的项目，所以主键是 { partion: "managerId", sort: "userId"} 二级全局索引是 { partition: "userId", sort: "managerId"} 所以我可以有效地查询所有特定的经理协议(protocol)列表或所有特定的用户协议(protocol)列表仅提供查询的相应经理或用户 ID。该方法在此处的文档中讨论:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html)。

我觉得我根本不明白这个概念。对于所提供的示例，使用 的关键模式的有效方法是什么？只有一个两种用户类型的 DynamoDB 表？

Answer 1

听起来在这种情况下您需要的是一个全局二级索引( https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html )，其中分区键是用户角色。这样，您可以通过 UserRoleIndex 查询所有具有特定角色的用户。并且，在用户 ID 上的排序键的帮助下，挑选出该角色中的一个特定用户。

或者，如果您从头开始使用新表，您甚至可能不需要索引(除非您在删除用户时不知道用户的角色)。您可以使用“复合主键”( https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey )，其中分区键和排序键与我在上面建议的索引中的相同。

使用您在问题中使用的相同符号，我会推荐 { partition: "userRole", sort: "userId" } .

DynamoDB 有时很难理解，在某些情况下，传统的 SQL 数据库确实更有意义。来自 AWS re:Invent 2018 的这段视频很好地了解了两者之间的区别:https://www.youtube.com/watch?v=HaEPXoXVf2k&feature=youtu.be .

但是，在您的情况下，您似乎有一个非常清晰的访问模式，因此 DDB 会为您工作。