您在什么情况下在 DynamoDB 上使用简单哈希键？答案

【问题标题】：In what situation do you use Simple Hash Keys on DynamoDB?您在什么情况下在 DynamoDB 上使用简单哈希键？
【发布时间】：2015-02-25 07:22:25
【问题描述】：

Simple Hash Keys 似乎太简单了，不能写一篇文章，而很多人写的是 Composite Hash/Range Keys，因为 Composite Hash/Range Keys 对于许多复杂的情况很有用。但我相信在常见的应用程序中，很多表都应该使用 Simple Hash Keys 来设计。您在什么情况下使用简单哈希键？

例如，当您设计如下层次模型时，您如何为每个表设计主键？（Tenant 以外的所有表都有tenant_id 作为字段。）

租户
用户
团队
项目
任务
团队成员

想法1

只有“团队成员”是由复合哈希/范围键设计的。其他的则由 Simple Hash Key 设计。

想法。 2

Tenant 由 Simple Hash Key 设计。
用户、团队和项目的主键将是复合的（tenant_id、sub_id）。
任务的主键将是复合的 ({tenant_id}_{project_range_key}, sub_id)。
团队成员的主键将是复合的（{tenant_id}_{team_range_key}、{tenant_id}_{user_range_key}）。

其中 sub_id 可以是序列号、created_at 或其他。

更新

发布此问题后，我了解了更多有关 DynamoDB 及其历史的信息，现在我清楚地认识到我的担忧。

在亚马逊发布 GSI 之前，我们必须设计像“Idea 2”这样的表来查询“tenant_id”。但是现在我们可以使用 GSI，所以我们可以使用“简单哈希键和 GSI”的组合来设计表（例如团队、项目或任务）。是对的吗？？

【问题讨论】：

标签： database amazon-web-services amazon-dynamodb key-value-store

【解决方案1】：

您使用单个哈希键表来描述一个项目。例如，一个用户有许多信息，如姓名、年龄等。您可以创建一个用户表，其中 user_id 作为 hashkey，所有其他信息作为属性。

您使用哈希范围模式来描述关系。例如，一个团队可以有多个用户。因此，您可以创建一个 Team-Member-Relationship 表，其中 team-id 作为 hashkey，user-id 作为 range key。

换句话说，绘制一个关系图，其中顶点为（用户、团队、项目），边为它们的关系（一对一、一对多、多对多等）。然后对顶点使用 Hashkey 模式，对边使用 Hash-Range 模式。

谢谢！

二本

【讨论】：

谢谢尔本。在这种情况下，全局二级索引用于查询“项目”表，对吧？
GSI 只是在基表中组织相同数据的另一种方式。您想要数据的另一种表示的原因是使查询更容易。假设您的基表是 user_id 作为 hashkey 和 project_id 作为范围键。这对于获取给定用户所涉及的所有项目很有用。但是如果要获取特定项目的所有成员，则必须扫描基表（非常低效）。您可以做的是创建一个 GSI，其中项目 ID 作为哈希键，用户 ID 作为范围键（基表的反向）。你可以查询这个GSI来获取一个项目的所有成员
我认为在项目表上使用 GSI 也很好。假设您有一个用户表，其中 user_id 作为哈希键，年龄作为属性。现在你想要所有 20
谢谢。我已经很好理解了。所以 GSI 发布后做法发生了变化，对吧？（顺便说一句，我已经更新了上面的问题。）
但是你可以使用的GSI数量有上限（5 / 10？）

【解决方案2】：

我已回复您在 AWS 论坛 here 上的同一帖子。希望对您有所帮助。尽管 Stack Overflow 和 AWS 论坛都受到 DynamoDB 专家的积极监控，请随时与我联系。感谢您对 DynamoDB 的关注！

【讨论】：