嗨，看了你的需求，咱们一步步来拆解怎么实现这个按时间段统计热门话题的需求，结合你的场景（每秒几千条帖子插入、每小时计算一次非实时结果），给你几个实用的方向：

首选方案：DynamoDB Streams + 增量聚合统计 #

这个方向和你一开始想到的DynamoDB Streams思路完全契合，而且适配你的高插入量场景：

• 先开启你的DynamoDB表的Streams功能，捕获所有新插入的帖子记录（只需要新插入的，选“仅新图像”的捕获模式就行）。
• 用Lambda（或者你自己的后台服务）消费这些流数据，维护一个增量统计表（可以存在DynamoDB里）。统计表的主键设为Topic#YYYYMMDDHH（比如IoT#2024052014代表2024年5月20日14点的IoT话题），属性就是该小时的帖子计数。每消费一条新帖子，就给对应话题的当前小时计数做+1操作（用DynamoDB的UpdateItem配合ADD操作符，原子性更新，不会有并发问题）。
• 到了每小时的计算时间，你只需要把最近24个小时的所有Topic#YYYYMMDDHH记录拉出来，按Topic汇总总计数，排序取Top N即可。计算好的结果可以存在专门的“热门话题结果表”里，比如主键设为Trending#24h，直接存包含Top 10话题和对应计数的列表，后续其他服务直接读这个表就好，速度极快。

这个方案的优势是增量计算，资源消耗极低，完全不影响主表的读写性能，成本可控，非常适合你每秒几千条的高插入场景。

不推荐的方案：定期全量扫描主表 #

虽然理论上你可以每小时对主表做一次全量扫描，过滤出过去24小时的SK（因为你的SK是Timestamp#UserId，只要构造出24小时前的时间戳，用SK > 24小时前的时间戳做条件过滤），然后按Topic分组计数，但这个方案的问题非常明显：

• 当数据量上来后，全量扫描会消耗巨量的读容量单位（RCU），不仅成本高，还会影响主表的正常读写性能。
• 扫描+过滤的速度会越来越慢，可能超过你每小时计算的时间窗口，完全不适合你的高插入量场景，所以除非你的数据量极小，否则别碰这个方案。

进阶方案：搭配分析型存储（适合未来需求扩展） #

如果以后你的统计需求变复杂了（比如要按天/周统计、按地域+话题联合统计、多维度过滤等），那可以考虑把DynamoDB的实时数据同步到专门的分析型存储：

• 比如用DynamoDB Streams把数据同步到数据仓库，然后每小时跑一次SQL查询：SELECT Topic, COUNT(*) AS post_count FROM posts WHERE timestamp > NOW() - INTERVAL '24 hours' GROUP BY Topic ORDER BY post_count DESC LIMIT 10;，直接就能拿到Top 10热门话题。
• 或者同步到Elasticsearch，用它的聚合查询功能来统计，好处是查询灵活，还能支持全文检索之类的附加需求。

这种方案的优势是统计逻辑用SQL/DSL就能实现，不需要自己写复杂的聚合代码，适合需求多变的场景，但前期的部署和维护成本会比第一种方案高一点。

最终方案建议 #

结合你当前的需求（仅按时间段统计Top N、每小时计算、高插入量），首选第一种方案（DynamoDB Streams + 增量统计表），这个方案最贴合你的场景，成本低、性能好、实现简单。如果以后需求变复杂了，再考虑升级到第三种方案。

备注：内容来源于stack exchange，提问作者Robot-43