Mongo Collection `Size` ist * größer * als` storageSize`?

Ich habe kürzlich meine Sammlung mit dem folgenden Befehl komprimiert:

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

Und jetzt scheint meine Sammlung größer zu sein als die Größe auf der Festplatte!

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

}}

Ich verstehe nicht, wie das möglich ist. Sind nicht alle Mongodb-Sammlungen immer auf der Festplatte gesichert?

Kann jemand diese Ergebnisse erklären?

mongodb

— Chris W.
quelle

Ich habe solche Statistiken schon einmal gesehen, habe aber keine Erklärung. Versuchen Sie ein validate?

— Eve Freeman

Antworten:

storageSize ist die Summe aller Speicherbereiche für diese Daten ohne Indizes.

Damit diese Sammlung 2 Bereiche einnimmt, sind sie jeweils ~ 2 GB, also ~ 4 GB. sizeenthält Indizes und ich glaube ein paar andere Dinge, die die Zahl aufblasen. Beides entspricht nicht wirklich der richtigen Größe auf der Festplatte. db.stats()Hat für die Festplattengröße ein Dateigrößenfeld, das näher an dem liegt, was Sie möchten. Ich denke, Sie suchen danach.

Das Handbuch beschreibt etwas besser, was die verschiedenen Felder bedeuten. Sammlungen finden Sie hier:

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

Und hier für Datenbankstatistiken:

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

Einige andere potenziell relevante Informationen:

Der Befehl compact verkleinert keine Datendateien. Es defragmentiert nur gelöschten Speicherplatz, damit größere Objekte ihn wiederverwenden können. Der Befehl compact löscht oder verkleinert niemals Datenbankdateien und benötigt im Allgemeinen zusätzlichen Speicherplatz für seine Arbeit, normalerweise mindestens einen zusätzlichen Bereich.

Wenn Sie die Datenbank reparieren , werden die Datendateien im Wesentlichen von Grund auf neu geschrieben, wodurch Auffüllungen entfernt und so effizient wie möglich auf der Festplatte gespeichert werden. Sie müssen jedoch ~ 2x die Größe auf der Festplatte haben, um dies zu tun (eigentlich weniger, aber es ist eine anständige Anleitung).

Eine andere Sache, die Sie hier beachten sollten - Polster reparieren und kompakt entfernen. Der Auffüllfaktor variiert zwischen 1 (keine Verschiebungen von Dokumenten aufgrund wachsender Dokumente) und 2 (viele Verschiebungen aufgrund wachsender Dokumente). Ihr Polsterungsfaktor von ~ 1,67 würde anzeigen, dass Sie ziemlich stark wachsen (und daher Bewegungen verursachen).

Wenn Sie eine Datenbank komprimieren oder reparieren, entfernen Sie diese Auffüllung. Das nachfolgende Wachstum von Dokumenten wird daher noch mehr Verschiebungen auslösen als zuvor. Da Umzüge relativ teuer sind, kann dies schwerwiegende Auswirkungen auf Ihre Leistung haben. Mehr Infos hier:

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

— Adam C.
quelle

Vielen Dank für Ihre Antwort @Adam, ich bin mit Padding-Faktoren und Komprimierung einigermaßen vertraut. Was mich in diesem Fall verwirrt, ist, dass wir unabhängig von der effektiven Komprimierung niemals mehr Daten in der Datenbank speichern können sollten, als wir speichern Festplatte! dh wie passt man 5,6 GB Mongo-Daten in 4,2 GB Festplatte?

— Chris W.

4,2 GB Festplatte sind nur die Daten, 5,6 GB sind die Daten plus Indizes, und für die tatsächliche Festplattengröße müssen Sie sich wahrscheinlich stattdessen die Statistiken auf Datenbankebene ansehen

— Adam C

Ich bin auf dasselbe gestoßen! Was seltsam ist, ist, dass in ihrem Dokument angegeben ist, dass die Größe keine Indizes berücksichtigt: "Zusätzlich enthält die Größe nicht die Größe von Indizes, die der Sammlung zugeordnet sind, die das Feld totalIndexSize meldet."

— MatijaSh

Der Grund kann sein, dass die Größe die unkomprimierte Datengröße anzeigt, während die Speichergröße die Komprimierung des Kontos berücksichtigt. Es wird hier auf DB-Ebene beschrieben, scheint aber auch für die Sammlung anwendbar zu sein: docs.mongodb.com/manual/reference/command/dbStats/…

— MatijaSh

Für 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)

Für 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)

Für db.stats ()

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

Wir können nicht genutzten Speicherplatz oder Loch dadurch löschen

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

Nach dem Ausführen des Kompakt- oder Reparaturbefehls können wir den genauen Unterschied zwischen Speichergröße und Datengröße ermitteln.

Komprimierungstechnik in 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
quelle