Microsoft AZ-204: Azure Cosmos DB — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Azure Cosmos DB to w pełni zarządzana, globalnie dystrybuowana, wielomodelowa baza danych zaprojektowana dla aplikacji wymagających niskich opóźnień i elastycznej skalowalności. Udostępnia wiele interfejsów API na wspólnym, partycjonowanym silniku przechowywania i replikacji, zapewnia pięć konfigurowalnych poziomów spójności oraz oferuje kompleksowe umowy SLA dotyczące dostępności, opóźnień, przepustowości i spójności. Dane są zorganizowane w konta, bazy danych i kontenery (lub kolekcje/tabele/grafy w zależności od API). Kontenery są partycjonowane horyzontalnie i skalowane za pomocą klucza partycji, a wszystkie operacje są mierzone w jednostkach żądań (Request Units, RU) – znormalizowanej walucie, która abstrahuje użycie procesora, IOPS i pamięci.

API i programowalność

Cosmos DB obsługuje kilka interfejsów API zgodnych na poziomie protokołu, dzięki czemu można używać natywnych zestawów SDK i sterowników bez przepisywania modelu danych:

SQL (Core) API: Zalecany domyślny wybór dla nowych obciążeń. Przechowuje dokumenty JSON z bogatymi zapytaniami podobnymi do SQL (SELECT, WHERE, ORDER BY, JOIN w obrębie dokumentu, agregacje) i deterministycznymi funkcjami UDF dla obliczanych predykatów/projekcji. Logika biznesowa po stronie serwera działa jako procedury składowane JavaScript oraz wyzwalacze pre/post w ramach jednej partycji logicznej, umożliwiając transakcje ACID na wielu elementach, które współdzielą klucz partycji. TransactionalBatch zapewnia operacje na wielu elementach w jednej partycji. Odczyty punktowe (ID + klucz partycji) są najbardziej wydajne pod względem zużycia RU. Utwórz klienta .NET za pomocą kodu takiego jak: new CosmosClient(endpoint, key).
MongoDB API: Zgodne na poziomie protokołu z MongoDB, co umożliwia korzystanie ze standardowych sterowników i narzędzi MongoDB (na przykład mongodump/mongorestore do migracji). Można używać funkcji MongoDB wspieranych przez dystrybucję, automatyczne skalowanie i umowy SLA Cosmos DB. Transakcje na wielu dokumentach są obsługiwane w ramach tej samej partycji logicznej; aby uzyskać ścisłą atomowość per użytkownik, należy użyć niepodzielonej na fragmenty (unsharded) kolekcji lub partycjonować według właściwości takiej jak nazwa użytkownika, aby powiązane dokumenty współdzieliły partycję.
Cassandra API: Kompatybilne ze sterownikami Apache Cassandra i CQL. Idealne dla wzorców dostępu szerokokulumnowych i szeregów czasowych. Otrzymujesz automatyczną globalną dystrybucję i skalowanie oparte na RU zamiast zarządzania węzłami.
Gremlin API: Model grafu właściwości z zapytaniami i przechodzeniem (traversals) w języku TinkerPop Gremlin. Partycjonowanie jest kluczowe do dystrybucji wierzchołków i krawędzi w celu zapewnienia skalowalnych operacji przechodzenia grafu.
Table API: Model klucz-wartość z zestawami SDK i semantyką kompatybilnymi z Azure Table Storage, ale wspierany przez globalną dystrybucję, przepustowość RU i indeksy o niższych opóźnieniach Cosmos DB.

Wspólne operacje SDK dla różnych API obejmują CRUD, współbieżność optymistyczną z ETagami, operacje upsert, skrypty po stronie serwera (procedury składowane, wyzwalacze) oraz UDF (dla SQL API). Zapytania są parametryzowane w celu zmniejszenia zużycia RU i poprawy bezpieczeństwa. Operacje zbiorcze i strumieniowe API minimalizują narzut po stronie klienta i koszty RU przy pozyskiwaniu danych o wysokiej przepustowości.

Spójność, indeksowanie i semantyka zapytań

Cosmos DB oferuje pięć dobrze zdefiniowanych poziomów spójności na poziomie konta (możliwych do nadpisania dla pojedynczego żądania w wielu zestawach SDK):

