Dieser Artikel führt Sie in das relevante Wissen über MongoDB ein und stellt die Speicher-Engine in MongoDB vor. Ich hoffe, er wird Ihnen hilfreich sein!
Das letzte Mal haben wir über Mongodb-Cluster gesprochen, die in „Master-Slave-Cluster“ und „Sharded-Cluster“ unterteilt sind. In Bezug auf die Shards in Sharded-Clustern müssen wir sie gemeinsam überprüfen :
Für(ein Shard-Schlüssel ist ein Indexfeld oder zusammengesetztes Indexfeld, das in jedem Dokument in der Sammlung vorhanden ist) führt dazu, dass alle Lese- oder Schreibanforderungen bearbeitet werden a Single Bei Datenblöcken oder Shards führt dies dazu, dass ein einzelner Shard-Server überlastet wird und der sich selbst erhöhende Shard-Schlüssel leicht zu Schreibproblemen führt [Empfohlen: MongoDB-Video-Tutorial]
FürIn diesem Fall können diese Dokumente nicht in mehrere Datenblöcke aufgeteilt werden, was die gleichmäßige Verteilung der Daten in der Mongodb-Fähigkeit einschränkt
Für
, was zu einer schlechten Abfrageleistung führtWir müssen uns der oben genannten Punkte bewusst sein und bei tatsächlichen Arbeitsproblemen auf ähnliche Probleme stoßen Ich kann versuchen, damit umzugehen. Heute werden wir kurz verstehen, was die Speicher-Engine von Mongodb ist imMemory-Speicher-Engine
Als die Speicher-Engine zum ersten Mal herauskam, wurde standardmäßig die MMAPV1-Speicher-Engine verwendet.MMAPV1-Engine. Wenn wir uns den Namen ansehen, wissen wir wahrscheinlich, dass sie mmap verwendet und das Prinzip der Linux-Speicherzuordnung verwendet
. Im Vergleich zu WiredTiger hat sie die folgenden Vorteile:
WiredTigerLese- und Schreibvorgangsleistung ist besser
MMAPV1-Engine Bei Verwendung von Sperren auf Tabellenebene ist der Durchsatz begrenzt, wenn auf einer einzelnen Tabelle gleichzeitige Vorgänge ausgeführt werden
Und WiredTiger verwendet Sperren auf Dokumentebene, wodurch die Parallelität und der Durchsatz verbessert werden Komprimierungsalgorithmus , der den Verbrauch von Festplattenressourcen erheblich reduzieren kann
Das Schreibprinzip der WiredTiger-EngineWenn der Cache 2 G
erreicht oder der60-Sekunden-Timer abläuft, werden die Daten im Cache geleert Vorsicht, xdm wird wissen, ob es jetzt genau 59 Sekunden sind. Wenn mehr als 1 GB vorhanden sind, wurden die Daten im Cache nicht mit der Festplatte synchronisiert, und Mongodb hängt nicht normal Daten verlieren?
Wir können alle mit unseren Fingern denken:
Wie konnte der Designer von Mongodb diese Situation zulassen, dann muss es eine Lösung gebenJournaling-Puffer
Ähnlich wie Transaktionsprotokolle in relationalen Datenbanken
Außerdem müssen wir hier wissen, dass die Protokollierungsfunktion des Journalings Protokolle schreibt, wenn mongodb Schreibvorgänge ausführen muss, d Wenn der Abrufvorgang ausgeführt wird, wird er nicht im Cache aufgezeichnet, sodass der Lesevorgang keine Auswirkungen hat. Das war's. Wenn es Abweichungen gibt, korrigieren Sie mich bitte
Das obige ist der detaillierte Inhalt vonEine ausführliche Analyse der MongoDB-Speicher-Engine (mit schematischer Darstellung). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!