Ubuntu 上 MongoDB 存储引擎选择建议
快速结论
- 新部署在 Ubuntu 上的 MongoDB 一律优先选择 WiredTiger，它是自 MongoDB 3.2 起的默认引擎，提供文档级并发、压缩与检查点+WAL的稳健持久化机制，适配高并发 OLTP 与通用业务场景。对于 MongoDB 4.x 及以上版本，生产环境不再使用 MMAPv1。若业务对延迟极度敏感且具备企业授权，可考虑 In‑Memory（企业版）。在 Ubuntu 20.04+ 与 SSD/NVMe 的组合下，WiredTiger 的性价比与可维护性最佳。
引擎对比与版本支持
| 引擎 |
并发控制 |
压缩 |
持久化机制 |
典型场景 |
版本与可用性 |
| WiredTiger |
文档级并发，多核可扩展 |
集合/索引压缩（默认 Snappy，可选 zlib） |
Checkpoint 约每 60 秒或 2GB 刷盘，Journal 默认 100ms 同步 |
高并发 OLTP、日志/时序、容器化与云盘 |
3.2+ 默认；Ubuntu 上推荐 4.4 LTS / 5.0+ |
| MMAPv1 |
集合级锁，写并发受限 |
无内置块压缩 |
依赖文件系统与 Journal |
仅限遗留系统维护 |
3.2 之前默认；4.x 起不再支持 |
| In‑Memory（企业版） |
内存级低延迟 |
不涉及磁盘压缩 |
主要为内存数据，持久化能力受限 |
超低延迟、容忍数据丢失的分析/缓存 |
需 MongoDB 企业版 |
| 说明：WiredTiger 的 Checkpoint + Journal 设计保证崩溃后可恢复到最近一致点；MMAPv1 的并发与碎片问题在现代高并发业务中劣势明显。 |
|
|
|
|
|
按场景选择
- 高并发 Web/API、订单/交易、实时分析前置库：选 WiredTiger（文档级并发、压缩省盘、检查点保障恢复）。
- 只读或近只读的历史数据分析：选 WiredTiger（压缩与缓存命中率更优；不建议为读多而回退到 MMAPv1）。
- 对延迟极端敏感、可接受数据非持久或具备完善外部持久化/补偿机制：选 In‑Memory（企业版）。
- 仅需维持老版本运行或兼容性验证：仅在 MongoDB ≤3.6 的遗留环境中考虑 MMAPv1，并尽快规划迁移。
关键配置要点（WiredTiger）
- 内存与缓存：WiredTiger 缓存默认约为 RAM 的 50%（减去 1GB），上限 10TB；在 Ubuntu 上建议为 物理内存的 50% 左右，并保留足够内存给 操作系统页缓存 与其他进程。示例：
storage:
wiredTiger:
engineConfig:
cacheSizeGB: 8 # 依据总内存与实例角色调整
- 压缩策略：集合/索引默认 Snappy（CPU/压缩比平衡），对更高压缩比可选 zlib（CPU 开销更高）。示例：
storage:
wiredTiger:
engineConfig:
journalCompressor: snappy
collectionConfig:
blockCompressor: snappy
indexConfig:
prefixCompression: true
- 持久化与恢复：保持 Journal 启用；WiredTiger Checkpoint 约每 60 秒或 2GB 创建，Journal 默认 100ms 同步，异常重启可通过 Journal 恢复到最近一致点。
- 存储与 I/O：优先 SSD/NVMe 与 ECC 内存，为检查点与日志预留稳定带宽；避免与其他高 I/O 服务争用同一磁盘。
迁移与运维提示
- 从 MMAPv1 升级：建议通过 逻辑备份/恢复（mongodump/mongorestore） 或 副本集/分片重同步 迁移到 WiredTiger，避免直接切换引擎导致结构与空间布局不兼容。
- 监控与诊断：使用 mongostat、mongotop 观察吞吐、锁、页面错误与缓存命中；结合慢查询分析优化索引与查询。
- 变更控制：调整 cacheSizeGB、压缩算法、Journal 等参数需结合负载与容量评估，先在测试环境验证再上线。