MongoDB-Konsistenz verstehen: Das BASE-Modell für Entwickler erklärt

MongoDB-Konsistenz wird verwirrend, weil Leute sie auf einen Satz reduzieren: „MongoDB ist eventuell konsistent.“ Das ist zu pauschal, um nützlich zu sein. Ein MongoDB-Replica-Set kann Ihnen für einige Operationen starkes Verhalten und für andere veraltete Lesevorgänge bieten, abhängig von Write Concern, Read Concern, Read Preference und ob ein Failover stattfindet.

Wenn Sie von PostgreSQL oder MySQL kommen, ist die größte Umstellung, dass Konsistenz keine feste Einstellung für die gesamte Anwendung ist. Sie wählen die Garantie, die Sie für jeden Pfad benötigen. Ein Checkout-Ablauf, ein Benachrichtigungs-Feed und ein Analyse-Dashboard benötigen nicht alle die gleiche Aktualität oder Haltbarkeit.

ACID vs. BASE: Zwei Ansätze zur Konsistenz

Bevor wir in das Modell von MongoDB eintauchen, ist es hilfreich, die beiden primären Paradigmen für Datenbankkonsistenz zu verstehen: ACID und BASE.

Die ACID-Eigenschaften (Traditionelle RDBMS)

Traditionelle relationale Datenbankmanagementsysteme (RDBMS) wie PostgreSQL oder MySQL halten sich in der Regel an die ACID-Eigenschaften, die Datenzuverlässigkeit, insbesondere bei Transaktionslasten, gewährleisten. ACID steht für:

Atomicity (Atomarität): Jede Transaktion wird als einzelne, unteilbare Einheit behandelt. Sie wird entweder vollständig abgeschlossen (committed) oder gar nicht ausgeführt (rollback). Es gibt keine partiellen Transaktionen.
Consistency (Konsistenz): Eine Transaktion bringt die Datenbank von einem gültigen Zustand in einen anderen. Sie stellt sicher, dass die in die Datenbank geschriebenen Daten gemäß allen definierten Regeln und Einschränkungen gültig sein müssen.
Isolation (Isolation): Gleichzeitige Transaktionen werden isoliert ausgeführt, sodass sie scheinbar sequenziell ablaufen. Das Ergebnis gleichzeitiger Transaktionen ist dasselbe, als ob sie nacheinander ausgeführt würden.
Durability (Dauerhaftigkeit): Sobald eine Transaktion committed wurde, bleibt sie auch bei Stromausfall, Abstürzen oder anderen Systemfehlern committed. Die Änderungen werden dauerhaft gespeichert.

ACID garantiert starke Konsistenz und ist daher ideal für Anwendungen, die strenge Datenintegrität erfordern, wie z. B. Finanztransaktionen.

Die BASE-Eigenschaften (NoSQL-Datenbanken wie MongoDB)

Im Gegensatz dazu priorisieren viele NoSQL-Datenbanken, einschließlich MongoDB, Verfügbarkeit und Partitionstoleranz gegenüber sofortiger Konsistenz und folgen oft dem BASE-Modell. BASE steht für:

Basically Available (Grundsätzlich verfügbar): Das System garantiert Verfügbarkeit, d. h. es reagiert auf jede Anfrage, auch wenn es nicht die aktuellste Version der Daten garantieren kann.
Soft State (Weicher Zustand): Der Zustand des Systems kann sich im Laufe der Zeit ändern, auch ohne Eingabe. Dies liegt an dem Modell der eventual consistency, bei dem Daten asynchron durch das System propagiert werden.
Eventual Consistency (Eventuelle Konsistenz): Wenn keine neuen Aktualisierungen an einem bestimmten Datenelement vorgenommen werden, geben alle Zugriffe auf dieses Element schließlich den zuletzt aktualisierten Wert zurück. Es gibt eine Verzögerung, bevor Änderungen auf allen Knoten in einem verteilten System sichtbar werden.

BASE-konforme Systeme sind für hohe Verfügbarkeit und Skalierbarkeit in verteilten Umgebungen ausgelegt und eignen sich daher für Anwendungen, die eine gewisse Latenz bei der Datenweitergabe tolerieren können.

Eventual Consistency in MongoDB verstehen

MongoDB kann eventual consistency-Verhalten zeigen, wenn Lesevorgänge von Secondaries bedient werden oder wenn Schreibvorgänge noch nicht überall repliziert wurden. Dies bedeutet, dass beim Schreiben von Daten in ein MongoDB-Replica-Set der primäre Knoten den Schreibvorgang bestätigt und diesen Schreibvorgang dann asynchron an seine sekundären Knoten repliziert. Während der Primärknoten die Dauerhaftigkeit des Schreibvorgangs sicherstellt, wartet er nicht darauf, dass alle Secondaries aufholen, bevor er dem Client den Erfolg bestätigt. Folglich spiegelt ein nachfolgender Lesevorgang von einem sekundären Knoten möglicherweise nicht sofort den letzten Schreibvorgang wider, obwohl er irgendwann konsistent wird.