Silna (Strong): Linearyzowalność – odczyty globalnie widzą ostatni zatwierdzony zapis. Maksymalizuje poprawność, ogranicza opóźnienia zapisu i elastyczność regionalną; nie jest dostępna przy włączonych zapisach do wielu regionów.
Ograniczona nieaktualność (Bounded Staleness): Odczyty są opóźnione w stosunku do zapisów o co najwyżej K wersji lub czas T. Gwarantuje monotoniczną kolejność odczytów i zapisów; dobry kompromis dla globalnie dystrybuowanych odczytów, które tolerują ograniczone opóźnienie.
Sesja (Session) (domyślny): W ramach sesji zapewnia spójność typu read-your-writes (odczyt własnych zapisów), write-follows-reads oraz odczyty monotoniczne. Każdy klient utrzymuje token sesji; udostępnianie go między węzłami (na przykład poprzez opcje żądania w SDK) zachowuje spójność read-your-writes między tymi węzłami.
Spójny prefiks (Consistent Prefix): Odczyty nigdy nie obserwują zapisów w nieprawidłowej kolejności, ale mogą widzieć prefiks dziennika (logu).
Ostateczna (Eventual): Najwyższa dostępność i najniższe opóźnienia bez gwarancji kolejności.

Dla SQL API indeksowanie jest domyślnie automatyczne i spójne. Każdy element i właściwość są indeksowane bez zarządzania schematem, więc zapisy natychmiast aktualizują indeks (tryb indeksowania: Consistent). Można doprecyzować politykę indeksowania, aby:

Wykluczyć duże lub intensywnie zapisywane ścieżki, aby obniżyć koszty RU zapisu.
Dodać indeksy złożone w celu obsługi wydajnego sortowania (ORDER BY) według wielu właściwości oraz zapytań łączących filtry i sortowanie według różnych właściwości.
Dodać indeksy przestrzenne dla typów GeoJSON (Point, LineString, Polygon, MultiPolygon) i wykonywać zapytania za pomocą funkcji przestrzennych, takich jak ST_DISTANCE, ST_WITHIN i ST_INTERSECTS. Tryb indeksowania można również ustawić na None dla kontenerów zoptymalizowanych pod kątem zapisu, które są odczytywane tylko przez ID/klucz partycji. Różne API udostępniają indeksowanie poprzez swoje natywne paradygmaty (np. konstrukcje sterowników MongoDB i Cassandra), ale wszystkie wykorzystują bazowy silnik indeksujący Cosmos.

Należy zwracać uwagę na rozmiar elementu i kształt zapytania. SQL API narzuca limit rozmiaru elementu (na przykład 2 MB), a zapytania międzypartycyjne, duże projekcje i złożone predykaty zwiększają zużycie RU. Używaj selektywnych projekcji, odpowiednich filtrów i zapytań świadomych partycjonowania, aby zminimalizować koszt RU.

Partycjonowanie i przepustowość (RU)

Cosmos DB rozdziela partycje logiczne i fizyczne:

Partycje logiczne grupują elementy według wartości klucza partycji. Wszystkie elementy o tym samym kluczu biorą razem udział w transakcyjnych operacjach wsadowych i skryptach po stronie serwera.
Partycje fizyczne są zarządzane przez usługę i hostują wiele partycji logicznych. Przepustowość (RU) i przestrzeń dyskowa są rozdzielane pomiędzy partycje fizyczne; „gorące” partycje logiczne mogą stać się wąskim gardłem dla przepustowości partycji fizycznej.

Wybierz efektywny klucz partycji o wysokiej kardynalności i równomiernym rozkładzie dostępu w czasie. Dobre klucze są skorelowane z główną ścieżką dostępu (na przykład userId, deviceId, tenantId lub orderId). Unikaj kluczy o niskiej kardynalności lub pogrupowanych czasowo, które powodują nierównomierny rozkład (ang. skew) (na przykład country, status lub day). Gdy żadna pojedyncza właściwość nie jest odpowiednia:

Użyj klucza syntetycznego, który jest konkatenacją wielu właściwości.
Dołącz losowy lub haszowany sufiks, aby rozłożyć obciążenie na partycje, zachowując jednocześnie możliwość odpytywania przez prefiks lub poprzez utrzymywanie tabeli przeglądowej (lookup).
Rozważ hierarchiczne klucze partycji, aby połączyć wiele właściwości, co umożliwia lepszą dystrybucję i wydajne zapytania z użyciem prefiksów.

Modele przepustowości:

