Systemy baz danych mają obowiązek gwarantować spójność i integralność danych, zwłaszcza w przypadku danych krytycznych. Aspekty te są egzekwowane przez transakcje ACID w MongoDB. Transakcja ACID powinna spełniać określone zasady ważności danych przed dokonaniem jakichkolwiek aktualizacji w bazie danych, w przeciwnym razie powinna zostać przerwana i nie należy wprowadzać żadnych zmian w bazie danych. Wszystkie transakcje bazy danych są traktowane jako pojedyncza operacja logiczna, aw czasie wykonywania baza danych jest wprowadzana w niespójny stan do momentu zatwierdzenia zmian. Operacje, które pomyślnie zmieniają stan bazy danych, są określane jako transakcje zapisu, podczas gdy te, które nie aktualizują bazy danych, ale tylko pobierają dane, są nazywane transakcjami tylko do odczytu. ACID to akronim oznaczający atomowość, spójność, izolację i trwałość.
Baza danych to współużytkowany zasób, do którego mogą mieć dostęp różni użytkownicy w różnym czasie lub w tym samym czasie. Z tego powodu mogą mieć miejsce współbieżne transakcje, a jeśli nie są dobrze zarządzane, mogą powodować awarie systemu, awarie sprzętu, zakleszczenie, spowolnienie działania bazy danych lub powtarzanie się podczas wykonywania tej samej transakcji.
Czym są zasady ACID?
Wszystkie systemy baz danych muszą spełniać właściwości ACID, aby zagwarantować integralność danych.
Atomowość
Transakcja jest uważana za pojedynczą jednostkę operacji, która może całkowicie się powieść lub całkowicie zakończyć niepowodzeniem. Transakcja nie może być zrealizowana częściowo. Jeśli jakikolwiek warunek konsultujący transakcję nie powiedzie się, cała transakcja zakończy się niepowodzeniem, a baza danych pozostanie niezmieniona. Na przykład, jeśli chcesz przelać środki z konta X na Y, tutaj są dwie transakcje, pierwsza to usunięcie środków z X, a druga to zapisanie środków w Y. Jeśli pierwsza transakcja się nie powiedzie, całość transakcja zostanie przerwana
Spójność
Kiedy operacja zostanie wydana, przed wykonaniem, baza danych jest w stanie spójnym i powinna tak pozostać po każdej transakcji. Nawet w przypadku aktualizacji transakcja powinna zawsze doprowadzić bazę danych do prawidłowego stanu, zachowując niezmienniki bazy danych. Na przykład nie można usunąć klucza podstawowego, do którego odniesiono się jako do klucza obcego w innej kolekcji. Wszystkie dane muszą spełniać określone ograniczenia, aby zapobiec uszkodzeniu danych w wyniku nielegalnej transakcji.
Izolacja
Wiele transakcji działających jednocześnie jest wykonywanych bez wpływu na siebie nawzajem, a ich wynik powinien być taki sam, jeśli miałyby być wykonywane sekwencyjnie. Gdy dwie lub więcej transakcji modyfikuje te same dokumenty w MongoDB, może wystąpić konflikt. Baza danych wykryje konflikt bezpośrednio przed jego zatwierdzeniem. Pierwsza operacja uzyskania blokady dokumentu będzie kontynuowana, podczas gdy druga zakończy się niepowodzeniem i zostanie wyświetlony komunikat o błędzie konfliktu.
Trwałość
To dyktuje, że po zatwierdzeniu transakcji zmiany powinny być utrzymane przez cały czas, nawet w przypadku awarii systemu, na przykład z powodu przerwy w dostawie prądu lub odłączenia Internetu.
Transakcje ACID MongoDB
MongoDB to oparta na dokumentach baza danych NoSQL z elastycznym schematem. Transakcje nie są operacjami, które powinny być wykonywane dla każdej operacji zapisu, ponieważ wiążą się z większymi kosztami wydajności w przypadku zapisu pojedynczego dokumentu. Dzięki strukturze opartej na dokumentach i zdenormalizowanemu modelowi danych zminimalizowane zostanie zapotrzebowanie na transakcje. Ponieważ MongoDB umożliwia osadzanie dokumentów, nie musisz koniecznie używać transakcji, aby wykonać operację zapisu.
MongoDB w wersji 4.0 zapewnia obsługę transakcji wielodokumentowych tylko dla wdrożeń zestawu replik i prawdopodobnie wersja 4.2 rozszerzy obsługę wdrożeń sharded (zgodnie z ich uwagami do wydania).
Przykład transakcji:
Upewnij się, że masz na miejscu replikę. Zakładając, że masz bazę danych o nazwie app i kolekcję, użytkownicy w powłoce Mongo uruchamiają następujące polecenia:
$mongos i powinieneś zobaczyć coś takiego jak nazwa użytkownika:PRIMARY>
$use app
$db.users.insert([{_id:1, name: ‘Brian’}, {_id:2, name: ‘Sheila’}, {_id:3, name: ‘James’}])Musimy rozpocząć sesję dla naszej transakcji:
$db.getMongo().startSession() and you should see something like
session { "id" : UUID("dcfa8de5-627d-3b1c-a890-63c9a355520c") }Korzystając z tej sesji możemy dodać więcej użytkowników za pomocą transakcji za pomocą następujących poleceń
$session.startTransaction()
session.getDatabase(‘app’).users.insert({_id:4, name: ‘Hitler’})Zostanie wyświetlony WriteResult({„nInsterted”:2})
Transakcja nie została jeszcze zatwierdzona, a normalny $db.users.find({}) da nam tylko wcześniej zapisanych użytkowników. Ale jeśli uruchomimy
$session.getDatabase(“app”).users.find()ostatnio dodany rekord będzie dostępny w zwróconych wynikach. Aby zatwierdzić tę transakcję, uruchamiamy poniższe polecenie
$session.commitTransaction()Modyfikacja transakcji jest przechowywana w pamięci, dlatego nawet po awarii dane będą dostępne podczas odzyskiwania.
Wielodokumentowe transakcje ACID w MongoDB
Są to operacje na wielu instrukcjach, które muszą być wykonywane sekwencyjnie bez wzajemnego oddziaływania. Dla powyższej próbki możemy utworzyć dwie transakcje, jedną w celu dodania użytkownika, a drugą w celu zaktualizowania użytkownika o pole wieku. To znaczy
$session.startTransaction()
db.users.insert({_id:6, name “Ibrahim”})
db.users.updateOne({_id:3 , {$set:{age:50}}})
session.commit_transaction()Transakcje można zastosować do operacji na wielu dokumentach zawartych w jednej lub wielu zbiorach/bazach danych. Wszelkie zmiany wynikające z transakcji dokumentu nie wpływają na wydajność w przypadku obciążeń niezwiązanych z nimi lub ich nie wymagają. Dopóki transakcja nie zostanie zatwierdzona, niezatwierdzone zapisy nie są replikowane do węzłów drugorzędnych ani nie można ich odczytać poza transakcjami.
Najlepsze praktyki dotyczące transakcji MongoDB
Transakcje wielodokumentowe są obsługiwane tylko w mechanizmie przechowywania WiredTiger. Jak wspomniano wcześniej, bardzo niewiele aplikacji wymagałoby transakcji, a jeśli tak, powinniśmy starać się je skrócić. W przeciwnym razie, w przypadku pojedynczej transakcji ACID, jeśli spróbujesz wykonać nadmierną liczbę operacji, może to spowodować duże obciążenie pamięci podręcznej WiredTiger. Pamięć podręczna jest zawsze podyktowana, aby zachować stan dla wszystkich kolejnych zapisów od czasu utworzenia najstarszej migawki. Oznacza to, że nowe zapisy będą gromadzone w pamięci podręcznej przez cały czas trwania transakcji i zostaną opróżnione dopiero po zatwierdzeniu lub przerwaniu transakcji aktualnie uruchomionych na starych migawkach. Aby uzyskać najlepszą wydajność bazy danych podczas transakcji, programiści powinni rozważyć:
- Zawsze modyfikuj niewielką liczbę dokumentów w transakcji. W przeciwnym razie będziesz musiał podzielić transakcję na różne części i przetworzyć dokumenty w różnych partiach. Co najwyżej przetwarzaj 1000 dokumentów na raz.
- Tymczasowe wyjątki, takie jak oczekiwanie na wybranie głównej i przejściowej czkawki sieci, mogą spowodować przerwanie transakcji. Deweloperzy powinni ustalić logikę, aby ponowić transakcję, jeśli zostaną przedstawione zdefiniowane błędy.
- Konfiguruj optymalny czas trwania transakcji z domyślnych 60 sekund dostarczonych przez MongoDB. Poza tym zastosuj indeksowanie, aby umożliwić szybki dostęp do danych w ramach transakcji. Masz również elastyczność, aby dostroić transakcję w adresowaniu limitów czasu, dzieląc ją na partie, które pozwalają na jej wykonanie w określonym czasie.
- Zdekomponuj transakcję na mały zestaw operacji, tak aby pasował do ograniczeń rozmiaru 16 MB. W przeciwnym razie, jeśli operacja wraz z opisem oplog przekroczy ten limit, transakcja zostanie przerwana.
- Wszystkie dane dotyczące podmiotu powinny być przechowywane w jednej, bogatej strukturze dokumentu. Ma to na celu zmniejszenie liczby dokumentów, które mają być buforowane, gdy różne pola mają zostać zmienione.
Ograniczenia transakcji
- Nie możesz tworzyć ani usuwać kolekcji wewnątrz transakcji.
- Transakcje nie mogą dokonywać zapisów do ograniczonej kolekcji
- Transakcje zajmują dużo czasu i mogą spowolnić działanie bazy danych.
- Rozmiar transakcji jest ograniczony do 16 MB, co wymaga podzielenia tych, które zwykle przekraczają ten rozmiar, na mniejsze transakcje.
- Poddawanie transakcji dużej liczby dokumentów może wywierać nadmierną presję na silnik WiredTiger, a ponieważ opiera się on na możliwości tworzenia migawek, w pamięci zostaną zachowane duże nieopróżnione operacje. Powoduje to pewne koszty wydajności w bazie danych.
Wnioski
MongoDB w wersji 4.0 wprowadził obsługę transakcji wielodokumentowych dla zestawów replik jako funkcję poprawiającą integralność i spójność danych. Jednak bardzo niewiele aplikacji wymagałoby transakcji podczas korzystania z MongoDB. Istnieją ograniczenia dotyczące tej funkcji, które sprawiają, że jest ona nieco niedojrzała, jeśli chodzi o koncepcję transakcji. Na przykład transakcje dla klastra podzielonego na fragmenty nie są obsługiwane i nie mogą być większe niż limit rozmiaru 16 MB. Modelowanie danych zapewnia lepszą strukturę redukcji transakcji w bazie danych. O ile nie masz do czynienia ze szczególnymi przypadkami, lepszą praktyką będzie unikanie transakcji w MongoDB.
