MongoDB每周全量集合替换适用设计模式选型咨询

你说的每次全量写入新集合再切换API使用的方案完全可行，这是MongoDB全量数据集替换场景下非常成熟的蓝绿发布模式，比逐行做增删改的稳定性、回滚成本低很多，完全适配你不想做增量处理的需求。操作步骤也很简单：

1. 先将本周的全量数据集完整写入新集合，写入、校验阶段完全不影响线上业务查询
2. 校验新集合数据无误后，通知API侧切换查询的集合名即可
3. 旧集合可以保留1~2个更新周期作为回滚备份，确认新集合无问题后再删除即可

• 你提到的phones_YYYYMMDD格式的命名规则完全可用，规则简单直观，适合固定周期更新的场景，API侧只需要在每次切换时更新对应集合名配置即可。
• 如果你想要实现API侧无感知切换、不用每次都改API配置的，可以额外增加一个固定名称的视图作为入口：比如创建一个名为phones_current的视图，永远指向当前生效的数据集集合。每次新集合校验通过后，只需要删除旧视图，重新创建phones_current视图指向新集合即可，API侧永远查询phones_current，完全不需要做任何改动，示例操作命令如下：

  // 新集合校验通过后，执行切换视图命令
  db.phones_current.drop()
  db.createView("phones_current", "phones_20240520", [])
  

针对你提到的仅需新增缺失记录、删除失效记录的需求，MongoDB不需要用MapReduce（当前官方更推荐性能更强、易用性更高的聚合管道框架），完全可以实现你之前在Oracle下的关联查询逻辑：

• 首先将新的全量数据集写入临时集合phones_staging
• 查询需要新增的记录：通过聚合管道的$lookup关联当前生效集合，匹配不到的即为需要新增的手机号记录，批量插入即可
• 查询需要删除的记录：反过来用当前生效集合关联临时集合phones_staging，匹配不到的即为需要删除的失效手机号记录，批量删除即可
• 如果你没有数据量过大导致全量写入成本过高的问题的话，还是更推荐你最开始想的全量替换集合的方案，逻辑最简单，出问题的概率最低，回滚也最快。

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