Mongo Collection `Size` 比 `storageSize` * 大*？

Question

我最近使用以下命令压缩了我的收藏：

 db.<collectionName>.runCommand( "compact" )

现在我的收藏大小似乎大于磁盘上的大小！

SECONDARY> db.<collectionName>.stats()
{
"ns" : "<databaseName>.<collectionName>",
"count" : 2937359,
"size" : 5681676492,                   # 5.6 GB
"avgObjSize" : 1934.2805874256433,
"storageSize" : 4292853728,            # 4.2 GB
"numExtents" : 2,
"nindexes" : 2,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1.669999999836597,
"flags" : 1,
"totalIndexSize" : 220735648,
"indexSizes" : {
    "_id_" : 162326304,
    "e_1_" : 58409344
},
"ok" : 1

}

我不明白这怎么可能。不是所有的 mongodb 集合都一直由磁盘支持吗？

谁能解释这些结果？

Answer 1

storageSize 是该数据的所有区的总和，不包括索引。

因此该集合占用 2 个盘区，每个盘区约为 2GB，因此约为 4GB。size包括索引，我相信还有一些其他因素会夸大数字。两者都没有真正代表正确的磁盘大小。对于磁盘大小，db.stats()有一个文件大小字段，它更接近您想要的我认为您正在寻找的内容。

该手册在概述各个字段的含义方面稍好一些，请参见此处的集合：

http://docs.mongodb.org/manual/reference/collection-statistics/

这里是数据库统计信息：

http://docs.mongodb.org/manual/reference/database-statistics/

其他一些可能相关的信息：

compact 命令不会收缩任何数据文件；它只对已删除的空间进行碎片整理，以便较大的对象可以重用它。compact 命令永远不会删除或收缩数据库文件，并且通常需要额外的空间来完成它的工作，通常至少需要一个额外的范围。

如果您修复数据库，它实际上将从头开始重写数据文件，这将删除填充并将它们存储在磁盘上，就像您将要获得的那样有效。但是，您需要有大约 2 倍的磁盘大小才能这样做（实际上更少，但这是一个不错的指南）。

这里要记住的另一件事 - 修复和紧凑删除填充。填充因子在 1（文档增长导致文档没有移动）到 2（文档增长导致大量移动）之间变化。您的填充因子约为 1.67 表示您正在增长（并因此导致移动）很多。

当您压缩或修复数据库时，您会删除该填充 - 因此后续文档增长将触发比以前更多的移动。由于移动是相对昂贵的操作，因此这会对您的性能产​​生严重影响。更多信息在这里：

http://www.mongodb.org/display/DOCS/Padding+Factor