Mongo Collection `Size` è * più grande * di` storageSize`?

Recentemente ho compattato la mia raccolta usando il comando:

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

E ora la dimensione della mia raccolta sembra essere maggiore della dimensione sul disco!

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

}

Non capisco come sia possibile. Tutte le raccolte di mongodb non sono sempre supportate da disco?

Qualcuno può spiegare questi risultati?

mongodb

— Chris W.
fonte

Ho già visto statistiche del genere prima, ma non ho una spiegazione. Prova a eseguire un validate?

— Eve Freeman,

Risposte:

storageSize è la somma di tutte le estensioni per tali dati, esclusi gli indici.

In modo che la raccolta occupi 2 estensioni, sono ~ 2 GB ciascuna, quindi ~ 4 GB. sizeinclude indici e credo un paio di altre cose che gonfiano il numero. Né rappresenta in realtà la dimensione corretta su disco. Per le dimensioni del disco, db.stats()ha un campo dimensione file che è più vicino a quello che vuoi, penso che tu stia cercando.

Il manuale è in qualche modo migliore per delineare il significato dei vari campi, vedere qui per le raccolte:

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

E qui per le statistiche del database:

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

Alcune altre informazioni potenzialmente rilevanti:

Il comando compatto non riduce i file di dati; deframmenta solo lo spazio eliminato in modo che oggetti più grandi possano riutilizzarlo. Il comando compatto non eliminerà o ridurrà mai i file di database e, in generale, richiede spazio extra per svolgere il suo lavoro, di solito un minimo di un'estensione aggiuntiva.

Se ripari il database, essenzialmente riscriverà i file di dati da zero, il che rimuoverà il riempimento e li memorizzerà sul disco con la stessa efficienza che otterrai. Tuttavia, per farlo, avrai bisogno di ~ 2 volte la dimensione del disco (in realtà meno, ma è una guida decente).

Un'altra cosa da tenere a mente qui: riparare e rimuovere l'imbottitura compatta. Il fattore di riempimento varia tra 1 (nessuna mossa dei documenti causata dalla crescita dei documenti), a 2 (molte mosse causate dalla crescita dei documenti). Il tuo fattore di imbottitura di ~ 1,67 indicherebbe che stai crescendo (e quindi causando mosse) abbastanza.

Quando compattate o riparate un database rimuovete quell'imbottitura: la successiva crescita del documento attiverà quindi ancora più mosse rispetto a prima. Poiché le mosse sono operazioni relativamente costose, ciò può avere un grave impatto sulle prestazioni. Maggiori informazioni qui:

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

— Adamo C.
fonte

Grazie per la tua risposta @Adam, ho una certa familiarità con i fattori di imbottitura e compattazione, ciò che mi confonde in questo caso è che, indipendentemente dall'efficacia della compattazione, non dovremmo mai essere in grado di archiviare più dati nel database di quelli su cui stiamo archiviando disco rigido! cioè, come si adattano 5,6 GB di dati mongo in 4,2 GB di disco?

— Chris W.

4,2 GB di disco sono solo i dati, 5,6 GB sono i dati più gli indici e quindi per le dimensioni effettive del disco probabilmente dovrai guardare le statistiche a livello di database

— Adam C

Mi sono imbattuto nella stessa cosa! La cosa strana è che nel loro documento dice che la dimensione non tiene conto degli indici: "Inoltre la dimensione non include la dimensione di tutti gli indici associati alla raccolta, che riporta il campo totalIndexSize".

— MatijaSh,

Il motivo potrebbe essere che la dimensione visualizza la dimensione dei dati non compressi, mentre la dimensione della memoria richiede la compressione nell'account. È descritto a livello di db qui, ma sembra essere applicabile anche per la raccolta: docs.mongodb.com/manual/reference/command/dbStats/…

— MatijaSh

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

Per db.getCollection ('nome'). 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)

Per db.stats ()

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

In questo modo possiamo eliminare lo spazio o il buco non utilizzati

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

Dopo aver eseguito il comando compatto o di ripristino, è possibile ottenere le dimensioni esatte di archiviazione e la differenza delle dimensioni dei dati.

Tecnica di compressione in mongodb cablata Tiger:

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

— Kamal Kumar
fonte