MongoDB单集合存储多粒度时序数据的最优长期设计方案咨询

直接选扁平化单条文档+核心字段打标的方案，不要用按日嵌套的时间桶结构，完全匹配你现在的业务场景，长期用也不会有架构硬伤。

为什么不推荐日聚合时间桶结构 #

这个结构看起来聚合度高，实际踩坑点全在你的高频场景上：

• 你99%的请求都是只查特定分辨率、特定数据源的数据，用嵌套结构每次都要把整个日维度的大文档读出来，再从里面反序列化筛对应的d/h/m数组，高QPS下白白浪费带宽和CPU，流量上来了很容易出现慢查询。
• 后续迭代成本极高：要是以后加个秒级IoT设备数据、或者接个第三方气象数据源，你得改所有日桶的嵌套结构，新旧数据兼容非常麻烦。
• 写冲突风险高：气象数据经常有延迟补录的情况，比如某小时的IoT数据晚到2小时，你要修改对应日桶里的数组字段，并发写的时候很容易覆盖其他刚写入的同天数据。

可落地的结构设计 #

每条数据单独存为一个文档，固定带4类核心字段，存储层配合索引优化就行：

• ts：对应精度的时间戳，日度数据存当日0点时间戳，小时级存整点时间戳，分钟级存对应分钟的时间戳
• resolution：枚举值，固定为day/hour/minute，标记数据粒度
• source：枚举值，固定为api/iot，标记数据来源，后续加新数据源直接扩枚举值即可
• 其余字段存具体的气象指标（温度、湿度、风速、气压等）

索引只需要建一个联合索引：(resolution, source, ts)，直接覆盖你所有高频请求：用户查特定粒度、特定来源、某个时间范围的数据时，直接走索引精准命中，不需要扫描任何多余数据，毫秒级响应，扛高QPS非常稳。存储层按天做分区，老数据归档、冷热分层都可以直接按天操作，运维成本极低。

优先级降级逻辑实现 #

你提到的"优先取分钟级IoT数据，无数据则降级取API数据"的逻辑，完全不用在存储层做复杂设计，放在业务服务层做两次轻量查询即可：

1. 先按最高优先级条件查询：匹配resolution=minute、source=iot、ts=目标时间，查到结果直接返回
2. 第一次查询无结果，就按下一个优先级条件查询：比如匹配resolution=day、source=api、ts=对应日期，查到直接返回

因为每次都是走索引的精准查询，两次查询的总开销远低于读取整个日桶大文档的开销，而且逻辑完全透明，后续要调整优先级顺序（比如新增第三方数据源插入优先级队列），只需要改业务层的查询顺序，不用动任何存储结构。

长期使用的额外优势 #

• 你提到的每天只有数次的跨粒度、跨数据源组合查询，也可以直接支持，按时间范围扫对应日分区即可，不需要做复杂的嵌套字段展开
• 写入完全无锁：不同来源、不同粒度的数据写入互相独立，延迟补录的数据直接写入对应单条文档即可，不会出现写冲突
• 生命周期管理灵活：可以针对不同粒度的数据配置不同的保留策略，比如分钟级数据只存3个月，小时级存1年，日度数据永久留存，直接按resolution字段配置规则即可，嵌套结构根本做不到这么细的粒度管控。

内容的提问来源于stack exchange，提问作者FFGH