Ta strona opisuje rywalizację z danymi transakcyjnymi, serializowalność i izolację. Przykładowe kody transakcji znajdziesz w artykule o transakcjach i zapisach wsadowych.
Transakcje i rywalizacja o dane
Aby transakcja została zrealizowana, dokumenty pobrane w ramach jej operacji odczytu nie mogą być zmodyfikowane przez operacje poza transakcją. Jeśli inna operacja próbuje zmienić jeden z tych dokumentów, przechodzi w stan rywalizacji o dane z transakcją.
- Rywalizacja o dane
- Gdy co najmniej 2 operacje konkurują o kontrolę tego samego dokumentu. Na przykład jedna transakcja może wymagać zachowania spójności dokumentu, a jednoczesna operacja próbuje zaktualizować wartości pól w tym dokumencie.
Cloud Firestore rozwiązuje konflikty dotyczące danych, opóźniając lub kończąc jedną z operacji. Biblioteki klienta Cloud Firestore automatycznie ponawiają próby transakcji, które zakończyły się niepowodzeniem z powodu rywalizacji o dane. Po skończonej liczbie ponownych prób operacja transakcji kończy się niepowodzeniem i zwraca komunikat o błędzie:
ABORTED: Too much contention on these documents. Please try again.
Podejmowanie decyzji o tym, które działanie zakończy się niepowodzeniem, czy z opóźnieniem, zależy od typu biblioteki klienta.
Pakiety SDK do aplikacji mobilnych i internetowych korzystają z optymistycznych ustawień równoczesności.
Biblioteki klienta serwera używają pesymistycznych ustawień równoczesności.
Rywalizacja o dane w mobilnych i internetowych pakietach SDK
Pakiety SDK na urządzenia mobilne i internetowe (platformy Apple, Android, internet, C++) wykorzystują optymistyczne ustawienia równoczesności, aby rozwiązywać konflikty o dane.
- Ustawienia optymalnej równoczesności
- Opieramy się na założeniu, że rywalizacja o dane jest mało prawdopodobna lub że nie jest skuteczne utrzymywanie blokad baz danych. W transakcjach optymistycznych nie są wykorzystywane blokady baz danych do blokowania innym operacji zmiany danych.
Pakiety SDK do aplikacji mobilnych i internetowych wykorzystują optymistyczne ustawienia równoczesności, ponieważ mogą działać w środowiskach z dużym czasem oczekiwania i niestabilnym połączeniem sieciowym. Blokowanie dokumentów w środowisku o dużym czasie oczekiwania spowodowałoby powstanie wielu błędów w ramach rywalizacji o dane.
W przypadku pakietów SDK do urządzeń mobilnych/internetowych transakcja śledzi wszystkie dokumenty czytane w jej ramach. Transakcja kończy się operacji zapisu tylko wtedy, gdy żaden z tych dokumentów nie został zmieniony podczas jej wykonywania. Jeśli jakikolwiek dokument uległ zmianie, moduł obsługi transakcji ponownie próbuje zrealizować transakcję. Jeśli po kilku próbach nie uda się uzyskać wiarygodnego wyniku, transakcja zakończy się niepowodzeniem z powodu rywalizacji o dane.
Rywalizacja o dane w bibliotekach klienta serwera
Biblioteki klienta serwera (C#, Go, Java, Node.js, PHP, Python, Ruby) używają pesymistycznych mechanizmów kontroli równoczesności do rozwiązywania rywalizacji o dane.
- Pesymistyczne ustawienia równoczesności
- Na podstawie założenia, że rywalizacja o dane jest prawdopodobna. Transakcje pesymistyczne wykorzystują blokady bazy danych, aby uniemożliwić innym operacjam modyfikowanie danych.
Biblioteki klienta serwera używają pesymistycznych mechanizmów kontroli równoczesności, ponieważ przyjmują krótki czas oczekiwania i niezawodne połączenie z bazą danych.
W bibliotekach klienta serwera transakcje nakładają blokady na odczytywane dokumenty. Blokada transakcji na dokumencie uniemożliwia zmianę tego dokumentu w przypadku innych transakcji, zapisów zbiorczych i zapisów niezwiązanych z transakcjami. Blokady dokumentów transakcji są zwalniane w czasie zatwierdzenia. Zwalnia swoje blokady też w przypadku przekroczenia limitu czasu lub awarii z jakiegoś powodu.
Gdy transakcja blokuje dokument, inne operacje zapisu muszą poczekać, aż transakcja odblokuje blokadę. Transakcje zostają zablokowane w kolejności chronologicznej.
Izolacja szeregowa
Rywalizacja danych między transakcjami jest ściśle związana z poziomami izolacji baz danych. Poziom izolacji bazy danych określa, jak dobrze system obsługuje konflikty między operacjami równoczesnymi. Konflikt wynika z tych wymagań bazy danych:
- Transakcje wymagają dokładnych i spójnych danych.
- Aby wydajnie wykorzystywać zasoby, bazy danych wykonują operacje jednocześnie.
W systemach o niskim poziomie izolacji operacja odczytu w ramach transakcji może odczytać nieprawidłowe dane pochodzące z niezatwierdzonych zmian w ramach równoczesnej operacji.
Serializowalna izolacja określa najwyższy poziom izolacji. Serializowalna izolacja oznacza, że:
- Możesz przyjąć, że baza danych wykonuje transakcje w serii.
- Niezatwierdzone zmiany w operacjach równoczesnych nie mają wpływu na transakcje.
Ta gwarancja musi być blokowana nawet wtedy, gdy baza danych wykonuje równolegle wiele transakcji. Baza danych musi wdrożyć ustawienia równoczesności, aby rozwiązywać konflikty, które mogłyby złamać tę gwarancję.
Cloud Firestore gwarantuje serializowalną izolację transakcji. Transakcje w Cloud Firestore są serializowane i odizolowane według czasu zatwierdzenia.
Serializowalna izolacja według czasu zatwierdzenia
Cloud Firestore przypisuje każdej transakcji czas zatwierdzenia, który reprezentuje pojedynczy punkt w czasie. Gdy Cloud Firestore zatwierdzi zmiany w transakcji w bazie danych, możesz przyjąć, że wszystkie odczyty i zapisy w ramach transakcji mają miejsce dokładnie w momencie zatwierdzenia.
Faktyczne wykonanie transakcji wymaga nieco czasu. Realizacja transakcji rozpoczyna się przed czasem zatwierdzenia i wykonanie wielu operacji może się nakładać. Cloud Firestore stosuje serializowalną izolację i gwarantuje, że:
- Cloud Firestore zatwierdza transakcje w kolejności według czasu zatwierdzenia.
- Cloud Firestore izoluje transakcje od działań równoległych z późniejszym czasem zatwierdzenia.
W przypadku rywalizacji o dane między operacjami równoczesnymi Cloud Firestore używa optymistycznej i pesymistycznej kontroli równoczesności do rozwiązywania rywalizacji.
Izolacja w ramach transakcji
Izolacja transakcji ma również zastosowanie do operacji zapisu w ramach transakcji. Zapytania i odczyty w ramach transakcji nie widzą wyników poprzednich zapisów w tej transakcji. Nawet jeśli zmodyfikujesz lub usuniesz dokument w ramach transakcji, wszystkie odczyty dokumentów w tej transakcji będą zwracać wersję dokumentu w czasie zatwierdzenia, przed wykonaniem operacji zapisu w transakcji. Operacje odczytu nie zwracają niczego, jeśli dokument nie istniał w danym momencie.
Problemy z rywalizacją o dane
Więcej informacji na temat rywalizacji o dane i sposobów jej rozwiązywania znajdziesz na stronie rozwiązywania problemów.