MongoDB 整体架构:mongod 自己不管数据怎么存

先看两层:mongod 和存储引擎

这条边界是理解 MongoDB 后面所有机制(索引、聚合、复制)的前提。

真实实验:确认本机跑的就是 WiredTiger

本机装的是 MongoDB Community 8.3.7,直接问它自己在用哪个存储引擎。

$ mongosh --quiet --eval "db.serverStatus().storageEngine"

devnull 是个只用于测试的"黑洞"引擎(写入直接丢弃),真正干活的只有 wiredTiger 一个——这份列表本身就是"存储引擎可插拔"这句话最直接的证据:mongod 在启动时看配置决定加载哪一个,不是编译期写死成某一个具体实现。

真实源码:存储引擎是怎么"插"进去的

每个存储引擎实现向全局注册一个 Factory,mongod 启动时按配置参数选一个来用。

src/mongo/db/storage/storage_engine.h · mongodb/mongo @ r8.3.7, L106 /** * The interface for creating new instances of storage engines. * * A storage engine provides an instance of this class (along with an associated * name) to the global environment, which then sets the global storage engine * according to the provided configuration parameter. */ class Factory { public: virtual ~Factory() {} virtual std::unique_ptr<StorageEngine> create(OperationContext* opCtx, const StorageGlobalParams& params, ...) = 0; };

这段注释把设计意图写得很直白:存储引擎"提供一个 Factory 实例给全局环境",然后 mongod 根据配置参数(也就是 --storageEngine 或配置文件里的 storage.engine)决定实际用哪一个。WiredTiger 只是众多可能实现里,现在被设为默认的那一个。

真实源码 + 真实文件:一个 collection 对应一棵独立的 B-tree

RecordStore 是 mongod 和存储引擎之间关于"怎么存文档"的抽象接口——一个 collection 一个 RecordStore,每个 index 也各自有自己的存储结构。

src/mongo/db/storage/record_store.h · mongodb/mongo @ r8.3.7, L296 /** * An abstraction used for storing documents in a collection or entries in an index. * * In storage engines implementing the KVEngine, record stores are also used for implementing * catalogs. * ... */ class MONGO_MOD_OPEN RecordStore { public: class Capped; class Oplog; ... };

光看源码还是抽象,直接去磁盘上验证。本机建一个 orders collection,插入几条文档,再建一个索引:

$ mongosh --quiet blogdemo --eval '
  db.orders.insertMany([
    { _id: 1, item: "pen", qty: 10, tags: ["office"] },
    { _id: 2, item: "laptop", qty: 1, specs: { cpu: "M4", ram: 16 } },
    { _id: 3, item: "paper", qty: 500 }
  ]);
  db.orders.createIndex({ item: 1 });
'

一个 collection、两个 index,磁盘上是三个完全独立的 .wt 文件——这不是巧合或者实现细节,是 RecordStore(用于 collection)和索引各自独立存储这个设计的直接物理体现。_mdb_catalog.wt 存的是"orders 这个名字对应哪个 UUID、进而对应哪个物理文件"这层映射,这也是为什么你在 mongosh 里操作的是名字,底层文件名却是一串 UUID。

真实源码:写一条文档,collection 和 index 谁先谁后

插入一条文档时,先写 collection 拿到一个 RecordId,再拿这个 RecordId 去建索引条目——顺序不能反,因为索引条目本身存的就是"指向哪条记录"。

src/mongo/db/collection_crud/collection_write_path.cpp · mongodb/mongo @ r8.3.7, L325 Status status = collection->getRecordStore()->insertRecords( opCtx, *shard_role_details::getRecoveryUnit(opCtx), &records, timestamps);

src/mongo/db/collection_crud/collection_write_path.cpp · mongodb/mongo @ r8.3.7, L378 collection->getIndexCatalog()->indexRecords(opCtx, collection, bsonRecords, &keysInserted);

L325 先把文档写进 collection 自己的 RecordStore,拿到一个 RecordId(标识这条记录在这个 B-tree 里的物理位置);L378 才拿着这批 RecordId 去更新每一个索引——每条索引条目本质是"索引字段的值 → RecordId"这样一对键值,没有 RecordId 就没法建索引条目,顺序天然是先 collection 后 index。

真实实验:文档模型是真的没有固定 schema

上面插入的三条文档,字段结构完全不一样,MongoDB 不会因此报错。

$ mongosh --quiet blogdemo --eval "db.orders.find().toArray()"

第一条有 tags 数组,第二条有嵌套的 specs 对象,第三条两个都没有——同一个 collection,三种不同的文档形状,插入时没有任何 schema 校验拦截。这是 BSON 文档模型的直接后果:collection 只是"一堆文档的集合",不是关系型数据库里"一张有固定列的表"。

演示:一条 insert 命令,分层往下走

按上面两段真实源码验证过的先后顺序,把 db.orders.insertOne(...) 拆成分层的步骤。

事件数据由 Python 脚本生成并自检过:索引写入严格晚于 collection 写入、且必须引用同一个 RecordId(对应上面 L325/L378 的真实顺序);journal 落盘晚于所有存储层写入。一套独立重写的重放函数核对过全部结果,断言通过后才用于渲染。