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

Question

我正在使用 Amazon DynamoDB 为活动流存储基于事件的数据。

我会自动为每个月创建一个新表，并打算将事件数据存储在每个相关表中。这样，我可以在需要时通过删除旧表快速删除旧月份，并为更新的表提供更好的负载。

但是根据阅读亚马逊文档，我可以看到哈希键本身非常重要。

预置吞吐量取决于主键选择，并且 单个项目的工作负载模式。存储数据时，亚马逊 DynamoDB 将表的项目划分为多个分区，并且 主要基于散列键元素分发数据。这 与表关联的预置吞吐量也被平均分配 在分区之间，不共享预置吞吐量 分区。

我很难理解这一点。

因此我的问题是，以上是介意，这两者之间哪个哈希键会更好：

1382465533_john.doe

或：

john.doe_1382465533

以上键是用户ID和事件时间戳的组合。

将如何查询这些表...

这些表将不具有范围键，因为对于此用例，它不是必需的。

这些数据将用于为用户构建活动源。

当事件发生时，单个活动 ID 被推送（扇出）到用户关注者 redis 列表（每个用户一个列表）；

因此，当用户请求他们的流时，我们会执行以下操作：

1. 从 Redis 获取 activityid 的列表
2. 遍历 activityid 并构造一个 BatchGetItem 查询以将它们从 DynamoDB 中提取出来。

考虑到所有这些，我需要了解的是如何最好地在活动表中定义我的哈希键。时间戳优先或用户标识优先。 DynamoDB 使用什么逻辑来自动对哈希键进行分区？

提前感谢您的任何建议。

Answer 1

根据您的问题，我想说的是，您如何组成散列键并不重要，因为您必须使用该散列键的确切值来查询您的表，而 DynamoDB 会将其视为字符串反正。另一件事是，如果您正在编写范围键，那么您可能希望按如下方式编写它

john.doe_1382465533

这样您就可以像这样轻松查询您的表

哈希键 = 不管，范围键 >= john.doe_1382460000

也就是说，也许您可​​以通过将 Redis 活动源直接集成到 DynamoDB 中来摆脱它，如下所示：

哈希键：用户 ID

范围键：时间戳

其余的活动数据

因此，无需将活动推送到 DynamoDB 并将活动 ID 推送到 Redis，您只需将其推送并从同一个 DynamoDB 表中查询即可。我不知道这是否与您的应用程序的其余部分兼容，但这是一个想法。