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?

mongodb

— Chris W.
źródło

Widziałem już takie statystyki, ale nie mam wyjaśnienia. Spróbuj uruchomić validate?

— Eve Freeman

Odpowiedzi:

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

— Adam C.
źródło

Dzięki za odpowiedź @Adam, jestem nieco zaznajomiony z czynnikami wypełniania i kompaktowaniem, co mnie w tym przypadku dezorientuje, ponieważ bez względu na to, jak skuteczne jest zagęszczanie, nigdy nie powinniśmy być w stanie przechowywać więcej danych w bazie danych, niż przechowujemy dysk twardy! tzn. jak zmieścisz 5,6 GB danych mongo na 4,2 GB dysku?

— Chris W.

4,2 GB dysku to tylko dane, 5,6 GB to dane plus indeksy, a następnie w przypadku rzeczywistego rozmiaru dysku prawdopodobnie będziesz musiał spojrzeć na statystyki na poziomie bazy danych

— Adam C

Wpadłem na to samo! Dziwne jest to, że w ich dokumencie napisano, że rozmiar nie uwzględnia indeksów: „Dodatkowo rozmiar nie obejmuje rozmiaru żadnych indeksów powiązanych z kolekcją, które zgłasza pole totalIndexSize”.

— MatijaSh

Przyczyną może być to, że rozmiar wyświetla rozmiar nieskompresowanych danych, podczas gdy rozmiar pamięci uwzględnia kompresję na koncie. Jest opisany na poziomie db tutaj, ale wydaje się, że ma również zastosowanie do zbierania: docs.mongodb.com/manual/reference/command/dbStats/…

— MatijaSh

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)

— Kamal Kumar
źródło