MongoDB WiredTiger磁盘存储与更新机制技术咨询

问题1：MongoDB是否会将BSON拆分为单元格并进行更新/版本控制？ #

不会。MongoDB从设计上就保持BSON文档的完整性，不会像Cassandra/HBase那样将数据拆分为单元格粒度。所有增删改操作都是以BSON文档为基本单元进行的，版本控制也是针对整个文档，而非文档内的单个字段或单元格。

问题2：若不拆分，内存中的memtable（平衡搜索树）如何更新BSON文件？BSON文件是否为可变文件？ #

WiredTiger的LSM树实现中，磁盘上的文件是不可变的，这点和Cassandra/HBase一致。内存中的memtable是可写的平衡树结构，当它达到配置的阈值（大小或时间）时，会被刷写到磁盘成为不可变的SSTable文件。

更新操作不会直接修改已有的磁盘文件，而是将新的文档版本写入当前活跃的memtable，或者后续新生成的SSTable中。旧的文档版本会在后台的**压缩（compaction）**过程中被清理掉，避免无效数据占用磁盘空间。

问题3：总体而言，MongoDB WiredTiger如何执行更新操作？磁盘文件是可变还是不可变？以及多索引类型下的索引管理机制是怎样的？ #

更新操作流程

1. 接收更新请求后，先将新的文档版本写入内存中的memtable，同时写入预写日志（WAL），确保即使服务器重启也不会丢失数据。
2. 当memtable达到阈值时，会被后台线程刷写到磁盘，成为只读的SSTable文件。
3. 查询时，WiredTiger会合并memtable和所有相关SSTable中的数据，返回最新版本的文档。
4. 后台定期执行compaction操作，合并多个SSTable，删除旧的文档版本，生成更大的、更高效的SSTable文件。

磁盘文件属性

所有磁盘上的存储文件（SSTable）都是不可变的，只有内存中的memtable是可写结构，一旦刷盘就会转为只读。

多索引类型的索引管理

不同类型的索引（单键、复合、文本、地理空间等）都拥有独立的LSM树结构：

• 每个索引对应一套自己的memtable和SSTable集合，与数据的存储结构相互独立。
• 当文档更新时，会同步更新所有关联的索引：在对应索引的memtable中写入新的索引条目，旧的索引条目同样会在compaction阶段被清理。
• 索引的compaction操作与数据的compaction是独立调度的，但WiredTiger会优化资源使用，避免两者同时占用过多系统资源。

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