阅读Amazon DynamoDB文档我仍然无法理解将其用于最常见任务的最佳方式 - 拥有多种类型的文档（例如，＆＃39; user＆＃39;，＆＃ 39;事件＆＃39;，＆＃39;新闻＆＃39;）都有独特的ID。 据我所知，由于DynamoDB仅对文档主键表示限制，因此我们可以在其中存储任何具有一个主键的数据。因此，最自然的解决方案如下：
- partion key 'type' is document type - 'user', 'event' etc
- sort key is uuid
但这与官方文件相矛盾，根据它，更好的是：
- partition key 'id' is just uuid
- sort key is type - 'user', 'event'
但由于关键名称，这与常识相矛盾。 最后，我们可以为用户，事件和新闻创建3个不同的DynamoDB实例，所有这些实例都具有uuid作为partiton键而没有排序键。 哪种解决方案是DynamoDB使用的最佳或常见做法？
答案 0 :(得分：2)
这是一个主观问题，但我会采取一些措施并给你一些理由。
1）您可以使用“uuid：type”作为主要ID。您不应该使用type作为分区ID的原因是因为您的所有数据都将在每个类型的单个分区上结束。分区是Dynamo和S3如何提供并行化。如果你这样做，你将极大地限制摄取和查询速度。
2）出于定价原因，我个人赞成每种类型的一张桌子。您支付每表读/写容量。使用单个表，您可以更少地跟踪和管理。调整一个表的容量比三个容易。
3）在这种情况下我不会使用排序键。
答案 1 :(得分：1)
确定性陈述需要具体细节，但对数据的含义做出一些假设：
- partion key 'type' is document type - 'user', 'event' etc
- sort key is uuid
以上观点几乎肯定是一个糟糕的设计。最终会出现一些大型分区，从而导致性能问题。另外我建议你最终会对查询进行扫描。
- partition key 'id' is just uuid
- sort key is type - 'user', 'event'
以上想法可能是一个糟糕的设计。排序键不会给您带来任何实际好处。假设您需要单独访问用户或事件等，您最终将执行扫描。
用户，活动等的极有可能的单独表格将是最好的。这些表中的键实际上只取决于您的数据。 UUID可能是一个不错的选择，但它取决于您想要如何查询数据。基于日期的属性，特别是对于事件，通常会产生良好的排序键。
我建议您结帐this answer这是对大致相同问题的更长答案。