Kolekcja Mongo „Rozmiar” jest * większy * niż „storageSize”?

Niedawno skompresowałem swoją kolekcję za pomocą polecenia:

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

A teraz rozmiar mojej kolekcji wydaje się większy niż rozmiar na dysku!

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

}

Nie rozumiem, jak to jest możliwe. Czy wszystkie kolekcje mongodb nie są zawsze wspierane przez dysk?

Czy ktoś może wyjaśnić te wyniki?

storageSize jest sumą wszystkich zakresów dla tych danych, z wyłączeniem indeksów.

Tak więc kolekcja zajmuje 2 zakresy, każdy ma ~ 2 GB, a więc ~ 4 GB. sizezawiera indeksy i uważam, że kilka innych rzeczy, które zawyżają liczbę. Żaden z nich tak naprawdę nie reprezentuje właściwego rozmiaru dysku. Rozmiar dysku db.stats()ma pole rozmiaru pliku, które jest bliższe temu, czego chcesz. Myślę, że szukasz.

Podręcznik jest nieco lepszy w opisywaniu znaczenia poszczególnych pól, zobacz tutaj kolekcje:

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

A tutaj statystyki bazy danych:

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

Niektóre inne potencjalnie istotne informacje:

Polecenie kompaktowe nie zmniejsza plików danych; defragmentuje tylko usunięte miejsce, aby większe obiekty mogły go ponownie wykorzystać. Polecenie kompaktowe nigdy nie usunie ani nie zmniejszy plików bazy danych i ogólnie wymaga dodatkowej przestrzeni do wykonania swojej pracy, zwykle co najmniej jednego dodatkowego zakresu.

Jeśli naprawisz bazę danych, zasadniczo przepisuje ona pliki danych od zera, co usunie wypełnianie i zapisze je na dysku tak skutecznie, jak to tylko możliwe. Jednak aby to zrobić, musisz mieć ~ 2x rozmiar na dysku (właściwie mniej, ale jest to porządny przewodnik).

Należy pamiętać o jeszcze jednej rzeczy - naprawić i usunąć wyściółkę. Współczynnik dopełniania waha się od 1 (brak ruchów dokumentów spowodowanych powiększaniem się dokumentów) do 2 (wiele ruchów spowodowanych wzrostem dokumentów). Twój współczynnik wypełnienia wynoszący ~ 1,67 wskazywałby, że rośniesz (a więc powodujesz ruchy) całkiem sporo.

Podczas kompaktowania lub naprawy bazy danych usuwasz tę dopełnienie - kolejne powiększanie dokumentu spowoduje jeszcze więcej ruchów niż wcześniej. Ponieważ ruchy są relatywnie drogimi operacjami, może to mieć poważny wpływ na wydajność. Więcej informacji tutaj:

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

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

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

Dla db.stats ()

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

Dzięki temu możemy usunąć nieużywane miejsce lub dziurę

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

Po uruchomieniu polecenia kompaktowania lub naprawy możemy uzyskać dokładny rozmiar pamięci i różnicę wielkości danych.

Technika kompresji w mongodb wiredTiger:

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