我使用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 回答
根据你的问题，我会说你如何编写你的哈希键并不重要，因为你必须使用该哈希键的确切值来查询你的表，而DynamoDB无论如何都将它视为一个字符串 . 另一件事是如果你正在编写一个范围键，那么你可能想要按如下方式编写它
所以你可以像这样轻松查询你的表格
也就是说，也许你可以通过将它直接集成到DynamoDB来摆脱你的Redis活动源，如下所示：
因此，您不必将活动推入DynamoDB，而将活动ID推送到Redis，您只需要推送它并从同一个DynamoDB表中查询它 . 我不知道这是否与你的应用程序的其余部分兼容，但这是一个想法 .