Poziomy spójności w usłudze Azure Cosmos DB

Rozproszone bazy danych, które opierają się na replikacji w celu zapewnienia wysokiej dostępności, małych opóźnień lub obu tych baz danych, muszą równoważyć spójność odczytu, dostępność, opóźnienie i przepływność zgodnie z definicją twierdzenia PACELC. Liniowość modelu silnej spójności jest standardem programowalności danych. Jednak zwiększa opóźnienia zapisu, ponieważ dane muszą być replikowane i zatwierdzane w dużych odległościach. Silna spójność zmniejsza również dostępność podczas awarii, ponieważ dane nie mogą być powielane 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ść rozproszonych baz danych NoSQL na rynku obecnie 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:

• Silny
• Ograniczona nieaktualność
• Sesja
• Spójny prefiks
• Ewentualny

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 równoważy dostępność i wydajność. Na poniższej ilustracji przedstawiono poziomy spójności jako spektrum.

Poziomy spójności i interfejsy API usługi Azure Cosmos DB

Usługa Azure Cosmos DB obsługuje interfejsy API zgodne z protokołem przewodowym dla popularnych baz danych, w tym MongoDB, Apache Cassandra, Apache Gremlin i Azure Table Storage. W przypadku interfejsu API dla języka Gremlin lub tabeli usługa Azure Cosmos DB używa domyślnego poziomu spójności skonfigurowanego na koncie. Aby dowiedzieć się więcej na temat mapowania poziomu spójności, zobacz API do mapowania spójności dla Apache Cassandra oraz API do mapowania spójności dla MongoDB.

Zakres spójności odczytu

Spójność odczytu ma zastosowanie do pojedynczej operacji odczytu w ramach partycji logicznej. Operację odczytu może wydać klient zdalny, procedura składowana lub wyzwalacz.

Konfigurowanie domyślnego poziomu spójności

Skonfiguruj domyślny poziom spójności na koncie usługi Azure Cosmos DB 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. Po zmianie spójności na poziomie konta ponownie wdróż aplikacje i wprowadź wszelkie niezbędne modyfikacje kodu, aby zastosować te zmiany. Dowiedz się więcej, jak skonfigurować domyślny poziom spójności. Można również zastąpić domyślny poziom spójności dla określonego żądania. Dowiedz się więcej w artykule dotyczącym zastępowania domyślnego poziomu spójności .

Wskazówka

Zastąpienie domyślnego poziomu spójności dotyczy tylko operacji odczytu w ramach klienta SDK. Konto skonfigurowane pod kątem silnej spójności domyślnie nadal zapisuje i replikuje dane synchronicznie do każdego regionu na koncie. Gdy instancja klienta SDK lub żądanie zastąpi tę spójność spójnością sesyjną lub słabszą, operacje odczytu są wykonywane przy użyciu pojedynczej repliki. Aby uzyskać więcej informacji, zobacz poziomy spójności i przepływność.

Ważna

Ponownie utwórz dowolne wystąpienie zestawu SDK po zmianie domyślnego poziomu spójności, uruchamiając ponownie aplikację. Ten krok gwarantuje, ż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% żądań odczytu spełnia gwarancję spójności dla 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 TLA — Czasowa logika akcji — język specyfikacji znajdują się w repozytorium Azure/azure-cosmos-tla GitHub.

Semantyka pięciu poziomów spójności opisano w poniższych sekcjach.

Silna spójność

Silna spójność oferuje gwarancję zlinearyzowania. Liniowość oznacza współbieżną obsługę żądań. Operacje odczytu mają gwarancję zwrócenia najnowszej zatwierdzonej wersji elementu. Klient nigdy nie widzi zapisu danych, który jest niezatwierdzony lub częściowy. Użytkownicy zawsze mają gwarancję przeczytania najnowszego zatwierdzonego zapisu.

