Wybieranie właściwego poziomu spójności
Każdy z modeli spójności może służyć do konkretnych rzeczywistych scenariuszy. Każda z nich zapewnia precyzyjne kompromisy w zakresie dostępności i wydajności wspierane przez kompleksowe umowy SLA. Poniższe proste zagadnienia ułatwiają wybór w wielu typowych scenariuszach.
Konfigurowanie domyślnego poziomu spójności
Domyślny poziom spójności na koncie usługi Azure Cosmos DB można skonfigurować w dowolnym momencie. Domyślny poziom spójności skonfigurowany na koncie ma zastosowanie do wszystkich baz danych i kontenerów usługi Azure Cosmos DB w ramach tego konta. Wszystkie operacje odczytu i zapytania wystawione względem kontenera lub bazy danych domyślnie używają określonego poziomu spójności.
Spójność odczytu ma zastosowanie do pojedynczej operacji odczytu o zakresie w ramach partycji logicznej. Operację odczytu można wydać przez klienta zdalnego lub procedurę składowaną.
Gwarancje związane z poziomami spójności
Usługa Azure Cosmos DB gwarantuje, że 100 procent żądań odczytu spełnia gwarancję spójności wybranego poziomu spójności. Dokładne definicje pięciu poziomów spójności w usłudze Azure Cosmos DB przy użyciu języka specyfikacji TLA+ znajdują się w repozytorium GitHub azure-cosmos-tla .
Silna spójność
Silna spójność zapewnia gwarancję operacji atomowych. Linearyzność odnosi się do współbieżnej obsługi żądań. Operacje odczytu mają gwarancję zwrócenia najnowszej zatwierdzonej wersji elementu. Klient nigdy nie widzi niezatwierdzonego lub częściowego zapisu. Użytkownicy zawsze mają gwarancję odczytu najnowszego zatwierdzonego zapisu.
Powiązana nieaktualność
W przypadku spójności powiązanej nieaktualności opóźnienie danych między dowolnymi dwoma regionami jest zawsze mniejsze niż określona ilość. Kwota może być wersjami "K" (czyli "aktualizacjami") elementu lub interwałami czasu "T", w zależności od tego, która z nich zostanie osiągnięta jako pierwsza. Innymi słowy, po wybraniu powiązanej nieaktualności maksymalną "nieaktualność" danych w dowolnym regionie można skonfigurować na dwa sposoby:
- Liczba wersji elementu (K)
- Odczyty interwału czasu (T) mogą być opóźniane za zapisami
Powiązana nieaktualność jest korzystna przede wszystkim dla kont zapisu w jednym regionie z co najmniej dwoma regionami. Jeśli opóźnienie danych w regionie (określonym na partycję fizyczną) przekracza skonfigurowaną wartość nieaktualności, zapisy dla tej partycji są ograniczane, dopóki nieaktualność nie zostanie przywrócona w skonfigurowanej górnej granicy.
W przypadku konta z jednym regionem powiązana nieaktualność zapewnia takie same gwarancje spójności zapisu jak sesja i spójność ostateczna. W przypadku nieograniczonej nieaktualności dane są replikowane do większości lokalnej (trzy repliki w czterech zestawach replik) w jednym regionie.
Spójność sesji
W ramach spójności sesji w ramach pojedynczej sesji klienta operacje odczytu są gwarantowane, aby przestrzegać gwarancji odczytu i zapisu po odczytach. Ta gwarancja zakłada, że jedna sesja "zapisywania" lub udostępnianie tokenu sesji dla wielu składników zapisywania.
Podobnie jak wszystkie poziomy spójności słabsze niż silne, zapisy są replikowane do co najmniej trzech replik (w czterech zestawach replik) w regionie lokalnym z replikacją asynchroniczną do wszystkich innych regionów.
Spójny prefiks
W spójnym prefiksie aktualizacje wprowadzone jako zapisy pojedynczego dokumentu widzą spójność ostateczną. Aktualizacje wprowadzone jako partia w ramach transakcji są zwracane zgodnie z transakcją, w której zostały zatwierdzone. Operacje zapisu w ramach transakcji wielu dokumentów są zawsze widoczne razem.
Załóżmy, że dwie operacje zapisu są wykonywane w dokumentach Doc 1 i Doc 2 w transakcjach T1 i T2. Gdy klient wykonuje odczyt w dowolnej repliki, użytkownik widzi dokument "Doc 1 v1 i Doc 2 v1" lub "Doc 1 v2 i Doc 2 v2", ale nigdy "Doc 1 v1 i Doc 2 v2" lub "Doc 1 v2 i Doc 2 v1" dla tej samej operacji odczytu lub zapytania.
Spójność ostateczna
W przypadku spójności ostatecznej nie ma gwarancji porządkowania odczytów. W przypadku braku jakichkolwiek dalszych zapisów repliki staną się ostatecznie zbieżne.
Spójność ostateczna jest najsłabszą formą spójności, ponieważ klient może odczytać wartości starsze niż te, które odczytał wcześniej. Spójność ostateczna jest idealnie dostosowana do sytuacji, w której aplikacja nie wymaga żadnych gwarancji związanych z kolejnością. Przykłady obejmują liczbę komentarzy Retweets, Likes lub nonthreaded