MongoDB超大集合更新速度过慢问题排查求助

• 代码逻辑存在严重效率缺陷
  首先脚本使用readlines()将14亿条文本数据一次性全部加载到Python进程内存，会占用数十GB甚至上百GB内存，触发系统swap交换后，所有磁盘操作性能都会大幅下降。其次脚本采用单条查询+单条更新的模式，14亿次请求会产生极高的网络往返开销（即使是本地SSH隧道也存在明显开销），且每次查询后将全部结果拉取到本地做去重，额外增加了数据传输和本地计算成本。另外频繁的print输出也会产生不必要的IO开销，拖慢执行速度。
• 索引缺失导致查询性能指数级下降
  若annotations_inchi集合的pn字段、contents集合的publication_number字段没有建立索引，每次查询都会触发全集合扫描。初始执行时热数据在系统缓存中速度较快，随着查询范围扩大，缓存命中率持续降低，每次查询都需要读取磁盘，速度会出现断崖式下跌，这是运行时间越长速度越慢的核心原因之一。
• 存储引擎与文件系统适配问题
  MongoDB默认的WiredTiger存储引擎对XFS文件系统做了专项优化，ext4在大量随机写入场景下日志开销更高、文件碎片化速度更快，运行时间越长磁盘写入性能衰减越明显。同时随着缓存的不断淘汰，冷数据查询需要频繁读写磁盘，进一步放大了文件系统的性能短板。
• 单线程架构无法利用硬件资源
  整个脚本为单线程串行执行，无法利用服务器的多核CPU资源，磁盘IO、网络带宽都无法被充分利用，硬件性能被严重浪费。

• 调整文本读取逻辑：将一次性全量读取改为逐行迭代读取，或者按批次分片读取，避免Python进程占用过多内存触发swap。
• 补建必要索引：执行以下命令为查询字段建立索引，可将查询性能提升至少两个数量级：

  // 为annotations_inchi集合的pn字段建索引
  db.annotations_inchi.createIndex({pn: 1})
  // 为contents集合的publication_number字段建索引
  db.contents.createIndex({publication_number: 1})
  

• 优化数据库操作逻辑：用MongoDB的聚合能力直接在数据库层完成分组去重，将单条操作改为批量操作，每1000~5000条数据作为一个批次，用$in批量查询、bulk_write批量更新，大幅降低请求开销。
• 改用并发处理：将脚本改为多进程/多线程模式，控制合理的并发数（建议初始设置为8~16），充分利用服务器硬件资源。
• 减少不必要的IO操作：关闭逐条打印逻辑，改为每处理10000条数据打印一次进度即可。
• 长期优化：后续将文件系统更换为XFS，可提升20%以上的读写性能，同时降低长期运行的性能衰减速度。

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