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