Przepustowość aprowizowana (Provisioned throughput): Zarezerwuj RU/s dla kontenera lub bazy danych (współdzielone przez kontenery podrzędne). Przewidywalna wydajność przy stabilności kosztów. Skaluj ręcznie lub za pomocą API/CLI.
Autoskalowanie (Autoscale): Ustaw maksymalną wartość RU/s; Cosmos DB elastycznie skaluje się w zakresie od 10% do 100% tej wartości maksymalnej w zależności od obciążenia. Rozliczane na podstawie najwyższej użytej wartości RU w ciągu godziny; doskonałe dla zmiennych obciążeń i nieprzewidzianych szczytów.
Bezserwerowy (Serverless): Brak aprowizowanych RU/s; płacisz za zużycie RU przez każdą operację. Idealny dla środowisk deweloperskich, obciążeń o gwałtownych skokach lub niskiej przepustowości bez przewidywalnego poziomu bazowego.

Techniki optymalizacji RU obejmują odczyty punktowe (point reads) po id+klucz partycji, zapytania sparametryzowane, selektywne projekcje, denormalizację w celu redukcji wzorców przypominających JOIN oraz użycie change feed do tworzenia widoków pochodnych zamiast złożonych zapytań obejmujących wiele kontenerów. Używaj ETags z If-Match do kontroli współbieżności, aby unikać kosztownych pod względem RU ponownych prób. Monitoruj metryki RU i ograniczanie przepustowości (throttling, HTTP 429) oraz implementuj w SDK polityki ponawiania prób z losowym opóźnieniem (jitter).

Globalna dystrybucja i zestawienie zmian (Change Feed)

Gotowa do użycia, wieloregionowa dystrybucja Cosmos DB pozwala na dodawanie i usuwanie regionów w dowolnym momencie. Wszystkie regiony są dostępne do odczytu; włączenie zapisów wieloregionowych (multi-region writes) umożliwia jednoczesne zapisy we wszystkich lokalizacjach z opóźnieniem odczytu poniżej 10 ms dla 99. percentyla w pobliskich regionach. Zestawy SDK klienta powinny być skonfigurowane z preferowanymi regionami, aby kierować ruch lokalnie i zapewniać płynne przełączanie awaryjne (failover). W .NET preferowane regiony podaje się za pomocą właściwości ApplicationPreferredRegions w CosmosClientOptions (lub jej odpowiednika w innych SDK). Zapisy wieloregionowe wymagają zdefiniowania polityki rozwiązywania konfliktów:

Last Write Wins (ostatni zapis wygrywa): Używa ścieżki rozwiązywania konfliktów (np. właściwości ze znacznikiem czasu lub wersją). Jeśli nie jest określona, można użyć systemowego znacznika czasu.
Rozwiązanie niestandardowe (Custom Resolution): Używa procedury składowanej typu merge do deterministycznego uzgadniania konfliktów.
Ręczne (Manual): Sprawdza zestawienie konfliktów (conflicts feed) i rozwiązuje je jawnie.

Zestawienie zmian (change feed) dostarcza uporządkowany, dostępny tylko do dopisywania (append-only) dziennik zmian dla każdego klucza partycji logicznej. Jest idealne do:

Architektur sterowanych zdarzeniami i CQRS (projekcja dokumentów na widoki zoptymalizowane pod kątem odczytu).
Potoków danych (ingestia do data lake, indeksowanie dla wyszukiwania, unieważnianie pamięci podręcznej).
Analityki i audytu w czasie zbliżonym do rzeczywistego. Istnieją dwa główne wzorce konsumpcji:
Biblioteka Change Feed Processor: Rozproszone, odporne na błędy przetwarzanie, które wykorzystuje kontener dzierżaw (leases container) do równoważenia obciążenia partycjami między workerami i bezpiecznego skalowania w poziomie.
Model ściągania (pull model) z FeedIterator: Jawna iteracja po zmianach z logiką punktów kontrolnych (checkpointing) pod Twoją kontrolą; segmentacja pracy za pomocą FeedRange w celu zrównoleglenia. Azure Functions oferuje wyzwalacz (trigger) Cosmos DB, który hermetyzuje wzorzec procesora na potrzeby przetwarzania bezserwerowego. Można rozpocząć od początku lub od „teraz”, a zestawienie zmian o pełnej wierności (full-fidelity change feed) przechwytuje pośrednie aktualizacje i usunięcia, tworząc kompletne ścieżki audytu. Zaprojektuj kontener dzierżaw z wystarczającą przepustowością i wybierz idempotentne procedury obsługi (handlery), aby obsłużyć ponowienia prób i dostarczanie typu „co najmniej raz” (at-least-once).

Praktyczny scenariusz problemowy

