MongoDB 5.0时序集合怎么用？针对IoT场景优化数据压缩与过期自动清理
时序集合必须显式创建，不能靠 createCollection 自动推断
MongoDB 5.0 带来的时序集合（time-series collection），本质上是对普通集合的一层逻辑封装，而非全新的数据类型。这意味着，它不会在你插入一个带有 timestamp 字段的文档时，就“智能地”自动变身。恰恰相反，你必须通过 createCollection 命令进行显式声明，并明确指定 timeField 和可选的 metaField。
一个常见的误区是，直接执行 db.sensor.insertOne({ts: ISODate(), temp: 23.5})，然后寄希望于后续添加索引就能激活压缩和自动过期（TTL）功能。结果呢？数据底层依然按普通集合存储，完全无法触发时序优化的内部路径。
timeField是关键：它必须是一个Date类型的字段，并且集合内的所有文档都必须包含此字段。实践中，建议统一使用如timestamp或ts这样的命名，避免大小写混用带来的麻烦。metaField是分组依据：这个可选字段用于存放设备ID、传感器类型等元数据。它的价值在于，能让你后续高效地按这些维度进行分组查询，例如快速筛选出{ deviceId: "D1001" }的所有数据。- 一经创建，不可更改：需要特别注意的是，
timeField或metaField在集合创建后便无法修改。同样，也无法将一个现有的普通集合直接转换为时序集合。
来看一个标准的创建命令示例：
db.createCollection("sensors", {
timeseries: {
timeField: "ts",
metaField: "device",
granularity: "minutes"
}
})
granularity 直接影响压缩率与时间范围查询性能
别把 granularity 简单理解为一个精度开关。它的真正作用是告诉 MongoDB：“在同一个物理存储块里，时间戳大致相差多少”。它有三个合法的设定值：seconds、minutes、hours。这个选择至关重要，选错了可能导致压缩失效，或者查询速度变慢。
以典型的IoT场景为例，传感器数据上报间隔通常是秒级或分钟级，极少需要毫秒级别的精确对齐。如果你将 granularity 设为 seconds，而实际数据每30秒才产生一条，MongoDB会强制按秒来切割存储块，结果就是产生大量稀疏的数据块，压缩率不升反降。反之，如果设为 minutes，MongoDB就能将几十条时间相近的数据打包进一个内部的“桶”（bucket）里，显著提升压缩比——实测中，压缩率提高3到5倍并不罕见。
- 选择
minutes：这适用于上报间隔大于等于10秒，且查询经常以1小时或1天为聚合窗口的场景，比如温度、湿度或电表读数监控。 - 慎用
seconds：仅当业务必须支持亚秒级时间窗口的聚合分析，并且能够接受更高的存储开销时，才考虑此选项。 - 核心原则：
granularity并不限制你存入什么样的时间值，它只影响数据在底层的组织方式。你的查询语句写法完全不受其影响。
TTL 索引在时序集合中要建在 metaField + timeField 组合上才真正高效
时序集合确实具备自动过期数据的能力，但这并非由传统的TTL索引直接驱动。你仍然需要手动创建TTL索引，只是策略有所不同：如果只在 timeField 字段上建立 expireAfterSeconds 索引，MongoDB在清理时需要扫描整个时间线，效率较低。而结合 metaField（例如 device）建立复合TTL索引，则可以实现按设备粒度进行分批清理，极大地减轻单次清理操作的系统压力。
这一点在设备数量庞大、数据上报不均衡的IoT环境中尤其重要。想象一下，有些设备可能几天都没有数据，而有些设备每秒都在上报。如果只按时间清理，那些“冷”设备的历史数据会长期滞留；而按“设备+时间”的组合来清理，就能让每个设备的数据独立地按设定策略过期。
- 正确做法：
db.sensors.createIndex({ device: 1, ts: 1 }, { expireAfterSeconds: 2592000 })（此例设置数据保留30天）。 - 错误做法：
db.sensors.createIndex({ ts: 1 }, { expireAfterSeconds: 2592000 })—— 这种方式虽然也能删除数据，但后台清理任务会消耗更多资源。 - 重要提醒：TTL删除是一个异步过程，通常延迟在60秒以内。因此，切勿在程序逻辑中依赖“数据写入后立刻查询不到”这种假设。
聚合查询必须用 $dateTrunc 配合 granularity 才能命中优化路径
时序集合对聚合查询的加速并不是默认开启的“黑魔法”。当你需要按时间窗口进行分组统计时（例如，每5分钟计算一次平均温度），MongoDB只有在 $dateTrunc 操作符中指定的 unit 与创建集合时设定的 granularity 相匹配或更粗时，才会聪明地复用内部已经组织好的bucket结构。否则，查询将退化为逐文档扫描，性能优势荡然无存。
举个例子，如果集合是用 granularity: "minutes" 创建的，那么聚合管道中使用 $dateTrunc: { date: "$ts", unit: "minute" } 或 "hour" 都能走上优化快车道。但如果你使用 "second" 作为单位，即使你只是想看个大致趋势，也无法享受优化。
- 避免使用替代方案：不要试图用
$bucket或$facet等操作符来模拟时间窗口聚合，它们会完全绕过时序集合的优化机制。 - 字段必须匹配：
$dateTrunc必须直接作用于创建时指定的timeField字段（即例子中的ts），而不能是某个计算后的派生字段。 - 非对齐窗口的处理：如果你的业务需求是非标准的时间窗口（例如“从每天06:00开始计算的每小时”），时序集合的优化将不适用。这种情况下，更稳妥的方案是继续使用普通集合并配合适当的索引。
一个典型的高效聚合查询写法如下：
db.sensors.aggregate([
{ $match: { ts: { $gte: ISODate("2024-01-01") } } },
{ $group: {
_id: { $dateTrunc: { date: "$ts", unit: "hour" } },
a vgTemp: { $a vg: "$temp" }
}
}
])
说到底，时序集合的压缩和自动过期功能，并非一个“开启即省心”的按钮。它将相当一部分责任前移到了数据建模阶段：字段的命名、granularity 的选择、索引结构的搭建、聚合查询的写法……这其中任何一个环节没有对齐，整个方案就会退回普通集合的表现水平。IoT数据看似结构简单，但其海量、持续写入、模式固定的特点，恰恰最需要这些技术细节的精密咬合。
