Obwohl diese Speicher-Engine bereits seit MongoDB Version 4.0 veraltet ist, enthält sie einige wichtige Funktionen. MMAPv1 ist die ursprüngliche Speicher-Engine in MongoDB und basiert auf zugeordneten Dateien. Nur die 64-Bit-Intel-Architektur (x86_64) unterstützt diese Speicher-Engine.
MMAPv1 sorgt für hervorragende Leistung bei Workloads mit...
- Große Updates
- Viel Lesevorgänge
- Einsätze mit hohem Volumen
- Hohe Auslastung des Systemspeichers
MMAPv1-Architektur
MMAPv1 ist ein B-Tree-basiertes System, das viele der Funktionen wie Speicherinteraktion und Speicherverwaltung für das Betriebssystem bereitstellt.
Es war die Standarddatenbank für MongoDB für Versionen vor 3.2 bis zur Einführung der WiredTiger-Speicher-Engine. Sein Name kommt von der Tatsache, dass es speicherabgebildete Dateien verwendet, um auf Daten zuzugreifen. Dies geschieht durch direktes Laden und Modifizieren von Dateiinhalten, die sich in einem virtuellen Speicher befinden, durch eine mmap()-Systemaufrufmethode.
Alle Datensätze befinden sich zusammenhängend auf der Festplatte, und falls ein Dokument größer als die zugewiesene Datensatzgröße wird, weist MongoDB einen neuen Datensatz zu. Für MMAPv1 ist dies vorteilhaft für den sequentiellen Datenzugriff, aber gleichzeitig eine Einschränkung, da es mit einem Zeitaufwand verbunden ist, da alle Dokumentindizes aktualisiert werden müssen und dies zu einer Speicherfragmentierung führen kann.
Die grundlegende Architektur der MMAPv1-Speicher-Engine ist unten dargestellt.
Wenn, wie oben erwähnt, eine Dokumentgröße die zugewiesene Datensatzgröße überschreitet, führt dies zu einer Neuzuweisung, was keine gute Sache ist. Um dies zu vermeiden, verwendet die MMAPv1-Engine eine Zweierpotenz-Zuordnung, sodass jedes Dokument in einem Datensatz gespeichert wird, der das Dokument selbst enthält (einschließlich eines zusätzlichen Platzes, der als Auffüllung bekannt ist). Die Auffüllung wird dann verwendet, um jegliches Dokumentwachstum zu berücksichtigen, das sich aus Aktualisierungen ergeben kann, während es die Wahrscheinlichkeit von Neuzuweisungen verringert. Andernfalls kann es bei Neuzuweisungen zu einer Speicherfragmentierung kommen. Durch die Polsterung wird zusätzlicher Platz eingetauscht, um die Effizienz zu verbessern und so die Fragmentierung zu reduzieren. Für Workloads mit einem hohen Volumen an Einfügungen, Aktualisierungen oder Löschungen sollte die Zuweisung mit der Potenz 2 am meisten bevorzugt werden, während die exakt passende Zuweisung ideal für Sammlungen ist, die keine Update- oder Lösch-Workloads beinhalten.
Power of 2 Sized Allocation
Für ein reibungsloses Dokumentenwachstum wird diese Strategie in der MMAPv1-Speicher-Engine eingesetzt. Jeder Datensatz hat eine Größe in Bytes, die eine Zweierpotenz ist, also (32, 64, 128, 256, 512...2 MB). 2 MB ist die standardmäßige größere Grenze. Jedes Dokument, das diese Grenze überschreitet, wird auf das nächste Vielfache von 2 MB gerundet. Wenn ein Dokument beispielsweise 200 MB groß ist, wird diese Größe auf 256 MB abgerundet, und 56 MB Speicherplatz stehen für zusätzliches Wachstum zur Verfügung. Dadurch können Dokumente wachsen, anstatt eine Neuzuweisung auszulösen, die das System vornehmen muss, wenn Dokumente sie erreichen Grenzen des verfügbaren Speicherplatzes.
Merits of Power 2 Sized Allocations
- Wiederverwendung freigegebener Datensätze zur Verringerung der Fragmentierung: Bei diesem Konzept werden Datensätze so speicherquantisiert, dass sie eine feste Größe haben, die groß genug ist, um neue Dokumente aufzunehmen, die in den zugewiesenen Speicherplatz passen würden, der durch eine frühere Löschung oder Verschiebung von Dokumenten erstellt wurde.
- Reduziert Dokumentenbewegungen: Wie bereits erwähnt, führen MongoDB-Einfügungen und -Aktualisierungen, die die Dokumentgröße größer als die festgelegte Datensatzgröße machen, standardmäßig auch zur Aktualisierung der Indizes. Dies bedeutet lediglich, dass die Dokumente verschoben wurden. Wenn jedoch innerhalb eines Dokuments genügend Platz für Wachstum vorhanden ist, wird das Dokument nicht verschoben, wodurch weniger Aktualisierungen an Indizes erforderlich sind.
Speichernutzung
Der gesamte freie Speicher auf dem Computer in der MMAPv1-Speicher-Engine wird als Cache verwendet. Korrekt bemessene Arbeitssätze und optimale Leistung werden durch einen Arbeitssatz erreicht, der in den Speicher passt. Außerdem spült MMAPv1 alle 60 Sekunden Änderungen an Daten auf die Festplatte und spart so Cache-Speicher. Dieser Wert kann so geändert werden, dass häufig gespült werden kann. Da der gesamte freie Speicher als Cache verwendet wird, wundern Sie sich nicht, dass Überwachungstools für Systemressourcen anzeigen, dass MongoDB viel Speicher verwendet, da diese Nutzung dynamisch ist.
Vorteile der MMAPv1-Speicher-Engine
- Reduzierte Fragmentierung auf der Festplatte bei Verwendung der Vorabzuweisungsstrategie.
- Sehr effiziente Lesevorgänge, wenn der Arbeitssatz so konfiguriert wurde, dass er in den Speicher passt.
- In-Place-Updates, d. h. einzelne Feldaktualisierungen können dazu führen, dass mehr Daten gespeichert werden, wodurch die Aktualisierung großer Dokumente mit minimalen gleichzeitigen Schreibern verbessert wird.
- Bei einer geringen Anzahl gleichzeitiger Schreiber kann die Schreibleistung durch das Konzept der häufigen Datenspülung auf die Festplatte verbessert werden.
- Das Sperren auf Sammlungsebene erleichtert Schreibvorgänge. Das Sperrschema ist einer der wichtigsten Faktoren für die Datenbankleistung. In diesem Fall kann immer nur 1 Client auf die Datenbank zugreifen. Dadurch entsteht ein Szenario, in dem Vorgänge schneller ablaufen, als wenn sie von der Speicher-Engine seriell dargestellt werden.
Einschränkungen der MMAPv1-Speicher-Engine
- Hohe Platznutzung bei Iterationen. MMAPv1 fehlt eine Komprimierungsstrategie für das Dateisystem, daher wird der Datensatzplatz überbelegt.
- Einschränkung des Sammlungszugriffs für viele Clients beim Ausführen eines Schreibvorgangs. MMAPv1 verwendet eine Sperrstrategie auf Sammlungsebene, was bedeutet, dass 2 oder mehr Clients nicht gleichzeitig auf dieselbe Sammlung zugreifen können, daher blockiert ein Schreibvorgang alle Lesevorgänge in dieser Sammlung. Dies führt zu einer groben Parallelität, die es unmöglich macht, die MMAPv1-Engine zu skalieren.
- Ein Systemabsturz kann möglicherweise zu Datenverlust führen, wenn die Journaling-Option nicht aktiviert ist. Aber selbst wenn dies der Fall ist, ist das Fenster zu klein, kann Sie aber zumindest vor einem großen Datenverlustszenario bewahren.
- Ineffiziente Speichernutzung. Bei Verwendung der Vorabzuweisungsstrategie belegen einige Dokumente mehr Speicherplatz auf der Festplatte als die Daten selbst.
- Wenn die Größe des Arbeitssatzes den zugewiesenen Speicher überschreitet, sinkt die Leistung erheblich. Außerdem kann ein erhebliches Dokumentwachstum nach der anfänglichen Speicherung zusätzliche E/A auslösen und somit zu Leistungsproblemen führen.
Vergleich von MMAPv1- und WiredTiger-Speicher-Engines
| Schlüsselfunktion | MMAPv1 | WiredTiger |
|---|---|---|
| CPU-Leistung | Das Hinzufügen weiterer CPU-Kerne erhöht die Leistung leider nicht | Leistung verbessert sich mit Multicore-Systemen |
| Verschlüsselung | Aufgrund der Verwendung von speicherabgebildeten Dateien wird keine Verschlüsselung unterstützt | Die Verschlüsselung sowohl für übertragene als auch für ruhende Daten ist sowohl in der MongoDB-Enterprise- als auch in der Beta-Installation verfügbar |
| Skalierbarkeit | Gleichzeitige Schreibvorgänge, die aus der Sperrung auf Sammlungsebene resultieren, machen eine Aufskalierung unmöglich. | Hohe Chancen auf Skalierung, da die niedrigste Sperrebene das Dokument selbst ist. |
| Abstimmung | Sehr geringe Möglichkeiten, diese Speicher-Engine zu optimieren | Variablen wie Cache-Größe, Checkpoint-Intervalle und Lese-/Schreib-Tickets können vielfältig angepasst werden |
| Datenkomprimierung | Keine Datenkomprimierung, daher kann mehr Speicherplatz verwendet werden | Snappy- und zlib-Komprimierungsmethoden verfügbar, daher können Dokumente weniger Speicherplatz belegen als in MMAPv1 |
| Atomtransaktionen | Nur anwendbar für ein einzelnes Dokument | Ab Version 4.0 werden atomare Transaktionen für mehrere Dokumente unterstützt. |
| Speicher | Der gesamte freie Speicher auf der Maschine wird als Cache verwendet | Dateisystem-Cache und interner Cache werden verwendet |
| Aktualisierungen | Unterstützt In-Place-Updates und eignet sich daher hervorragend für Workloads mit großen Volume-Einfügungen, Lesevorgängen und In-Place-Updates | Unterstützt keine Inplace-Updates.Das gesamte Dokument muss neu geschrieben werden. |
Schlussfolgerung
Bei der Auswahl einer Speicher-Engine für eine Datenbank wissen viele Menschen nicht, welche sie wählen sollen. Die Wahl hängt normalerweise von der Arbeitsbelastung ab, der sie ausgesetzt wird. Im Allgemeinen würde MMAPv1 eine schlechte Wahl treffen, und deshalb hat MongoDB viele Fortschritte bei der WiredTiger-Option gemacht. Es kann jedoch je nach Anwendungsfall einige andere Speicher-Engines übertreffen, z. B. wenn Sie nur Lese-Workloads durchführen oder viele separate Sammlungen mit großen Dokumenten speichern müssen, wobei 1 oder 2 Felder häufig aktualisiert werden.
