Mongo Collection `Size` es * más grande * que` storageSize`?

Recientemente compacté mi colección usando el comando:

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

¡Y ahora el tamaño de mi colección parece ser mayor que el tamaño en el 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

}

No entiendo cómo esto es posible. ¿No están todas las colecciones mongodb respaldadas por disco en todo momento?

¿Alguien puede explicar estos resultados?

mongodb Chris W.
fuente

He visto estadísticas como esa antes, pero no tengo una explicación. Intenta ejecutar un validate?

Eve Freeman

Respuestas:

storageSize es la suma de todas las extensiones para esos datos, excluyendo los índices.

Para que la colección tome 2 extensiones, son ~ 2GB cada una, por lo tanto ~ 4GB. sizeincluye índices y creo que hay un par de otras cosas que inflan el número. Ninguno de los dos representa realmente el tamaño adecuado en el disco. Para el tamaño del disco, db.stats()tiene un campo de tamaño de archivo que está más cerca de lo que quieres, creo que estás buscando.

El manual es algo mejor para delinear lo que significan los diversos campos, vea aquí las colecciones:

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

Y aquí para las estadísticas de la base de datos:

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

Alguna otra información potencialmente relevante:

El comando compacto no reduce ningún archivo de datos; solo desfragmenta el espacio eliminado para que los objetos más grandes puedan reutilizarlo. El comando compacto nunca eliminará ni reducirá los archivos de la base de datos, y en general requiere espacio adicional para hacer su trabajo, generalmente un mínimo de una extensión adicional.

Si repara la base de datos, esencialmente reescribirá los archivos de datos desde cero, lo que eliminará el relleno y los almacenará en el disco de la manera más eficiente que pueda obtener. Sin embargo, necesitará tener ~ 2 veces el tamaño en el disco para hacerlo (en realidad menos, pero es una guía decente).

Otra cosa a tener en cuenta aquí: reparar y compactar quitar el acolchado. El factor de relleno varía entre 1 (sin movimientos de documentos causados por documentos en crecimiento), a 2 (muchos movimientos causados por documentos en crecimiento). Su factor de relleno de ~ 1.67 indicaría que está creciendo (y por lo tanto causando movimientos) bastante.

Cuando compacta o repara una base de datos, elimina ese relleno, por lo que el crecimiento posterior del documento desencadenará aún más movimientos que antes. Debido a que los movimientos son operaciones relativamente caras, esto puede tener un grave impacto en su rendimiento. Más información aquí:

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

Adam C
fuente

Gracias por su respuesta @ Adam, estoy algo familiarizado con los factores de relleno y la compactación, lo que me confunde en este caso es que, no importa cuán efectiva sea la compactación, nunca deberíamos poder almacenar más datos en la base de datos de los que estamos almacenando. ¡disco duro! es decir, ¿cómo encaja 5.6GB de datos mongo en 4.2GB de disco?

Chris W.

4,2 GB de disco son solo los datos, 5,6 GB son los datos más los índices, y luego, para el tamaño real del disco, es probable que tengas que mirar las estadísticas del nivel de la base de datos

Adam C

Me encontré con lo mismo! Lo extraño es que en su documento dice que el tamaño no tiene en cuenta los índices: "Además, el tamaño no incluye el tamaño de ningún índice asociado con la colección, que informa el campo totalIndexSize".

MatijaSh

La razón puede ser que el tamaño muestra el tamaño de datos sin comprimir, mientras que el tamaño de almacenamiento tiene compresión en la cuenta. Aquí se describe a nivel de base de datos, pero también parece ser aplicable para la recopilación: docs.mongodb.com/manual/reference/command/dbStats/…

MatijaSh

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

Para db.getCollection ('nombre'). 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)

Para db.stats ()

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

Podemos eliminar el espacio o agujero no utilizado por este

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

Después de ejecutar un comando compacto o de reparación, podemos obtener el tamaño exacto de almacenamiento y la diferencia de tamaño de datos.

Técnica de compresión en 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
fuente