根据文档，我理解DynamoDB将获取所提供的分区键的值，并将其通过散列函数来决定数据应该放到哪个物理位置。
这是否意味着使用顺序但仍然唯一的分区键写入项将产生热分区键?
例如，插入分区键值为10001、10002、10003、10004的项是否允许数据在分区间均匀分布?
或者随机生成分区键值(如UUID)会使其分布更均匀吗?
DynamoDB支持两种不同的主键:
- 分区键
- 分区键+排序键
分区键
如果你有一个只有分区键的主键，你很少会遇到热分区问题，因为在一个只有分区键的表中，没有两个项目可以有相同的分区键值。
你的键总是唯一的，DynamoDB的内部哈希函数将总是输出唯一的哈希&然后，您的所有数据将始终均匀地分布在逻辑分区和物理分区上。
例如，这是10001的MD5散列:d89f3a35931c386956c1a402a8e09941
这是10002的MD5哈希值:9103c8c82514f39d8360c7430c4ee557
尽管10001只增加了1，但整个哈希是不同的，并且与10002的MD5哈希没有任何相似之处。
从一致哈希的角度来看，UUID值和增量值之间没有区别。
只有当你非常频繁地访问一个特定的分区(在这里与item同属)时，你才会得到一个热分区，在这种情况下，rcu &wcu需要正确设置，您应该考虑为频繁访问的项实现缓存层。
分区键+排序键
如果你有一个主键也包含一个排序键，如果你不小心，你可能会有热分区问题，因为现在你可能有重复的分区键值。
具有相同分区键值的所有项物理上存储在一起，按排序键值排序。
如果你没有尽可能明显的主键，你可以创建热分区。
让我给你一个例子:
一个电子商务网站决定这样设计他们的订单表，当前日期是分区键，排序键是项目ID:
+---------------+----------+
| Partition Key | Sort Key |
+---------------+----------+
| 19/10/2021 | item3000 |
| 19/10/2021 | item3001 |
| 20/10/2021 | item4000 |
+---------------+----------+
这可能在这个规模下工作得很好——在上面的例子中，他们每天处理1000个项目&
黑色星期五-26/11/2021-到达&他们现在一天有超过20000个订单:
+---------------+-----------+
| Partition Key | Sort Key |
+---------------+-----------+
| 26/10/2021 | item6000 |
| 26/10/2021 | item15000 |
| 26/10/2021 | item27000 |
| 27/10/2021 | item27100 |
+---------------+-----------+
所有都将导致大量热分区问题。2021年10月26日的20000多个订单中，现在只有一个被写入单个分区键值(如前所述，具有相同分区键的项将存储在一起)。
26/11/2021分区键将是重度请求&热，降低数据库性能因为您将尝试处理订单，最终，由于应用程序性能缓慢，您将损失收入。
表应该设计成允许更多不同的主键值相对于总主键计数(总项目)-写分片(随机或计算)将防止这个问题，如果必须使用日期作为分区键。
如果没有排序键作为主键的一部分，则不用担心文档中所指的热分区问题。-如果你有1/2的频繁访问的项目，考虑一个缓存解决方案，也许像DAX。
如果你有一个排序键作为你的主键的一部分，在你的表模式设计中，你的分区+排序键的组合是唯一的，尽可能的不同，以避免热分区。