Diese Designentscheidung ist grundlegend für die Fähigkeit von MongoDB, horizontal zu skalieren und eine hohe Verfügbarkeit aufrechtzuerhalten. Indem nicht für jede Operation eine perfekte Synchronisierung aller Knoten erforderlich ist, kann MongoDB weiterhin Lese- und Schreibvorgänge bedienen, selbst wenn einige Knoten vorübergehend nicht verfügbar sind oder nachhinken.

Die Kompromisse der Eventual Consistency

Vorteile: Höhere Verfügbarkeit, bessere Leistung (geringere Latenz bei Schreibvorgängen) und größere Skalierbarkeit für verteilte Systeme.
Nachteile: Anwendungen müssen so ausgelegt sein, dass sie die Möglichkeit des Lesens veralteter Daten handhaben können. Dies ist besonders relevant für Operationen, bei denen sofortige Konsistenz über alle Replikate hinweg kritisch ist.

Lese- und Schreibkonfigurationen (Read and Write Concerns) von MongoDB: Konsistenz abstimmen

Während MongoDB standardmäßig eventual consistency verwendet, bietet es leistungsstarke Mechanismen – Read Concerns und Write Concerns – die es Entwicklern ermöglichen, den Grad der Konsistenz pro Operation anzupassen. Dies ermöglicht es Ihnen, Konsistenz, Verfügbarkeit und Leistung entsprechend den Anforderungen Ihrer Anwendung auszugleichen.

Write Concerns

Ein Write Concern beschreibt die Ebene der Bestätigung, die von MongoDB für einen Schreibvorgang angefordert wird. Er legt fest, wie viele Replica-Set-Mitglieder den Schreibvorgang bestätigen müssen, bevor die Operation als erfolgreich zurückgemeldet wird.

Wichtige Write Concern-Optionen:

w: Gibt die Anzahl der mongod-Instanzen an, die den Schreibvorgang bestätigen müssen.
- w: 0: Keine Bestätigung. Der Client wartet nicht auf eine Antwort von der Datenbank. Dies bietet den höchsten Durchsatz, birgt jedoch das Risiko von Datenverlust, wenn der Primärknoten unmittelbar nach dem Schreibvorgang ausfällt.
- w: 1 (Standard): Bestätigung nur vom primären Knoten. Der Primärknoten bestätigt, dass er den Schreibvorgang empfangen und verarbeitet hat. Es ist schnell, garantiert aber nicht, dass der Schreibvorgang auf irgendeinen Secondary repliziert wurde.
- w: "majority": Bestätigung von der Mehrheit der Replica-Set-Mitglieder (einschließlich des Primärknotens). Dies bietet stärkere Dauerhaftigkeitsgarantien, da der Schreibvorgang auf einer Mehrheit der Knoten committed wird. Wenn der Primärknoten ausfällt, ist garantiert, dass die Daten auf einer Mehrheit der anderen Knoten vorhanden sind.
j: Gibt an, ob die mongod-Instanz in das On-Disk-Journal schreiben soll, bevor der Schreibvorgang bestätigt wird. Die Aktivierung des Journalings (j: true) bietet Dauerhaftigkeit, selbst wenn der mongod-Prozess abstürzt.
wtimeout: Ein Zeitlimit für die Erfüllung des Write Concerns. Wenn der Write Concern nicht innerhalb dieser Zeit erfüllt wird, gibt der Schreibvorgang einen Fehler zurück.

Beispiel Write Concern (mit w: "majority" und Journaling):

db.products.insertOne(
  { item: "laptop", qty: 50 },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
);

Tipp: Für kritische Daten, die dauerhaft und hochverfügbar sein müssen, wird w: "majority" mit j: true empfohlen. Für weniger kritische Daten oder Hochdurchsatz-Logging kann w: 1 oder sogar w: 0 akzeptabel sein.

Read Concerns

Ein Read Concern ermöglicht es Ihnen, den Grad der Konsistenz und Isolation für Leseoperationen anzugeben. Er bestimmt, welche Daten MongoDB an Ihre Abfragen zurückgibt, insbesondere in einer replizierten Umgebung.

Wichtige Read Concern-Optionen:

local: Gibt Daten von der Instanz (primär oder sekundär) zurück, mit der der Client verbunden ist. Dies ist die Standardeinstellung für eigenständige Instanzen und Secondaries. Für Replica-Sets bietet dies die geringste Latenz, kann aber veraltete Daten zurückgeben.
available: Gibt Daten von der Instanz zurück, ohne zu garantieren, dass die Daten auf eine Mehrheit des Replica-Sets geschrieben wurden. Ähnlich wie local priorisiert es Verfügbarkeit und niedrige Latenz.
majority: Gibt Daten zurück, die von einer Mehrheit der Replica-Set-Mitglieder bestätigt wurden. Dies garantiert, dass die Daten dauerhaft sind und nicht zurückgesetzt werden. Es bietet eine stärkere Konsistenz als local oder available, jedoch zu Lasten einer potenziell höheren Latenz.
linearizable: Garantiert, dass die zurückgegebenen Daten den aktuellsten bestätigten Schreibvorgang global widerspiegeln. Dies ist der stärkste Read Concern und stellt sicher, dass Lesevorgänge alle Schreibvorgänge sehen, die durch einen majority Write Concern bestätigt wurden. Dies kann zu erheblichen Leistungseinbußen führen und ist nur für Lesevorgänge vom Primärknoten verfügbar.
snapshot (für Multi-Dokument-Transaktionen): Garantiert, dass die Abfrage Daten von einem bestimmten Zeitpunkt zurückgibt, sodass Lesevorgänge innerhalb einer Transaktion über mehrere Dokumente hinweg konsistent sind.

Beispiel Read Concern (mit majority):

db.products.find(
  { item: "laptop" },
  { readConcern: { level: "majority" } }
);

Warnung: Obwohl linearizable starke Konsistenz bietet, hat es Auswirkungen auf die Leistung. Verwenden Sie es mit Bedacht für Szenarien, in denen eine strenge Reihenfolge und globale Sichtbarkeit von Schreibvorgängen kritisch sind.

Warum BASE und Eventual Consistency für die Skalierung wichtig sind

Das BASE-Modell und die eventual consistency sind Kernvoraussetzungen für die Skalierbarkeit und hohe Verfügbarkeit von MongoDB:

Horizontale Skalierung (Sharding): Durch die Lockerung der sofortigen Konsistenz kann MongoDB Daten auf mehrere Shards (Cluster von Replica-Sets) verteilen. Jeder Shard arbeitet relativ unabhängig, sodass die Datenbank horizontal skaliert werden kann, um massive Datensätze und hohen Durchsatz zu bewältigen, ohne dass jeder Knoten im gesamten verteilten System zu jeder Zeit perfekt synchronisiert sein muss.
Hohe Verfügbarkeit und Fehlertoleranz: In einem Replica-Set kann, wenn der primäre Knoten nicht verfügbar wird, ein neuer Primärknoten aus den Secondaries gewählt werden. Eventual consistency bedeutet, dass sekundäre Knoten auch während Failovern weiterhin Lesevorgänge bedienen können (abhängig vom Read Concern) und das System verfügbar bleibt. Wenn der Primärknoten bei jedem Schreibvorgang auf alle Secondaries warten müsste, könnte ein einzelner nachhinkender Secondary das gesamte System ausbremsen.
Leistung: Weniger strenge Konsistenzanforderungen bedeuten eine geringere Latenz bei Schreibvorgängen und einen höheren Gesamtdurchsatz, da das System nicht blockieren und auf Bestätigungen von allen Knoten warten muss, bevor es fortfährt.

Durch die Bereitstellung abstimmbarer Konsistenz über Read und Write Concerns befähigt MongoDB Entwickler, fundierte Entscheidungen zu treffen. Anwendungen, die hohe Verfügbarkeit und Durchsatz priorisieren (z. B. IoT-Datenerfassung, Echtzeitanalysen), können sich für schwächere Konsistenz entscheiden. Umgekehrt können Anwendungen, die eine stärkere Datenintegrität erfordern (z. B. Finanztransaktionen, Bestandsaktualisierungen), stärkere Konsistenzstufen wählen und die damit verbundenen Leistungseinbußen akzeptieren.

Praktische Überlegungen und Best Practices

Kritische Daten identifizieren: Bestimmen Sie, welche Daten unbedingt starke Konsistenz erfordern (z. B. Kontostände) im Vergleich zu Daten, die eventual consistency tolerieren können (z. B. Benutzerprofilaktualisierungen, Sitzungsdaten).
Auf Idempotenz auslegen: Bei Verwendung schwächerer Write Concerns kann ein Schreibvorgang auf dem Primärknoten erfolgreich sein, aber vor der Replikation auf Secondaries fehlschlagen, was zu einem anschließenden Rollback führt und der Client glaubt, der Schreibvorgang sei fehlgeschlagen. Wenn der Client den Vorgang wiederholt, könnte dies zu Duplikaten führen. Gestalten Sie Ihre Operationen nach Möglichkeit idempotent.
Clientseitiges Read-Your-Own-Writes: Wenn ein Benutzer einen Schreibvorgang durchführt und dann sofort versucht, ihn zu lesen, könnte er veraltete Daten sehen, wenn er mit einem schwachen Read Concern von einem Secondary liest. Um sicherzustellen, dass ein Benutzer immer seine eigenen aktuellen Schreibvorgänge liest, sollten Sie solche Lesevorgänge entweder an den Primärknoten leiten oder einen majority Read Concern verwenden, möglicherweise gekoppelt mit einem majority Write Concern für diese spezifischen Operationen.
Überwachung: Behalten Sie die Replica-Set-Verzögerung im Auge, indem Sie rs.printReplicationInfo() oder MongoDB-Atlas-Metriken verwenden. Eine hohe Replikationsverzögerung kann Probleme mit der eventual consistency verschärfen.