Spotify musi dostarczyć globalnie dostępną usługę personalizacji, która w czasie rzeczywistym przyjmuje interakcje użytkowników, aktualizuje rekomendacje dla poszczególnych użytkowników i obsługuje odczyty o niskim opóźnieniu z najbliższego regionu. Zapisy mogą pochodzić od klientów mobilnych na całym świecie, a aktualizacje rekomendacji muszą być rozsyłane (fan-out) do systemów podrzędnych.

Wybór Cosmos DB SQL (Core) API z zapisami wieloregionowymi

Dlaczego: Core API oferuje bogate możliwości zapytań i programowania po stronie serwera. Zapisy wieloregionowe minimalizują globalne opóźnienia zapisu i tolerują awarie regionalne bez przestojów w zapisie.

Zdefiniowanie klucza partycji o wysokiej kardynalności i kluczy hierarchicznych

Podejście: Partycjonowanie według userId; dla wyjątkowo aktywnych użytkowników użyj kluczy hierarchicznych, takich jak [“userId”, “bucket”], gdzie bucket to sufiks haszujący.
Dlaczego: Równomiernie rozkłada obciążenie zapisu i odczytu, umożliwia transakcyjne aktualizacje dla danego użytkownika i pozwala uniknąć gorących partycji (hot partitions).

Konfiguracja automatycznego skalowania przepustowości (autoscale throughput) na głównych kontenerach

Dlaczego: Ruch ma charakter dobowy i jest napędzany kampaniami; automatyczne skalowanie obsługuje skoki obciążenia do skonfigurowanej maksymalnej wartości RU/s, utrzymując koszt proporcjonalny do rzeczywistego obciążenia.

Ustawienie spójności na poziomie Session na poziomie konta

Dlaczego: Klienci mobilni wymagają spójności odczytu własnych zapisów (read-your-writes) dla dobrego doświadczenia użytkownika, bez ograniczeń opóźnień narzucanych przez poziom Strong. Tokeny sesji są przenoszone przez klientów i warstwę bramy (gateway), aby zachować semantykę sesji między węzłami.

Implementacja przetwarzania zestawienia zmian (change feed) za pomocą Azure Functions i Change Feed Processor

Podejście: Utwórz aplikację Functions z wyzwalaczem Cosmos DB powiązanym z kontenerem interakcji. Użyj dedykowanego kontenera dzierżaw (leases container) i włącz wiele instancji w celu zrównoleglenia.
Dlaczego: Zapewnia to odporne, skalowalne i niewymagające dużych nakładów operacyjnych (low-ops) przetwarzanie w celu aktualizacji zmaterializowanych widoków (np. kontenera z rekomendacjami) oraz publikowania zdarzeń w Event Hubs na potrzeby analityki strumieniowej.

Utworzenie pochodnego kontenera rekomendacji z dostosowaną polityką indeksowania

Podejście: Wyklucz z indeksowania duże właściwości, na których jest dużo zapisów; dodaj indeksy złożone dla (userId, score DESC) w celu obsługi zapytań TOP-K.
Dlaczego: Zmniejsza to koszty zapisu w RU, jednocześnie umożliwiając wydajne wyszukiwanie posortowanych wyników dla spersonalizowanych kanałów.

Włączenie globalnej dystrybucji z preferowanymi regionami w SDK

Podejście: Dodaj regiony w North America, Europe i APAC. Skonfiguruj CosmosClientOptions z ApplicationPreferredRegions w oparciu o region wdrożenia aplikacji.
Dlaczego: Zapewnia to, że odczyty są obsługiwane lokalnie z opóźnieniem poniżej 10 ms, a przełączanie awaryjne (failover) jest przezroczyste.

Konfiguracja rozwiązywania konfliktów i obserwowalności (observability)

Podejście: Użyj polityki Last Write Wins z generowanym przez serwer zegarem logicznym (właściwość wersji) dla idempotentnych aktualizacji i kieruj konflikty do kolejki monitorującej dla rzadkich przypadków brzegowych.
Dlaczego: Gwarantuje to deterministyczną zbieżność przy jednoczesnych zapisach wieloregionowych i zapewnia wgląd operacyjny.

Taka architektura zapewnia globalnie niskie opóźnienia odczytu i zapisu, odporne przetwarzanie zdarzeń za pośrednictwem zestawienia zmian (change feed), efektywne kosztowo automatyczne skalowanie oraz solidną semantykę spójności odpowiednią dla obciążeń personalizacyjnych.

← Azure Storage i Blob Storage · Wszystkie domeny · Rozwiązania kontenerowe Azure →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →