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

Question

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

\n

\n

分区键 \xe2\x80\x93 一个简单的主键，由一个称为分区键的属性组成。

\n

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

\n

在只有一个分区键的表中，任何两个项目都不能具有相同的分区键值。

\n

表、项目和属性People中描述的表是具有简单主键 ( ) 的表的示例。您可以通过提供该项目的值来立即访问表中的任何项目。PersonIDPeoplePersonId

\n

\n

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

\n

在我的项目中，我们使用随机 v4 UUID 作为主键，目前我们以字符串/S形式保留该 UUID（包含破折号）。我发现，与整数类似，这个 UUID 字符串可以根据内部哈希函数进行漂亮或惨淡的哈希处理。

\n

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

\n

因此，我想了解有关内部哈希函数的更多信息（最好是来自 Dynamo 开发人员本身）。请向我们提供有关该内部哈希函数的智能程度的详细信息。S它与 String/ 、 Number/N和 Binary/的行为如何B？

\n

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

\n

如果字符串/S密钥哈希算法很简单，是否有任何编程方式可以用来向 Dynamo 提示我的字符串密钥是 UUID 并使其以二进制形式进行哈希？我正在使用 DynamoSDK for Java 和 DynamoDBMapper 来访问我的表，并且无论您在何处指示，我都可以在我的实体上添加额外的注释。我还通过 DynamoDB 架构 json 配置控制自己的表定义，并可以根据需要进行更改。

\n

Answer 1

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

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