MongoDB 存储引擎选择指南
一、可选引擎与定位
- WiredTiger：自 MongoDB 3.2 起的默认引擎，提供文档级并发、MVCC 快照与检查点、WAL 日志、压缩与多核扩展，覆盖绝大多数在线业务场景。
- In-Memory（企业版）：数据主要驻留在内存，极大降低访问延迟，适用于低延迟与缓存层场景，需评估内存容量与数据持久化诉求。
- MMAPv1：早期引擎，已在 MongoDB 4.2 移除，新项目不应再使用。
- 云托管方面，MongoDB Atlas 统一使用 WiredTiger。
以上定位与适用范围以官方文档为准。
二、快速决策表
| 场景诉求 |
首选引擎 |
关键理由 |
注意事项 |
| 通用在线业务、需要事务与压缩 |
WiredTiger |
文档级并发、MVCC、检查点+WAL、默认压缩，生态与工具链成熟 |
合理规划内存与压缩策略 |
| 超低延迟、容忍数据不落盘或可接受企业许可 |
In-Memory（企业版） |
避免磁盘 I/O，显著降低延迟 |
成本高、容量受限、需评估持久化与高可用设计 |
| 历史版本维护（≤4.0） |
WiredTiger（不建议 MMAPv1） |
4.0 起 MMAPv1 已弃用，4.2 起已移除 |
尽快迁移至 WiredTiger |
| 云上托管 |
WiredTiger |
Atlas 全托管统一使用 |
无需自管引擎选择 |
上述结论基于官方特性与版本变更说明。
三、选择时的关键考量
- 版本与兼容性：新版本默认与长期支持方向均为 WiredTiger；MMAPv1 已在 4.2 移除，不建议新项目采用。
- 并发与一致性：WiredTiger 提供文档级并发与乐观并发控制，在冲突时由 MongoDB 透明重试；适合高并发写入不同文档的场景。
- 持久化与恢复：WiredTiger 通过检查点（默认每 60 秒）与WAL 日志保障持久性与快速恢复。
- 内存与缓存：WiredTiger 内部缓存默认取 max((RAM-1GB)×50%, 256MB)；同时配合操作系统文件系统缓存提升 I/O 效率。
- 压缩与 CPU 权衡：集合默认 Snappy 块压缩、索引默认前缀压缩；时间序列集合默认 zstd。压缩节省存储但增加 CPU 开销，可按负载选择。
- 许可与成本：In-Memory 为企业版特性，需评估许可成本与容量规划。
四、WiredTiger 关键配置要点（按常见诉求）
- 缓存大小：默认 cacheSizeGB = max((RAM-1GB)×50%, 256MB)；通常无需超过默认值，避免挤占操作系统缓存与引发换页。容器环境应以容器的内存限制为基准计算。
- 压缩策略：集合用 storage.wiredTiger.collectionConfig.blockCompressor（如 snappy/zlib/zstd），索引前缀压缩用 storage.wiredTiger.indexConfig.prefixCompression；WAL 日志压缩用 storage.wiredTiger.engineConfig.journalCompressor（默认 snappy）。
- 检查点与日志：检查点默认 60 秒；WAL 保障崩溃恢复，日志默认 snappy 压缩。
- 时间序列数据：默认使用 zstd 块压缩，更利于高压缩比与顺序 I/O 场景。
示例（YAML 配置片段）：
storage:
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 4
journalCompressor: snappy
collectionConfig:
blockCompressor: zstd
indexConfig:
prefixCompression: true
以上参数与默认值以官方文档为准。
五、迁移与落地建议
- 新部署：直接使用 WiredTiger（默认），按数据热度与 CPU 预算调优压缩与缓存，并开启WAL。
- 从旧版本升级：优先升级到包含 WiredTiger 的版本并完成迁移；历史 MMAPv1 部署应规划迁移路径，避免停留在已移除或弃用引擎上。
- 云上场景：选择 MongoDB Atlas 即可获得稳定的 WiredTiger 引擎与运维保障。
