Learn how Firestore can scale to power your enterprise applications, now with MongoDB compatibility. Learn more in Google Cloud.

Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

serializowalność i izolacja transakcji;

Na tej stronie opisano rywalizację o dane transakcyjne, serializowalność i izolację. Przykładowe kody transakcji znajdziesz w sekcji Transakcje i zapisy zbiorcze.

Transakcje i rywalizacja o dane

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, przechodzi w stan rywalizacji o dane 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 pozostał spójny, podczas gdy równoczesna operacja próbuje zaktualizować wartości pól tego dokumentu.

Cloud Firestore rozwiązuje problem rywalizacji o dane, opóźniając lub unieważniając jedną z operacji. Biblioteki klienta Cloud Firestore automatycznie ponawiają transakcje, które nie powiodły się z powodu rywalizacji o dane. Po określonej 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.

Decyzja o tym, którą operację nie wykonać lub opóźnić, zależy od typu kontroli równoczesności.

Kontrola równoczesności

Tryb równoczesności to konfigurowalna opcja bazy danych. Cloud Firestore obsługuje te tryby równoczesności:

PESSIMISTIC: pesymistyczna kontrola równoczesności zakłada, że rywalizacja o dane jest prawdopodobna. Transakcje pesymistyczne używają blokad bazy danych, aby uniemożliwić innym operacjom modyfikowanie danych.

W przypadku pesymistycznej kontroli równoczesności transakcje blokują odczytywane dokumenty. Blokada dokumentu przez transakcję uniemożliwia innym transakcjom, zapisom zbiorczym i zapisom nietransakcyjnym zmianę tego dokumentu. Transakcja zwalnia blokady dokumentów w momencie zatwierdzenia. Zwalnia też blokady, jeśli upłynie limit czasu lub wystąpi błąd.

Gdy transakcja blokuje dokument, inne operacje zapisu muszą poczekać, aż transakcja zwolni blokadę. Transakcje uzyskują blokady w porządku chronologicznym.
OPTIMISTIC: optymistyczna kontrola równoczesności zakłada, że rywalizacja o dane jest mało prawdopodobna lub że blokowanie bazy danych jest nieefektywne. Transakcje optymistyczne nie używają blokad bazy danych, aby uniemożliwić innym operacjom zmianę danych.

W przypadku optymistycznej kontroli równoczesności transakcja śledzi wszystkie dokumenty, które odczytujesz w jej ramach. Transakcja kończy operacje zapisu tylko wtedy, gdy żaden z tych dokumentów nie uległ zmianie podczas jej wykonywania. Jeśli którykolwiek dokument uległ zmianie, moduł obsługi transakcji ponawia transakcję. Jeśli po kilku próbach transakcja nie może uzyskać czystego wyniku, kończy się niepowodzeniem z powodu rywalizacji o dane.

Domyślne ustawienia trybu równoczesności

Wartość domyślna w wersji Standard to PESSIMISTIC. Wartość domyślna w wersji Enterprise to OPTIMISTIC. Jednak zachowanie zależy też od typu biblioteki klienta:

Pakiety SDK do aplikacji mobilnych i internetowych korzystają z optymistycznej kontroli równoczesności. Pakiety SDK na urządzenia mobilne i do aplikacji internetowych działają niezależnie od tego ustawienia, ponieważ zawsze emulują optymistyczną równoczesność.
Biblioteki klienta serwera używają ustawień kontroli równoczesności bazy danych.

Tryb równoczesnego wyświetlania

Uruchom polecenie gcloud firestore databases describe, aby wyświetlić tryb równoczesności po stronie serwera bazy danych:

gcloud firestore databases describe \
  --project=PROJECT_ID \
  --database=DATABASE_ID

Zmiana trybu równoczesności

Uruchom polecenie gcloud firestore databases update, aby zmienić tryb równoczesności po stronie serwera bazy danych:

gcloud firestore databases update \
  --project=PROJECT_ID \
  --database=DATABASE_ID \
  --concurrency-mode=CONCURRENCY_MODE

gdzie:

CONCURRENCY_MODE to PESSIMISTIC lub OPTIMISTIC.
PROJECT_ID to identyfikator projektu Google Cloud.
DATABASE_ID to identyfikator bazy danych Cloud Firestore.

