MongoDB 5.0 无原生流式插入API,所谓流式插入实为应用层基于 insertMany 和 BulkWrite 的封装;需控制批次大小(推荐100起)、设 ordered: false 保障连续性,并避免在事务中使用或调用已弃用的 insert() 方法。
MongoDB 5.0 本身不提供“流式插入”原语(比如像 insertStream 这样的 API),所谓“流式插入”实际是应用层基于批量写入机制 + 网络/内存缓冲做的模式封装,核心依赖的是 insertMany 和底层 BulkWrite 能力。
insertMany 模拟流式写入,但必须控制批次大小直接把数万条文档塞进一个 insertMany 调用里,很容易触发 BSON 大小限制(16MB)或内存溢出。实际中应按固定 batch size(如 100–500 条)切分:
insertMany 单次最多支持约 1000 条(取决于单文档平均体积),超过会报 errmsg: "BSON object too large"
ordered: false 是流式场景的刚需配置流式数据常含脏数据(如重复 _id、类型冲突),若用默认 ordered: true,一条失败整批中断,后续数据全积压——这违背“流”的连续性原则。
务必显式传参:
db.collection.insertMany(docs, { ordered: false })
ordered: false 下失败项被跳过,其余继续执行,返回结果里 writeErrors 字段列出具体失败项_id 冲突仍报错,但不影响其他文档)ordered: false,MongoDB 5.0 不允许db.collection.insert()
mongosh 1.8+(MongoDB 5.0 默认配套)中 db.collection.insert() 已标记为 deprecated,且行为不一致:
ordered 参数,也无法兼容现代驱动的 writeConcern 行为insertMany 后,错误对象结构统一,便于日志解析和重试逻辑编写MongoDB 5.0 的复制集 oplog 和 changeStream 是“流式消费”,不是“流式插入”。插入动作始终是离散的 RPC 请求。
如果真需要持续低延迟写入,关键点不在数据库命令,而在:
bulkWrite 实例(避免反复创建 write model 对象)stream.pipeline 或 Java 的 Flow.Subscriber 控制上游吐速)漏掉任何一环,都可能让“流式插入”变成内存泄漏或连接打满。