Moderne Datenbanken müssen in der Lage sein, Daten zu erfassen und darauf zu reagieren, während sie in Echtzeit fließen. Dies erklärt, warum MongoDB über eine Funktion namens MongoDB Change Streams verfügt, die für die Erfassung und Reaktion auf Daten in Echtzeit verantwortlich ist. Change Streams ist eine Funktion, die eingeführt wurde, um Informationen in Echtzeit von der Anwendung an die Datenbank zu streamen. Es basiert auf einem Aggregationsframework, das Sammlungen überwacht und Änderungen in Datenbanken und Datenbanksammlungen zulässt. Darüber hinaus kann MongoDB Change Stream Daten von IoT-Sensoren erfassen und Berichte wie Betriebsdatenänderungen in einem Unternehmen aktualisieren. Dieser Blog eröffnet den Diskurs über MongoDB Change Stream und Änderungsempfehlungen in der Produktion.
MongoDB Change Streams und Löschen der Sammlung
Das Umbenennen oder Löschen einer Datenbank oder Sammlung führt zum Schließen des Cursors, wenn ein offener Änderungsstrom gegen die gelöschte Sammlung gearbeitet hat. Durch das Umbenennen oder Löschen einer Sammlung wird der Cursor mit FullDocument:updateLookup veranlasst, null für jedes angegebene Nachschlagedokument zurückzugeben. Ein Fehler tritt auf, wenn versucht wird, nach dem Löschen einer Datenbank mit einem laufenden Änderungsstrom fortzufahren.
Außerdem gehen alle Änderungen an Daten verloren, die vor dem Umbenennen einer Sammlung mit einem laufenden Änderungsstrom vorgenommen wurden. Das Dokumentenlimit für Change Stream beträgt weiterhin 16 MB BSON; Daher werden Dokumente, die größer als 16 MB sind, nicht akzeptiert. Wenn man versucht, mit einem Dokument zu arbeiten, das größer als 16 MB ist, schlägt die Benachrichtigung fehl, und das Dokument wird durch ein anderes Dokument ersetzt, das das festgelegte Limit erfüllt.
Wenn eine Sammlung oder Datenbank mit geöffneten Änderungsströmen gelöscht oder umbenannt wird, neigen die Änderungsstrom-Cursor dazu, sich zu schließen, wenn sie zu diesem Punkt im Oplog vorrücken. Wenn Sie die Stream-Cursor mit dem vollständigen Dokument ändern, gibt die updateLookup-Option möglicherweise null an das Suchdokument zurück.
Daher führt der Versuch, Änderungsströme für eine gelöschte Sammlung fortzusetzen, zu einem Fehler. Alle Datenänderungen in der Sammlung zwischen dem letzten erfassten Ereignis des Änderungsstroms und dem Löschereignis der Sammlung gehen verloren.
Antwortdokumente zur Änderung des Streams müssen das 16-MB-BSON-Dokumentlimit einhalten. Abhängig von der Größe der Dokumente in der Sammlung, für die Sie den Änderungsstrom öffnen, können Benachrichtigungen fehlschlagen, wenn das resultierende Benachrichtigungsdokument größer als 16 MB ist. Ein gutes Beispiel sind die Aktualisierungsvorgänge für die Änderungsströme, die so eingerichtet sind, dass sie ein vollständig aktualisiertes Dokument zurückgeben oder Prozesse zum Ersetzen/Einfügen mit dem Dokument am Limit oder leicht unter dem Limit zurückgeben.
MongoDB Change Stream und Replikatsätze
Ein MongoDB-Replikatsatz ist eine Sammlung von Prozessen in MongoDB, deren Datensatz sich nicht ändert; das heißt, der Datensatz bleibt gleich. Im Fall von Replikatsätzen mit Arbiter-Mitgliedern bleiben Änderungsströme wahrscheinlich im Leerlauf, wenn nicht genügend Mitglieder, die die Daten tragen, verfügbar sind, so dass die Mehrheit die Operationen nicht festschreiben kann. Beispielsweise können wir einen Replikatsatz mit drei Mitgliedern mit zwei datentragenden Knoten neben einem Arbiter betrachten. Falls die Sekundärseite ausfällt, z. B. infolge eines Ausfalls oder Upgrades oder einer Wartung, können die Schreiboperationen nicht mehrheitlich festgeschrieben werden. Der Änderungsstream bleibt geöffnet, sendet jedoch keine Benachrichtigungen. Im vorliegenden Szenario kann die Anwendung alle Operationen nachholen, die während der Ausfallzeit stattgefunden haben, solange sich die letzte von der Anwendung empfangene Operation noch im Oplog dieses bestimmten Replikatsatzes befindet. Zusätzlich wird der Befehl rs.printReplicationInfo() verwendet, um Daten aus oplog abzurufen; Die abgerufenen Daten umfassen eine Reihe von Operationen und die Größe von oplog.
Wenn die Ausfallzeit erheblich geschätzt wird, z. B. um ein Upgrade durchzuführen oder im Fall einer Katastrophe, ist die Erhöhung der Oplog-Größe die beste Option, um den Betrieb für einen Zeitraum von mehr als aufrechtzuerhalten die ungefähre Ausfallzeit. Um Oplog-Statusinformationen abzurufen, ist der verwendete Befehl printReplicationInfo(). Der Befehl ruft nicht nur die Oplog-Statusinformationen ab, sondern auch die Oplog-Größe und den Zeitraum der Operationen.
Verfügbarkeit von MongoDB Change Streams
MongoDB-Änderungsstreams sind für Replikatsätze und Sharding-Cluster erhältlich:Read Concern „majority“ Enablement, Storage Engine und Replica Set Protocol Version. Read Concern „Majority“-Aktivierung:Beginnend mit MongoDB Version 4.2 und höher sind Änderungsströme trotz der vorherrschenden Umstände der „Majority“ Read Concern-Unterstützung zugänglich, was bedeutet, dass die Read Concern Majority-Unterstützung aktiviert oder deaktiviert werden kann. In MongoDB Version 4.0 und Ältere Versionen, Änderungsströme sind nur verfügbar, wenn die Unterstützung für "mehrheitliche" Leseangelegenheiten aktiviert ist.
- Speicher-Engine:WiredTiger-Speicher-Engine ist der Speicher-Engine-Typ, der von den Replica-Sets und den Sharding-Clustern verwendet wird.
- Version des Replikatsatzprotokolls:Replikatsätze und fragmentierte Cluster müssen immer Version 1 des Replikatsatzprotokolls (pv1) verwenden.
Sharded MongoDB-Cluster
Sharded-Cluster in MongoDB bestehen aus Shards, Mongos und Konfigurationsservern. Ein Shard besteht aus einer Teilmenge von Shard-Daten. Im Fall von MongoDB 3.6 werden Shards als Replikatsatz verwendet. Mongos stellt eine Schnittstelle zwischen Sharded-Clustern und Client-Anwendungen bereit; mongos spielt die Rolle eines Abfragerouters. Ab MongoDB-Version 4.4 und höher unterstützt Mongos abgesicherte Lesevorgänge, um Latenzen zu verringern. Konfigurationsserver sind die Speicherorte für Clusterkonfigurationseinstellungen und Metadaten.
Change Streams verwenden eine globale logische Uhr, um eine globale Reihenfolge von Änderungen über Shards hinweg bereitzustellen. MongoDB stellt sicher, dass die Reihenfolge der Änderungen beibehalten wird und dass die Benachrichtigungen des Änderungsstroms in der Reihenfolge, in der sie empfangen wurden, sicher interpretiert werden können. Beispielsweise gibt der Cursor des Änderungsstroms, der für einen 3-Shard-Cluster geöffnet ist, die Änderungsbenachrichtigungen bezüglich der Gesamtreihenfolge der Änderungen in den drei Shards zurück.
Um die vollständige Reihenfolge der Änderungen zu gewährleisten, überprüft Mongos bei jedem Shard, ob es neuere Änderungen für jede Änderungsbenachrichtigung gesehen hat. Sharded-Cluster mit einem oder mehreren Shards mit geringer oder keiner Erfassungsaktivität oder „kalt“ haben wahrscheinlich negative Auswirkungen auf die Reaktionszeit des Änderungsstroms, da die Mongos immer noch mit diesen kalten Shards überprüfen müssen, um die vollständige Reihenfolge der Änderungen sicherzustellen. Dieser Effekt kann deutlicher werden, wenn Shards geografisch verteilt sind oder wenn Workloads mit den meisten Vorgängen auf einer Teilmenge von Shards in einem Cluster auftreten. Wenn die Shard-Sammlung ein hohes Maß an Aktivität aufweist, schaffen es die Mongos möglicherweise nicht, die Änderungen in allen Shards zu verfolgen. Erwägen Sie die Verwendung von Benachrichtigungsfiltern für diese Art von Erfassung, indem Sie beispielsweise die $match-Pipeline übergeben, die so konfiguriert ist, dass nur die Einfügevorgänge gefiltert werden.
Im Fall von fragmentierten Sammlungen führen mehrere ordnungsgemäße Aktualisierungsvorgänge wahrscheinlich dazu, dass Änderungsdatenströme, die für die Sammlung geöffnet werden, Benachrichtigungen für verwaiste Dokumente senden. Ab dem Zeitpunkt, an dem eine unsharded-Sammlung fragmentiert wird, bis zu dem Zeitpunkt, an dem der Change Stream den ersten Migrationsabschnitt erreicht, enthält der documentKey im Change Stream-Benachrichtigungsdokument nur die Dokument-ID und nicht den vollständigen Shard-Schlüssel.
Fazit
Der Zweck der Änderungsströme besteht darin, Datenänderungen der Anwendung in Echtzeit zu ermöglichen, ohne das Risiko, den Oplog zu verfolgen, und ohne jede Spur von Komplexität. MongoDB-Anwendungen verwenden Änderungsströme, um Datenänderungen in einer Datenbank, einer Sammlung oder der Bereitstellung zu signieren und sofort darauf zu reagieren. Da Änderungsströme das Aggregations-Framework verwenden, können Anwendungen die spezifischen Änderungen filtern und Benachrichtigungen selbst konvertieren.
