Mongo Collection的“大小”比“ storageSize”大*？

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

 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集合都始终由磁盘备份吗？

谁能解释这些结果？

mongodb

— 克里斯·W
source

我以前看过类似的统计信息，但没有任何解释。尝试运行validate？

— 伊芙·弗里曼

Answers:

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

— 亚当·C
source

感谢您@Adam的回复，我对填充因子和压缩有些熟悉，在这种情况下，让我感到困惑的是，无论压缩多么有效，我们都永远不能在数据库中存储比存储更多的数据。硬盘！即，您如何在4.2GB磁盘中容纳5.6GB mongo数据？

— 克里斯·W

盘的4.2GB仅仅是数据，5.6GB的数据加上索引，然后实际的磁盘大小，你可能将不得不在数据库级别的统计数据看，而不是

— 亚当ç

我遇到了同样的事情！奇怪的是，在他们的文档中，它说大小不代表索引：“另外，大小不包括与集合关联的任何索引的大小，totalIndexSize字段报告该集合。”

— MatijaSh

原因可能是大小显示未压缩的数据大小，而存储大小将压缩到帐户中。它在数据库级别上进行了描述，但似乎也适用于收集：docs.mongodb.com/manual/reference/command/dbStats/…–

— MatijaSh

对于mongodb> 3.x

For MMAPv1: 
datasize < storageSize

but For wiredTiger
datasize > storageSize (most cases due to compression but may be
                        storageSize greater, it varies on condition like
                        compression technique, whether compact/repair 
                        command run or not)

对于db.getCollection（'name'）。stats（）

size = total size in memory of all records in a collection + padding (excluded index size + record header which is 16 byte per header, header means  = field name)        
avgObjSize = avg size of obj + padding
storageSize =  total amount of storage allocated to this collection for document storage. (totalIndex size excluded)
totalIndexSize : totalIndexSize (compressed in case of wiredTiger)

对于db.stats（）

dataSize = document + padding
storageSize = document + padding + deleted space
fileSize = document + padding extents +  index extents + yet-unused space

由此可以删除未使用的空间或孔

db.getCollection('name').runCommand( "compact" )

运行压缩或修复命令后，我们可以获得确切的存储大小和数据大小差异。

mongodbwiredTiger中的压缩技术：

- snappy : good compression, low overhead
- zlib: better compression, more CPU
- none (we can disable compression, by default its enable in WT)

— 卡马尔·库马尔（Kamal Kumar）
source