Moderne databases moeten de capaciteit hebben om gegevens vast te leggen en erop te reageren terwijl ze in realtime stromen. Dit verklaart waarom MongoDB een functie heeft genaamd MongoDB Change Streams die verantwoordelijk is voor het in realtime vastleggen en beantwoorden van gegevens. Change Streams is een functie die is geïntroduceerd om informatie in realtime van applicatie naar de database te streamen. Het is gebaseerd op een aggregatieraamwerk dat verzamelingen bewaakt en wijzigingen in de database en databaseverzameling mogelijk maakt. Bovendien kan MongoDB Change Stream gegevens van IOT-sensoren vastleggen en rapporten bijwerken, zoals wijzigingen in operationele gegevens in een onderneming. Deze blog opent een verhandeling over MongoDB Change Stream en wijzigingsaanbevelingen in productie.
MongoDB-streams wijzigen en verzameling laten vallen
Het hernoemen of verwijderen van een database of verzameling zal leiden tot het sluiten van de cursor als er een open wijzigingsstroom was die de verwijderde verzameling tegenwerkte. Het hernoemen of neerzetten van een verzameling zorgt ervoor dat de cursor met FullDocument:updateLookup null retourneert op een bepaald opzoekdocument. Er treedt een fout op als men probeert te hervatten na het verwijderen van een database met een lopende wijzigingsstroom.
Bovendien gaan alle wijzigingen in gegevens die zijn aangebracht voordat de naam van een verzameling wordt gewijzigd met een wijzigingsstroom die er tegen loopt, verloren. De documentlimiet voor Change stream is nog steeds 16 MB BSON; daarom worden documenten groter dan 16 MB niet geaccepteerd. Als men probeert te werken met een document dat groter is dan 16 MB, mislukt de melding en wordt het document vervangen door een ander document dat aan de ingestelde limiet voldoet.
Als een collectie of database met geopende wijzigingsstromen wordt verwijderd of hernoemd, hebben de wijzigingsstroomcursors de neiging om te sluiten naarmate ze verder gaan naar dat punt in de oplog. Als u de streamcursors wijzigt met het volledige document, kan de updateLookup-optie null teruggeven aan het zoekdocument.
Daarom resulteert een poging om wijzigingsstreams voor een collectie die is verwijderd, te hervatten in een fout. Elk optreden van gegevenswijzigingen in de verzameling tussen de laatste gebeurtenis van de vastgelegde wijzigingsstroom en de verwijdering van de verzameling gaat verloren.
Wijziging van streamresponsdocumenten moet voldoen aan de 16 MB BSON-documentlimiet. Afhankelijk van de grootte van de documenten in de collectie waartegen u de wijzigingsstroom opent, kunnen meldingen mislukken als het resulterende meldingsdocument groter is dan 16 MB. Een goed voorbeeld zijn de update-bewerkingen op de wijzigingsstromen die zijn ingesteld om een volledig bijgewerkt document te retourneren of processen te vervangen/invoegen met het document op de limiet of iets onder de limiet.
MongoDB Stream- en replicasets wijzigen
Een MongoDB Replica Set is een verzameling processen in MongoDB waarvan de dataset niet verandert; dat wil zeggen, de dataset blijft hetzelfde. In het geval van replicasets met arbiterleden, zullen wijzigingsstromen waarschijnlijk inactief blijven als er niet voldoende leden met de gegevens beschikbaar zijn, zodat de meerderheid de bewerkingen niet kan uitvoeren. We kunnen bijvoorbeeld een replicaset overwegen met drie leden met twee gegevensdragende knooppunten naast een arbiter. In het geval dat de secundaire uitvalt, bijvoorbeeld als gevolg van een storing, upgrade of onderhoud, is het onmogelijk dat de schrijfbewerkingen met meerderheid worden vastgelegd. De wijzigingsstroom blijft open maar stuurt geen meldingen. In het onderhavige scenario kan de applicatie alle operaties inhalen die hebben plaatsgevonden in de periode van downtime, zolang de laatste operatie die door de applicatie is ontvangen zich nog in de oplog van die specifieke replicaset bevindt. Bovendien wordt de opdracht rs.printReplicationInfo() gebruikt om gegevens op te halen uit oplog; opgehaalde gegevens omvatten een reeks bewerkingen en grootte van oplog.
Als de uitvaltijd aanzienlijk wordt geschat, bijvoorbeeld om een upgrade uit te voeren of in het geval van een ramp, is het vergroten van de oplog-grootte de beste optie om de bewerkingen te behouden voor een periode die langer is dan de geschatte uitvaltijd. Om oplog-statusinformatie op te halen, is de gebruikte opdracht printReplicationInfo(). De opdracht haalt niet alleen de oplog-statusinformatie op, maar ook de oplog-grootte en het tijdsbereik van de bewerkingen.
Beschikbaarheid MongoDB-wijzigingsstreams
MongoDB-wijzigingsstromen zijn verkrijgbaar voor replicasets en sharded-clusters:Lees Concern "meerderheid" Enablement, Storage Engine en Replica Set Protocol Version. Read Concern "meerderheid" inschakelen:Vanaf MongoDB versie 4.2 en hoger zijn wijzigingsstromen toegankelijk ondanks de heersende omstandigheden van de "meerderheid" read concern-ondersteuning, wat betekent dat de read concern-meerderheidsondersteuning kan worden in- of uitgeschakeld. In MongoDB versie 4.0 en oudere versies, Wijzigingsstreams zijn alleen beschikbaar als de "meerderheid" leeszorgondersteuning is geactiveerd.
- Opslagengine:WiredTiger-opslagengine is het type opslagengine dat wordt gebruikt door de replicasets en de shardclusters.
- Replicaset-protocolversie:replicasets en shard-clusters moeten altijd versie 1 van het replicaset-protocol (pv1) gebruiken.
MongoDB Shard-clusters
Sharded-clusters in MongoDB bestaan uit shards, mongo's en configuratieservers. Een shard bestaat uit een subset van shardgegevens. In het geval van MongoDB 3.6 worden shards gebruikt als replicaset. Mongos biedt een interface tussen sharded-clusters en clienttoepassingen; mongos speelt de rol van een query-router. Vanaf MongoDB versie 4.4 en hoger ondersteunt mongos hedged reads om latenties te verminderen. Config-servers zijn de opslaglocaties voor clusterconfiguratie-instellingen en metadata.
Wijzigingsstromen gebruiken een globale logische klok om een globale volgorde van veranderingen over shards te bieden. MongoDB zorgt ervoor dat de volgorde van wijzigingen wordt gehandhaafd en dat de meldingen van de wijzigingsstroom veilig kunnen worden geïnterpreteerd in de volgorde waarin ze zijn ontvangen. De cursor van de wijzigingsstroom die is geopend tegen een cluster met 3 shards, retourneert bijvoorbeeld de wijzigingsmeldingen met betrekking tot de totale volgorde van de wijzigingen over de drie shards.
Om de totale volgorde van wijzigingen te garanderen, controleert Mongos bij elke shard of er meer recente wijzigingen zijn voor elke wijzigingsmelding. Sharded-clusters met één tot meerdere shards met weinig of geen verzamelactiviteit of die 'koud' zijn, hebben waarschijnlijk negatieve effecten op de reactietijd van de wijzigingsstroom, aangezien de mongo's nog steeds met die koude scherven moeten controleren om de totale volgorde van de wijzigingen te garanderen. Dit effect is mogelijk duidelijker wanneer shards geografisch zijn gedistribueerd of wanneer workloads met de meeste bewerkingen plaatsvinden op een subset van shards in een cluster. Als de shardverzameling een hoog activiteitsniveau heeft, slagen de mongo's er mogelijk niet in om de wijzigingen in alle shards bij te houden. Overweeg het gebruik van meldingsfilters voor dit soort verzameling, bijvoorbeeld door de $match-pijplijn door te geven, die is geconfigureerd om alleen de invoegbewerkingen te filteren.
In het geval van shard-collecties, veroorzaken multi:juiste update-bewerkingen waarschijnlijk wijzigingsstromen die worden geopend tegen de collectie om meldingen te verzenden voor verweesde documenten. Vanaf het moment dat een verzameling zonder shard wordt geshard tot het moment waarop de wijzigingsstroom bij het eerste migratieblok komt, bevat de documentKey in het meldingsdocument voor de wijzigingsstroom alleen de document-ID en niet de volledige shardsleutel.
Conclusie
Het doel van de wijzigingsstromen is om het mogelijk te maken dat de gegevens van de applicatie in realtime worden gewijzigd, zonder het risico dat de oplog wordt achtervolgd en zonder enig spoor van complexiteit. MongoDB-applicaties gebruiken wijzigingsstromen om te ondertekenen voor gegevenswijzigingen in een database, een verzameling of de implementatie, en er onmiddellijk op te reageren. Aangezien wijzigingsstromen gebruik maken van het aggregatieraamwerk, kunnen applicaties de specifieke wijzigingen filteren en zelf meldingen omzetten.