UUID 作为 DynamoDB 中的主键——好主意还是坏主意? [英] UUID as primary key in DynamoDB -- good or bad idea?

问题描述

在一个新的 DynamoDB 表中，我的用例已经通过以下关键架构设计实现:

In a new DynamoDB table, my use cases are already fulfilled by the following key schema design:

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

基本上，访问模式是:

1. 获取特定用户的特定帖子.
2. 获取特定用户的特定评论.
3. 按特定用户列出所有帖子.
4. 列出特定用户的所有评论.
5. 列出特定用户的所有实体(发布或评论).

1. Get specific post by a specific user.
2. Get specific comment by a specific user.
3. List all posts by specific user.
4. List all comments by specific user.
5. List all entities (post or comment) by a specific user.

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

What benefits do I get if I use a more random ID as partition key instead and simply use GSIs for my access patterns above?

• 分区键:pseudo_random_id(这实际上是一个 UUID.请忽略这不是图中的 UUID).
• GSI:
  • 分区键:user_id
  • 排序键:entity_id
  • partition key: pseudo_random_id (This is going to be a UUID in reality. Please ignore that this is NOT a UUID in the illustration).
  • GSI:
    • partition key: user_id
    • sort key: entity_id

    推荐答案

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

    You don’t need UUIDs or any pseudo-random ID.

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

    It was once possible that you could have a hot partition if one user is particularly active, but hot partitions are basically a non-issue now because of DynamoDB’s adaptive capacity. Furthermore, you should probably be limiting how fast users can create comments/posts, which would prevent hot partitions even if adaptive capacity didn’t exist.

    (为什么要限制用户可以发帖的速度?您不希望恶意行为者能够每隔几毫秒创建一个新帖子——您应该有某种速度限制来防止拒绝服务攻击.)

    (Why should you limit the rate a user can post? You don’t want a malicious actor to be able to create a new post every few milliseconds—you should have some sort of rate limit as a protection against denial of service attacks.)

    这篇关于UUID 作为 DynamoDB 中的主键——好主意还是坏主意?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！