如何处理 DynamoDB 单表设计？答案

【问题标题】：How do I approach a DynamoDB single table design?如何处理 DynamoDB 单表设计？
【发布时间】：2022-02-06 22:02:54
【问题描述】：

我正在了解有关 DynamoDB 的更多信息，并且我正在构建一个完整的无服务器项目，并将其用作我的主数据库。该项目是一个简单的投票应用程序，用户可以在其中创建和投票。

SQL 数据库的数据模型非常简单，实际上这就是它的样子

但是对于 DynamoDB，我需要考虑访问模式，这让我有点困惑。

在观看了一些与数据建模无关的 DynamoDB 课程后，我能够按照单表设计提出这个聚合视图。

这是在 NoSQL Workbench 应用程序中完成的

同一张表中有相同的 3 个实体，但我有一个问题

这些是我的应用所需的访问模式，至少是我现在能想到的那些

[Put, Delete, Get] User by userId
[Get] All Users by pollId (who voted in what)
[Put, Delete, Get] Poll by pollId
[Put, Delete, Get] All Polls by userId
[Put, Delete, Get] All Polls by visibility
[Create, Get] Poll Votes by pollId

我是否只需要全局二级索引来满足这些访问模式？

我设计数据的方式有什么缺陷吗？

您还有其他建议吗？

【问题讨论】：

标签： database nosql amazon-dynamodb

【解决方案1】：

您是正确的，使用 GSI 将有助于在此处设计良好的访问模式，但在您的 NoSQL Workbench 屏幕截图中，您没有显示 GSI。相反，您正在为每个投票操作显示批量写入（或事务写入）操作。 1. pk: 用户id, sk: 投票id, 2. pk: 投票id, sk: 用户id。

如果您想强制执行一个规则，即任何用户都不能在同一个投票中投票两次，那么效率会降低。要使用当前的密钥结构强制执行此操作，您需要使用更昂贵的事务写入 API 调用。

相反，您可以尝试使用单次写入进行投票，将条件检查所需的属性保留在 pk 或 sk 中，并使用 GSI 提供替代访问模式。

替代模式：型号：投票 pk：民意调查， sk：用户ID gsi1pk：用户 ID， gsi1sk: pollId

型号：用户 pk：用户ID， sk: 用户ID

型号：投票 pk：民意调查 sk: pollId

这有一个权衡，即“通过 UserId 获取所有波兰人（投票）”或“通过 PollId 获取所有用户”将需要 2 次读取操作。选择 Vote pk 和 sk 以支持读取操作，这将获得更多流量。

此设计还建议您可能希望将一些数据从 Poll 模型非规范化到 Vote 模型。

如果您的应用程序被大量阅读，您的原始模型可能是正确的选择。但是考虑到一个查询可以读取 0.5 个 RRU 的额外数据项，1 个按需 RRU 成本为 0.25 美元/百万，而事务写入操作每个项目成本 2 WRU，1 个按需 WRU 成本为 1.25 美元/百万。这意味着除非您的查询“获取用户的所有投票”获得至少 20 倍于“创建投票”的流量，否则最好使用 GSI（GSI 需要额外花费 1 个 WRU，但 3 个事务写入项需要 6 个 WRU） .

即使使用先读后写来强制唯一性，每次投票仍会导致额外的 1 WRU + 1 RRU 消耗。

【讨论】：