需要DynamoDB / Redis活动流帮助

Question

我选择DynamoDB作为活动供稿/事件数据的后端，但在决定使用最佳数据结构方面遇到了一些麻烦。

首先，我应该解释每个用户的活动ID存储在Redis排序集（用于个人配置文件活动）和Redis列表中的个人活动流，这意味着我在DymaoDB中的任何活动表只需要一个哈希键并且不需要范围，本地或全局索引，因为它们基本上是在Redis中编制索引的。

我们这样做是为了通过操作Redis中的ID列表和集合来有效地聚合Feed和配置文件活动数据。

无论如何......我们最初的计划是每个月创建一个DynamoDB表，将活动数据存储在那里......然后随着年龄的增长拨打旧表的预配置吞吐量，保持最新数据的快速和可用保持旧数据的成本。

虽然这种技术对于活动流本身非常有效，但在查看用户配置文件（以及他们自己的历史活动）时它不起作用。因为，以类似于Facebook时间线的方式，用户能够查看我们返回的所有内容他们的出生，并能够在他们的个人资料中添加自定义生活事件。这个要求意味着在过去80年左右的每个月都有一张表格，因此，我们还需要其他的东西。

目前，我们正在考虑将活动表拆分为活动类型。 e.g：

activities_comments
actvities_likes
actiities_uploads
activities_posts

......等等。

我们需要大约20个表来涵盖我们当前的所有活动类型。使用这种方法可以让我们有选择地为最常见的活动提供吞吐量，对于我们而言，保持单个活动表具有庞大且昂贵的预配置吞吐量似乎更为可取。

在redis中，我们只需为每个活动ID添加一个表后缀，以便我们知道活动元数据存储在哪个表中，然后我们就可以按如下方式查询数据：

对于活动流：

• 存储在Redis列表中的每个用户流的activityID（包含聚合后所有关注者的活动数据）
• 保持列表截断以说明500项以保持redis内存要求下降
• 使用Redis lrange进行简单查询以获取最近的活动20个活动
• 使用DynamoDB batchGetitem从各种表中提取ID ....当用户向下滚动流时，冲洗并重复。

对于用户个人资料

• 针对每个用户的Redis排序集中存储的聚合activitID 时间戳记为分数
• 使用Redis zrangebyscore从中获取活动ID的特定月份或时间范围 排序集（即用户可以根据需要快速提取2012年7月的活动历史记录）
• 再次使用batchGetItem从DynamoDB中检索数据

数据聚合将在离线状态下完成，我们将分析在给定时间段内发生的类似活动的redis列表/排序集，然后使用聚合元数据创建新活动，将其添加到dynamoDB，添加新数据Redis在正确的位置进行活动，最后从Redis列表/集合中删除所有旧的相关活动。

e.g。

• 同一张照片中有260张相似的图片都可在一周之内找到。
• 我们使用反映这一点的元数据构建一个SINGLE新活动，其中包含旧活动ID的列表（我们需要检索它们）
• 从redis列表/集中删除260个activityID，并替换为单个新的activityID。

以上实际上要复杂得多，并且考虑到我们开发的最受欢迎的帖子和活动权重...但它给你一个粗略的想法。

所以，既然我已经描述了我们目前正在考虑的解决方案，我想知道的是：

1. 这听起来像是一个好/快/灵活/可扩展的解决方案吗？
2. 是否有可能比我描述的更好的替代数据结构？
3. 我们可能没有想过上述场景是否存在任何明显问题？

我知道这是一个模糊的问题，需要阅读很多，但任何意见或评论都会受到高度赞赏。

注意：为了完整起见，我应该说明活动ID是在写入Redis中的用户关注者活动流时被推出的。虽然我们并不反对在阅读时改变扇形，但是有人应该让我们相信它在答案中的好处。

Answer 1

您可以在活动表上启用DynamoDB Streams，并为attach Lambda functions启用Redis结构中的活动。建议使用时间序列表来管理热/冷数据的配置吞吐量成本。但是，存在一些实际限制，例如256 tables的每个帐户的每个帐户限制可能会限制您在DynamoDB中保留所有数据的能力。相同的Lambda函数可以使用滑动窗口维护活动计数缓存，您可以使用该窗口将许多小活动聚合为聚合活动。

Answer 2

在DynamoDB上构建活动源和新闻源需要大量额外的基础架构，因为您传播数据的方式（写入时出扇），这通常会导致大量的配置剧和高成本。

我写了一篇文章，描述了在DynamoDB here上运行新闻源的挑战。

免责声明：我是首席技术官，也是Stream的共同创始人之一