Co nowego w MongoDB 4.2

Aktualizacje bazy danych zawierają ulepszone funkcje zwiększające wydajność, bezpieczeństwo oraz nowe zintegrowane funkcje. Zawsze zaleca się przetestowanie nowej wersji przed wdrożeniem jej do produkcji, aby upewnić się, że odpowiada ona Twoim potrzebom i nie ma możliwości wystąpienia awarii.

Biorąc pod uwagę wiele produktów, te poprzedzające pierwsze wersje pomocnicze nowej wersji głównej mają najważniejsze poprawki. Na przykład wolałbym mieć MongoDB w wersji 4.2.1 w produkcji kilka dni po wydaniu niż w wersji 4.2.0.

W tym blogu omówimy, co zostało uwzględnione i jakie ulepszenia wprowadzono w MongoDB w wersji 4.2

Co nowego w MongoDB 4.2

1. Transakcje rozproszone
2. Indeksy wieloznaczne
3. Ponowna próba odczytu i zapisu
4. Automatyczne szyfrowanie na poziomie pola po stronie klienta.
5. Ulepszony język zapytań dla ekspresyjnych aktualizacji
6. Zmaterializowane widoki na żądanie
7. Nowoczesne operacje konserwacyjne

Transakcje rozproszone

Transakcje są ważnymi cechami bazy danych, które zapewniają spójność i integralność danych, szczególnie te, które gwarantują procedury ACID. MongoDB w wersji 4.2 obsługuje teraz transakcje wielodokumentowe w zestawach replik i klastrze podzielonym na fragmenty za pośrednictwem podejścia transakcji rozproszonych. Zachowano tę samą składnię do korzystania z transakcji, co w poprzedniej wersji 4.0.

Jednak specyfikacje sterowników klienta nieco się zmieniły, dlatego jeśli ktoś zamierza korzystać z transakcji w MongoDB 4.2, należy zaktualizować sterowniki do wersji zgodnych z serwerami 4.2.

Ta wersja nie ogranicza rozmiaru transakcji pod względem wykorzystania pamięci, ale zależy tylko od rozmiaru sprzętu i możliwości obsługi sprzętu.

Globalne ponowne przypisanie ustawień regionalnych klastra jest teraz możliwe w wersji 4.2. Oznacza to, że w przypadku implementacji dzielenia strefy geograficznej, jeśli użytkownik mieszkający w regionie A przenosi się do regionu B, zmieniając wartość jego pola lokalizacji, dane mogą być automatycznie przenoszone z regionu A do B za pośrednictwem transakcji.

System shardingu pozwala teraz na zmianę klucza sharda w przeciwieństwie do poprzedniej wersji. Dosłownie, zmiana klucza fragmentu jest odpowiednikiem przeniesienia dokumentu do innego fragmentu. W tej wersji MongoDB otacza tę aktualizację i jeśli dokument musi zostać przeniesiony z jednego fragmentu do drugiego, aktualizacja zostanie wykonana wewnątrz transakcji w tle.

Wykorzystywanie transakcji nie jest zalecanym podejściem, ponieważ obniżają one wydajność bazy danych, zwłaszcza jeśli występują wielokrotnie. W okresie transakcji istnieje rozciągnięte okno na operacje, które mogą powodować konflikty podczas wykonywania zapisów w dokumencie, którego dotyczy problem. Chociaż można ponowić próbę transakcji, przed ponowną próbą może nastąpić aktualizacja dokumentu, a za każdym razem, gdy nastąpi ponowna próba, może ona dotyczyć starej, a nie najnowszej wersji dokumentu. Ponowne próby oczywiście wiążą się z większymi kosztami przetwarzania, oprócz wydłużenia czasu przestoju aplikacji przez rosnące opóźnienia.

Dobre praktyki dotyczące korzystania z transakcji obejmują:

1. Unikaj używania niezaindeksowanych zapytań wewnątrz transakcji jako sposobu na zapewnienie, że Opera nie będzie powolna.
2. Twoja transakcja powinna obejmować kilka dokumentów.

Dzięki dynamicznemu formatowi schematu MongoDB i funkcji osadzania możesz zdecydować się na umieszczenie wszystkich pól w tej samej kolekcji, aby uniknąć konieczności używania transakcji jako pierwszej miary.

Indeksy wieloznaczne

