MongoDB 部署中的磁盘空间管理和释放
磁盘空间管理是维护健康、高性能 MongoDB 部署的关键方面。与传统的关系型数据库不同，MongoDB 的存储引擎动态处理空间分配，这意味着删除后物理磁盘空间通常不会立即回收。如果不加以管理，不必要的存储消耗可能导致意外的停机、写入性能下降以及显著的财务开销，尤其是在云环境中。
本指南提供了专业的策略和实用的命令，用于监控存储利用率、识别空间消耗源（空间占用者），并实施有效的方法——例如压缩、索引优化和强大的保留策略——以主动回收和管理磁盘空间。通过了解 MongoDB 如何利用存储，管理员可以确保长期的稳定性和效率。
监控磁盘空间使用情况
有效管理的第一步是持续监控。您需要区分逻辑数据大小和物理存储大小。
系统级别监控
始终监控 MongoDB 数据（dbPath）和日志文件所在的文件系统。当整体磁盘利用率达到关键阈值（例如 80-90%）时，需要使用标准操作系统工具进行警报。
df -h /path/to/mongodb/data
MongoDB 特定指标
要了解 MongoDB 内部的存储使用情况，请通过 mongosh shell 使用 db.stats() 和 db.collection.stats() 命令。
数据库统计信息 (db.stats())
此命令提供整个数据库的概览：
use myDatabase
db.stats()
要观察的关键字段：
dataSize：所有集合中原始文档数据的总大小（逻辑大小）。storageSize：数据和填充（物理大小）占用的总磁盘空间。indexSize：磁盘上所有索引的总大小。
集合统计信息 (db.collection.stats())
这是识别空间占用者的最精细、最有用的工具：
db.myCollection.stats(1024 * 1024) // 返回兆字节大小
要观察的关键字段：
size：集合中文档的逻辑大小。storageSize：集合在磁盘上分配的物理空间。size和storageSize之间的大差异通常表明存在严重的碎片化或高文档更新率。totalIndexSize：此集合的索引占用的物理磁盘空间。
提示： 如果
storageSize远大于size，则表示存储分配效率低下（碎片化或过多的填充）。如果totalIndexSize相对于size过大，请检查集合的索引策略。
识别空间占用者
MongoDB 的空间消耗通常由三个因素驱动：
1. 删除导致的碎片化
删除文档时，MongoDB（尤其是 WiredTiger）会标记空间为可用，但不会立即将其释放回操作系统。这些空闲空间保留在存储引擎分配的文件中以供将来重用。高更新率的集合（频繁写入和删除）极易发生碎片化，导致 storageSize 指标膨胀。
2. 索引开销
索引与数据文档分开存储。复杂或大量的索引很容易使集合的存储需求加倍或三倍。识别和删除未使用的索引通常是回收空间最快的方法。
3. 集合结构和填充
MongoDB 会在数据文件中分配额外的空间（填充）以适应更新期间文档的增长。虽然这有利于性能（减少文档重新定位的需求），但如果更新很少或文档在创建后不可变，过多的填充会低效地使用存储。
释放磁盘空间策略
1. 压缩和数据重定位
对于使用 WiredTiger 存储引擎的现代 MongoDB 部署，有两种主要方法可以回收碎片化的空间：
A. 使用 compact（请谨慎使用）
compact 命令会重新组织集合内的数据以回收碎片化空间并重建索引。但是，这是一个繁重的操作，通常会阻塞受影响集合上的所有读/写操作，并且资源消耗巨大。
db.runCommand({ compact: 'myCollection' })
警告： 除非绝对必要，否则通常应避免在生产环境中使用压缩，或者最好在受控维护窗口期间，在副本集的辅助成员上执行。
B. mongodump / mongorestore 方法（推荐）
对于严重碎片化的集合，恢复磁盘空间最可靠的方法是转储数据并恢复它。此过程会顺序重写数据，消除内部碎片。
- 转储数据：
bash mongodump --db myDatabase --collection myCollection --out /path/to/dump - 删除集合：（在此步骤之前确保您有完整的备份）
javascript db.myCollection.drop() - 恢复数据：（恢复过程会高效地分配存储）
bash mongorestore --db myDatabase --collection myCollection /path/to/dump/myDatabase/myCollection.bson
2. 优化索引
重建或删除低效的索引可以节省大量空间。
删除未使用的索引
使用分析器或 db.collection.getIndexes() 分析查询模式，以识别从未使用或很少使用的索引。
db.myCollection.dropIndex('index_name_to_drop')
重建索引
索引本身也可能发生碎片化。有时在辅助成员上重建索引可以减小其物理占用空间。
db.myCollection.reIndex()
最佳实践： 始终先在辅助成员上重建或删除索引，等待复制完成后，再在主成员上执行操作。这可以最大限度地减少停机时间。
3. 数据保留和归档策略
防止无界增长是解决磁盘空间问题的最佳防御措施。
使用 TTL（生存时间）索引
对于日志、会话或时间序列数据，TTL 索引会在指定时间段后自动使文档过期，从而确保在无人为干预的情况下强制执行数据保留策略。
db.logEvents.createIndex(
{ "createdAt": 1 },
{ expireAfterSeconds: 86400 } // 文档在 24 小时后过期
)
实施归档
使用 mongoexport 等工具或自定义归档脚本，将访问频率较低的旧数据移动到较慢的存储层（例如 S3 或 Glacier），然后再从主部署中删除原始文档。
高级存储引擎注意事项（WiredTiger）
现代 MongoDB 部署默认使用 WiredTiger 存储引擎，与旧的 MMAPv1 引擎相比，它提供了更优越的压缩和并发性。
压缩设置
WiredTiger 默认启用压缩（通常是 Snappy）。如果磁盘空间严重受限，您可以通过切换算法（例如改为 zlib）来提高压缩率，但会增加 CPU 利用率。
此配置在启动时设置，或为特定集合动态设置：
db.runCommand({
collMod: "myCollection",
storageEngine: {
wiredTiger: {
configString: "compression_engine=zlib"
}
}
})
预分配和空间重用
WiredTiger 使用的数据文件通常以 2GB 的块进行预分配。虽然这可能看起来是浪费空间，但它通过减少文件系统碎片来提高性能。关键在于理解该空间由数据库内部管理，并且在分配新块之前会被数据库重用，即使文档已被删除。
警告： 切勿尝试手动缩小 MongoDB 数据文件或直接从文件系统中删除日志文件。这会保证数据损坏。请使用 MongoDB 的内置工具，如
mongodump和mongorestore进行受控的空间回收。
结论
MongoDB 中主动的磁盘空间管理依赖于持续的监控和明智的数据保留实践。通过定期检查逻辑数据大小与物理存储大小之间的差异、优化不必要的索引以及利用 TTL 索引实现自动清理，管理员可以显著降低运营成本，并防止因过多的存储碎片化导致性能瓶颈。对于严重的碎片化问题，mongodump/mongorestore 周期仍然是回收空间最有效、最安全、最健壮的解决方案。