Home Articles

哪个哈希键最适合DynamoDB中的事件数据?

Asked
Viewed 1995 times
3

我使用Amazon DynamoDB存储活动流的基于事件的数据 .

我自动为每个月创建一个新表,并打算将事件数据存储在每个相关表中 . 通过这种方式,我可以在需要时通过删除旧表快速删除旧月,以及更好地为更新的表提供负载 .

然而,基于阅读亚马逊文档,我可以看到哈希键本身非常重要 .

预配置吞吐量取决于主键选择以及各个项目的工作负载模式 . 存储数据时,Amazon DynamoDB会将表的项划分为多个分区,并主要根据散列键元素分发数据 . 与表关联的预配置吞吐量也在分区之间平均分配,而不跨分区共享预配置吞吐量 .

我很难理解这个问题 .

因此,我的问题,上面提到的是,这两个哈希密钥会更好:

1382465533_john.doe

要么:

john.doe_1382465533

以上键是userid和事件时间戳的组合 .

How these tables will be queried...

这些表将 NOT 具有范围键,对于此用例,它不是必需的 .

此数据将用于为用户构建活动源 .

当一个事件发生时,个人活动ID被推送(扇出)到用户关注者 redis 列表(每个用户一个列表);

因此,当用户请求他们的流时,我们执行以下操作:

  • Redis 获取activityid列表

  • 循环遍历activityid并构造BatchGetItem查询以将它们从DynamoDB中拉出 .

考虑到所有这些,我需要了解的是如何最好地在活动表中定义我的哈希键 . 首先是时间戳,或者是用户ID . DynamoDB使用什么逻辑来自动分区哈希键?

提前感谢任何建议 .

1 Answer

  • 2

    根据你的问题,我会说你如何编写你的哈希键并不重要,因为你必须使用该哈希键的确切值来查询你的表,而DynamoDB无论如何都将它视为一个字符串 . 另一件事是如果你正在编写一个范围键,那么你可能想要按如下方式编写它

    john.doe_1382465533

    所以你可以像这样轻松查询你的表格

    hash key = whatever,range key> = john.doe_1382460000

    也就是说,也许你可以通过将它直接集成到DynamoDB来摆脱你的Redis活动源,如下所示:

    哈希键:用户ID范围键:时间戳其余的活动数据

    因此,您不必将活动推入DynamoDB,而将活动ID推送到Redis,您只需要推送它并从同一个DynamoDB表中查询它 . 我不知道这是否与你的应用程序的其余部分兼容,但这是一个想法 .

Related