Poziomy spójności w usłudze Azure Cosmos DB
DOTYCZY: 
NoSQL MongoDB Kasandra Gremlin Stół
Rozproszone bazy danych, które opierają się na replikacji w celu zapewnienia wysokiej dostępności, małych opóźnień lub obu tych metod, muszą mieć fundamentalny kompromis między spójnością odczytu, dostępnością, opóźnieniami i przepływnością zdefiniowaną przez twierdzenie PACELC. Liniowość modelu silnej spójności jest złotym standardem programowym danych. Dodaje jednak stromą cenę z wyższych opóźnień zapisu ze względu na konieczność replikacji i zatwierdzania danych w dużych odległościach. Silna spójność może również mieć obniżoną dostępność (podczas awarii), ponieważ dane nie mogą być replikowane i zatwierdzane w każdym regionie. Spójność ostateczna zapewnia większą dostępność i lepszą wydajność, ale jest trudniej programować aplikacje, ponieważ dane mogą nie być spójne we wszystkich regionach.
Większość dostępnych komercyjnie rozproszonych baz danych NoSQL dostępnych obecnie na rynku zapewnia tylko silną i ostateczną spójność. Usługa Azure Cosmos DB oferuje pięć dobrze zdefiniowanych poziomów. Od najsilniejszych do najsłabszych poziomów:
Aby uzyskać więcej informacji na temat domyślnego poziomu spójności, zobacz konfigurowanie domyślnego poziomu spójności lub zastępowanie domyślnego poziomu spójności.
Każdy poziom zapewnia kompromisy dotyczące dostępności i wydajności. Na poniższej ilustracji przedstawiono różne poziomy spójności jako spektrum.
Poziomy spójności i interfejsy API usługi Azure Cosmos DB
Usługa Azure Cosmos DB zapewnia natywną obsługę interfejsów API zgodnych z protokołem wire dla popularnych baz danych. Należą do nich bazy danych MongoDB, Apache Cassandra, Apache Gremlin i Azure Table Storage. W interfejsie API dla języka Gremlin lub tabeli używany jest domyślny poziom spójności skonfigurowany na koncie usługi Azure Cosmos DB. Aby uzyskać szczegółowe informacje na temat mapowania poziomu spójności między usługą Apache Cassandra i usługą Azure Cosmos DB, zobacz API for Cassandra consistency mapping (Interfejs API dla mapowania spójności bazy danych Cassandra). Aby uzyskać szczegółowe informacje na temat mapowania poziomu spójności między bazą danych MongoDB i usługą Azure Cosmos DB, zobacz Api for MongoDB consistency mapping (Interfejs API dla mapowania spójności bazy danych MongoDB).
Zakres spójności odczytu
Spójność odczytu ma zastosowanie do pojedynczej operacji odczytu o zakresie w ramach partycji logicznej. Klient zdalny, procedura składowana lub wyzwalacz może wystawiać operację odczytu.
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. Podczas zmiany spójności na poziomie konta upewnij się, że ponownie wdrażasz aplikacje i wprowadzasz wszelkie niezbędne modyfikacje kodu, aby zastosować te zmiany. Aby dowiedzieć się więcej, zobacz konfigurowanie domyślnego poziomu spójności. Możesz również zastąpić domyślny poziom spójności dla określonego żądania, aby dowiedzieć się więcej, zobacz, jak zastąpić domyślny poziom spójności artykułu.
Napiwek
Zastąpienie domyślnego poziomu spójności dotyczy tylko operacji odczytu w kliencie zestawu SDK. Konto skonfigurowane pod kątem silnej spójności domyślnie będzie nadal zapisywać i replikować dane synchronicznie do każdego regionu na koncie. Gdy wystąpienie klienta zestawu SDK lub żądanie zastąpi to za pomocą sesji lub słabszej spójności, operacje odczytu będą wykonywane przy użyciu pojedynczej repliki. Aby uzyskać więcej informacji, zobacz Poziomy spójności i przepływność.
Ważne
Po zmianie domyślnego poziomu spójności wymagane jest ponowne utworzenie dowolnego wystąpienia zestawu SDK. Można to zrobić, uruchamiając ponownie aplikację. Gwarantuje to, że zestaw SDK używa nowego domyślnego poziomu spójności.
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 .
Semantyka pięciu poziomów spójności opisano w poniższych sekcjach.
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.
Poniższa grafika ilustruje silną spójność z nutami muzycznymi. Po zapisaniu danych w regionie "Zachodnie stany USA 2" podczas odczytywania danych z innych regionów uzyskasz najnowszą wartość:
Dynamiczne kworum
W normalnych okolicznościach dla konta z silną spójnością zapis jest uznawany za zatwierdzony, gdy wszystkie regiony uznają, że rekord został zreplikowany do niego. Jednak w przypadku kont z co najmniej 3 regionami (w tym regionem zapisu) system może "obniżyć" kworum regionów do globalnej większości w przypadkach, gdy niektóre regiony nie odpowiadają lub reagują powoli. W tym momencie regiony nie odpowiadają z zestawu kworum dla regionów w celu zachowania silnej spójności. Zostaną one dodane tylko wtedy, gdy będą zgodne z innymi regionami i działają zgodnie z oczekiwaniami. Liczba regionów, które mogą zostać potencjalnie wyjęte z zestawu kworum, będzie zależeć od całkowitej liczby regionów. Na przykład na koncie 3 lub 4 regionów większość to odpowiednio 2 lub 3 regiony, więc w obu przypadkach można usunąć tylko jeden region. W przypadku konta 5 regionów większość wynosi 3, więc można usunąć maksymalnie 2 regiony, które nie odpowiadają. Ta funkcja jest znana jako "dynamiczne kworum" i może zwiększyć dostępność zapisu i opóźnienie replikacji dla kont z co najmniej 3 regionami.
Uwaga
Gdy regiony zostaną usunięte z zestawu kworum w ramach kworum dynamicznego, te regiony nie będą już mogły obsługiwać odczytów do momentu ponownego dodania do kworum.
Powiązana nieaktualność
W przypadku kont zapisu w jednym regionie z co najmniej dwoma regionami dane są replikowane z regionu podstawowego do wszystkich regionów pomocniczych (tylko do odczytu). W przypadku kont zapisu w wielu regionach z co najmniej dwoma regionami dane są replikowane z regionu, w którym zostały pierwotnie zapisane we wszystkich innych regionach zapisywalnych. W obu scenariuszach, choć nie jest to typowe, czasami może występować opóźnienie replikacji z jednego regionu do drugiego.
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.
Ważne
Ze spójnością powiązana nieaktualność kontrole nieaktualności są wykonywane tylko w różnych regionach, a nie w regionie. W danym regionie dane są zawsze replikowane do większości lokalnej (trzy repliki w czterech zestawach replik) niezależnie od poziomu spójności.
Odczyty w przypadku używania powiązanej nieaktualności zwracają najnowsze dane dostępne w tym regionie, odczytując z dwóch dostępnych replik w tym regionie. Ponieważ zapisy w regionie zawsze są replikowane do większości lokalnej (trzy z czterech replik), skonsultowanie się z dwoma replikami zwraca najbardziej zaktualizowane dane dostępne w tym regionie.
Ważne
Ze spójnością powiązana nieaktualność odczyty wystawione dla regionu innego niż podstawowy mogą niekoniecznie zwracać najnowszą wersję danych globalnie, ale mają gwarancję zwrócenia najnowszej wersji danych w tym regionie, która będzie znajdować się w granicach maksymalnej nieaktualności na całym świecie.
Powiązana nieaktualność działa najlepiej w przypadku aplikacji rozproszonych globalnie przy użyciu kont zapisu w jednym regionie z co najmniej dwoma regionami, w których wymagana jest niemal silna spójność między regionami. W przypadku kont zapisu w wielu regionach z co najmniej dwoma regionami serwery aplikacji powinny kierować odczyty i zapisy do tego samego regionu, w którym są hostowane serwery aplikacji. Powiązana nieaktualność na koncie z wieloma zapisami to antywzór. Ten poziom wymaga zależności od opóźnienia replikacji między regionami, co nie powinno mieć znaczenia, czy dane są odczytywane z tego samego regionu, do którego został zapisany.
Poniższa grafika ilustruje powiązaną spójność nieaktualności z nutami muzycznymi. Po zapisaniu danych w regionie "Zachodnie stany USA 2" regiony "Wschodnie stany USA 2" i "Australia Wschodnia" odczytują wartość zapisaną na podstawie skonfigurowanego maksymalnego czasu opóźnienia lub maksymalnej liczby operacji:
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.
Po każdej operacji zapisu klient otrzymuje zaktualizowany token sesji z serwera. Klient buforuje tokeny i wysyła je do serwera na potrzeby operacji odczytu w określonym regionie. Jeśli replika, dla której jest wystawiana operacja odczytu, zawiera dane dla określonego tokenu (lub nowszego tokenu), zwracane są żądane dane. Jeśli replika nie zawiera danych dla tej sesji, klient ponawia żądanie względem innej repliki w regionie. W razie potrzeby klient ponawia próbę odczytu względem dodatkowych dostępnych regionów do momentu pobrania danych dla określonego tokenu sesji.
Ważne
W obszarze Spójność sesji użycie tokenu sesji przez klienta gwarantuje, że dane odpowiadające starszej sesji nigdy nie będą odczytywane. Jeśli jednak klient korzysta ze starszego tokenu sesji, a nowsze aktualizacje zostały wprowadzone do bazy danych, większa wersja danych zostanie zwrócona pomimo użycia starszego tokenu sesji. Token sesji jest używany jako minimalna bariera wersji, ale nie jako określona (prawdopodobnie historyczna) wersja danych do pobrania z bazy danych.
Tokeny sesji w usłudze Azure Cosmos DB są powiązane z partycjami, co oznacza, że są one wyłącznie skojarzone z jedną partycją. Aby mieć pewność, że możesz odczytać zapisy, użyj tokenu sesji, który został ostatnio wygenerowany dla odpowiednich elementów.
Jeśli klient nie zainicjował zapisu w partycji fizycznej, klient nie zawiera tokenu sesji w pamięci podręcznej i odczytuje do tej partycji fizycznej zachowanie jako odczyty ze spójnością ostateczną. Podobnie, jeśli klient zostanie ponownie utworzony, jego pamięć podręczna tokenów sesji również zostanie ponownie utworzona. W tym przypadku również operacje odczytu są zgodne z tym samym zachowaniem co spójność ostateczna, dopóki kolejne operacje zapisu nie ponownie skompilują pamięci podręcznej klienta tokenów sesji.
Ważne
Jeśli tokeny sesji są przekazywane z jednego wystąpienia klienta do innego, zawartość tokenu nie powinna być modyfikowana.
Spójność sesji jest najczęściej używanym poziomem spójności zarówno dla pojedynczego regionu, jak i aplikacji rozproszonych globalnie. Zapewnia opóźnienia zapisu, dostępność i przepływność odczytu porównywalną z spójnością ostateczną. Spójność sesji zapewnia również gwarancje spójności, które odpowiadają potrzebom aplikacji napisanych w kontekście użytkownika. Poniższa grafika ilustruje spójność sesji z nutami muzycznymi. Składnik zapisywania "Zachodnie stany USA 2" i "Czytnik wschodnich stanów USA 2" używają tej samej sesji (sesji A), aby obaj odczytywali te same dane w tym samym czasie. Podczas gdy region "Australia Wschodnia" używa "Sesja B", więc odbiera dane później, ale w tej samej kolejności co zapisy.
Spójny prefiks
Podobnie jak wszystkie poziomy spójności słabsze niż silne, zapisy są replikowane do co najmniej trzech replik (w zestawie czterech replik) w regionie lokalnym z replikacją asynchroniczną do wszystkich innych regionów.
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 transakcyjnie (wszystkie operacje lub nic) w dokumencie Doc1, a następnie dokument Doc2 w ramach transakcji T1 i T2. Gdy klient wykonuje odczyt w dowolnej repliki, użytkownik widzi ciąg "Doc1 v1 i Doc2 v1" lub "Doc1 v2 i Doc2 v2" lub żaden dokument, jeśli replika jest opóźniona, ale nigdy "Doc1 v1 i Doc2 v2" lub "Doc1 v2 i Doc2 v1" dla tej samej operacji odczytu lub zapytania.
Poniższa grafika ilustruje spójność prefiksu spójności z nutami muzycznymi. We wszystkich regionach odczyty nigdy nie widzą zapisów poza kolejnością dla transakcyjnej partii zapisów:
Spójność ostateczna
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.
W przypadku spójności ostatecznej klient wystawia żądania odczytu względem dowolnej z czterech replik w określonym regionie. Ta replika może się opóźnić i może zwracać nieaktualne lub nie ma danych.
Spójność ostateczna jest najsłabszą formą spójności, ponieważ klient może odczytać wartości starsze niż te, które odczytał w przeszłości. 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 non-threaded. Poniższa grafika ilustruje ostateczną spójność z nutami muzycznymi.
Gwarancje spójności w praktyce
W praktyce często można uzyskać silniejsze gwarancje spójności. Gwarancje spójności dla operacji odczytu odpowiadają świeżości i kolejności żądanego stanu bazy danych. Spójność odczytu jest powiązana z kolejnością i propagacją operacji zapisu/aktualizacji.
Jeśli w bazie danych nie ma żadnych operacji zapisu, operacja odczytu z poziomami spójności ostatecznej, sesji lub spójnego prefiksu może przynieść te same wyniki co operacja odczytu z wysokim poziomem spójności.
Jeśli twoje konto jest skonfigurowane z poziomem spójności innym niż silna spójność, możesz sprawdzić prawdopodobieństwo, że klienci mogą uzyskać silne i spójne odczyty dla obciążeń. To prawdopodobieństwo można ustalić, przeglądając metryki Probabilistically Bounded Staleness (PBS). Ta metryka jest uwidoczniona w witrynie Azure Portal, aby dowiedzieć się więcej, zobacz Monitor Probabilistically Bounded Staleness (PBS) metryka.
Probabilistically powiązana nieaktualność pokazuje, jak ostateczna jest spójność ostateczna. Ta metryka zawiera szczegółowe informacje o tym, jak często można uzyskać silniejszą spójność niż poziom spójności, który jest obecnie skonfigurowany na koncie usługi Azure Cosmos DB. Innymi słowy, można zobaczyć prawdopodobieństwo (mierzone w milisekundach) uzyskiwania spójnych odczytów dla kombinacji regionów zapisu i odczytu.
Poziomy spójności i opóźnienia
Opóźnienie odczytu dla wszystkich poziomów spójności jest zawsze gwarantowane mniej niż 10 milisekund w 99. percentylu. Średnie opóźnienie odczytu, przy 50. percentylu, wynosi zwykle 4 milisekundy lub mniej.
Opóźnienie zapisu dla wszystkich poziomów spójności jest zawsze gwarantowane mniej niż 10 milisekund w 99. percentylu. Średnie opóźnienie zapisu w 50. percentylu wynosi zwykle 5 milisekund lub mniej. Konta usługi Azure Cosmos DB obejmujące kilka regionów i skonfigurowane z silną spójnością stanowią wyjątek od tej gwarancji.
Opóźnienie zapisu i silna spójność
W przypadku kont usługi Azure Cosmos DB skonfigurowanych z silną spójnością z więcej niż jednym regionem opóźnienie zapisu jest równe dwa razy większe niż dwa razy w czasie rundy (RTT) między dowolnym z dwóch najbardziej odległych regionów, a także 10 milisekund w 99. percentylu. Protokół RTT o wysokiej sieci między regionami przekłada się na większe opóźnienie żądań usługi Azure Cosmos DB, ponieważ silna spójność kończy operację dopiero po upewnieniu się, że została zatwierdzona we wszystkich regionach w ramach konta.
Dokładne opóźnienie RTT jest funkcją prędkości światła i topologii sieci platformy Azure. Sieć platformy Azure nie zapewnia żadnych umów SLA opóźnienia dla RTT między dwoma regionami świadczenia usługi Azure, jednak publikuje statystyki opóźnień sieci platformy Azure. W przypadku konta usługi Azure Cosmos DB opóźnienia replikacji są wyświetlane w witrynie Azure Portal. Możesz użyć witryny Azure Portal, przechodząc do sekcji Metryki, a następnie wybierając opcję Spójność. Za pomocą witryny Azure Portal można monitorować opóźnienia replikacji między różnymi regionami skojarzonymi z kontem usługi Azure Cosmos DB.
Ważne
Silna spójność kont z regionami obejmującymi ponad 5000 mil (8000 kilometrów) jest domyślnie blokowana z powodu dużego opóźnienia zapisu. Aby włączyć tę funkcję, skontaktuj się z pomocą techniczną.
Poziomy spójności i przepływność
W przypadku silnej i powiązanej nieaktualności operacje odczytu są wykonywane względem dwóch replik w czterech zestawach replik (kworum mniejszości) w celu zapewnienia gwarancji spójności. Sesja, spójny prefiks i ostateczne operacje odczytu pojedynczej repliki. Wynikiem jest to, że w przypadku tej samej liczby jednostek żądania przepływność odczytu dla silnej i powiązanej nieaktualności jest połowę innych poziomów spójności.
Dla danego typu operacji zapisu, takich jak wstawianie, zastępowanie, upsert i usuwanie, przepływność zapisu dla jednostek żądań jest identyczna dla wszystkich poziomów spójności. Aby zapewnić silną spójność, zmiany muszą być zatwierdzane w każdym regionie (większość globalna), podczas gdy dla wszystkich innych poziomów spójności jest używana większość lokalna (trzy repliki w czterech zestawach replik).
| Poziom spójności | Odczyty kworum | Zapisy kworum |
|---|---|---|
| Silny | Mniejszość lokalna | Większość globalna |
| Powiązana nieaktualność | Mniejszość lokalna | Większość lokalna |
| Sesja | Pojedyncza replika (przy użyciu tokenu sesji) | Większość lokalna |
| Spójny prefiks | Pojedyncza replika | Większość lokalna |
| Ewentualnego | Pojedyncza replika | Większość lokalna |
Uwaga
Koszt odczytu jednostek RU dla odczytów mniejszości lokalnej jest dwa razy większy niż w przypadku słabszych poziomów spójności, ponieważ operacje odczytu są wykonywane z dwóch replik w celu zapewnienia gwarancji spójności dla poziomów spójności Silna i Powiązana nieaktualność.
Poziomy spójności i trwałość danych
W środowisku globalnej rozproszonej bazy danych istnieje bezpośrednia relacja między poziomem spójności a trwałością danych w obecności awarii całego regionu. Podczas opracowywania planu ciągłości działania należy zrozumieć maksymalny okres najnowszych aktualizacji danych, które aplikacja może tolerować utratę podczas odzyskiwania po wystąpieniu zdarzenia powodującego zakłócenia. Okres aktualizacji, które mogą zostać utracone, jest znany jako cel punktu odzyskiwania (RPO).
Ta tabela definiuje relację między modelem spójności a trwałością danych w obecności awarii całego regionu.
| Regiony | Tryb replikacji | Poziom spójności | RPO |
|---|---|---|---|
| 1 | Pojedyncze lub wiele regionów zapisu | Dowolny poziom spójności | < 240 minut |
| >1 | Region pojedynczego zapisu | Sesja, spójny prefiks, ostateczna | < 15 minut |
| >1 | Region pojedynczego zapisu | Powiązana Nieaktualność | K & T |
| >1 | Region pojedynczego zapisu | Silna | 0 |
| >1 | Wiele regionów zapisu | Sesja, spójny prefiks, ostateczna | < 15 minut |
| >1 | Wiele regionów zapisu | Powiązana Nieaktualność | K & T |
K = liczba wersji "K" (czyli aktualizacji) elementu.
T = interwał czasu "T" od ostatniej aktualizacji.
W przypadku pojedynczego konta regionu minimalna wartość K i T to 10 operacji zapisu lub 5 sekund. W przypadku kont obejmujących wiele regionów minimalna wartość K i T wynosi 100 000 operacji zapisu lub 300 sekund. Ta wartość definiuje minimalny cel punktu odzyskiwania dla danych podczas korzystania z nieaktualności powiązanej.
Silna spójność i wiele regionów zapisu
Nie można skonfigurować kont usługi Azure Cosmos DB skonfigurowanych z wieloma regionami zapisu pod kątem silnej spójności, ponieważ nie jest możliwe, aby system rozproszony zapewniał cel punktu odzyskiwania o wartości zero i cel czasu odzyskiwania zera. Ponadto nie ma żadnych korzyści związanych z opóźnieniem zapisu przy użyciu silnej spójności z wieloma regionami zapisu, ponieważ zapis w dowolnym regionie musi zostać zreplikowany i zatwierdzony we wszystkich skonfigurowanych regionach w ramach konta. W tym scenariuszu występuje takie samo opóźnienie zapisu, jak jedno konto regionu zapisu.
Więcej informacji
Aby dowiedzieć się więcej na temat pojęć dotyczących spójności, przeczytaj następujące artykuły:
- Ogólne specyfikacje TLA+ dla pięciu poziomów spójności oferowanych przez usługę Azure Cosmos DB
- Zreplikowana spójność danych wyjaśniona za pośrednictwem baseballu (wideo) autorstwa Doug Terry
- Zreplikowana spójność danych wyjaśniona za pośrednictwem baseballu (oficjalny dokument) autorstwa Doug Terry
- Gwarancje sesji dla słabo spójnych replikowanych danych
- Kompromisy spójności w nowoczesnym projekcie rozproszonych systemów baz danych: CAP jest tylko częścią scenariusza
- Probabilistic Bounded Staleness (PBS) for Practical Partial Quorums
- Ostatecznie spójne — ponownie