不能直接升级分桶集合为timeseries集合，必须重建集合+迁移数据+切换读写路径；因二者底层结构不同，renamecollection和converttocapped均无效，且timeseries仅接受扁平化单点文档、强制校验timefield等字段。
不能直接“升级”分桶集合为timeseries集合，必须重建集合 + 迁移数据 + 切换读写路径。 MongoDB 不提供 convertToTimeSeries 这类命令，也没有就地改造的机制。所谓“平滑”，关键在于如何让业务在新旧集合并存期间不中断、不丢数据、不查错。
为什么不能用 renameCollection 或 db.collection.convertToCapped？
原生 timeseries 集合和普通集合底层结构完全不同：前者是引擎级优化的桶文档（bucket document）自动管理，后者是你手动控制的任意文档结构。尝试对已有分桶集合执行 renameCollection 只是改个名，不会触发时序特性；而 convertToCapped 仅适用于普通集合转 capped，与 timeseries 无关，强行调用会报 CommandNotSupportedOnTimeSeries 或直接失败。
- timeseries 集合创建后，MongoDB 会强制校验字段名（如必须含
timeField）、时间戳类型（必须是Date或Timestamp）、且不允许自定义_id生成逻辑 - 你原来的分桶文档里可能有
"measurements": [ {...}, {...} ]数组，这种结构 timeseries 集合根本不识别——它只接受扁平化单点格式，例如每条传感器上报就是独立文档 - 索引策略也得重设：
timeseries自动建{ timeField: 1 }和{ metaField: 1, timeField: 1 }复合索引，你原来的手动分桶索引（比如{"deviceId": 1, "bucketStart": 1}）完全失效
迁移前必须做的三件事：字段对齐、时间字段标准化、meta 字段提取
你的分桶文档大概长这样：
{ "_id": ObjectId("..."),
"deviceId": "dev-001",
"bucketStart": ISODate("2024-01-01T00:00:00Z"),
"measurements": [
{ "ts": ISODate("2024-01-01T00:00:12Z"), "temp": 23.1, "humi": 65 },
{ "ts": ISODate("2024-01-01T00:00:27Z"), "temp": 23.2, "humi": 64 }
]
}
要迁入 timeseries 集合，得先把它“摊平”成单点文档流。这一步必须做：
- 确认所有原始时间字段（比如
ts）是合法Date类型，不是字符串或数字时间戳；否则聚合管道会跳过或报$dateFromString错误 - 把
deviceId这类设备标识统一抽成metaField（创建集合时指定），不能再混在measurements数组里 - 检查是否有重复时间戳 + meta 组合——timeseries 集合不禁止重复，但后续按
metaField + timeField建唯一索引防重时会失败
用聚合管道 + $merge 实现零停机双写过渡
别一次性 dump & restore。真实场景下，你要让应用继续往老分桶集合写，同时把新增数据实时“翻译”进新 timeseries 集合。核心是用 aggregate + $unwind + $replaceRoot 摊平，再用 $merge 写入目标：
db.old_bucket_collection.aggregate([
{ $match: { "bucketStart": { $gte: ISODate("2024-01-01") } } },
{ $unwind: "$measurements" },
{ $replaceRoot: { newRoot: {
"timestamp": "$measurements.ts",
"deviceId": "$deviceId",
"temperature": "$measurements.temp",
"humidity": "$measurements.humi"
}
}},
{ $merge: {
into: "sensor_readings_ts",
on: ["deviceId", "timestamp"],
whenMatched: "keepExisting",
whenNotMatched: "insert"
}
}
])
-
$merge的on字段必须是目标 timeseries 集合的metaField和timeField，否则会报Cannot merge on non-existent field - 如果老集合还在持续写入，这个聚合需封装成定时任务（比如每分钟跑一次），或监听 oplog 增量触发，避免漏数据
- 切记：
whenMatched: "keepExisting"是安全兜底，防止重放时覆盖已写入的正确数据；真正去重靠你在sensor_readings_ts上建的唯一索引：db.sensor_readings_ts.createIndex({"deviceId": 1, "timestamp": 1}, {unique: true})
切换读写时最容易被忽略的两个点
很多团队卡在最后一步：明明数据全了，查询却变慢或结果不对。问题往往出在这两处：
- 应用代码里还留着对老集合的
find({ bucketStart: { $gte: ... } })查询，这种范围查询在 timeseries 集合上必须改写为find({ timestamp: { $gte: ..., $lt: ... } })，且要确保timestamp字段上有索引（timeseries 自带，但如果你删过重建过，得手动确认） - 聚合管道中用了
$group+$sum统计每分钟均值？那得换成$dateTrunc窗口函数：{ $dateTrunc: { date: "$timestamp", unit: "minute" } }—— 这是 timeseries 原生优化点，传统集合没这能力
真正的平滑，不在工具多炫酷，而在你是否愿意花半天时间 audit 所有涉及该数据源的查询语句和写入逻辑。哪怕只漏一个 updateOne 调用没切过去，都会导致元数据和时序数据错位。
