我们正在构建一个会话系统，该系统将支持2个用户之间的消息（最终支持3个以上的用户）。每个对话都有一组可以参与/查看对话的用户以及一组消息。用户界面将显示特定对话中最近的10条消息，并能够“页面”（逐步滚动？）消息，以便及时查看消息。
计划是在MSSQL中存储会话和参与者，然后仅在DynamoDB中存储消息（表示可能会变得非常大的数据）。消息表将使用对话ID作为散列键，并使用消息CreateDate作为范围键。对话ID可以是此处的任何内容（整数，GUID等），以确保跨分区的均匀消息分发。
为了避免热分区，一个建议是为时间序列数据创建单独的表，因为通常只访问最新的数据。当我们需要在用户滚动/翻页时拉回用户的先前消息时，这是否会导致问题，因为我们必须跨多个表查询以拼凑一批消息？
是否有不同的/更好的方法来存储可能不经常访问但可以快速获得的时间序列数据？
答案 0 :(得分：1)
我想我们可以假设有很多“主动”对话并行，对吧？含义 - 我们没有处理所有流量都涉及单个会话（或少数）的情况。
如果是这种情况，并且你使用随机数/ GUID作为你的HASH键，你的对象将在整个节点中均匀分布，据我所知，你不应该害怕偏斜。由于CreateDate只是RANGE键，因此同一个会话的所有消息都将存储在同一节点上（基于其ConversationID），因此如果您查询最新消息实际上并不重要5个记录或最早的5个。在这两种情况下，它使用CreateDate上的索引进行查询。
我不会将数据分成多个表。我没有看到它给你带来了什么好处（考虑到上一节），它会让你的管理生活成为一场噩梦（想象一下，改变所有表的吞吐量，或者备份它们，或者创建一个CloudFormation模板来创建整个环境）
我会关注拉取历史记录时返回的消息数。我猜你会用query命令实现它，ConversationID作为HASH键，并按CreationDate降序排序。在这种情况下，我只返回结果的第一页（我认为它返回最多1MB的数据，所以取决于平均消息长度，它可能是否足够）并且只有当用户继续滚动时，才获取下一页。否则，您可能会在很长的对话中使用大量的吞吐量，无论如何，客户端并不想长时间等待数兆字节的数据出现在屏幕上。
希望这有帮助