performance - DynamoDB 中 UUID 的 "internal hash function"是什么？

Question

Amazon 的 DynamoDB 文档似乎对如何为一行选择分区刻意保持谨慎。这是discussion关于分区键(强调我的):

Partition key – A simple primary key, composed of one attribute known as the partition key.

DynamoDB uses the partition key's value as input to an internal hash function. The output from the hash function determines the partition (physical storage internal to DynamoDB) in which the item will be stored.

In a table that has only a partition key, no two items can have the same partition key value.

The People table described in Tables, Items, and Attributes is an example of a table with a simple primary key (PersonID). You can access any item in the People table immediately by providing the PersonId value for that item.

因此，给出的示例将 PersonID 作为数字，这对于散列来说可能很大也可能很糟糕——这取决于内部散列函数。
在我的项目中，我们使用随机 v4 UUID 作为主键，目前我们将该 UUID 保存在 String/S 中。形式(包括破折号)。我突然想到，与整数类似，这个 UUID 字符串可以根据内部散列函数进行漂亮或暗淡的散列。
将 UUID 保留为字符串对我们来说很方便(尽管浪费了空间)，因为我们可以在 Dynamo 控制台中以与应用程序日志中显示的相同的 v4 格式查看/查询 UUID。但是，如果将我们的 UUID 保存在 String/S 中形式而不是二进制/B form 将导致我们的行被可怕地别名为一两个分区，因为内部散列函数对于将我们的 UUID 字符串转换为字节很幼稚，那么方便就该死和 Binary/B表单最适合 UUID。
所以，我想更多地了解内部散列函数(最好是来自 Dynamo 开发人员自己)。请告诉我们有关该内部散列函数的智能水平的详细信息。它与 String/S 的关系如何？ , 编号/N , 和二进制/B类型？
内部散列函数是否识别我们正在传递一个 v4 UUID 格式的字符串并在该 UUID 的二进制形式上自动散列？或者，它是按字典序哈希的吗？
如果字符串/S默认情况下， key 散列算法是幼稚的，是否有任何编程方式可以用来向 Dynamo 提示我的 String 键是 UUID 并将其散列在二进制形式上？我使用 DynamoSDK for Java 和 DynamoDBMapper 来访问我的表，我可以在我的实体上撒上额外的注释，无论你在哪里。我也通过 DynamoDB 架构 json 配置控制我自己的表定义，并且可以根据需要在那里进行更改。

Answer 1

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

无法提示 DynamoDB 如何在内部散列您的分区键。此外，DynamoDBMapper 没有这样的注释。

由于 DynamoDB 不会公开其散列方案的内部结构，因此您不应在系统中使用任何此类假设。这是因为 DynamoDB 可以随时自由更改前者，无论这种情况多么罕见。

DynamoDB 实际上在内部进行了两次散列，因此我认为您不必太担心:

它首先散列以避免连续的键落在一起。查询 this论坛入口。

它对上述内容进行散列以决定记录应该转到哪个分区。