含频繁增长数组的MongoDB文档高效设计及性能问题咨询

• WiredTiger不存在MMAPv1时代的「全文档磁盘移动」问题：WiredTiger采用写时复制（COW）的页式存储机制，修改文档时不会原地覆盖旧数据，只会将修改后的内存页写入新的磁盘块，旧块会在后续检查点（checkpoint）时回收，和旧版MMAPv1因文档超过预分配空间导致的全文档移动逻辑完全不同。
• 频繁追加数组仍然会产生持续IO开销：虽然没有全文档移动，但每次$push追加数组的操作都会触发WAL日志写入、对应数据页的重写、元数据更新三类IO操作。你当前场景每2秒更新1次，全天累计4万+次更新，每次更新涉及6个数组的修改，即使单次IO量很小，累积的持续IO负载也会触发Atlas节点的性能阈值，甚至导致主节点重启，和你观察到的现象完全吻合。
• 2的幂次分配确实会减少重分配次数：WiredTiger默认按64KB为单位分配数据页，单文档大小增长时仅当超出当前占用的所有页总容量时才会申请新页，你的单日单文档最终大小约2MB左右，全生命周期仅需要申请30余次新页，重分配开销本身极低，当前的高IOPS并非来自页重分配，而是来自频繁更新本身的写放大。

以下方案按改造成本从低到高排序，均不影响原始数据的访问能力：

• 小粒度分桶优化：将现有按天存储的单文档拆分为按小时/15分钟分桶，单文档仅存储1小时/15分钟的采集数据，单文档大小上限从2MB降低到128KB以内，单文档更新次数从4万次降低到1800次（按1小时分桶），可直接降低70%以上的持续写IO开销，不需要修改业务读写逻辑，仅需要调整分桶粒度的判断逻辑。
• 文档结构调整：将拆分的6个平行数组改为单条采集对象数组，结构参考如下：

{
  "_id": "string",
  "tracker": "string",
  "startTime": Date,
  "endTime": Date,
  "readings": [
    {
      "time": Date,
      "sensor1": 1.0,
      "sensor2": 2.0,
      "coordinate": [116.4, 39.9]
    }
  ]
}

每次更新仅需要向readings数组追加1个对象，不需要同时修改6个数组，单次更新的IO量直接降低60%，同时不需要跨数组对齐索引即可获取单次采集的全量数据，查询原始数据的效率也更高。

• 原生时间序列集合：如果你的MongoDB版本≥5.0，可直接改用官方原生的时间序列集合，专门针对IoT高频率写入场景做了底层优化，自动做时间分桶、列式存储压缩，写入性能比普通集合高30%~50%，查询原始数据的语法和普通集合完全兼容，不需要修改上层业务逻辑。
• 预分配固定大小文档：如果必须保留现有文档结构，可在创建单日文档时，预先用占位符将所有数组填充到接近单日最大长度，后续更新用$set按索引位修改对应位置的数据，而非$push追加，文档大小从创建时就固定，完全消除后续页分配的开销，写入性能可提升40%以上。

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