Poniższa grafika pokazuje wyraźną zgodność 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 potwierdzają replikację rekordu. Jeśli Twoje konto ma co najmniej trzy regiony, system może zmniejszyć liczbę regionów potrzebnych do kworum, gdy niektóre regiony działają wolno lub nie odpowiadają. Pomaga to zachować silną spójność, nawet jeśli kilka regionów ma problemy. W tym momencie regiony nie odpowiadające są usuwane z zestawu kworum regionów, aby zachować silną spójność. Są one dodawane tylko wtedy, gdy stają się spójne z innymi regionami i działają zgodnie z oczekiwaniami. Liczba regionów, które mogą zostać potencjalnie wyjęte z zestawu kworum, zależy od całkowitej liczby regionów. Na przykład na koncie trzech lub czterech regionów większość to odpowiednio dwa lub trzy regiony, więc w obu przypadkach można usunąć tylko jeden region. W przypadku pięcio-regionowego konta, większość wynosi trzy, więc można usunąć maksymalnie dwa nieodpowiadające regiony. Ta funkcja jest znana jako "dynamiczne kworum" i może zwiększyć dostępność zapisu i opóźnienie replikacji dla kont z co najmniej trzema regionami.

Uwaga / Notatka

Gdy regiony zostaną usunięte z zestawu kworum w ramach kworum dynamicznego, nie będą mogły obsługiwać odczytów do momentu ponownego dodania do kworum.

Spójność ograniczonej nieaktualności

Dla kont zapisu w jednym regionie, które mają co najmniej dwa regiony, dane są replikowane z regionu podstawowego do wszystkich regionów wtórnych (tylko do odczytu). W przypadku kont zapisu w wielu regionach z dwiema lub więcej regionami dane są replikowane z regionu, w którym zostały pierwotnie zapisane do wszystkich innych zapisywalnych regionów. W obu scenariuszach, choć nie jest to wspólne, czasami może występować opóźnienie replikacji z jednego regionu do drugiego.

W przypadku spójności z ograniczoną nieaktualnością opóźnienie danych między dowolnymi dwoma regionami jest zawsze mniejsze niż określona wartość. Ilość może być liczbą wersji "K" (czyli "aktualizacjami") elementu lub interwałami czasu "T", w zależności od tego, co zostanie osiągnięte jako pierwsze. Innymi słowy, po wybraniu ograniczonej stęchlizny maksymalny poziom "stęchlizny" danych w dowolnym regionie jest konfigurowalny na dwa sposoby:

• Liczba wersji elementu (K)
• Odczyty interwału czasu (T) mogą być opóźnione w stosunku do zapisów

Powiązany stan ustalonej przestarzałości jest szczególnie korzystny dla kont z zapisem w jednym regionie, które mają co najmniej dwa regiony. Jeśli opóźnienie danych w regionie (określonym dla każdej partycji fizycznej) przekracza skonfigurowaną wartość nieaktualności, operacje zapisu dla tej partycji są ograniczane, dopóki nieaktualność nie powróci do skonfigurowanej górnej granicy.

W przypadku konta z jednym regionem, Bounded Staleness zapewnia takie same gwarancje spójności zapisu jak spójność sesyjna i ostateczna. W przypadku ograniczonej nieaktualności dane są replikowane do większości lokalnej (trzy repliki w czterech replikach) w jednym regionie.

Ważna

Dla spójności Bounded Staleness kontrole nieaktualności są wykonywane tylko między regionami, a nie wewnątrz regionu. W danym regionie dane są zawsze replikowane do większości lokalnej (trzy repliki w zestawie czterech replik), niezależnie od poziomu spójności.

Odczyty przy używaniu ograniczonej przestarzałości zwracają najnowsze dane dostępne w tym regionie, czytając z dwóch dostępnych replik znajdujących się w tym regionie. Ponieważ zapisy w regionie zawsze są replikowane do lokalnej większości (trzy z czterech replik), odczyt danych z dwóch replik zwraca najbardziej aktualne dane dostępne w tym regionie.

Ważna

Przy spójności ograniczonej aktualności, odczyty z regionu innego niż główny mogą nie wyświetlać najnowszych danych ze wszystkich regionów. Jednak zawsze zwracają najnowsze dane dostępne w tym regionie w ramach dozwolonego limitu opóźnienia.

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. Ograniczona nieaktualność na koncie z wieloma operacjami zapisu to antywzór. Ten poziom wymaga zależności od opóźnienia replikacji między regionami, co nie powinno mieć znaczenia, jeśli dane są odczytywane z tego samego regionu, do którego zostały zapisane.

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 pojedynczą sesję "piszącego" lub udostępnianie tokenu sesji dla wielu piszących.

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żna

