Nowoczesne bazy danych muszą mieć możliwość przechwytywania danych i reagowania na nie w czasie rzeczywistym. To wyjaśnia, dlaczego MongoDB ma funkcję o nazwie MongoDB Change Streams odpowiedzialną za przechwytywanie danych i odpowiadanie na nie w czasie rzeczywistym. Strumienie zmian to funkcja wprowadzona do przesyłania strumieniowego informacji z aplikacji do bazy danych w czasie rzeczywistym. Opiera się na strukturze agregacji, która monitoruje kolekcje i umożliwia wprowadzanie zmian w bazie danych i kolekcji baz danych. Ponadto MongoDB Change Stream może przechwytywać dane z czujników IOT i aktualizować raporty, takie jak zmiany danych operacyjnych w przedsiębiorstwie. Ten blog otworzy dyskurs na temat strumienia zmian MongoDB i rekomendacji zmian w produkcji.
MongoDB Zmień strumienie i porzucaj kolekcję
Zmiana nazwy lub usunięcie bazy danych lub kolekcji doprowadzi do zamknięcia kursora, jeśli był otwarty strumień zmian działający przeciwko usuniętej kolekcji. Zmiana nazwy lub upuszczenie kolekcji powoduje, że kursor z FullDocument:updateLookup zwraca null w dowolnym dokumencie wyszukiwania. W przypadku próby wznowienia po usunięciu bazy danych z uruchomionym strumieniem zmian wystąpi błąd.
Ponadto, wszystkie zmiany w danych dokonane przed zmianą nazwy kolekcji z uruchomionym strumieniem zmian zostaną utracone. Limit dokumentów dla strumienia zmian nadal wynosi 16 MB BSON; dlatego dokumenty większe niż 16 MB nie są akceptowane. Jeśli ktoś spróbuje pracować z dokumentem większym niż 16 MB, powiadomienie nie powiedzie się, a dokument zostanie zastąpiony innym dokumentem, który spełnia ustalony limit.
Kiedy kolekcja lub baza danych z otwartymi strumieniami zmian jest usuwana lub zmieniana, kursory strumienia zmian mają tendencję do zamykania się, gdy przechodzą do tego punktu w oplogu. Jeśli zmienisz kursory strumienia z pełnym dokumentem, opcja updateLookup może zwrócić null do dokumentu wyszukiwania.
Dlatego próba wznowienia strumieni zmian w kolekcji, która została upuszczona, zakończy się błędem. Każde wystąpienie zmian danych w kolekcji między ostatnim przechwyconym zdarzeniem strumienia zmian a zdarzeniem porzucenia kolekcji jest tracone.
Zmiana dokumentów odpowiedzi na strumień musi być zgodna z limitem 16 MB dokumentów BSON. W zależności od rozmiaru dokumentów w kolekcji, dla której otwierasz strumień zmian, powiadomienia mogą się nie powieść, jeśli wynikowy dokument powiadomienia ma więcej niż 16 MB. Dobrym przykładem są operacje aktualizacji w strumieniach zmian skonfigurowane do zwracania w pełni zaktualizowanego dokumentu lub zastępowania/wstawiania procesów z dokumentem na poziomie limitu lub nieco poniżej limitu.
MongoDB Zmień zestawy strumieni i replik
Zestaw replik MongoDB to zbiór procesów w MongoDB, których zbiór danych się nie zmienia; to znaczy, że zestaw danych pozostaje taki sam. W przypadku zestawów replik posiadających członków-arbitrów, strumienie zmian prawdopodobnie pozostaną bezczynne, jeśli wystarczająca liczba członków niosących dane nie jest dostępna, tak że większość nie może wykonać operacji. Na przykład możemy rozważyć zestaw replik składający się z trzech członków z dwoma węzłami przenoszącymi dane obok arbitra. W przypadku awarii drugorzędnej, np. w wyniku awarii, aktualizacji lub konserwacji, większość operacji zapisu będzie niemożliwa. Strumień zmian pozostanie otwarty, ale nie będzie wysyłać żadnych powiadomień. W omawianym scenariuszu aplikacja może dogonić wszystkie operacje, które miały miejsce w okresie przestoju, o ile ostatnia operacja odebrana przez aplikację nadal znajduje się w oplogu tego konkretnego zestawu replik. Ponadto polecenie rs.printReplicationInfo() służy do pobierania danych z oplog; pobierane dane obejmują zakres operacji i rozmiar pliku oplog.
Jeśli czas przestoju jest znacznie szacowany, na przykład w celu przeprowadzenia aktualizacji lub w przypadku awarii, zwiększenie rozmiaru oploga będzie najlepszą opcją zachowania operacji przez okres dłuższy niż przybliżony czas przestoju. Aby pobrać informacje o stanie oplog, użyto polecenia printReplicationInfo(). Polecenie pobierze nie tylko informacje o stanie oplog, ale także rozmiar oplog i zakres czasu operacji.
MongoDB Zmień dostępność strumieni
Strumienie zmian MongoDB są dostępne dla zestawów replik i klastrów sharded:Read Concern „większość” Enablement, Storage Engine i Replica Set Protocol Version. Włączenie „większości” problemu odczytu:Począwszy od MongoDB w wersji 4.2 i nowszych, strumienie zmian są dostępne pomimo panujących okoliczności obsługi problemów odczytu „większości”, co oznacza, że obsługa większości problemów odczytu może być włączona lub wyłączona. W MongoDB w wersji 4.0 i starsze wersje, Strumienie zmian są dostępne tylko wtedy, gdy włączona jest obsługa „większości” problemów odczytu.
- Silnik pamięci masowej:Silnik pamięci masowej WiredTiger to typ silnika pamięci masowej używany przez zestawy replik i klastry podzielone na fragmenty.
- Wersja protokołu zestawu replik:zestawy replik i klastry podzielone na fragmenty muszą zawsze używać wersji 1 protokołu zestawu replik (pv1).
Klastry podzielone na fragmenty MongoDB
Klastry podzielone na fragmenty w MongoDB składają się z fragmentów, mongos i serwerów konfiguracyjnych. Fragment składa się z podzbioru danych podzielonych na fragmenty. W przypadku MongoDB 3.6 shardy są wykorzystywane jako zestaw replik. Mongos zapewnia interfejs między klastrami podzielonymi na fragmenty a aplikacjami klienckimi; Mongos pełni rolę routera zapytań. Od wersji MongoDB 4.4 i nowszych, mongos obsługuje zabezpieczone odczyty w celu zmniejszenia opóźnień. Serwery konfiguracyjne to miejsca przechowywania ustawień konfiguracji klastra i metadanych.
Strumienie zmian używają globalnego zegara logicznego, aby zapewnić globalną kolejność zmian we fragmentach. MongoDB zapewnia zachowanie kolejności zmian i bezpieczne interpretowanie powiadomień strumienia zmian w kolejności ich otrzymywania. Na przykład kursor strumienia zmian otwarty względem klastra z trzema fragmentami zwraca powiadomienia o zmianie dotyczące całkowitej kolejności zmian w trzech fragmentach.
Aby zapewnić całkowitą kolejność zmian, Mongos sprawdza w każdym odłamku, czy w każdym powiadomieniu o zmianach pojawiły się nowsze zmiany. Klastry podzielone na fragmenty z jednym do kilku fragmentów z niewielką lub zerową aktywnością zbierania lub są „zimne” prawdopodobnie będą miały negatywny wpływ na czas odpowiedzi strumienia zmian, ponieważ mongos nadal muszą sprawdzać te zimne fragmenty, aby zapewnić całkowitą kolejność zmian. Ten efekt może być bardziej widoczny, gdy fragmenty są rozproszone geograficznie lub gdy obciążenia z większością operacji występują w podzbiorze fragmentów w klastrze. Jeśli kolekcja sharded ma wysoki poziom aktywności, mongos mogą nie śledzić zmian we wszystkich shardach. Rozważ użycie filtrów powiadomień dla tego rodzaju kolekcji, na przykład przekazanie potoku $match, który jest skonfigurowany do filtrowania tylko operacji wstawiania.
W przypadku kolekcji podzielonych na fragmenty, multi:prawidłowe operacje aktualizacji prawdopodobnie spowodują, że strumienie zmian, które zostaną otwarte względem kolekcji, będą wysyłać powiadomienia o osieroconych dokumentach. Począwszy od momentu podzielenia na fragmenty kolekcji, która nie została podzielona na fragmenty, aż do momentu, gdy strumień zmian dostanie się do pierwszej porcji migracji, documentKey w dokumencie powiadomienia strumienia zmian zawiera tylko identyfikator dokumentu, a nie pełny klucz fragmentu.
Wnioski
Strumienie zmian mają na celu umożliwienie zmian danych aplikacji w czasie rzeczywistym, bez ryzyka śledzenia ologu i bez śladu złożoności. Aplikacje MongoDB używają strumieni zmian do podpisywania zmian danych w bazie danych, kolekcji lub wdrożeniu i natychmiast na nie reagują. Ponieważ strumienie zmian korzystają ze struktury agregacji, aplikacje mogą samodzielnie filtrować określone zmiany i konwertować powiadomienia.
