这是一个糟糕的 DynamoDB 数据库架构吗？

Question

在观看了一些有关 DynamoDB 及其最佳实践的视频后，我决定试一试；但是，我不禁觉得我正在做的事情可能是一种反模式。据我了解，最佳做法是利用尽可能少的表，同时利用 GS​​I 进行一些“繁重”的工作。不幸的是，我正在处理一个实际上并没有严格定义访问模式的用例，因为我们仍处于早期开发阶段。

我们可能会看到一些早期访问模式：

• 检索特定游戏的获胜次数：剪刀石头布、拳击等。[1 快速查找]
• 检索用户拥有的硬币数量。 [1 次快速查找]
• 检索某人购买的所有物品（不关心日期）。 [不确定？]
• 可能检索与用户关联的所有属性（rps 获胜、盒子获胜、硬币等）。 [我真的不知道。]

此外，我们可能需要完成 2 个操作。例如，如果用户赢得特定游戏，他们可能会收到“硬币”。实际上，我们需要将硬币添加到用户“硬币”属性并更新他们在游戏中的获胜次数。

你认为我应该重新审视这个策略吗？此外，我们可能会开始创建与各种游戏和每个人的游戏相关的“日志”。

Answer 1

在不完全了解应用程序访问模式的情况下设计 DynamoDB 数据模型是反模式。

花时间定义您的实体（用户、游戏、订单等）、它们之间的关系以及您的应用程序密钥访问模式。当您刚刚开始时，这可能是一项艰巨的工作，但在使用 DynamoDB 时执行此操作绝对至关重要。我们（或您或任何人）还能如何评估您是否正确使用 DDB？

当我第一次使用 DDB 时，我以与您描述的类似的方式处理该过程。我习惯于使用 SQL 数据库，我可以在其中定义一些表并依靠 SQL 的魔力来支持我的访问模式，因为我对应用程序访问模式的理解不断发展。我很快意识到，如果我想使用 DynamoDB，这是行不通的！

相反，我从应用程序的前端开始。我勾勒出我的应用程序中的不同页面，并确定了我的应用程序中最重要的概念。诚然，我可能没有涵盖应用程序中的所有访问模式，但该练习肯定确定了拥有可用应用程序所需的最小访问模式。

如果您需要快速制作应用程序原型以更好地了解您的访问模式，请考虑使用您和您的团队已有的技能。如果您已经了解使用 SQL 数据库进行数据建模，那么现在就开始吧。一旦您更好地了解您的访问模式并确定您的应用程序可以从使用 NoSQL 数据库中受益，您就可以随时重新访问 DynamoDB。