Na tej stronie opisano rywalizację o dane transakcyjne, możliwość serializacji i izolację. Aby zapoznać się z przykładowymi kodami transakcji, zobacz transakcje i zapisy wsadowe .
Transakcje i rywalizacja o dane
Aby transakcja zakończyła się sukcesem, dokumenty pobrane w wyniku operacji odczytu muszą pozostać niezmienione przez operacje poza transakcją. Jeżeli inna operacja podejmie próbę zmiany jednego z tych dokumentów, operacja ta wejdzie w stan rywalizacji o dane z transakcją.
- Konflikt danych
- Gdy dwie lub więcej operacji konkuruje o kontrolę nad tym samym dokumentem. Na przykład jedna transakcja może wymagać, aby dokument pozostał spójny, podczas gdy współbieżna operacja próbuje zaktualizować wartości pól tego dokumentu.
Cloud Firestore rozwiązuje rywalizację o dane, opóźniając lub niepowodzeniem jednej z operacji. Biblioteki klienckie Cloud Firestore automatycznie ponawiają transakcje, które nie powiodły się 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.
Przy podejmowaniu decyzji, która operacja zakończy się niepowodzeniem lub opóźnieniem, zachowanie zależy od typu biblioteki klienckiej.
Zestawy SDK dla urządzeń mobilnych/internetowych korzystają z optymistycznej kontroli współbieżności.
Biblioteki klienta serwera korzystają z pesymistycznej kontroli współbieżności.
Rywalizacja o dane w mobilnych/internetowych zestawach SDK
Zestawy SDK dla urządzeń mobilnych/internetowych (platformy Apple, Android, Internet, C++) wykorzystują optymistyczną kontrolę współbieżności w celu rozwiązywania rywalizacji o dane.
- Optymistyczna kontrola współbieżności
- Opiera się na założeniu, że rywalizacja o dane jest mało prawdopodobna lub że utrzymywanie blokad bazy danych jest nieefektywne. Transakcje optymistyczne nie korzystają z blokad baz danych w celu blokowania innych operacji przed zmianą danych.
Zestawy SDK do urządzeń mobilnych/internetowych korzystają z optymistycznej kontroli współbieżności, ponieważ mogą działać w środowiskach o dużych opóźnieniach i zawodnym połączeniu sieciowym. Blokowanie dokumentów w środowisku o dużym opóźnieniu mogłoby spowodować zbyt wiele niepowodzeń rywalizacji o dane.
W pakietach SDK dla urządzeń mobilnych/internetowych transakcja śledzi wszystkie dokumenty, które przeczytałeś w ramach transakcji. Transakcja kończy operację zapisu tylko wtedy, gdy żaden z tych dokumentów nie uległ zmianie w trakcie realizacji transakcji. Jeśli jakikolwiek dokument uległ zmianie, osoba obsługująca transakcję ponawia transakcję. Jeśli transakcja nie może uzyskać czystego wyniku po kilku ponownych próbach, transakcja kończy się niepowodzeniem z powodu rywalizacji o dane.
Rywalizacja danych w bibliotekach klienta serwera
Biblioteki klienta serwera (C#, Go, Java, Node.js, PHP, Python, Ruby) wykorzystują pesymistyczną kontrolę współbieżności, rozwiązując rywalizację o dane.
- Pesymistyczna kontrola współbieżności
- Opiera się na założeniu, że spór o dane jest prawdopodobny. Transakcje pesymistyczne korzystają z blokad baz danych, aby zapobiec modyfikowaniu danych przez inne operacje.
Biblioteki klienta serwera stosują pesymistyczną kontrolę współbieżności, ponieważ zakładają małe opóźnienia i niezawodne połączenie z bazą danych.
W bibliotekach klienta serwera transakcje nakładają blokady na czytane dokumenty. Blokada transakcji na dokumencie blokuje inne transakcje, zapisy wsadowe i zapisy nietransakcyjne uniemożliwiające zmianę tego dokumentu. Transakcja zwalnia blokady dokumentów w momencie zatwierdzenia. Zwalnia również blokady, jeśli upłynie limit czasu lub zakończy się niepowodzeniem z jakiegokolwiek powodu.
Kiedy transakcja blokuje dokument, inne operacje zapisu muszą poczekać, aż transakcja zwolni blokadę. Transakcje uzyskują swoje blokady w porządku chronologicznym.
Izolacja z możliwością serializacji
Rywalizacja danych pomiędzy transakcjami jest ściśle powiązana z poziomami izolacji bazy danych. Poziom izolacji bazy danych opisuje, jak dobrze system radzi sobie z konfliktami pomiędzy współbieżnymi operacjami. Konflikt wynika z następujących wymagań bazy danych:
- Transakcje wymagają dokładnych i spójnych danych.
- Aby efektywnie wykorzystywać zasoby, bazy danych wykonują operacje współbieżnie.
W systemach o niskim poziomie izolacji operacja odczytu w ramach transakcji może odczytać niedokładne dane z niezatwierdzonych zmian w operacji współbieżnej.
Izolacja serializowalna definiuje najwyższy poziom izolacji. Izolacja serializowalna oznacza, że:
- Można założyć, że baza danych realizuje transakcje seriami.
- Niezatwierdzone zmiany w operacjach współbieżnych nie mają wpływu na transakcje.
Gwarancja ta musi obowiązywać nawet wtedy, gdy baza danych wykonuje wiele transakcji równolegle. Baza danych musi implementować kontrolę współbieżności, aby rozwiązywać konflikty, które mogłyby naruszyć tę gwarancję.
Cloud Firestore gwarantuje serializowalną izolację transakcji. Transakcje w Cloud Firestore są serializowane i izolowane według czasu zatwierdzenia.
Izolacja z możliwością serializacji według czasu zatwierdzenia
Cloud Firestore przypisuje każdej transakcji czas zatwierdzenia, który reprezentuje pojedynczy punkt w czasie. Kiedy Cloud Firestore zatwierdza zmiany transakcji w bazie danych, możesz założyć, że wszystkie odczyty i zapisy w ramach transakcji mają miejsce dokładnie w momencie zatwierdzenia.
Rzeczywista realizacja transakcji wymaga pewnego czasu. Wykonanie transakcji rozpoczyna się przed czasem zatwierdzenia, a wykonanie wielu operacji może się nakładać. Cloud Firestore utrzymuje izolację umożliwiającą serializację i gwarantuje, że:
- Cloud Firestore zatwierdza transakcje w kolejności według czasu zatwierdzenia.
- Cloud Firestore izoluje transakcje od współbieżnych operacji z późniejszym czasem zatwierdzenia.
W przypadku rywalizacji danych między współbieżnymi operacjami Cloud Firestore wykorzystuje optymistyczną i pesymistyczną kontrolę współbieżności w celu rozwiązania rywalizacji.
Izolacja w ramach transakcji
Izolacja transakcji dotyczy również operacji zapisu w ramach transakcji. Zapytania i odczyty wewnątrz 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 zwrócą wersję dokumentu w momencie zatwierdzenia, przed operacjami zapisu transakcji. Operacje odczytu nic nie zwracają, jeśli dokument wtedy nie istniał.
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 .