W obszarze Spójność sesji klient używa tokenu sesji, aby zagwarantować, że nigdy nie odczytuje danych odpowiadających starszej sesji. Jeśli klient używa starego tokenu sesji, ale nowsze dane są dostępne w bazie danych, system zwraca najnowszą wersję. Nawet w przypadku nieaktualnego tokenu zawsze uzyskujesz najnowsze dane. 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 skojarzone wyłącznie 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 do partycji fizycznej, w pamięci podręcznej klienta nie ma tokenu sesji, a odczyty z tej partycji fizycznej są traktowane 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żna

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 dla aplikacji jednoregionowych i globalnie rozproszonych. 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. "West US 2 writer" i "East US 2 reader" używają tej samej sesji (sesji A), tak aby obaj mogli odczytywać te same dane jednocześnie. Podczas gdy region "Australia Wschodnia" używa "Sesja B", więc odbiera dane później, ale w tej samej kolejności co zapisy.

Spójna konsystencja prefiksu

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 kontekście spójnego prefiksu, aktualizacje wprowadzane jako operacje zapisu pojedynczego dokumentu osiągają ostateczną spójność.

Aktualizacje wprowadzone jako partia w ramach transakcji są zwracane zgodnie z transakcją, w której zostały zatwierdzone. Operacje zapisu w transakcjach obejmujących wiele dokumentów zawsze są widoczne razem.

Załóżmy, że dwie operacje zapisu są wykonywane transakcyjnie (operacje typu wszystko albo nic) na dokumencie Doc1, a następnie na dokumencie Doc2 w ramach transakcji T1 i T2. Gdy klient wykonuje odczyt w dowolnej replice, użytkownik widzi "Doc1 v1 i Doc2 v1" lub "Doc1 v2 i Doc2 v2" lub żaden z dokumentów, jeśli replika ma opóźnienie, ale nigdy "Doc1 v1 i Doc2 v2" lub "Doc1 v2 i Doc2 v1" w przypadku tej samej operacji odczytu lub zapytania.

Poniższa grafika ilustruje zgodność prefiksu spójności z nutami muzycznymi. We wszystkich regionach odczyty nigdy nie napotykają zapisów poza kolejnością w ramach 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óźniać oraz zwracać przestarzałe lub brak danych.

Spójność ostateczna jest najsłabszą formą spójności, ponieważ klient może odczytywać wartości starsze niż te odczytane 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ę Retweetów, polubień lub komentarzy nieprowadzonych w wątku. 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 i aktualizacji.

Jeśli w bazie danych nie ma operacji zapisu, operacja odczytu z poziomem spójności docelowej, sesji lub spójnego prefiksu może dać takie same wyniki jak operacja odczytu z poziomem spójności silnym.

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 wyniki odczytu dla obciążeń roboczych. Ustal to prawdopodobieństwo, patrząc na metrykę Probabilistically Bounded Staleness (PBS). Ta metryka jest widoczna w witrynie Azure Portal. Aby uzyskać więcej informacji, zobacz metryka Monitor Probabilistically Bounded Staleness (PBS).

Probabilistyczne ograniczenie opóźnienia pokazuje, jak rzeczywista jest spójność ostateczna. Ta metryka zawiera szczegółowe informacje o tym, jak często uzyskujesz większą spójność niż poziom spójności aktualnie 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 musi być mniejsze niż 10 milisekund w 99. percentylu. Średnie opóźnienie odczytu, przy 50. percentylu, zwykle wynosi 4 milisekundy lub mniej.

Opóźnienie zapisu dla wszystkich poziomów spójności ma być mniejsze niż 10 milisekund w 99. percentylu. Średnie opóźnienie zapisu w 50. percentylu zwykle wynosi 5 milisekund lub mniej. Konta usługi Azure Cosmos DB obejmujące kilka regionów o silnej spójności stanowią wyjątek od tej gwarancji.

Opóźnienie zapisu i silna spójność

W przypadku kont Azure Cosmos DB, które są skonfigurowane z silną spójnością i mają więcej niż jeden region, opóźnienie zapisu jest równe dwukrotności czasu rundy (RTT) między dwoma najdalszymi regionami, plus 10 milisekund na 99. percentyl. Protokół RTT o wysokiej sieci między regionami zwiększa opóźnienie żądań usługi Azure Cosmos DB, ponieważ silna spójność kończy operację dopiero po upewnieniu się, że operacja jest zatwierdzana we wszystkich regionach na koncie.

Dokładne opóźnienie RTT zależy od prędkości światła i topologii sieci platformy Azure. Sieć platformy Azure nie zapewnia umów dotyczących poziomu usług opóźnienia (SLA) dla protokołu RTT między regionami platformy Azure, ale 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. Użyj witryny Azure Portal, przechodząc do sekcji Metryki i 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żna

