Moderna databaser måste ha kapacitet att fånga in och reagera på data när de flödar i realtid. Detta förklarar varför MongoDB har en funktion som heter MongoDB Change Streams som ansvarar för att fånga in och svara på data i realtid. Change Streams är en funktion som introduceras för att strömma information från applikationen till databasen i realtid. Den är baserad på ett aggregeringsramverk som övervakar samlingar och tillåter förändringar att ske i databas- och databassamling. Dessutom kan MongoDB Change Stream fånga data från IOT-sensorer och uppdatera rapporter som förändringar av driftsdata i ett företag. Den här bloggen kommer att öppna diskussionen om MongoDB Change Stream och ändra rekommendationer i produktionen.
MongoDB Ändra strömmar och tappa samling
Att byta namn på eller ta bort en databas eller samling kommer att leda till att markören stängs om det fanns en öppen ändringsström som fungerade mot den släppta samlingen. Om du byter namn på eller släpper en samling får markören FullDocument:updateLookup att returnera null på ett givet uppslagsdokument. Ett fel uppstår om man försöker återuppta efter att ha släppt en databas med en pågående ändringsström.
Dessutom förloras alla ändringar i data som gjorts innan man döpte om en samling med en ändringsström som körs mot. Dokumentgränsen för Change stream är fortfarande 16 MB BSON; därför accepteras inte dokument som är större än 16MB. Om man försöker arbeta med ett dokument som är större än 16 MB misslyckas aviseringen och dokumentet ersätts med ett annat dokument som uppfyller den angivna gränsen.
När en samling eller databas med ändringsströmmar öppnade mot den släpps eller byter namn, tenderar ändringsströmmarkörerna att stängas när de går till den punkten i oploggen. Om du ändrar strömmarkörerna med hela dokumentet kan alternativet updateLookup returnera null till sökdokumentet.
Därför kommer ett försök att återuppta ändringsströmmar mot en samling som har tagits bort att resultera i ett fel. Alla förekomster av dataändringar i insamlingen mellan den senaste händelsen i ändringsströmmen som registrerades och insamlingshändelsen förloras.
Ändring av strömsvarsdokument måste överensstämma med 16 MB BSON-dokumentgränsen. Beroende på storleken på dokumenten i samlingen som du öppnar ändringsflödet mot, kan meddelanden misslyckas om det resulterande meddelandedokumentet är mer än 16 MB. Ett bra exempel är uppdateringsoperationerna på ändringsströmmarna som är inställda för att returnera ett helt uppdaterat dokument eller ersätta/infoga processer med dokumentet vid gränsen eller något under gränsen.
MongoDB Change Stream and Replica Sets
En MongoDB Replica Set är en samling processer i MongoDB vars datauppsättning inte ändras; det vill säga att datamängden förblir densamma. I fallet med replikuppsättningar som har arbitermedlemmar kommer förändringsströmmar sannolikt att förbli inaktiva om tillräckligt många medlemmar som bär data inte är tillgängliga så att majoriteten inte kan utföra operationerna. Till exempel kan vi överväga en replikuppsättning som har tre medlemmar med två databärande noder vid sidan av en arbiter. Om sekundären råkar vara nere, t.ex. som ett resultat av fel eller uppgradering eller underhåll, kommer det att vara omöjligt för skrivoperationerna att vara majoritetsbeslutade. Ändringsströmmen kommer att förbli öppen men skickar inga aviseringar. I det aktuella scenariot kan applikationen komma ikapp med alla operationer som har ägt rum under perioden med stillestånd, så länge som den senaste operationen som applikationen tog emot fortfarande finns i den aktuella replikuppsättningen. Dessutom används kommandot rs.printReplicationInfo() för att hämta data från oplog; data som hämtas inkluderar en rad operationer och storleken på oplog.
Om driftstoppet uppskattas avsevärt, till exempel för att utföra en uppgradering eller i händelse av en katastrof, är en ökning av oplogstorleken det bästa alternativet för att behålla verksamheten under en period som är längre än den ungefärliga stilleståndstiden. För att hämta information om oplogstatus är kommandot som används printReplicationInfo(). Kommandot hämtar inte bara oplogstatusinformationen utan även oplogstorleken och tidsintervallet för operationerna.
MongoDB Change Streams Tillgänglighet
MongoDB-ändringsströmmar kan erhållas för replikuppsättningar och fragmenterade kluster:Läs Bekymrad "majority" Enablement, Storage Engine och Replica Set Protocol Version. Aktivering för "majoritet" för läsproblem:Från och med MongoDB version 4.2 och senare är ändringsströmmar tillgängliga trots rådande omständigheter för stödet för "majority" läsproblem, vilket innebär att majoritetsstödet för läsproblem kan aktiveras eller inaktiveras. I MongoDB version 4.0 och äldre versioner, Ändra strömmar är endast tillgängliga om stödet för "majoriteten" är aktiverat.
- Lagringsmotor:WiredTiger-lagringsmotor är lagringsmotortypen som används av replikuppsättningarna och de sönderdelade klustren.
- Replica Set Protocol Version:Replikuppsättningar och fragmenterade kluster måste alltid använda version 1 av replikuppsättningsprotokollet (pv1).
MongoDB Sharded Clusters
Delade kluster i MongoDB består av shards, mongos och config-servrar. En shard består av en delmängd av shard data. I fallet med MongoDB 3.6 används shards som en replikuppsättning. Mongos tillhandahåller ett gränssnitt mellan fragmenterade kluster och klientapplikationer; mongos spelar rollen som en frågerouter. Från MongoDB version 4.4 och senare stöder mongos säkrade läsningar för att få ner latenser. Konfigurationsservrar är lagringsplatserna för klusterkonfigurationsinställningar och metadata.
Change-strömmar använder en global logisk klocka för att ge en global ordning av ändringar över skärvor. MongoDB säkerställer att ändringsordningen bibehålls och att ändringsströmmens meddelanden kan tolkas säkert i den ordning de togs emot. Till exempel, ändringsströmmens markör öppnad mot ett kluster med 3 skärvor returnerar ändringens meddelanden om den totala ordningen för ändringarna över de tre skärvorna.
För att säkerställa den totala ordningen av ändringar kontrollerar Mongos med varje shard för att se om det har sett nyare ändringar för varje ändringsmeddelande. Delade kluster med en till flera skärvor med liten eller ingen insamlingsaktivitet eller är "kalla" kommer sannolikt att ha negativa effekter på förändringsströmmens svarstid eftersom mongonerna fortfarande måste kontrollera med dessa kalla skärvor för att säkerställa den totala ordningen av förändringarna. Denna effekt kan vara mer påtaglig när skärvor är geografiskt fördelade eller när arbetsbelastningar med de flesta av operationerna inträffar på en delmängd av skärvor i ett kluster. Om den skärvade samlingen har en hög aktivitetsnivå kanske mongon inte lyckas hålla reda på förändringarna över alla skärvor. Överväg att använda aviseringsfilter för den här typen av insamling, till exempel att passera $match-pipelinen, som är konfigurerad att filtrera endast infogningsoperationerna.
I fallet med fragmenterade samlingar, kommer sannolikt flera:korrekta uppdateringsåtgärder att göra att ändringsströmmar som öppnas mot samlingen skickar meddelanden om föräldralösa dokument. Från det att en odelad samling delas fram till den tidpunkt då ändringsströmmen når den första migreringsdelen, inkluderar documentKey i meddelandet om ändringsström endast dokument-id och inte den fullständiga shardnyckeln.
Slutsats
Syftet med förändringsströmmarna är att göra det möjligt för applikationens dataförändringar i realtid, utan risk att förfölja oploggen och utan spår av komplexitet. MongoDB-applikationer använder ändringsströmmar för att logga till dataändringar på en databas, en samling eller distributionen och reagerar omedelbart på dem. Eftersom förändringsströmmar använder aggregeringsramverket, kan applikationer filtrera de specifika ändringarna och konvertera aviseringar på egen hand.