Коллекция Mongo `Size` * больше * чем` 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 не поддерживаются диском постоянно?

Кто-нибудь может объяснить эти результаты?

storageSize это сумма всех экстентов для этих данных, исключая индексы.

Таким образом, эта коллекция занимает 2 экстента, каждый по ~ 2 ГБ, а значит, ~ 4 ГБ. sizeвключает в себя индексы, и я считаю, что несколько других вещей, которые раздувают число. Ни один из них не представляет правильный размер на диске. Что касается размера диска, db.stats()имеет поле размера файла, которое ближе к тому, что вы хотите, я думаю, что вы ищете.

В руководстве несколько лучше изложено, что означают различные поля, см. Здесь для коллекций:

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

А вот для статистики базы данных:

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

Некоторая другая потенциально важная информация:

Компактная команда не сжимает никакие файлы данных; он только дефрагментирует удаленное пространство, чтобы большие объекты могли использовать его повторно. Команда compact никогда не удаляет и не сжимает файлы базы данных, и, как правило, для ее работы требуется дополнительное пространство, обычно минимум один дополнительный экстент.

Если вы восстановите базу данных, она по существу перезапишет файлы данных с нуля, что уберет заполнение и сохранит их на диске так же эффективно, как вы собираетесь получить. Однако для этого вам понадобится ~ 2х размер диска (на самом деле меньше, но это достойное руководство).

Еще одна вещь, которую нужно иметь в виду, - это ремонт и компактное удаление прокладки. Коэффициент заполнения варьируется от 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)