Co tak naprawdę oznacza brak zgodności MongoDB z kwasem przed v4?

To nie jest poprawne, że MongoDB nie jest zgodny z kwasami. Wręcz przeciwnie, MongoDB jest Acid-compilant na poziomie dokumentu.

Każda aktualizacja do pojedynczego dokumentu to

• atomowy: albo w pełni się uzupełnia, albo nie
• spójny: żaden czytelnik nie zobaczy "częściowo zastosowanej" aktualizacji
• odizolowany: ponownie, żaden czytelnik nie zobaczy "brudnego" odczytu
• trwały: (z odpowiednim zapisem)

Jaki MongoDB nie ma is transakcje -- oznacza to, że aktualizacje wielu dokumentów, które można cofnąć i są zgodne z kwasami.

Zauważ, że możesz budować transakcje w oparciu o aktualizacje Zgodne z ACID do pojedynczego dokumentu, za pomocą przy użyciu dwufazowego commita.

Dobre wyjaśnienie zawarte jest w "Starbucks nie używa dwufazowego Commita" .

Nie chodzi o bazy danych NoSQL, ale pokazuje, że czasami możesz sobie pozwolić na utratę transakcji lub tymczasową niespójność bazy danych.

Nie uznałbym tego za coś, co trzeba "naprawić". Poprawką jest użycie relacyjnej bazy danych zgodnej z kwasem. Wybierasz alternatywę NoSQL, gdy jej zachowanie odpowiada twojej aplikacji wymagania.

