MongoDB Time Series Collection 是什么？适合存监控指标吗？

简化版

Time Series Collection 是 MongoDB 针对时序数据优化的集合类型，适合按时间持续写入并按时间范围查询的指标、传感器、日志类数据。它能自动按时间和元数据组织数据，但不等于专业时序数据库的全部能力。

详细版

时序数据通常有共同特点：数据按时间追加写入，查询按时间范围聚合，历史数据可能按周期过期。MongoDB Time Series Collection 针对这类模式做了存储和查询优化。

创建时要指定时间字段 timeField，常配合元数据字段 metaField。
适合设备指标、IoT 采样、业务监控点、简单日志事件。
可以结合 TTL 自动清理过期数据。
查询通常围绕时间范围和元数据过滤设计。
如果需要超高吞吐、复杂降采样和长期监控生态，仍要评估专业时序系统。

完整版教学

一、时序数据和普通业务数据有什么不同

普通业务数据常常围绕实体更新，比如用户资料会被反复修改；时序数据更多是追加写入，比如每 10 秒采集一次 CPU、温度或接口耗时。它的查询也很有规律：按设备、指标、时间范围过滤，再做平均值、最大值、趋势聚合。MongoDB Time Series Collection 就是利用这些规律，对存储组织和查询路径做优化。它不是换一个集合名字，而是让数据库知道“这批数据的核心维度是时间”。

db.createCollection("metrics", {
  timeseries: {
    timeField: "ts",
    metaField: "device",
    granularity: "seconds"
  }
})

记忆钩子：Time Series Collection 的主角不是某条记录，而是“某个对象随时间变化的一串点”。

二、`timeField` 和 `metaField` 怎么设计

timeField 是每条数据的时间戳，查询范围、桶组织和过期策略都围绕它展开。metaField 通常放变化较少的维度，比如设备 ID、机房、指标类别，帮助数据库把相同来源的数据组织得更紧凑。如果把频繁变化的大字段塞进 meta，会破坏聚集效果；如果没有设计好 meta，查询某台设备最近 1 小时指标时也可能扫描更多数据。好的时序建模是先确定“按谁、按什么时间查”。

db.metrics.insertOne({
  ts: new Date(),
  device: { id: "host-01", room: "cn-east" },
  cpu: 0.73,
  memory: 0.61
})

三、为什么它适合范围查询和聚合

时序查询往往是 WHERE device = ? AND ts BETWEEN ? AND ?，然后按时间窗口聚合。Time Series Collection 会把相近时间、相同元数据的数据组织到内部桶结构里，使范围查询更容易跳过无关数据。比如查某设备最近 10 分钟 CPU 平均值，不需要扫描所有设备所有历史记录。普通集合也能建索引实现类似查询，但时序集合在存储布局上更贴合这种模式。

db.metrics.aggregate([
  { $match: { "device.id": "host-01", ts: { $gte: ISODate("2026-07-30T08:00:00Z") } } },
  { $group: { _id: null, avgCpu: { $avg: "$cpu" }, maxCpu: { $max: "$cpu" } } }
])

四、带数字看时序数据增长速度

假设 1000 台机器每 10 秒上报一次指标，每台每次 20 个指标点。一天的数据点数量是 1000 × 6 × 60 × 24 = 864 万 次上报，如果按指标展开则更多。一个月下来就是 2.5 亿级别上报记录。这个增长速度说明，时序数据必须提前考虑压缩、过期、降采样和查询范围，否则普通业务集合很快就会变成大而慢的历史仓库。

每分钟每台 6 次
1000 台 × 6 × 60 × 24 = 8,640,000 次/天
30 天约 259,200,000 次

五、TTL 和保留周期怎么配合

监控指标通常有保留周期，例如原始秒级数据保留 7 天，分钟聚合保留 30 天，小时聚合保留 1 年。MongoDB 可以结合过期策略清理旧时序数据，避免集合无限增长。但删除策略要和业务查询需求对齐：如果报表要查半年趋势，就不能只保留 7 天原始数据，除非你提前做了降采样聚合表。时序系统的核心不是只存进去，还要能按成本把旧数据变轻。

数据层	粒度	保留时间
原始指标	10 秒	7 天
分钟聚合	1 分钟	30 天
小时聚合	1 小时	1 年

六、和专业时序数据库的边界

MongoDB Time Series Collection 适合已经使用 MongoDB 的系统承载中等规模时序数据，尤其是指标和业务文档有关联时。但如果你要做超大规模监控、PromQL 风格查询、复杂告警、长期降采样、可视化生态，Prometheus、VictoriaMetrics、InfluxDB 等专业系统可能更合适。面试回答要避免绝对化：MongoDB 能做时序，但是否适合要看吞吐、查询语言、生态和运维目标。

选型判断：
业务附属指标、中等规模 -> MongoDB Time Series 可评估
核心监控平台、复杂告警 -> 专业时序数据库更自然

七、常见误区与追问

误区：时序数据直接普通集合加时间索引就够了。 小规模可以，大规模下存储组织、过期和聚合成本都要考虑。
误区：metaField 随便放什么都行。 meta 应该是相对稳定、常用于过滤的维度，否则组织效果变差。
误区：MongoDB Time Series 等于专业监控系统。 它是集合能力，不包含完整监控生态和复杂查询体系。
追问：为什么要降采样？ 原始数据增长太快，长期查询通常只需要较粗粒度趋势。
追问：适合存日志吗？ 简单事件日志可以评估，但全文检索、复杂日志分析通常更适合日志/搜索系统。

八、加强记忆

Time Series Collection 记成“按时间装桶的数据集合”。它适合持续追加、按时间范围查、按元数据分组的指标类数据。回答时先讲时序特点，再讲 timeField/metaField，然后用增长速度说明为什么要 TTL 和降采样，最后补上专业时序系统边界，答案就不会空。

简化版

详细版