回顾：使用 MongoDB 7.0 进行 AI/ML 流水线的 6 个月经验 – 文档存储提升 30%

Source: Dev.to

引言

当我们在 2023 年第四季度着手现代化我们的 AI/ML 流水线时，需要一个文档存储能够处理高吞吐量的训练数据写入、低延迟的模型制品存储，并且能够无缝集成到我们现有的基于 Python 的机器学习栈中。经过对 Cassandra、PostgreSQL 和 MongoDB 7.0 的评估后，我们选择了 MongoDB 7.0，原因是它原生支持向量搜索、灵活的模式设计以及在非结构化机器学习工作负载上的可验证可扩展性。六个月后，我们分享我们的成果：文档存储速度提升了 30 %，运维开销降低， 并为运行类似工作负载的团队提供了关键经验教训。

MongoDB 7.0 在机器学习流水线中的关键特性

• Atlas Vector Search – 原生支持向量嵌入，免除使用单独向量数据库的需求。
• Improved Time‑Series Collections – 为高吞吐量的训练指标、推理日志和流水线遥测的快速写入进行优化，具备自动压缩和 TTL 支持。
• Enhanced Aggregation Pipeline – 新增 $vectorSearch 和 $densify 操作符，使在数据库内直接对训练数据进行预处理更为简便，降低数据搬迁。
• Sharding Improvements – 更佳的弹性扩展；我们的训练数据集在六个月内从 12 TB 增长至 41 TB，且分片重新平衡期间无停机。

性能测量

我们在三个核心流水线阶段测量了存储性能：

1. 原始训练数据摄取
2. 模型制品写入（检查点、权重、元数据）
3. 推理结果日志记录

所有基准测试使用相同的工作负载配置：每分钟 1.2 M 文档写入，平均文档大小 4.7 KB，且在我们的生产集群中进行 3× 复制。

与 MongoDB 6.0 的对比结果

我们使用 MongoDB 内置的 Performance Advisor 以及自定义的 Prometheus/Grafana 仪表盘（用于跟踪写入延迟、吞吐量和错误率）验证了这些结果。未观察到训练数据访问的读取性能回退；95 百分位读取延迟保持在 6 ms 稳定。

配置与模式调整

用于机器学习工作负载的模式设计

• 将大型训练元数据对象从嵌入改为在单独的集合中引用，以减小高吞吐写入路径的文档大小。
• 仅对大于 16 MB 的文件使用 GridFS；较小的检查点存储为 BSON 文档，以避免 GridFS 开销。

索引策略

• 避免对写入密集型集合进行过度索引，依赖 MongoDB 7.0 对时序数据改进的默认索引。
• 使用 HNSW 算法创建 1024 维嵌入索引，调优至 90 % 召回率，以平衡查询速度和准确性。

运营调优

• 为写入密集型集合启用新的存储引擎缓存优先级。
• 在非高峰时段设置自动分片键重新平衡，以免影响管道吞吐量。
• 将我们的 Python ML 工作进程迁移到 MongoDB 7.0 的新连接池默认设置，将连接开销降低约 15 %。

未奏效的尝试

• 曾尝试使用 Change Streams 在新数据到达时触发模型再训练，但其增加的延迟和开销超过了对高吞吐管道的收益。我们改为使用批处理触发再训练。

Outcomes & Recommendations

在六个月的生产使用后，MongoDB 7.0 已成为我们 AI/ML 堆栈的核心组件。30 % 更快的文档存储，结合原生向量搜索和改进的可扩展性，使我们的流水线运行时间缩短了 22 %，运营成本降低了 18 %。对于运行类似非结构化机器学习工作负载的团队，我们强烈建议评估 MongoDB 7.0——尤其是如果您已经在使用或考虑使用向量搜索来存储嵌入。

下一步

• 将剩余的传统 PostgreSQL 训练元数据存储迁移到 MongoDB 7.0。
• 评估 MongoDB 7.0.1 小版本，以获取向量搜索工作负载的额外性能提升。
• 在六个月后发布后续更新，报告这些迁移的结果。