首页 文章

使用数字哈希键进行DynamoDB分区 . 此密钥方案是否保持统一的数据访问?

提问于
浏览
0

Dynamodb的文档在如何通过管理散列/范围密钥命名方案在分区之间均匀分布数据方面相当清楚 .

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.UniformWorkload

因此,我倾向于使用独特的字母数字哈希键 . 然而,在这种情况下,我们的情况是密钥本身的实际大小非常重要,因为在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 回答

  • 2

    发电机访问速度取决于“密钥访问模式”(而不仅仅是密钥是随机的)

    即使你有递增键也没关系,如果你确定101经常被访问102或104.另一方面,如果你认为103将比其他人“更多”访问,它会导致问题(然后你必须通过附加随机的方式在多个密钥上传播103访问权限)

    引用它们:

    例如,如果一个表具有非常少量的访问量很大的散列键元素,甚至可能是一个使用频率非常高的散列键元素,则流量集中在少量分区上 - 可能只有一个分区 . 为了充分利用DynamoDB吞吐量,构建表,其中哈希键元素具有大量不同的值,并且请求相当均匀,尽可能随机

相关问题