Moderní databáze musí mít kapacitu zachycovat data a reagovat na ně při jejich toku v reálném čase. To vysvětluje, proč má MongoDB funkci nazvanou MongoDB Change Streams, která je zodpovědná za zachycování dat a odpovídání na ně v reálném čase. Change Streams je funkce zavedená pro streamování informací z aplikace do databáze v reálném čase. Je založen na agregačním rámci, který monitoruje kolekce a umožňuje změny v databázi a databázové kolekci. Kromě toho může MongoDB Change Stream zachytit data ze senzorů IOT a aktualizovat zprávy, jako jsou změny provozních dat v podniku. Tento blog otevře diskurz o MongoDB Change Stream a doporučení změn v produkci.
Změna streamů MongoDB a odstranění kolekce
Přejmenování nebo zrušení databáze nebo kolekce povede k uzavření kurzoru, pokud proti zrušené kolekci fungoval otevřený proud změn. Přejmenováním nebo zrušením kolekce se kurzor změní na FullDocument:updateLookup, který vrátí hodnotu null pro jakýkoli daný vyhledávací dokument. Při pokusu o pokračování po zrušení databáze se spuštěným proudem změn dojde k chybě.
Navíc budou ztraceny všechny změny v datech provedené před přejmenováním kolekce s běžícím proudem změn. Limit dokumentu pro tok změn je stále 16 MB BSON; proto nejsou akceptovány dokumenty větší než 16 MB. Pokud se někdo pokusí pracovat s dokumentem větším než 16 MB, upozornění se nezdaří a dokument je nahrazen jiným dokumentem, který splňuje nastavený limit.
Když je kolekce nebo databáze s otevřenými proudy změn zrušena nebo přejmenována, kurzory proudů změn mají tendenci se zavírat, když postupují k tomuto bodu v oplogu. Pokud změníte kurzory proudu s celým dokumentem, možnost updateLookup může vrátit do vyhledávacího dokumentu hodnotu null.
Pokus o obnovení streamů změn u kolekce, která byla zrušena, proto povede k chybě. Jakýkoli výskyt změn dat v kolekci mezi poslední událostí zachyceného toku změn a událostí poklesu kolekce je ztracen.
Změna dokumentů s odezvou na stream musí splňovat limit 16 MB pro dokumenty BSON. V závislosti na velikosti dokumentů v kolekci, proti které otevíráte tok změn, mohou oznámení selhat, pokud je výsledný dokument oznámení větší než 16 MB. Dobrým příkladem jsou operace aktualizace u toků změn nastavených tak, aby vrátily plně aktualizovaný dokument nebo nahradily/vložily procesy s dokumentem na limitu nebo mírně pod limitem.
MongoDB změnit stream a sady replik
Sada MongoDB Replica Set je kolekce procesů v MongoDB, jejichž datová sada se nemění; to znamená, že soubor dat zůstává stejný. V případě sad replik, které mají členy arbitra, toky změn pravděpodobně zůstanou nečinné, pokud není k dispozici dostatek členů nesoucích data, takže většina nemůže provést operace. Můžeme například zvážit sadu replik se třemi členy se dvěma uzly nesoucími data vedle arbitra. V případě, že dojde k výpadku sekundárního dílu, např. v důsledku selhání, upgradu nebo údržby, nebude možné, aby byly operace zápisu většinou provedeny. Stream změn zůstane otevřený, ale nebude odesílat žádná upozornění. V daném scénáři může aplikace dohnat všechny operace, které proběhly v období výpadku, pokud je poslední operace přijatá aplikací stále v oplogu této konkrétní sady replik. Příkaz rs.printReplicationInfo() se navíc používá k načtení dat z oplog; načtená data zahrnují řadu operací a velikost oplog.
Pokud se výpadek významně odhaduje, například kvůli provedení upgradu nebo v případě havárie, bude zvýšení velikosti oplogu nejlepší možností, jak zachovat operace po dobu delší než přibližnou dobu odstávky. K načtení informací o stavu oplogu se používá příkaz printReplicationInfo(). Příkaz získá nejen informace o stavu oplogu, ale také velikost oplogu a časový rozsah operací.
Dostupnost streamů změn MongoDB
Toky změn MongoDB lze získat pro sady replik a sdílené clustery:Povolení „většiny“ týkající se čtení, Storage Engine a Verze protokolu sady replik. Povolení „většinového“ zájmu o čtení:Počínaje verzí MongoDB 4.2 a vyšší jsou streamy změn přístupné navzdory převažujícím okolnostem podpory „většinového“ čtení, což znamená, že většinu zájmu o čtení lze povolit nebo zakázat. V MongoDB verze 4.0 a starší verze jsou toky změn dostupné pouze v případě, že je aktivována podpora „většinového“ čtení.
- Storage Engine:Úložný engine WiredTiger je typ úložiště, který používají sady replik a sdílené clustery.
- Verze protokolu sady replik:Sady replik a sdílené clustery musí vždy používat verzi 1 protokolu sady replik (pv1).
Sdílené clustery MongoDB
Sharded clustery v MongoDB se skládají z fragmentů, mongos a konfiguračních serverů. Shard se skládá z podmnožiny dat sharded. V případě MongoDB 3.6 jsou úlomky použity jako sada replik. Mongos poskytuje rozhraní mezi sdílenými clustery a klientskými aplikacemi; mongos hraje roli směrovače dotazů. Od verze MongoDB 4.4 a vyšší mongos podporuje hedgované čtení, aby se snížily latence. Konfigurační servery jsou umístění úložiště pro nastavení konfigurace clusteru a metadata.
Proudy změn používají globální logické hodiny k zajištění globálního řazení změn napříč fragmenty. MongoDB zajišťuje, že pořadí změn je zachováno a že oznámení toku změn lze bezpečně interpretovat v pořadí, v jakém byly přijaty. Například kurzor toku změn otevřený proti shluku 3 útržků vrátí oznámení o změně týkající se celkového pořadí změn ve třech útržcích.
Aby bylo zajištěno celkové pořadí změn, Mongos kontroluje u každého fragmentu, zda u každého oznámení o změně zaznamenal novější změny. Rozbité shluky s jedním až několika úlomky s malou nebo žádnou aktivitou shromažďování nebo jsou „studené“ pravděpodobně budou mít negativní vliv na dobu odezvy toku změn, protože mongos stále musí kontrolovat tyto studené úlomky, aby zajistili úplné uspořádání změn. Tento efekt může být patrnější, když jsou úlomky geograficky rozmístěny, nebo když k pracovní zátěži s většinou operací dochází na podmnožině útržků v clusteru. Pokud má sbírka úlomků vysokou úroveň aktivity, mongos nemusí zvládnout sledovat změny ve všech útržcích. Zvažte použití filtrů oznámení pro tento druh kolekce, například předávání kanálu $match, který je nakonfigurován tak, aby filtroval pouze operace vkládání.
V případě sdílených kolekcí je pravděpodobné, že operace multi:správné aktualizace způsobí toky změn, které se otevřou proti kolekci, aby posílaly upozornění na osiřelé dokumenty. Počínaje okamžikem, kdy je nesdílená kolekce rozštěpena, až do okamžiku, kdy se tok změn dostane k prvnímu bloku migrace, klíč documentKey v dokumentu oznámení toku změn obsahuje pouze ID dokumentu, nikoli úplný shard klíč.
Závěr
Účelem toků změn je umožnit změny dat aplikace v reálném čase, bez rizika pronásledování oplogu a bez jakékoli stopy složitosti. Aplikace MongoDB používají toky změn k podepisování změn dat v databázi, kolekci nebo nasazení a okamžitě na ně reagují. Protože toky změn využívají agregační rámec, mohou aplikace filtrovat konkrétní změny a převádět oznámení samy.