Nie jestem ekspertem od baz danych i nie mam formalnego zaplecza informatycznego, więc proszę o wyrozumiałość. Chcę poznać rodzaje negatywnych rzeczy w świecie rzeczywistym, które mogą się zdarzyć, jeśli użyjesz starej wersji MongoDB przed wersją v4 , które nie były zgodne z ACID . Dotyczy to każdej bazy danych niezgodnej z ACID.
Rozumiem, że MongoDB może wykonywać Operacje Atomowe , ale nie obsługują „tradycyjnych blokad i złożonych transakcji”, głównie ze względu na wydajność. Rozumiem również znaczenie transakcji w bazie danych i przykład, kiedy twoja baza danych jest dla banku, a aktualizujesz kilka rekordów, z których wszystkie muszą być zsynchronizowane, chcesz, aby transakcja powróciła do stanu początkowego, jeśli istnieje przerwa w zasilaniu, więc kredyt równa się zakupowi itp.
Ale kiedy wchodzę w rozmowy na temat MongoDB, ci z nas, którzy nie znają technicznych szczegółów tego, jak bazy danych są faktycznie wdrażane, zaczynają rzucać się na takie stwierdzenia:
MongoDB jest znacznie szybszy niż MySQL i Postgres, ale istnieje niewielka szansa, na przykład 1 na milion, że „nie zapisze się poprawnie”.
Ta część „nie zapisuje się poprawnie” odnosi się do tego zrozumienia: jeśli w chwili pisania w MongoDB nastąpi przerwa w dostawie prądu, istnieje szansa na określony rekord (powiedzmy, że śledzisz odsłony w dokumentach z 10 atrybutami każdego), że jeden z dokumentów zapisał tylko 5 atrybutów… co z czasem oznacza, że liczniki wyświetleń strony będą „nieznacznie” wyłączone. Nigdy nie dowiesz się o ile, wiesz, że będą one w 99,999% poprawne, ale nie w 100%. Wynika to z faktu, że dopóki nie uczynisz tego konkretnie operacją atomową mongodb , nie ma gwarancji, że operacja ta będzie atomowa.
Więc moje pytanie brzmi: jaka jest prawidłowa interpretacja kiedy i dlaczego MongoDB może nie „poprawnie zapisać”? Jakie części ACID nie spełnia i pod jakimi warunkami i skąd wiesz, kiedy 0,001% twoich danych jest wyłączone? Czy nie da się tego jakoś naprawić? Jeśli nie, oznacza to, że nie powinieneś przechowywać takich rzeczy jak twój usersstół w MongoDB, ponieważ rekord może nie zostać zapisany. Ale z drugiej strony, 1/1 000 000 użytkowników może po prostu „spróbować zarejestrować się ponownie”, nie?
Właśnie szukam być może listy, kiedy / dlaczego zdarzają się negatywne rzeczy z niezgodną bazą danych ACID, taką jak MongoDB, i idealnie, jeśli istnieje standardowe obejście (na przykład uruchomienie zadania w tle w celu oczyszczenia danych lub użycie SQL tylko do tego itp.) .