如何在MongoDB中高效存储数十亿级数据并仅保留最新版本文档

最优方案：带过滤条件的原子upsert #

这是性能最高的实现方式，全程为数据库端单原子操作，不需要业务侧做任何查询判断，完全避免了并发冲突和多轮网络IO开销。

实现步骤 #

• 首先给unique id字段创建唯一索引，如果是分片集群，直接把unique id设为分片键，能最大化路由效率，避免跨分片查询。
• 直接用updateOne配合upsert: true和时间过滤条件即可实现所有规则，语法示例：

db.yourCollection.updateOne(
  // 匹配条件：仅匹配unique id相等、且已有文档的document time小于新文档时间的记录
  { 
    unique_id: 新文档的唯一id,
    document_time: { $lt: 新文档的时间戳 }
  },
  // 更新内容：直接替换为完整新文档
  {
    $set: 新文档完整内容
  },
  // 开启upsert，匹配不到对应记录时自动插入
  { upsert: true }
)

逻辑说明 #

• 若对应unique id不存在：匹配条件找不到记录，触发upsert直接插入新文档，符合规则1。
• 若对应unique id已存在：
  • 新文档时间晚于已存储时间：匹配条件命中，执行更新替换为新文档，符合规则2的更新逻辑。
  • 新文档时间早于或等于已存储时间：匹配条件不命中，无任何操作执行，自动忽略新文档，完全符合要求。

数十亿级数据量的配套优化建议 #

• 分片设计：直接用unique id作为分片键，所有upsert请求都可以直接路由到对应分片，不需要跨节点协调，性能损失极小。如果业务查询经常按时间范围扫描，也可以用unique id + document time的复合分片键，注意避免写入热点即可。
• 索引优化：不需要额外创建其他索引，唯一索引已经完全覆盖了upsert的匹配条件，查询效率为O(1)。如果使用MongoDB 4.4及以上版本，可以开启索引前缀压缩，数十亿条索引的存储空间占用能降低30%以上。
• 批量写入优化：如果是批量导入数据，用bulkWrite批量提交upsert请求，每次提交1000-5000条的批次，比单条提交吞吐量高5-10倍，语法示例：

db.yourCollection.bulkWrite(
  新文档列表.map(doc => ({
    updateOne: {
      filter: { unique_id: doc.unique_id, document_time: { $lt: doc.document_time } },
      update: { $set: doc },
      upsert: true
    }
  }))
)

• 写入级别调整：如果对数据一致性要求不是极端高，可以把写入关注设为w:1，不需要等待从节点同步，写入性能能再提升一倍左右，可根据业务场景权衡调整。

性能对比说明 #

业务端先查再改的方式需要至少两次网络IO（一次查询、一次写入），高并发下还会存在ABA问题、查询加锁的开销，十亿级数据量下查询本身的延迟也很高。而原子upsert所有逻辑都在存储节点本地执行，仅单次网络IO、无锁开销，性能至少高出一个数量级。

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