存储多种文档类型的最佳 DynamoDB 架构是什么？

Question

阅读 Amazon DynamoDB 文档我仍然无法理解将它用于最常见任务的最佳方式是什么 - 拥有多种类型的文档（例如，“用户”、“事件”、“新闻”）具有唯一 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 作为分区键并且没有排序键。 哪种解决方案是 DynamoDB 使用的最佳或常见做法？

Answer 1

这是一个主观的问题，但我会试一试并给你一些理由。

1) 您可以使用“uuid:type”作为您的主 ID。您不应该使用 type 作为分区 id 的原因是因为您的所有数据最终都将位于每种类型的单个分区上。分区是 Dynamo 和 S3 提供并行化的方式。如果这样做，您将极大地限制摄取和查询速度。

2) 出于定价原因，我个人更喜欢一张桌子，而不是每种类型一张。您按表的读/写容量付费。使用单个表，您将无需跟踪和管理。调整一张表的容量比调整三张表的容量更容易。

3) 在这种情况下我不会使用排序键。

Answer 2

明确的陈述需要具体说明，但对您的数据的外观做出一些假设：

- 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，这是对大致相同问题的更长答案。