Myślę, że inni już dali dobre odpowiedzi. Chciałbym jednak dodać, że istnieją Acid NOSQL DBs (jak http://ravendb.net / ). Więc nie jest to tylko decyzja NOSQL - no ACID vs Relational with ACID....

"nie zapisuje poprawnie" może oznaczać:

1. Domyślnie MongoDB nie zapisuje zmian na dysku natychmiast. Istnieje więc możliwość, że powiesz użytkownikowi "aktualizacja się powiodła", nastąpi przerwa w zasilaniu i aktualizacja zostanie utracona. MongoDB udostępnia opcje kontroli poziomu "trwałości" aktualizacji. MoĹźe czekaÄ ‡ na otrzymanie aktualizacji przez inne repliki(w pamiÄ ™ ci), czekaÄ ‡ na zapis do lokalnego pliku dziennika, itd.

2. Nie ma łatwego " atomic" aktualizacje wielu kolekcji, a nawet wielu dokumentów w tej samej kolekcji. W większości przypadków nie jest to problem, ponieważ można go obejść za pomocą dwufazowego Commita lub restrukturyzacji schematu tak, aby aktualizacje były dokonywane w jednym dokumencie. Zobacz to pytanie: bazy dokumentów: zbędne dane, referencje itp. (MongoDB)

Począwszy od MongoDB v4. 0, WIELODOKUMENTOWE transakcje ACID mają być obsługiwane. Dzięki izolacji migawek transakcje zapewnią globalnie spójny widok danych i wymuszą wykonanie "wszystko albo nic", aby zachować integralność danych.

Czują się jak transakcje ze świata relacyjnego, np.:

with client.start_session() as s:
    s.start_transaction()
    try:
        collection.insert_one(doc1, session=s)
        collection.insert_one(doc2, session=s)
        s.commit_transaction()
    except Exception:
        s.abort_transaction()

Zobacz https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb

Aby lepiej zrozumieć, przeczytaj o właściwościach kwasu .

Również w dokumentacji MongoDB można znaleźć Pytanie i ODPOWIEDŹ .

MongoDB nie jest zgodny z kwasami. Przeczytaj poniżej, aby omówić kwas zgodność.

1. MongoDB jest Atylko na poziomie dokumentu. Nie odpowiada definicji atomu, którą znamy z relacyjnych systemów bazodanowych, w szczególności linku powyżej. W tym sensie MongoDB nie jest zgodny z a z kwasu.
2. MongoDB jest domyślnie Consitent. jednakże, możesz odczytywać z drugorzędnych serwerów w zestawie replik. W tym przypadku można tylko mieć ostateczną konsystencję. Jest to przydatne, jeśli nie masz nic przeciwko odczytaniu nieco nieaktualnych danych.
3. MongoDB nie gwarantuje Isolacji (ponownie zgodnie z powyższą definicją):

1. w przypadku systemów z wieloma współbieżnymi czytnikami i pisarzami, MongoDB będzie pozwalają klientom odczytać wyniki operacji zapisu przed write operation returns.
2. Jeśli mongod zakończy się przed zatwierdzeniem dziennika, nawet jeśli zapis zwraca pomyślnie, zapytania mogą odczytywać dane, które nie będą istniały po ponownym uruchomieniu mongod.

Jednak, MongoDB modyfikuje każdy dokument w izolacji (dla wstawek i aktualizacje); tylko na poziomie dokumentu, a nie na transakcjach wielodokumentowych.

1. w odniesieniu do Durabialność - możesz skonfigurować to zachowanie za pomocą opcji write concern, jednak nie jestem pewien. Może ktoś wie lepiej.

Uważam, że trwają badania nad przesunięciem NoSQL w kierunku ograniczeń kwasowych lub podobnych. Jest to wyzwanie, ponieważ bazy danych NoSQL są zwykle szybkie (er), a ograniczenia kwasowe mogą znacznie spowolnić wydajność.

Jedynym powodem, dla którego Atomic modyfikuje działanie przeciwko pojedynczej kolekcji, jest to, że deweloperzy mongodb wymienili ostatnio blokadę bazy danych z blokadą zapisu całej kolekcji. Decydując, że zwiększona współbieżność tutaj była warta kompromisu. W jego rdzeniu mongodb jest plikiem mapowanym w pamięci: przekazali zarządzanie pulą buforów podsystemowi maszyny wirtualnej. Ponieważ jest zawsze w pamięci, są w stanie uciec z bardzo oczywiście ziarnistych zamków: będziesz wykonywać tylko w pamięci operacje podczas trzymania go, co będzie niezwykle szybkie. Różni się to znacznie od tradycyjnego systemu bazodanowego, który jest czasami zmuszony do wykonywania operacji I / O podczas trzymania pagelocka lub rowlocka.

"W MongoDB operacja na pojedynczym dokumencie jest atomowa" - to rzecz o przeszłości

W nowej wersji MongoDB 4.0 Można:

Jednak w sytuacjach wymagających atomiczności aktualizacji wielu dokumentów lub spójności odczytów do wielu dokumentów, MongoDB zapewnia możliwość wykonywania transakcji wielodokumentowych na zestawach replik. Transakcje wielodokumentowe mogą być wykorzystywane w wielu operacjach, kolekcjach, bazy danych i dokumenty. Transakcje wielodokumentowe zapewniają propozycję "wszystko albo nic". Po zatwierdzeniu transakcji wszystkie zmiany danych dokonane w transakcji są zapisywane. Jeśli jakakolwiek operacja w transakcji nie powiedzie się, transakcja zostanie przerwana, a wszystkie zmiany danych wprowadzone w transakcji zostaną odrzucone, nigdy nie staną się widoczne. Dopóki transakcja nie zostanie zatwierdzona, żadne operacje zapisu w transakcji nie są widoczne poza transakcją.

Choć jest kilka ograniczeń dla Jak i Jakie operacje można wykonać.

Sprawdź Mongo Doc. https://docs.mongodb.com/master/core/transactions/

Możesz zaimplementować aktualizacje Atomic multi-key (transakcja serializowalna) po stronie klienta, jeśli twoja pamięć obsługuje liniowość według klucza oraz porównywanie i ustawianie (co jest prawdą w przypadku MongoDB). Takie podejście jest używane w Percolator Google i w CockroachDB , ale nic nie stoi na przeszkodzie, aby używać go z MongoDB.

Stworzyłem wizualizację krok po kroku takich transakcji. Mam nadzieję, że to pomoże Ci je zrozumieć.

If you ' re fine with Czytaj poziom committed isolation, a następnie warto przyjrzeć się transakcjom RAMPOWYM autorstwa Petera Bailisa. Mogą być również zaimplementowane dla MongoDB po stronie klienta.