Festplattenspeicher ist eine kritische Ressource für jedes skalierbare Datenbanksystem. Die Leistung Ihrer festplattenbasierten Datenbanken hängt davon ab, wie Daten auf der Festplatte verwaltet werden. Ihr MongoDB-Server unterstützt verschiedene Plug-in-Storage-Engines, die die Speicherverwaltung übernehmen und zunächst alle Dokumente sequenziell speichern. Wenn die Datenbank wächst und mehrere Schreibvorgänge ausgeführt werden, wird dieser zusammenhängende Speicherplatz in kleinere Blöcke mit dazwischen liegenden Teilen freien Speicherplatzes fragmentiert. Die typische Lösung besteht darin, die Laufwerksgröße zu erhöhen. Es gibt jedoch Alternativen, mit denen Sie den freien Speicherplatz zurückgewinnen können, ohne die Laufwerksgröße skalieren zu müssen. Eine wichtige Sache, die Sie beachten sollten, sind die MongoDB-Speicherstatistiken und wie Sie die Datenbank komprimieren oder reparieren können, um die Fragmentierung zu bewältigen.
Wie groß ist Ihre Datenbank wirklich?
Sie sollten immer den freien Speicherplatz auf Ihrem Produktionsserver im Auge behalten und auch vorsichtig sein, Ihre Datenbankgröße zu kennen, wenn Sie dafür auf einer Cloud-Plattform bezahlen. MongoDB hat einen Befehl db.stats() die Einblicke in die Speicherstatistiken einer MongoDB-Instanz geben kann.
>db.stats()
{
"db" : "test",
"collections" : 5,
"views" : 0,
"objects" : 53829,
"avgObjSize" : 43.555,
"dataSize" : 2344556121,
"storageSize" :3124416336,
"numExtents" : 0,
"indexes" : 7,
"indexSize" : 8096876,
"ok" : 1
}
Datengröße
Die Gesamtgröße in Bytes der unkomprimierten Daten in dieser Datenbank gespeichert.
Speichergröße
Die Gesamtmenge an Festplattenspeicher Allen Sammlungen in der Datenbank zugeordnet.
Die Antwort von db.stats() hängt vom Typ der MongoDB-Engine ab. Sie finden Ihre versionsabhängige Beschreibung der oben genannten Messwerte in der MongoDB-Dokumentation.
Warum der große Unterschied zwischen storageSize und Datengröße ? Dies liegt an der zuvor erläuterten Fragmentierung von Datendateien. MongoDB versucht nach Möglichkeit, freien Speicherplatz zwischen fragmentierten Daten wiederzuverwenden und gibt ihn nicht an das Betriebssystem frei. In WiredTiger kann storageSize jedoch kleiner als dataSize sein, wenn die Komprimierung aktiviert ist.
Falls ein großer Datenblock aus einer Sammlung gelöscht wird und die Sammlung den gelöschten Speicherplatz nie für neue Dokumente verwendet, muss dieser Speicherplatz an das Betriebssystem zurückgegeben werden, damit er von Ihren anderen Datenbanken oder Sammlungen verwendet werden kann. Sie müssen eine Komprimierung ausführen oder reparieren Vorgang, um den Speicherplatz zu defragmentieren und den nutzbaren freien Speicherplatz zurückzugewinnen.
MongoDB komprimieren
Der Kompaktbetrieb von MongoDB schreibt alle Dokumente und Indizes in einer Sammlung in zusammenhängende Blöcke von Speicherplatz um. Dieser Vorgang blockiert jedoch alle anderen Vorgänge in der Datenbank, zu der die Sammlung gehört. Für einen eigenständigen Server wird daher empfohlen, ihn während eines Wartungsfensters auszuführen, und für Replikatsätze sollten Sie ihn für jeden Shard fortlaufend ausführen. Das bedeutet, dass Sie zuerst alle sekundären Datenbanken und dann zum Schluss die primären Datenbanken komprimieren, damit Ihre Datenbankverfügbarkeit nicht beeinträchtigt wird. Die Syntax des Befehls lautet:
db.runCommand({compact: collection-name }) 1. MMAPv1
- Der Komprimierungsvorgang defragmentiert Datendateien und Indizes. Beachten Sie jedoch, dass es keinen Speicherplatz für das Betriebssystem freigibt. Der Vorgang ist immer noch nützlich, um zu defragmentieren und mehr zusammenhängenden Speicherplatz für die Wiederverwendung durch MongoDB zu schaffen, aber er ist nutzlos, wenn der freie Speicherplatz sehr gering ist.
- Während des Komprimierungsvorgangs ist zusätzlicher Speicherplatz von bis zu 2 GB erforderlich.
- Während des Komprimierungsvorgangs wird eine Sperre auf Datenbankebene aufrechterhalten.
2. WiredTiger
Die WiredTiger-Engine bietet standardmäßig eine Komprimierung, die weniger Speicherplatz verbraucht als MMAPv1.
- Der Kompaktprozess gibt den freien Speicherplatz für das Betriebssystem frei.
- Für die Ausführung des Kompaktvorgangs ist nur minimaler Speicherplatz erforderlich.
- WiredTiger blockiert auch alle Operationen auf der Datenbank, da eine Sperre auf Datenbankebene erforderlich ist.
Wenn Sie WiredTiger ausführen, empfehlen wir Ihnen, den kompakten Vorgang auszuführen, wenn der Speicher 80 % der Festplattengröße erreicht hat. Sie können dies tun, indem Sie auf unserer Detailseite den Vorgang „Compact“ auslösen.
MongoDB reparieren
MongoDB reparieren Der Vorgang repariert alle Fehler und Inkonsistenzen in der Datenspeicherung, ähnlich wie der fcsk-Befehl für ein Dateisystem. Dieser Befehl stellt die Datenintegrität nach einem unerwarteten Herunterfahren oder Absturz sicher. Wenn das Journaling jedoch auf dem Server aktiviert ist, ist keine Reparatur erforderlich, da der Server das Journal verwendet, um nach dem Neustart automatisch in den sauberen Zustand zu wechseln. Wenn Ihre Datenbank beschädigt wurde, dann eine Datenbank reparieren würde die beschädigten Daten nicht speichern, daher wird es nicht empfohlen, diesen Vorgang für die Datenwiederherstellung zu verwenden wenn Sie andere Optionen haben.
Für MMAPv1 Datenbank reparieren ist die einzige Möglichkeit, Speicherplatz zurückzugewinnen, wenn Sie der Meinung sind, dass Ihre Datenbank nicht beschädigt wurde und genügend Speicherplatz für den Reparaturvorgang erforderlich ist. Die Syntax des Befehls lautet:
db.runCommand({repairDatabase: 1}) - Dieser Befehl komprimiert alle Sammlungen in der Datenbank und erstellt alle Indizes neu.
- Für den Auftrag ist freier Speicherplatz erforderlich, der der Größe Ihres aktuellen Datensatzes plus 2 Gigabyte entspricht.
Bei ScaleGrid verwenden wir die repairDatabase Vorgang zur Rückgewinnung von freiem Speicherplatz für MMAPv1 Engine-Cluster.
