DynamoDB 中 UUID 的“内部哈希函数”是什么？

Question

Amazon 的 DynamoDB 文档似乎故意对如何为一行选择分区保持谨慎。这是关于分区键的discussion（重点是我的）：

分区键 - 一个简单的主键，由一个称为 分区 键的属性组成。

DynamoDB 使用分区键的值作为内部散列函数的输入。哈希函数的输出决定了存储项目的分区（DynamoDB 内部的物理存储）。

在只有一个分区键的表中，没有两个项目可以具有相同的分区键值。

Tables, Items, and Attributes 中描述的People 表是具有简单主键 (PersonID) 的表的示例。您可以通过为该项目提供PersonId 值来立即访问People 表中的任何项目。

因此，给出的示例将 PersonID 作为一个数字，对于散列来说可能很大也可能很糟糕 - 取决于内部散列函数。

在我的项目中，我们使用随机 v4 UUID 作为主键，目前我们以 String/S 形式（包括破折号）保留该 UUID。我突然想到，类似于整数，这个 UUID 字符串可以根据内部散列函数进行漂亮或暗淡的散列。

将 UUID 保存为字符串对我们来说很方便（尽管会浪费空间），因为我们可以在 Dynamo 控制台中以与应用程序日志中显示的相同的 v4 格式查看/查询 UUID。但是，如果将我们的 UUID 保存在 String/S 形式而不是 Binary/B 形式将导致我们的行的可怕别名只有一个或两个分区，因为内部散列函数对于将我们的 UUID 字符串转换为天真字节，那么方便就该死，Binary/B 形式最适合 UUID。

所以，我想了解更多关于内部散列函数的信息（最好来自 Dynamo 开发人员自己）。请向我们详细说明该内部散列函数的智能水平。它对 String/S、Number/N 和 Binary/B 类型有何表现？

内部散列函数是否识别出我们正在传递一个 v4 UUID 格式的字符串并自动对该 UUID 的二进制形式进行散列？或者，它是按字典顺序散列吗？

如果默认情况下 String/S 键散列算法是幼稚的，是否有任何编程方式我可以用来向 Dynamo 提示我的 String 键是 UUID 并使其以二进制形式散列？我将 DynamoSDK for Java 与 DynamoDBMapper 一起使用来访问我的表，并且无论您指向何处，我都可以在我的实体上添加额外的注释。我也通过 DynamoDB 模式 json 配置控制自己的表定义，并且可以根据需要进行更改。

Answer 1

我不是这里 DynamoDB 团队的开发人员，但我仍会尽力回答。

• 无法提示 DynamoDB 如何在内部散列您的分区键。此外，DynamoDBMapper 没有这样的注释。
• 由于 DynamoDB 不公开其哈希方案的内部结构，因此您不应在系统中使用任何此类假设。这是因为 DynamoDB 可以随时随意更改前者，尽管这种情况可能很少见。
• DynamoDB 实际上在内部进行了两次哈希运算，因此我认为您不必太担心：
  • 它首先散列以避免连续的键落在一起。检查this论坛条目。
  • 它对上述内容进行哈希处理，以决定记录应该转到哪个分区。