从 RDBMS 迁移，我不确定如何最好地设计以下场景
我有一个包含大约 200,000 个问题的表格，其中问题 ID 作为分区键。
用户查看问题，我不希望再次向用户显示查看的问题。那么哪一个是更好的选择呢？
1 和 2 可能对项目的 400 kb 大小限制有问题。第三个似乎更好的选择虽然我最终会得到 1 亿个项目，因为每个用户查看的每个问题都会有一行。但我认为这对发电机来说不是问题？
另一个问题是如何获得 10 个用户未查看的随机问题。我是否会生成 10 个介于 1 到 200,000（问题数）之间的随机数，然后检查是否不在上面第 3 点提到的表格中？
【问题讨论】：
标签： amazon-web-services database-design amazon-dynamodb
由于您提到的原因，我绝对不会选择选项 1 或 2：您已经将可扩展性限制在 400kb 限制。如果 UUID 为 128 位，则每个问题最多只能有 250 个用户。
选项 3 是使用 DynamoDB 的方式，但您需要考虑的是分区键和范围键是什么。您可以将 user_id 作为分区键，将 question_id 作为范围键。该决定的答案取决于您的数据将如何被访问。 DynamoDB 将总表吞吐量除以每个分区键：您的每个 n 个分区键获得表吞吐量的 1/nth。例如，如果您有一个分区键子集的访问次数多于其他分区键，那么您将无法有效地利用表吞吐量，因为这些分区键实际上用完 不到 1/n 个的吞吐量仍为 1/nth 的吞吐量提供。一般的想法是您希望平等地利用每个分区键。我认为你说得对，我假设每个问题都是随机给出的，并且不比另一个更受欢迎，而有些用户可能比其他用户更活跃。
您问题的另一部分有点难以回答/确定。您可以按照自己的方式进行操作，其中包含针对这些用户已阅读的问题的问题和用户对，或者您可以拥有包含针对这些用户没有阅读的问题的对的表格。这里的权衡是在初始写入成本和后续读取成本之间，答案取决于您与消耗率相比的问题数量。
当您有大量问题与用户通过它们的速度相比时，随机选择一个已经选择的问题的机会很小，因此您需要存储已读问题-用户对.使用此设置，您无需花很多钱来初始化用户（您不必为每个问题编写问题-用户对），并且您不会有很多未读成本（即您选择一个问题-用户对，事实证明他们已经读过了，这仍然消耗读写单元）。
如果与用户使用它们的速度相比，您的问题数量较少，那么您将需要存储未读问题-用户对。您支付一些费用来初始化每个用户（为每个问题编写一个问题-用户对），但是您不会有任何意外的误读。如果您在它们是少量问题时将它们存储为已读对，那么当已读问题的百分比接近 100% 时，您将遇到很多未读（如果您最好设置将它们列为未读对）。
我希望这对您的设计考虑有所帮助。如果您需要澄清，请发表评论！
【讨论】：