Ta strona opisuje rywalizację o dane transakcyjne, serializację i izolację. Przykłady kodu transakcji znajdziesz w artykule Transakcje i zbiorowe zapisy.
Transakcje i konflikt danych
Aby transakcja się powiodła, dokumenty pobrane przez operacje odczytu nie mogą zostać zmodyfikowane przez operacje spoza transakcji. Jeśli inna operacja próbuje zmienić jeden z tych dokumentów, wchodzi ona w stan kolizji danych z transakcją.
- Rywalizacja o dane
- Gdy co najmniej 2 operacje konkurują o kontrolę nad tym samym dokumentem. Na przykład jedna transakcja może wymagać, aby dokument był spójny, podczas gdy równoległa operacja próbuje zaktualizować wartości pól tego dokumentu.
Cloud Firestore rozwiązuje konflikt danych, opóźniając lub zniechęcając jedną z operacji. Biblioteki klienta Cloud Firestore automatycznie powtarzają transakcje, które nie powiodły się z powodu konfliktu danych. Po określonej liczbie prób operacja transakcji kończy się niepowodzeniem i zwraca komunikat o błędzie:
ABORTED: Too much contention on these documents. Please try again.
Decyzja o tym, która operacja ma się nie powieść lub opóźnić, zależy od typu biblioteki klienta.
Pakiety SDK na urządzenia mobilne i internet korzystają z optymalnych mechanizmów kontroli współbieżności.
Biblioteki klienta serwera używają elementów sterujących współbieżnością opartych na pesymizmie.
Rywalizacja o dane w pakietach SDK na urządzenia mobilne i internet
Pakiety SDK na urządzenia mobilne i sieci (platformy Apple, Android, Web, C++) używają optymizmu w przypadku kontroli współbieżności, aby rozwiązywać konflikty danych.
- Optymistyczne mechanizmy kontroli równoczesności
- Na podstawie założenia, że rywalizacja o dane jest mało prawdopodobna lub że blokowanie bazy danych nie jest wydajne. Transakcje optymistycznych aktualizacji nie używają blokad bazy danych, aby uniemożliwić innym operacjom zmianę danych.
Pakiety SDK na urządzenia mobilne i internet używają optymalnych mechanizmów kontroli współbieżności, ponieważ mogą działać w środowiskach o wysokim opóźnieniu i niepewnym połączeniu z internetem. Blokowanie dokumentów w środowisku o wysokiej latencji spowodowałoby zbyt wiele błędów związanych z rywalizacją o dane.
W pakietach SDK na urządzenia mobilne i internet transakcja śledzi wszystkie przeczytane dokumenty w ramach transakcji. Transakcja wykonuje operacje zapisu tylko wtedy, gdy żaden z tych dokumentów nie zmienił się podczas jej wykonywania. Jeśli jakikolwiek dokument uległ zmianie, moduł obsługi transakcji powtarza transakcję. Jeśli transakcja nie może uzyskać czystego wyniku po kilku próbach, transakcja nie powiedzie się z powodu konfliktu danych.
Rywalizacja o dane w bibliotekach klienta serwera
Biblioteki klienta serwera (C#, Go, Java, Node.js, PHP, Python, Ruby) korzystają z kontroli współbieżności w trybie pesymistycznym, aby rozwiązywać konflikty danych.
- Pesymistyczne ustawienia równoczesności
- Na podstawie założenia, że prawdopodobieństwo kolizji danych jest wysokie. Transakcje pesymistyczne używają blokad bazy danych, aby uniemożliwić modyfikowanie danych przez inne operacje.
Biblioteki klienta serwera używają pesymistycznego mechanizmu kontroli współbieżności, ponieważ zakładają niskie opóźnienie i niezawodne połączenie z bazą danych.
W bibliotekach klienta serwera transakcje blokują dokumenty, które są odczytywane. Blokada transakcji na dokumencie uniemożliwia zmianę tego dokumentu przez inne transakcje, zbiorcze zapisy i zapisy niezwiązane z transakcjami. Transakcja odblokowuje blokady dokumentu w momencie zatwierdzenia. Zwalnia też blokady, jeśli czas oczekiwania wygaśnie lub nie powiedzie się z jakiegokolwiek powodu.
Gdy transakcja zablokuje dokument, inne operacje zapisu muszą czekać, aż transakcja zwolni blokadę. Transakcje są blokowane w porządku chronologicznym.
Izolacja serializacji
Rywalizacja o dane między transakcjami jest ściśle powiązana z poziomami izolacji bazy danych. Poziom izolacji bazy danych określa, jak dobrze system radzi sobie z konfliktami między równoległymi operacjami. Konflikt wynika z tych wymagań dotyczących bazy danych:
- Transakcje wymagają dokładnych i spójnych danych.
- Aby efektywnie korzystać z zasobów, bazy danych wykonują operacje równolegle.
W systemach o niskim poziomie izolacji operacja odczytu w ramach transakcji może odczytać niedokładne dane z niezaakceptowanych zmian w równoległej operacji.
Izolacja serializacji określa najwyższy poziom izolacji. Izolacja serializowana oznacza, że:
- Możesz założyć, że baza danych wykonuje transakcje w serii.
- Niezrealizowane zmiany w równoległych operacjach nie mają wpływu na transakcje.
Ta gwarancja musi obowiązywać nawet wtedy, gdy baza danych wykonuje wiele transakcji równolegle. Baza danych musi stosować mechanizmy kontroli współbieżności, aby rozwiązywać konflikty, które mogłyby naruszyć tę gwarancję.
Cloud Firestore gwarantuje serializowalne izolowanie transakcji. Transakcje w Cloud Firestore są serializowane i izolowane w momencie zatwierdzania.
Izolacja serializacji według czasu zatwierdzenia
Cloud Firestore przypisuje do każdej transakcji czas zatwierdzenia, który reprezentuje pojedynczy punkt w czasie. Gdy Cloud Firestore przesyła zmiany transakcji do bazy danych, można założyć, że wszystkie operacje odczytu i zapisu w ramach transakcji mają miejsce dokładnie w momencie przesyłania.
Przeprowadzenie transakcji wymaga pewnego czasu. Wykonywanie transakcji rozpoczyna się przed czasem zatwierdzenia, a wykonywanie wielu operacji może się na siebie nakładać. Cloud Firestore zapewnia izolację serializowaną i gwarantuje, że:
- Cloud Firestore zatwierdza transakcje w kolejności według czasu ich zatwierdzenia.
- Cloud Firestore izoluje transakcje od równoczesnych operacji z późniejszym czasem zatwierdzenia.
W przypadku rywalizacji o dane między równoległymi operacjami Cloud Firestore używa optymizmu i pesymizmu w celu rozwiązania konfliktu.
Izolacja w ramach transakcji
Izolacja transakcji dotyczy również operacji zapisu w ramach transakcji. Zapytania i odczyty w ramach transakcji nie widzą wyników poprzednich zapisów w ramach tej transakcji. Nawet jeśli zmodyfikujesz lub usuniesz dokument w ramach transakcji, wszystkie odczyty dokumentu w tej transakcji zwracają wersję dokumentu w momencie zatwierdzenia, czyli przed operacjami zapisu transakcji. Operacje odczytu nie zwracają niczego, jeśli dokument nie istniał.
Problemy z konfliktem danych
Więcej informacji o konflikcie danych i sposobach jego rozwiązania znajdziesz na stronie z poradami dotyczącymi rozwiązywania problemów.