Silna spójność dla kont w regionach obejmujących ponad 5000 mil (8000 kilometrów) jest domyślnie wyłączona ze względu na duże opóźnienie operacji zapisu. Aby włączyć tę funkcję, skontaktuj się z pomocą techniczną.

Poziomy spójności i przepływność

• W przypadku silnej i ograniczonej nieaktualności operacje odczytu są wykonywane względem dwóch replik w zestawie replik z czterema replikami (kworum mniejszości) w celu zapewnienia gwarancji spójności. Spójność sesji, spójny prefiks i spójność ostateczna używają operacji odczytu z jedną repliką. W związku z tym, przy tej samej liczbie jednostek żądań, przepustowość odczytu dla silnej i ograniczonej nieaktualności wynosi połowę przepustowości na innych poziomach spójności.

• Dla danego typu operacji zapisu, takich jak wstawianie, zastępowanie, upsert lub usuwanie, przepływność zapisu dla jednostek żądań jest identyczna we wszystkich poziomach spójności. Aby zapewnić silną spójność, zmiany muszą być zatwierdzane w każdym regionie (większość globalna), natomiast w przypadku wszystkich pozostałych poziomów spójności jest używana większość lokalna (trzy repliki w zestawie z czterema replikami).

Poziom spójności	Odczyty kworum	Zapisy kworum
Silny	Mniejszość lokalna	Większość globalna
Ograniczona 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
Ewentualny	Pojedyncza replika	Większość lokalna

Uwaga / Notatka

Koszt odczytu jednostek RU dla lokalnych odczytów mniejszościowych jest dwukrotnie wyższy w porównaniu z niższymi poziomami spójności, ponieważ operacje odczytu są wykonywane z dwóch replik w celu zapewnienia gwarancji spójności dla silnych i ograniczonych poziomów nieaktualności.

Poziomy spójności i trwałość danych

W środowisku globalnej rozproszonej bazy danych poziom spójności bezpośrednio wpływa na trwałość danych podczas awarii całego regionu. Podczas opracowywania planu ciągłości działania należy zrozumieć maksymalny okres ostatnich 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 określany jako cel punktu odzyskiwania (RPO).

W tej tabeli przedstawiono relację między modelami spójności a trwałością danych podczas awarii całego regionu.

Regions	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	Ograniczona Przestarzałość	K & T
>1	Region pojedynczego zapisu	Mocny	0
>1	Wiele regionów zapisu	Sesja, spójny prefiks, ostateczna	< 15 minut
>1	Wiele regionów zapisu	Ograniczona Przestarzałość	K & T

K = liczba wersji K (aktualizacje) elementu.

T = interwał czasu T od ostatniej aktualizacji.

W przypadku konta z jednym regionem minimalna wartość K i T to 10 operacji zapisu lub 5 sekund. W przypadku kont z wieloma regionami minimalna wartość K i T wynosi 100 000 operacji zapisu lub 300 sekund. Ta wartość definiuje minimalny cel punktu odzyskiwania (RPO) dla danych podczas korzystania z ograniczonej nieaktualności (Bounded Staleness).

Silna spójność i wiele regionów zapisu

Konta usługi Azure Cosmos DB z wieloma regionami zapisu nie mogą używać silnej spójności, ponieważ rozproszony system nie może zapewnić celu punktu odzyskiwania (RPO) wynoszącego zero i celu czasu odzyskiwania (RTO) wynoszącego zero. Ponadto silna spójność z wieloma regionami zapisu nie poprawia opóźnienia zapisu, ponieważ zapisy muszą być replikowane i zatwierdzane we wszystkich regionach na koncie. Ta konfiguracja powoduje takie samo opóźnienie zapisu jak konto z jednorazowym regionem 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 na przykładzie baseballu (wideo) autor Doug Terry
• Spójność replikowanych danych wyjaśniona na przykładzie baseballu (biała księga) autorstwa Douga Terry'ego
• 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
• Probabilistyczna ograniczona nieaktualność (PBS) dla praktycznych częściowych kworum
• Ostateczna spójność — ponownie omówiona

Treści powiązane

• Konfigurowanie domyślnego poziomu spójności
• Zastąpij domyślny poziom spójności
• Dowiedz się więcej o umowie SLA usługi Azure Cosmos DB.