Eine nützlichere Art, über MongoDB-Konsistenz nachzudenken

MongoDB ist nicht einfach in jeder Situation „eventuell konsistent“, und es so zu behandeln, führt zu schlampigen Designs. Ein Lesevorgang vom Primärknoten nach einem bestätigten Schreibvorgang kann sich ganz anders verhalten als ein Lesevorgang, der an einen Secondary weitergeleitet wird, der ein paar Sekunden hinterherhinkt. Ein mit w: 1 bestätigter Schreibvorgang hat ein anderes Risikoprofil als ein mit w: "majority" bestätigter Schreibvorgang. Die Konsistenzgeschichte hängt von Ihrer Read Preference, Ihrem Read Concern, Ihrem Write Concern, der Topologie und davon ab, ob zur falschen Zeit ein Failover auftritt.

Für eine normale Produktseite ist eventual consistency möglicherweise in Ordnung. Wenn ein Administrator eine Produktbeschreibung ändert und ein Kunde kurzzeitig die alte Beschreibung von einem Secondary sieht, sind die geschäftlichen Auswirkungen in der Regel gering. Für eine Bestellbestätigungsseite ist die Toleranz anders. Wenn ein Kunde eine Bestellung aufgibt und der nächste Bildschirm sie nicht finden kann, auch nur kurzzeitig, fühlt sich das System kaputt an. Hier ist das Read-Your-Own-Writes-Verhalten wichtiger als der rohe Durchsatz.

Ein praktisches Muster ist die Verwendung stärkerer Einstellungen für benutzerorientierte Bestätigungspfade und lockerer Einstellungen für Hintergrund- oder Analysepfade. Beispielsweise könnte ein Bestellschreibvorgang w: "majority" verwenden, und der sofortige Bestätigungslesevorgang könnte zum Primärknoten gehen. Ein Dashboard, das die Aktivitäten von gestern zusammenfasst, kann von Secondaries lesen, da eine kleine Verzögerung normalerweise akzeptabel ist. Eine Log-Erfassungspipeline kann eine schwächere Bestätigung akzeptieren als ein Abrechnungsbuch, sollte aber dennoch ehrlich darüber sein, was bei einem Absturz oder Failover verloren gehen kann.

Seien Sie auch vorsichtig mit dem Wort „verfügbar“. Eine verteilte Datenbank kann während Ausfällen weiterhin einige Anfragen bedienen, aber das bedeutet nicht, dass jede Anfrage mit denselben Garantien erfolgreich sein kann. Eine Primärknotenwahl pausiert Schreibvorgänge für einen kurzen Zeitraum. Ein Secondary kann Lesevorgänge nur bedienen, wenn Ihre Read Preference dies zulässt. Eine Netzwerkpartition kann MongoDB dazu zwingen, Sicherheit gegenüber der Annahme von Schreibvorgängen auf einem Knoten zu priorisieren, der nicht mehr zur Mehrheit gehört. Dies sind keine Fehler; es sind die Kompromisse, die verhindern, dass replizierte Daten in zwei widersprüchliche Verläufe aufgespalten werden.

Hier ist die Entscheidung, die ich in einen Anwendungsdesign-Hinweis schreiben würde:

Kritische Konto-, Bestell- und Bestandsmutationen:
- writeConcern: majority
- Lesen vom Primärknoten bei Bestätigung der eigenen Aktion des Benutzers
- wiederholbare Schreibvorgänge verwenden, wo der Treiber sie unterstützt
- Schreiboperationen mit Anfrage-IDs oder eindeutigen Schlüsseln idempotent machen

Suchseiten, Feed-Seiten, Analysen und nicht-kritische Profilanzeigen:
- Sekundäre Lesevorgänge können akzeptabel sein
- Veraltete Ergebnisse in der Benutzeroberfläche tolerieren
- Zeitstempel anzeigen, wenn Aktualität wichtig ist

Diese Art von Hinweis ist nützlicher, als zu sagen „MongoDB ist BASE“ und weiterzumachen. Er sagt zukünftigen Ingenieuren, wo veraltete Lesevorgänge akzeptabel sind und wo nicht.