UUID 作为 DynamoDB 中的主键——好主意还是坏主意？

Question

在新的 DynamoDB 表中，我的用例已通过以下关键模式设计实现：

• 分区键： user_id
• 排序键： entity_id

基本上，访问模式是：

1. 获取特定用户的特定帖子。
2. 获取特定用户的特定评论。
3. 列出特定用户的所有帖子。
4. 列出特定用户的所有评论。
5. 列出特定用户的所有实体（帖子或评论）。

如果我使用更随机的 ID 作为分区键并仅将 GSI 用于上述访问模式，我会得到什么好处？

• partition key: pseudo_random_id （这实际上是一个 UUID。请忽略这不是图中的 UUID）。
• 全球情报局：
  • 分区键： user_id
  • 排序键： entity_id

Answer 1

您不需要UUID或任何伪随机ID。

如果一个用户特别活跃，曾经有可能拥有一个热分区，但是由于DynamoDB的自适应能力，现在基本上不再有热分区。 此外，您可能应该限制用户创建评论/帖子的速度，即使不存在自适应功能，这也将阻止热分区。

（为什么要限制用户可以发布的速率？您不希望恶意参与者每隔几毫秒就可以创建一个新帖子-您应该具有某种速率限制，以防止拒绝服务攻击。）

Answer 2

使用UUID不会为您做任何事情...

分区键的随机性无关紧要。 重要的是您拥有多少个不同的分区键以及该分区键的条目的数量/速度。

换句话说，唯一值是唯一值。 Dynamo不在乎它是16个字节，36个字节还是128个字节。

Dynamo将其自己的哈希应用于分区键，以确定数据将放置在哪个分区中。

Answer 3

如果您正在查看 DynamoDB 中的唯一 + 序列号，值得阅读Atomic Counters 作为一个选项。 在表中维护一个计数器。 但对于请求 ID 的高负载应用程序来说可能是个问题。 因为 UpdateItem 是每个元组同步的。