Indeksy wieloznaczne zostały wprowadzone w MongoDB w wersji 4.2 w celu ulepszenia zapytań o dowolne pola lub pola, których nazwy nie są znane z góry, poprzez indeksowanie całego dokumentu lub poddokumentu. Nie mają one zastępować indeksów opartych na obciążeniu ale garnitur pracuje z danymi obejmującymi wzór polimorficzny. Wzorzec polimorficzny to taki, w którym wszystkie dokumenty w kolekcji są podobne, ale nie mają identycznej struktury. Polimorficzne wzorce danych można generować na podstawie aplikacji, katalogów produktów lub danych społecznościowych. Poniżej znajduje się przykład danych kolekcji polimorficznej

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

Indeksując cały dokument za pomocą indeksów wieloznacznych, możesz utworzyć zapytanie, używając dowolnego dowolnego pola jako indeksu.

Aby utworzyć indeks wieloznaczny

$db.collection.createIndex({“fieldA.$**”: 1})

Jeśli wybrane pole jest dokumentem zagnieżdżonym lub tablicą, indeks symboli zastępczych powraca do dokumentu i przechowuje wartość wszystkich pól w dokumencie lub tablicy.

Ponowna próba odczytu i zapisu

Normalnie baza danych może podlegać częstym przejściowym awariom sieci, które mogą skutkować częściowym lub całkowitym niewykonaniem zapytania. Te błędy sieciowe mogą nie być tak poważne, dlatego dają szansę na ponowną próbę tych zapytań po ponownym połączeniu. Począwszy od MongoDB 4.2 konfiguracja ponawiania jest domyślnie włączona. Sterowniki MongoDB mogą ponawiać nieudane odczyty i zapisy dla niektórych transakcji, gdy napotkają drobne błędy sieciowe lub raczej, gdy nie mogą znaleźć zdrowego podstawowego w zestawie klastrów/replik podzielonych na fragmenty. Jeśli jednak nie chcesz wielokrotnych zapisów, możesz jawnie wyłączyć je w swoich konfiguracjach, ale nie znajduję przekonującego powodu, dla którego należałoby je wyłączać.

Ta funkcja ma zapewnić, że w żadnym przypadku zmiany infrastruktury MongoDB nie wpłynie to na kod aplikacji. Jeśli chodzi o przykład wyjaśniony przez Eliota Horowitza, współzałożyciela MongoDB, dla strony internetowej, która wykonuje 20 różnych operacji na bazie danych, zamiast przeładowywać całość lub owijać całą stronę w jakąś pętlę, sterownik pod okładkami może po prostu zdecydować się na ponowną próbę operacji. Za każdym razem, gdy zapis się nie powiedzie, automatycznie ponawia próbę i będzie miał umowę z serwerem, aby zagwarantować, że każdy zapis nastąpi tylko raz.

Zapisy z wielokrotną próbą wykonują tylko jedną ponowną próbę, co pomaga w rozwiązaniu problemu wyborów zestawu replik i przejściowych błędów sieciowych, ale nie w przypadku trwałych błędów sieciowych.

Zapisy z wielokrotną próbą nie dotyczą przypadków, w których okres przełączania awaryjnego przekracza wartość serverSelectionTimoutMs w konfiguracjach parametrów.

W tej wersji MongoDB można aktualizować wartości klucza fragmentu dokumentu (z wyjątkiem sytuacji, gdy klucz fragmentu jest niezmiennym polem _id) przez wydawanie operacji findAndModify/update na pojedynczym dokumencie w ramach transakcji lub jako zapis z możliwością ponownej próby .

MongoDB w wersji 4.2 może teraz ponowić operację upsert pojedynczego dokumentu (tj. upsert:true i multi:false), która mogła się nie powieść z powodu błędu zduplikowanego klucza, jeśli operacja spełnia następujące warunki klucza:

1. Kolekcja docelowa zawiera unikalny indeks, który spowodował błąd zduplikowanego klucza.
2. Operacja aktualizacji nie zmodyfikuje żadnego z pól w predykacie zapytania.
3. Warunkiem dopasowania aktualizacji jest pojedynczy predykat równości {pole:„wartość”} lub logiczne AND predykatów równości {pole:„wartość”, pole0:„wartość0”}
4. Zestaw pól w unikalnym wzorcu klucza indeksu pasuje do zestawu pól w predykacie zapytania aktualizującego.

Automatyczne szyfrowanie na poziomie pola po stronie klienta

MongoDB w wersji 4.2 zawiera automatyczne szyfrowanie na poziomie pola po stronie klienta (CSFLE), funkcję, która umożliwia programistom selektywne szyfrowanie poszczególnych pól dokumentu po stronie klienta przed wysłaniem go na serwer. Zaszyfrowane dane są zatem chronione przed dostawcami obsługującymi bazę danych i każdym użytkownikiem, który może mieć bezpośredni dostęp do bazy danych.

