Dynamodb 的文档非常清楚地说明了如何通过管理哈希/范围键命名方案将数据均匀地分布在分区之间。
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.UniformWorkload
因此，我倾向于经常使用唯一的字母数字哈希键。 但是，在这种情况下，我们遇到一种情况，即密钥本身的实际大小非常重要，因为在dynamodb中选择的哈希密钥将在redis的各种流中一遍又一遍地复制。
因此，我们需要一个既适合dynamodb数据访问/分区角度的键，也适合纯键大小角度的redis键。
考虑到这一点，我们决定在redis中保留一个递增计数器，并对dynamodb项目使用单个NUMBER哈希键。 每次我们将新项目插入 dynamodb 时递增redis计数器。
这些整数键在redis中被很好地压缩，并且从我们的测试中产生了比基于唯一字符串的ID超过300-400%的存储空间改进（因为这些ID可能会被推送到100个流中，所有这些都存储在redis lists/zsets中。
不过，据我了解，这对dynamodb不利，因为只有一个递增的哈希键：
101
102
103
104
等。。。
插入多个项目时写入速度会很慢，并且考虑到我们的访问模式，我们希望将这些键的组一起检索。
为了解决这个问题，我们正在考虑将一个随机数连接到哈希键的末尾。
(float)$itemId . '.' . mt_rand(0, 200)
生成如下键：
101.26
102.199
103.87
104.5
使用这些键，我们仍然可以在redis中获得存储改进，并且我们还设法保留了广告顺序（这意味着我们不需要存储时间戳）......
但是，我不完全清楚dynamodb将如何管理和分区这些。
所以我的问题是，上面显示的单个哈希键是否是最佳的，并鼓励 dynamodb 有效地对表进行分区，并最终允许我们满足或吞吐量分配。
提前谢谢。
dynamo 访问速度取决于"密钥访问模式"（而不仅仅是随机密钥）
即使您有递增键也没关系，如果您确定 101 的访问频率与 102 或 104 一样频繁。另一方面，如果您认为 103 将比其他访问"更多"，则会导致问题（然后您将不得不通过附加随机键将 103 访问权限分散到多个键）
引用他们的话：
例如，如果表具有非常少量的频繁访问哈希键元素，甚至可能是一个非常频繁使用的哈希键元素，流量集中在少数分区上 –可能只有一个分区。
要充分利用 DynamoDB 吞吐量，请构建表，其中哈希键元素具有大量不同的值，值是尽可能随机地相当一致地请求