Dynamodb的文档在如何通过管理散列/范围密钥命名方案在分区之间均匀分布数据方面相当清楚 .
因此,我倾向于使用独特的字母数字哈希键 . 然而,在这种情况下,我们的情况是密钥本身的实际大小非常重要,因为在dynamodb中选择的散列密钥将在 redis
中的各种流中反复复制 .
因此,从数据访问/分区的角度来看,我们需要一个适合 dynamodb
的密钥,从纯密钥大小的角度来看,我们需要 redis
.
考虑到这一点,我们决定在 redis
中保留一个递增计数器,并为dynamodb项使用单个 NUMBER
哈希键 . 每次我们在dynamodb中插入一个新项目时递增 redis
计数器 .
这些整数键在 redis
中得到了非常好的压缩,并且从我们的测试中,存储空间的改进超过了基于唯一字符串的ID 's (since these ID'的超过300-400%,可能会被推送到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有效地分区我们的表,并最终允许我们满足或吞吐量分配 .
提前致谢 .
1 回答
发电机访问速度取决于“密钥访问模式”(而不仅仅是密钥是随机的)
即使你有递增键也没关系,如果你确定101经常被访问102或104.另一方面,如果你认为103将比其他人“更多”访问,它会导致问题(然后你必须通过附加随机的方式在多个密钥上传播103访问权限)
引用它们: