MongoDB：长期添加大量子记录引发OpLog问题及优化咨询

我们有一款应用，用于存储车辆的父记录及采集到的遥测信息，遥测信息约每秒上报一次，目前将其作为子文档添加至父记录中。

示例文档（含两条遥测记录，实际字段更多） #

{
    "_id" : ObjectId("654d76b8667a5972b20f06d9"),
    "deviceIdentifier" : "TEST1",
    "pathId" : NumberInt(300887),
    "createdAt" : ISODate("2023-11-10T00:17:59.310+0000"),
    "path" : [
        {
          "eventTime" : "2022-02-11T06:00:11.000Z",
          "timestamp" : "2022-02-11T06:00:11.000Z",
          "speed" : NumberInt(50),
          "lat" : -43.8678108049212,
          "lng" : 172.552684388425
        },
        {
          "eventTime" : "2022-02-11T06:00:12.000Z",
          "timestamp" : "2022-02-11T06:00:12.000Z",
          "speed" : NumberInt(50),
          "lat" : -43.8679108049212,
          "lng" : 172.552784388425
        }
    ],
    "updatedAt" : ISODate("2023-11-10T00:17:59.310+0000")
}

当前更新代码 #

await VehiclePathConnection.findOneAndUpdate(
   { pathId, deviceIdentifier },
   {
      ...pathAggregateMeta,
      $push: { path: { $each: points, $sort: { timestamp: 1 } } },
   },
   { upsert: true }
);

我们使用Mongo Atlas三节点集群，接收数据后出现OpLog GB/Hr指标大幅飙升的问题，最终导致Mongo无响应甚至崩溃，推测是单文档持续扩容后同步至各节点引发的。现咨询：在Mongo中存储此类数据的最佳方案是什么？是否不应将遥测数据存储在父记录内？或是有更优的更新方式？单辆车的遥测数据就引发该问题，说明当前方案存在根本性错误。

1. 拆分集合存储（核心最优方案） #

当前嵌入式子文档方案的根本性问题是：每次$push更新都会修改整个父文档，MongoDB需要将完整的新版本文档同步到所有集群节点。随着遥测数据持续积累，单文档体积会不断膨胀（甚至可能触及MongoDB 16MB的单文档大小上限），每次更新生成的OpLog条目也会越来越大，直接导致OpLog暴涨、集群同步压力过载，最终引发崩溃。

正确的做法是将数据拆分为两个独立集合：

• 车辆元数据集合（如vehicle_metadata）：存储deviceIdentifier、pathId、createdAt等静态/低频更新的字段，每个车辆对应一条记录。
• 遥测数据集合（如telemetry_data）：每条记录对应一条遥测上报数据，包含deviceIdentifier、pathId、eventTime、timestamp、speed、lat、lng等字段，同时创建{deviceIdentifier:1, pathId:1, timestamp:1}复合索引，满足按车辆+路径查询历史数据的需求。

示例遥测记录：

{
    "deviceIdentifier": "TEST1",
    "pathId": NumberInt(300887),
    "eventTime": "2022-02-11T06:00:11.000Z",
    "timestamp": "2022-02-11T06:00:11.000Z",
    "speed": NumberInt(50),
    "lat": -43.8678108049212,
    "lng": 172.552684388425
}

遥测数据插入代码改为批量插入：

// 批量插入遥测点数据
await TelemetryDataConnection.insertMany(points);

该方案的优势：

• 每条遥测记录独立，插入/更新仅产生极小的OpLog条目，大幅降低集群同步压力；
• 彻底避免单文档体积膨胀问题，无16MB大小限制；
• 借助复合索引，查询单辆车历史遥测数据的性能优于从大文档数组中检索。

2. 嵌入式方案临时优化（仅过渡使用，不推荐长期依赖） #

若因业务限制必须保留嵌入式结构，可做以下优化缓解问题，但无法从根本解决：

• 取消$push时的$sort操作：写入时排序会增加CPU开销和文档更新复杂度，可改为查询时排序；
• 增大批量插入的批次大小：减少findOneAndUpdate的调用频率，降低OpLog生成次数；
• 预分配文档空间：初始插入带占位符的空数组，减少文档频繁扩容产生的存储碎片，但无法解决长期增长问题。

3. 额外优化建议 #

• 针对遥测数据集合，根据实际查询模式调整索引，确保插入和查询性能平衡；
• 若遥测数据有过期需求，开启TTL索引自动清理历史数据，降低存储压力；
• 始终优先使用insertMany批量插入遥测数据，提升写入效率并减少OpLog条目数量。

内容的提问来源于stack exchange，提问作者Matthew van Boheemen