モンゴコレクションの「サイズ」は「ストレージサイズ」よりも*大きい*のですか？

最近、次のコマンドを使用してコレクションを圧縮しました。

 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コレクションが常にディスクでバックアップされているわけではありませんか？

誰でもこれらの結果を説明できますか？

storageSize インデックスを除く、そのデータのすべてのエクステントの合計です。

そのため、そのコレクションは2つのエクステントを使用します。これらはそれぞれ2GBまでなので、4GBまでです。sizeインデックスが含まれていますが、数値を膨らませる他のいくつかのことを信じています。どちらも実際の適切なディスク上のサイズを表すものではありません。ディスクサイズについてdb.stats()は、あなたが探していると思うものに近いファイルサイズフィールドがあります。

マニュアルは、さまざまなフィールドの意味を概説するのにいくらか優れています。コレクションについては、こちらを参照してください。

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

そして、ここにデータベース統計があります：

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

その他の関連する可能性のある情報：

compactコマンドはデータファイルを縮小しません。より大きなオブジェクトが再利用できるように、削除されたスペースを最適化するだけです。コンパクトコマンドはデータベースファイルを削除または縮小することはなく、通常、作業を行うために追加の領域が必要です。

データベースを修復すると、基本的にデータファイルが最初から書き換えられます。これにより、パディングが削除され、ディスクに効率よく保存されます。ただし、これを行うには、ディスクのサイズを2倍にする必要があります（実際にはそれより少ないですが、適切なガイドです）。

ここでもう1つ心に留めておくべきこと-修復とコンパクトなパッドの削除。パディング係数は、1（ドキュメントの増加によるドキュメントの移動なし）から2（ドキュメントの増加による多くの移動）の間で変化します。パディングファクター〜1.67は、かなり成長している（したがって移動を引き起こしている）ことを示します。

データベースを圧縮または修復すると、そのパディングが削除されます-したがって、その後のドキュメントの増加により、以前よりも多くの移動がトリガーされます。移動は比較的高価な操作であるため、これはパフォーマンスに深刻な影響を与える可能性があります。詳細はこちら：

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

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" )

圧縮または修復コマンドを実行した後、正確なストレージサイズとデータサイズの違いを取得できます。

mongodb WiredTigerの圧縮技術：

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