Tylko aplikacje z dostępem do właściwych kluczy szyfrowania mogą odszyfrować i odczytać chronione dane. W przypadku usunięcia klucza szyfrowania wszystkie dane, które zostały zaszyfrowane, staną się nieczytelne.

Uwaga:ta funkcja jest dostępna tylko w MongoDB Enterprise.

Ulepszony język zapytań dla ekspresyjnych aktualizacji

MongoDB w wersji 4.2 zapewnia bogatszy język zapytań niż jego poprzednicy. Obsługuje teraz agregacje i nowoczesne operacje dotyczące przypadków użycia na wzór wyszukiwania geograficznego, wyszukiwania wykresów i wyszukiwania tekstowego. Ma zintegrowaną wyszukiwarkę innej firmy, która przyspiesza wyszukiwanie, biorąc pod uwagę, że wyszukiwarka działa na innym procesie/serwerze. Generalnie poprawia to wydajność bazy danych, w przeciwieństwie do sytuacji, w której wszystkie wyszukiwania byłyby przeprowadzane w procesie mongod, który raczej powodowałby niestabilność opóźnienia operacji bazy danych za każdym razem, gdy wyszukiwarka ponownie indeksuje.

Dzięki tej wersji możesz teraz obsługiwać tablice, wykonywać sumy i inne operacje matematyczne bezpośrednio za pomocą instrukcji aktualizacji.

Zmaterializowane widoki na żądanie

Struktura potoku agregacji danych w MongoDB to świetna funkcja z różnymi etapami przekształcania dokumentu do pożądanego stanu. MongoDB w wersji 4.2 wprowadza nowy etap $merge, co, jak dla mnie, zaoszczędziło mi trochę czasu na pracy z ostatecznym wyjściem, które musiałem być przechowywane w kolekcji. Początkowo etap $out umożliwia utworzenie nowej kolekcji na podstawie agregacji i zapełnienie kolekcji uzyskanymi wynikami. Jeśli kolekcja już istnieje, nadpisze kolekcję nowymi wynikami, w przeciwieństwie do etapu $merge, który uwzględnia tylko wyniki potoku w istniejących danych wyjściowych, a nie całkowicie zastępuje kolekcję. Ponowne generowanie całej kolekcji za każdym razem na etapie $out pochłania dużo procesora i IO, co może obniżyć wydajność bazy danych. Treść wyjściowa będzie zatem aktualizowana na czas, umożliwiając użytkownikom tworzenie zmaterializowanych widoków na żądanie

Nowoczesne operacje konserwacyjne

Programiści mogą teraz korzystać z doskonałej obsługi operacyjnej dzięki MongoDB w wersji 4.2 ze zintegrowanymi funkcjami, które zwiększają wysoką dostępność, strategię tworzenia kopii zapasowych zarządzanych w chmurze, poprawiają moc monitorowania i systemy ostrzegania. Platformami obsługującymi te funkcje są MongoDB Atlas i MongoDB Ops Manager. Ten ostatni został oznaczony jako najlepszy do uruchamiania MongoDB w przedsiębiorstwie. Został również zintegrowany z operatorem Kubernetes dla użytkowników on-premise, którzy przenoszą się do chmury prywatnej. Ten interfejs umożliwia bezpośrednie sterowanie Ops Managerem.

Istnieją pewne wewnętrzne zmiany wprowadzone do MongoDB w wersji 4.2, które obejmują:

1. Lista otwartych kursorów.
2. Usunięcie silnika pamięci masowej MMAPv1.
3. Poprawa naprawy pliku danych WiredTiger.
4. Pola diagnostyczne mogą teraz mieć queryHash
5. Automatycznie dzielący się wątek dla węzłów Mongos został usunięty.

Wnioski

MongoDB w wersji 4.2 zawiera kilka ulepszeń w zakresie bezpieczeństwa i wydajności bazy danych. Zawiera automatyczne szyfrowanie na poziomie pola po stronie klienta, które zapewnia ochronę danych od strony klienta. Więcej funkcji, takich jak wyszukiwarka firm trzecich i włączenie etapu $merge do struktury agregacji, zapewniają pewną poprawę wydajności bazy danych. Przed wprowadzeniem tej wersji do produkcji upewnij się, że wszystkie Twoje potrzeby są w pełni zaspokojone.