1. 课程导入与治理目标
MongoDB 的容量增长与成本治理，本质上不是“磁盘快满了就扩容”这么简单。它同时牵涉数据量、索引量、副本集冗余、oplog、备份、缓存命中率、分片均衡、云盘 IOPS 与吞吐计费等多个维度。很多团队遇到的真实困境是：业务写入持续增长，磁盘使用率看似平稳，但账单逐月上升；或者单节点磁盘告警，扩容后不久又告警，成本却已经翻倍。要解决这类问题，必须先建立一套统一的观察框架，把“容量”和“成本”放在同一张图上理解。
一、容量增长从哪里来：四个必须分开看的层次
讨论 MongoDB 容量时，最容易犯的错误是把“业务数据量”直接等同于“集群总占用”。实际上，一个副本集或分片集群的物理占用至少由四层构成：
- 业务集合数据：文档本身占用的空间，受文档平均大小、数量、更新模式影响。
- 索引数据：每个索引都是一份独立的数据结构，索引越多、字段越长，占用越可观。常见情况下索引总量可达数据量的 30%～80%。
- 副本冗余：三节点副本集意味着同一份数据至少存三份，物理成本约为单份的 3 倍。
- 运行与保护开销：oplog、journal、备份快照、迁移临时空间、碎片与预分配空间等。
因此，当业务方说“我们只有 500GB 数据”时，一个三节点副本集加索引后的实际占用可能是 2TB 以上。治理的第一步，就是让团队用同一口径描述容量：单份逻辑数据量、索引量、副本数、运行开销、总物理占用，缺一不可。
二、成本不只是存储：三类成本要分清
MongoDB 的成本通常分布在三个方向。第一类是存储成本，包括数据盘容量、备份存储、快照保留。第二类是计算成本，包括实例规格、CPU、内存，尤其是内存不足导致的频繁磁盘读。第三类是IO 与网络成本，在云环境中常表现为 IOPS 计费、跨可用区流量、跨地域复制流量。很多“容量问题”实际是 IO 或内存问题：数据量没涨多少，但查询模式变化导致缓存命中率下降，磁盘读放大，最终表现为延迟上升和成本上升。
三、关键指标：从容量、性能到成本的三组信号
治理需要可观测的指标。建议至少覆盖以下三组：
| 维度 | 关键指标 | 观察意义 |
|---|---|---|
| 容量 | dbStats.dataSize、storageSize、indexSize、磁盘使用率、oplog 窗口 | 判断数据、索引、冗余与保护空间是否失衡 |
| 性能 | 缓存命中率、page faults、查询延迟 P95/P99、扫描文档数与返回文档数比 | 判断容量增长是否已转化为性能压力 |
| 成本 | 实例规格费用、存储费用、备份费用、跨区流量、单位请求成本 | 判断成本增长是否与业务增长匹配 |
其中，索引与扫描比尤其值得关注。若一个查询扫描了 10 万条文档却只返回 20 条，说明索引设计或查询模式存在问题，这类问题往往比单纯扩容更能影响成本。另一个常被忽视的指标是 oplog 窗口：窗口过短会导致从节点无法追上主节点，被迫全量同步，带来额外 IO 和网络成本。
四、整体方法论：观测、归因、治理、验证
容量与成本治理不是一次性项目，而是一个持续循环。可以把它概括为四个动作：
- 观测：统一采集容量、性能、成本三类指标，建立基线。
- 归因：把增长拆解到具体集合、索引、查询或副本策略上，而不是笼统地说“数据涨了”。
- 治理：按优先级处理，常见手段包括索引精简、TTL 过期、冷热分离、压缩、分片键调整、副本策略优化。
- 验证：治理后重新测量容量斜率与单位成本，确认是否真正改善，而不是把问题推迟。
下面这张图把上述关系组织成一条从“增长来源”到“治理动作”再到“成本结果”的链路，帮助你在后续章节中始终带着全局视角看问题。
五、一个可操作的起点：先算清“单份数据成本”
在进入后续章节前，建议先做一次最小可行的基线测算。假设某业务集合单份数据为 200GB，索引 80GB，三节点副本集，oplog 与备份合计约 60GB，则单副本集物理占用约为 (200+80)×3+60 = 900GB。若云盘单价为 0.8 元/GB/月，仅存储成本约 720 元/月；若实例规格为 3 台 8 核 32GB，每台 1500 元/月，则计算成本 4500 元/月。此时存储只占约 14%，真正的大头在计算。这个简单测算说明：容量治理不能只盯磁盘，必须同时看计算与 IO。
本课程后续将围绕这条主线展开：先建立容量与成本的观测能力，再逐层拆解数据、索引、副本、分片与查询模式带来的增长，最后给出可落地的治理手段与验证方法。你不需要一次记住所有指标，但需要先建立“增长来源—观测指标—成本构成—治理动作—验证”的闭环意识，这是后续所有章节的共同基础。