serializowalność i izolacja transakcji;

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 korzystają z pesymistycznych mechanizmów kontroli współbieżności.

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 optymistyczne 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) używają pesymistycznego mechanizmu kontroli współbieżności, aby rozwiązywać konflikty danych.

Pesymistyczne ustawienia równoczesności
Na podstawie założenia, że prawdopodobieństwo konfliktu 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 zwalni z blokady dokumenty 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.

Rzeczywiste wykonanie 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.