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

【问题标题】：UUID as primary key in DynamoDB -- good or bad idea?UUID 作为 DynamoDB 中的主键——好主意还是坏主意？
【发布时间】：2019-11-11 18:07:08
【问题描述】：

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

基本上，访问模式是：

如果我使用更随机的 ID 作为分区键，并简单地将 GSI 用于上述访问模式，我可以获得什么好处？

【问题讨论】：

仅供参考，您的示例 pseudo_random_id 值是 not UUID。术语UUID 具有非常具体的标准化含义。 UUID 是一个 128 位的值，以规范格式呈现给人类，由 4 个连字符组成的 32 个十六进制字符组成。示例：403fc3f4-9bb9-11e9-a2a3-2a2ae2dbcce4。请编辑问题的标题和正文，以明确您的意思是 UUID 还是其他内容。

【解决方案1】：

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

如果一个用户特别活跃，您曾经有可能拥有一个热分区，但由于 DynamoDB 的自适应能力，现在热分区是basically a non-issue。此外，您可能应该限制用户创建 cmets/posts 的速度，这将防止热分区，即使不存在自适应容量。

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

【讨论】：

只是添加一点，他不需要它，因为他已经有用户 ID，但是 UUID 很棒，因为您不需要维护索引，而且由于 DynamoDB 没有自动增量功能，您需要执行额外的查询，并且可能会遇到一些非常烦人的一致性问题。
@Mojimi，同意。任何 ID 类型尚未确定的用例，最好使用 UUID。

【解决方案2】：

使用 UUID 对您没有任何帮助...

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

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

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

【讨论】：

【解决方案3】：

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

【讨论】：