在新的 DynamoDB 表中，我的用例已通过以下关键架构设计实现:
- 分区键:
user_id - 排序键:
entity_id
基本上，访问模式是:
- 获取特定用户的特定帖子。
- 获取特定用户的具体评论。
- 列出特定用户的所有帖子。
- 列出特定用户的所有评论。
- 列出特定用户的所有实体(帖子或评论)。
如果我使用更随机的 ID 作为分区键并简单地使用 GSI 作为上述访问模式，我会获得什么好处？
- 分区键:
pseudo_random_id(这实际上是一个 UUID。请忽略这不是图中的 UUID)。 - GSI:
- 分区键:
user_id - 排序键:
entity_id
- 分区键:
最佳答案
您不需要 UUID 或任何伪随机 ID。
如果一个用户特别活跃，您曾经有可能拥有一个热分区，但热分区是 basically a non-issue现在是因为 DynamoDB 的自适应能力。此外，您可能应该限制用户创建评论/帖子的速度，这样即使不存在自适应容量，也可以防止热分区。
(为什么要限制用户发帖的速率？您不希望恶意行为者每隔几毫秒就创建一个新帖子 - 您应该有某种速率限制来防止拒绝服务攻击。)
关于amazon-web-services - UUID 作为 DynamoDB 中的主键——好还是坏主意？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56829651/