Mongo Collection `Size` est * plus grand * que` storageSize`?

J'ai récemment compacté ma collection en utilisant la commande:

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

Et maintenant, la taille de ma collection semble être plus grande que la taille du disque!

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

}

Je ne comprends pas comment cela est possible. Toutes les collections mongodb ne sont-elles pas toujours sauvegardées par disque?

Quelqu'un peut-il expliquer ces résultats?

mongodb

— Chris W.
source

J'ai déjà vu des statistiques comme ça, mais je n'ai pas d'explication. Essayez d'exécuter un validate?

— Eve Freeman

Réponses:

storageSize est la somme de toutes les extensions pour ces données, à l'exclusion des index.

Donc, cette collection prend 2 extensions, elles sont ~ 2 Go chacune, donc ~ 4 Go. sizecomprend des index et je crois que quelques autres choses qui gonflent le nombre. Ni l'un ni l'autre ne représente vraiment la taille appropriée du disque. Pour la taille du disque, db.stats()a un champ de taille de fichier qui est plus proche de ce que vous voulez, je pense que vous recherchez.

Le manuel décrit un peu mieux la signification des différents domaines, voir ici pour les collections:

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

Et ici pour les statistiques de la base de données:

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

Quelques autres informations potentiellement pertinentes:

La commande compacte ne réduit aucun fichier de données; il défragmente uniquement l'espace supprimé afin que des objets plus gros puissent le réutiliser. La commande compacte ne supprimera ni ne réduira jamais les fichiers de base de données et nécessite généralement un espace supplémentaire pour effectuer son travail, généralement au moins une extension supplémentaire.

Si vous réparez la base de données, elle réécrira essentiellement les fichiers de données à partir de zéro, ce qui supprimera le rembourrage et les stockera sur le disque aussi efficacement que possible. Cependant, vous devrez avoir ~ 2x la taille du disque pour le faire (en fait moins, mais c'est un guide décent).

Une autre chose à garder à l'esprit ici - réparer et enlever le rembourrage compact. Le facteur de remplissage varie entre 1 (aucun déplacement de documents causé par la croissance des documents) et 2 (beaucoup de mouvements causés par la croissance des documents). Votre facteur de remplissage de ~ 1,67 indiquerait que vous grandissez (et par conséquent provoquez des mouvements) un peu.

Lorsque vous compactez ou réparez une base de données, vous supprimez ce remplissage - la croissance ultérieure du document va donc déclencher encore plus de mouvements qu'auparavant. Les déplacements étant des opérations relativement coûteuses, cela peut avoir un impact sérieux sur vos performances. Plus d'infos ici:

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

— Adam C
source

Merci pour votre réponse @Adam, je suis un peu familier avec les facteurs de remplissage et de compactage, ce qui m'embrouille dans ce cas, c'est que, quelle que soit l'efficacité du compactage, nous ne devrions jamais pouvoir stocker plus de données dans la base de données que nous n'en stockons disque dur! c'est-à-dire, comment ajustez-vous 5,6 Go de données Mongo dans 4,2 Go de disque?

— Chris W.

4,2 Go de disque ne sont que les données, 5,6 Go sont les données et les index, puis pour la taille réelle du disque, vous devrez probablement consulter les statistiques au niveau de la base de données à la place

— Adam C

J'ai rencontré la même chose! Ce qui est étrange, c'est que dans leur document, il est dit que la taille ne tient pas compte des index: "De plus, la taille n'inclut pas la taille des index associés à la collection, que le champ totalIndexSize rapporte."

— MatijaSh

La raison peut être que la taille affiche la taille des données non compressées, tandis que la taille du stockage prend la compression dans le compte. Il est décrit au niveau db ici, mais semble également être applicable pour la collecte: docs.mongodb.com/manual/reference/command/dbStats/…

— MatijaSh

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

Pour db.getCollection ('nom'). 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)

Pour db.stats ()

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

Nous pouvons supprimer l'espace ou le trou inutilisé par ce

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

Après avoir exécuté la commande compact ou repair, nous pouvons obtenir la taille de stockage exacte et la différence de taille des données.

Technique de compression dans 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
source