这是《MongoDB 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 容量规划把业务增长翻译为存储、内存、网络、连接、索引、分片和备份容量。MongoDB 特别需要关注工作集：数据总量能很大，但常用数据和索引必须尽量留内存。
26.1 输入数据
收集：
| 项目 | 说明 |
|---|---|
| 文档速率 | 每秒插入、更新、删除 |
| 文档大小 | 平均值和 P99 |
| 读 QPS | 高频查询和聚合 |
| 工作集 | 常用数据和索引 |
| 保留周期 | 在线、归档、备份 |
| 峰值系数 | 促销、重试、回放 |
| 副本数 | 每份数据复制 |
| 索引数量 | 写放大和空间 |
26.2 存储容量
估算：
logical bytes = docs × avg doc size
raw bytes = logical bytes × compression factor
index bytes = sum(index size)
replica storage = raw bytes + index bytes
retention storage = daily growth × retention days
再预留：
- 系统和日志空间；
- journal 和 checkpoint 空间；
- 索引重建空间；
- chunk 迁移临时空间；
- 备份恢复窗口；
- 突发增长；
- 至少一个扩容周期。
磁盘水位建议 70% 开始评估扩容，90% 进入应急处理。
26.3 内存容量
工作集包括：
- 热点集合页；
- 热点索引；
- 排序和聚合；
- 连接缓冲；
- 查询执行状态。
判断：
working set + system + mongod overhead < RAM
观察：
db.serverStatus().wiredTiger.cache
如果缓存未命中和磁盘读持续增长，说明内存或工作集需要调整。
26.4 连接与线程
估算：
connections = app instances × pool size
示例：
50 app pods × 20 connections = 1000 connections
容量还要看：
- 每连接内存和线程开销；
- mongod
maxIncomingConnections； - mongos 连接扇出；
- 分片数；
- 操作执行队列；
- TLS 握手开销。
分片集群中每个 mongos 可能连接每个 shard，连接模型必须提前评估。
26.5 写入容量
压测指标：
insert / update / delete TPS
P99 operation latency
write conflicts
journal latency
cache dirty pages
disk throughput
replication lag
规划原则：
- 峰值低于压测安全水位；
- 留出副本同步余量；
- 事务要短；
- 热点文档单独治理；
- 索引数量受控；
- 批处理错峰。
26.6 读容量
按查询分层：
| 查询类型 | 容量策略 |
|---|---|
| 主键或索引点查 | 常规容量 |
| 列表分页 | 排序索引 |
| 聚合报表 | Hidden Secondary 或分析库 |
| 全文搜索 | 搜索服务 |
| 冷数据查询 | 归档系统 |
Secondary 读可以扩展读吞吐，但要考虑复制延迟和 Secondary 磁盘能力。
26.7 分片容量
评估：
single shard safe capacity
required shards = ceil(total peak load / shard safe load)
示例：
peak write = 120,000 ops/s
single shard safe = 30,000 ops/s
required shards = 4
还要验证：
- 分片键能均匀分布；
- 高频查询能定向；
- 每个 shard 的数据量；
- chunk 迁移成本；
- Config Server 容量；
- mongos 数量；
- 跨 shard 事务比例。
26.8 备份容量
规划：
- 全量备份大小；
- 增量或 oplog 窗口；
- 保留天数；
- 异地副本；
- 恢复临时集群空间；
- 备份网络带宽；
- 恢复 RTO。
分片集群要同时备份 Config Server 与各 shard，不能只算业务数据总量。
26.9 容量评审
上线前回答：
- 一年数据增长多少；
- 热点集合大小多少；
- 索引总大小多少；
- P99 目标多少；
- 峰值读写多少；
- 工作集是否在内存；
- 磁盘水位何时到达 70%；
- 分片扩容触发条件；
- 备份空间是否足够；
- 恢复演练多久一次。
本章小结
MongoDB 容量规划的核心是工作集、索引空间、写入放大、复制开销和分片路由。磁盘总量不代表性能能力，常用数据和索引是否能留在内存更关键。分片与备份容量应一起规划。
思考题
- 为什么工作集比总数据量更关键？
- 副本数如何影响容量？
- mongos 连接扇出如何估算？
- 分片数量如何从压测推导？
- 备份容量为什么包含 Config Server？