3

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

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

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

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

我很难理解这一点。

因此，我的问题是，请注意，这两者之间哪个哈希键更好：

1382465533_john.doe

或者：

john.doe_1382465533

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

如何查询这些表...

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

此数据将用于为用户构建活动提要。

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

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

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

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

提前感谢您的任何建议。

4

1 回答 1

4

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

john.doe_1382465533

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

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

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

哈希键：用户id

范围键：时间戳

其余活动数据

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

于 2013-10-28T22:48:49.353 回答