Rywalizacja o dane w pakietach SDK na urządzenia mobilne i do przeglądarek

Pakiety SDK do aplikacji mobilnych i internetowych emulują transakcje optymistycznej równoległości, używając warunków wstępnych zapisu w wersjach dokumentów. Ta emulacja występuje niezależnie od ustawienia trybu równoczesności bazy danych. Pakiety SDK na urządzenia mobilne i do przeglądarek nie korzystają z funkcji wbudowanych transakcji, więc nawet jeśli tryb równoczesności bazy danych jest skonfigurowany na PESSIMISTIC, klienci mobilni nadal zachowują się optymistycznie.

Pakiety SDK na urządzenia mobilne i do przeglądarek korzystają z optymistycznej kontroli równoczesnoś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 powodowałoby zbyt wiele błędów związanych z rywalizacją o dane.

Rywalizacja o dane w bibliotekach klienta serwera

Biblioteki klienta serwera (C#, Go, Java, Node.js, PHP, Python, Ruby) korzystają z funkcji wbudowanych transakcji. Te transakcje używają ustawienia trybu równoczesności na poziomie bazy danych, a domyślne ustawienie zależy od wersji:

Wersja Enterprise domyślnie używa optymistycznej kontroli równoczesności do obsługi operacji, które skanują całe kolekcje. Optymistyczna kontrola równoczesności pomaga uniknąć operacji skanowania, które blokują dużą liczbę dokumentów.
Wersja Standard używa pesymistycznej kontroli równoczesności i zakłada małe opóźnienia oraz niezawodne połączenie z bazą danych.

Izolacja serializowalna

Rywalizacja o dane między transakcjami jest ściśle związana z poziomami izolacji bazy danych. Poziom izolacji bazy danych określa, jak dobrze system radzi sobie z konfliktami między równoczesnymi operacjami. Konflikt wynika z tych wymagań bazy danych:

Transakcje wymagają dokładnych i spójnych danych.
Aby efektywnie wykorzystywać zasoby, bazy danych wykonują operacje jednocześnie.

W systemach o niskim poziomie izolacji operacja odczytu w ramach transakcji może odczytać niedokładne dane z niezatwierdzonych zmian w operacji równoczesnej.

Izolacja serializowalna definiuje najwyższy poziom izolacji. Izolacja Serializable oznacza, że:

Możesz założyć, że baza danych wykonuje transakcje szeregowo.
Na transakcje nie mają wpływu niezatwierdzone zmiany w operacjach równoczesnych.

Ta gwarancja musi obowiązywać nawet wtedy, gdy baza danych wykonuje wiele transakcji równolegle. Baza danych musi implementować mechanizmy kontroli równoczesnoś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. Gdy Cloud Firestore przesyła zmiany transakcji do bazy danych, możesz założyć, że wszystkie odczyty i zapisy w ramach transakcji odbywają się dokładnie w momencie przesłania.

Rzeczywiste wykonanie transakcji wymaga pewnego czasu. Wykonywanie transakcji rozpoczyna się przed czasem zatwierdzenia, a wykonywanie wielu operacji może się nakładać. Cloud Firestore zachowuje izolację z możliwością serializacji i gwarantuje, że:

Cloud Firestore zatwierdza transakcje w kolejności według czasu zatwierdzenia.
Cloud Firestore izoluje transakcje od równoczesnych operacji z późniejszym czasem zatwierdzenia.

W przypadku rywalizacji o dane między równoczesnymi operacjami Cloud Firestore używa optymistycznej i pesymistycznej kontroli równoczesności, aby rozwiązać problem.

Izolacja w ramach transakcji

Izolacja transakcji dotyczy też 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 dokumentu w tej transakcji zwrócą wersję dokumentu z czasu zatwierdzenia, przed operacjami zapisu transakcji. Operacje odczytu nie zwracają niczego, jeśli dokument nie istniał w danym momencie.

Problemy z rywalizacją o dane

Więcej informacji o rywalizacji o dane i sposobach jej rozwiązywania znajdziesz na stronie rozwiązywania problemów.