亚马逊的DynamoDB文档似乎故意谨慎地讨论如何为行选择分区。以下是关于分区键的discussion（强调我的）：
分区键 - 一个简单的主键，由一个称为分区键的属性组成。
DynamoDB使用分区键的值作为内部哈希函数的输入。散列函数的输出确定将存储项目的分区（DynamoDB内部的物理存储）。
在只有分区键的表中，没有两个项可以具有相同的分区键值。
Tables, Items, and Attributes中描述的
People表是具有简单主键（PersonID）的表的示例。您可以通过提供该项目的People值来立即访问PersonId表中的任何项目。
因此给出的示例将PersonID作为数字，对于散列来说可能是宏的或令人沮丧的 - 取决于内部散列函数。
在我的项目中，我们使用随机的v4 UUID作为主键，目前我们以字符串/ S形式（包含破折号）保持UUID。在我看来，类似于整数，这个UUID字符串可以根据内部散列函数漂亮地或令人沮丧地散列。
将UUID作为字符串保存对我们来说很方便（虽然浪费空间），因为我们可以使用与应用程序日志中显示的v4格式相同的方式查看/查询Dynamo控制台中的UUID。但是，如果以字符串/ S形式而不是二进制/ B形式持久化我们的UUID将导致我们的行的可怕别名只有一个或两个分区，因为内部哈希函数对于转换是天真的我们的UUID字符串为字节，然后方便被诅咒，二进制/ B形式最适合UUID。
所以，我想更多地了解内部哈希函数（最好是来自Dynamo开发人员本身。）请给我们详细说明内部哈希函数中的智能级别。它对String / S，Number / N和Binary / B类型的行为如何？
内部哈希函数是否识别我们正在传递v4 UUID格式的字符串并自动散列在该UUID的二进制形式上？或者，它是按字典顺序散列的吗？
如果String / S键哈希算法默认是天真的，是否有任何编程方式我可以用来向Dynamo暗示我的String键是UUID并在二进制表单上对它进行哈希处理？我正在使用DynamoSDK for Java和DynamoDBMapper访问我的表格，无论你指向哪里，我都可以在我的实体上添加额外的注释。我也可以通过DynamoDB架构json配置控制自己的表定义，并可以根据需要进行更改。
答案 0 :(得分：3)
我不是DynamoDB团队的开发人员，但我仍然会尽力回答。