Microsoft AZ-305: Przechowywanie danych i rozwiązania bazodanowe — Przewodnik do nauki

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Przegląd

Projektowanie magazynu danych na platformie Azure wymaga zrównoważenia spójności, opóźnień, dostępności, złożoności operacyjnej i kosztów w ramach wielu opcji baz danych i magazynów. Platforma obejmuje w pełni zarządzane relacyjne bazy danych, globalnie dystrybuowane bazy NoSQL, magazyn obiektów z zarządzaniem cyklem życia danych, wysokoprzepustowe analityczne jeziora danych oraz pamięci podręczne w pamięci (in-memory). Twoja architektura powinna zaczynać się od charakterystyki obciążenia roboczego — transakcyjne czy analityczne, zasięg globalny czy lokalność, sztywność schematu, wzorce odczytu/zapisu, rozmiar i szybkość napływu danych — i na tej podstawie należy wybrać usługę oraz konfigurację, które odpowiadają tym ograniczeniom, jednocześnie spełniając wymagania dotyczące bezpieczeństwa, odporności i ładu korporacyjnego.

Relacyjne usługi danych na platformie Azure

Azure SQL Database oferuje dwa modele zakupowe. Model DTU łączy CPU, pamięć i operacje we/wy w jedną jednostkę w warstwach Basic, Standard i Premium; jest prosty, ale nieprzejrzysty pod kątem planowania pojemności. Model vCore oddziela zasoby obliczeniowe, pamięć i magazyn, oferując wybór sprzętu, przewidywalne skalowanie i dźwignie kosztowe, takie jak Azure Hybrid Benefit i pojemność zarezerwowana. W modelu vCore główne warstwy usług to General Purpose (oddzielone zasoby obliczeniowe i zdalny magazyn, zrównoważony koszt), Business Critical (lokalny dysk SSD z replikami Always On dla niskich opóźnień we/wy i szybkiego przełączania awaryjnego) oraz Hyperscale (architektura oparta na strukturze logów z serwerami stron i rozproszonym magazynem dla skalowania do wielu terabajtów i szybkich operacji opartych na migawkach). Warstwa Serverless dla General Purpose automatycznie skaluje moc obliczeniową między skonfigurowanym minimum a maksimum i może automatycznie wstrzymywać działanie w stanie bezczynności; płacisz za sekundę obliczeń i za magazyn. Jest to dobre rozwiązanie dla obciążeń sporadycznych lub deweloperskich, ale wiąże się z zimnym startem i koniecznością rozgrzania pamięci podręcznej po wznowieniu.

Pule elastyczne pozwalają wielu bazom danych współdzielić budżet obliczeniowy i zapas operacji we/wy, co wygładza skoki obciążenia i zmniejsza koszty w przypadku wielu małych baz danych o zmiennym obciążeniu. Pule istnieją zarówno w modelu DTU, jak i vCore; prawidłowe dobranie rozmiaru wymaga zrozumienia zagregowanej współbieżności i limitów szczytowych dla poszczególnych baz danych, aby uniknąć efektu „hałaśliwego sąsiada” (noisy-neighbor).

Wzorce odporności Azure SQL obejmują aktywną replikację geograficzną i grupy automatycznego przełączania awaryjnego. Aktywna replikacja geograficzna asynchronicznie utrzymuje do czterech odczytywalnych baz danych pomocniczych w dowolnym regionie Azure, a przełączanie awaryjne jest inicjowane dla każdej bazy danych osobno. Grupy automatycznego przełączania awaryjnego zarządzają wieloma bazami danych jako jednostką na sparowanych serwerach logicznych, zapewniają punkty końcowe odbiornika (listener) do odczytu/zapisu i tylko do odczytu oraz obsługują planowane lub nieplanowane przełączanie awaryjne z konfigurowalnymi okresami prolongaty — idealne dla rozwiązań SaaS z wieloma dzierżawcami. Nadmiarowość strefowa jest dostępna w warstwach Business Critical (i Hyperscale), aby rozciągać się na Strefy dostępności w obrębie regionu, poprawiając tolerancję na błędy wewnątrzregionalne.

Azure SQL Managed Instance (MI) ma na celu zapewnienie niemal 100% zgodności z SQL Server (SQL Agent, zapytania międzybazodanowe, Linked Servers, CLR, Service Broker). Działa wewnątrz Twojej sieci wirtualnej w dedykowanej, delegowanej podsieci (Microsoft.Sql/managedInstances). Instancje używają wyłącznie prywatnych adresów IP; skonfiguruj sieciowe grupy zabezpieczeń i tabele routingu, aby zezwolić na ruch zarządczy do płaszczyzn sterowania Azure oraz na ruch danych do Twoich aplikacji. Zintegruj z Azure Private DNS (lub niestandardowym DNS), aby klienci mogli rozpoznawać prywatną nazwę FQDN wystąpienia zarządzanego. W celu zapewnienia łączności hybrydowej i migracji, zapewnij bezpośrednią widoczność sieciową poprzez site-to-site VPN lub ExpressRoute. Ścieżki migracji obejmują natywne tworzenie kopii zapasowych/przywracanie do Azure Blob Storage (WITH COPY_ONLY, WITH MOVE), migracje online lub offline przy użyciu Azure Database Migration Service (DMS) oraz, w odpowiednich przypadkach, replikację transakcyjną lub wysyłanie logów (log shipping). Warstwa Business Critical w MI dodaje magazyn o niskim opóźnieniu i wysoką dostępność; warstwa General Purpose oferuje opłacalny magazyn z dyskami zdalnymi.

Azure Database for PostgreSQL i MySQL Flexible Server zapewniają szczegółową kontrolę nad oknami konserwacji, opcję zatrzymywania/uruchamiania w celu oszczędności kosztów oraz izolację sieciową poprzez integrację z VNet. Opcje wysokiej dostępności obejmują synchroniczny serwer rezerwowy w tej samej strefie (same-zone synchronous standby) dla najszybszego przełączania awaryjnego oraz nadmiarową strefowo wysoką dostępność (zone-redundant HA) odporną na awarie stref (replikacja synchroniczna z automatycznym przełączaniem awaryjnym). Repliki do odczytu (wewnątrzregionalne i, dla wielu wersji, międzyregionalne) odciążają obciążenia odczytu i wspierają analitykę w czasie zbliżonym do rzeczywistego; są one asynchroniczne i nie nadają się do odczytów wymagających ścisłej spójności. Wybierz warstwy obliczeniowe i magazynowe na podstawie docelowych wartości IOPS/opóźnień i zaplanuj obsługę przełączania awaryjnego połączeń w bibliotekach klienckich.

Nierelacyjne i globalnie rozproszone magazyny danych

Azure Cosmos DB to w pełni zarządzana, wielomodelowa, globalnie rozproszona baza danych z gotową do użycia globalną replikacją oraz odczytami i zapisami na poziomie jednocyfrowych milisekund dla 99. percentyla. Wybierz API w oparciu o dopasowanie do ekosystemu i model danych: Core (SQL) API dla dokumentów i zapytań podobnych do SQL z bogatym wsparciem SDK; MongoDB API dla kompatybilności z protokołem Mongo; Cassandra API dla obciążeń szerokokulumnowych; Gremlin API do przechodzenia po grafach; oraz Table API dla scenariuszy klucz-atrybut. Przepustowość jest alokowana w jednostkach żądań (request units, RU) w trybie stałym lub autoskalowania; projektuj partycje i indeksowanie tak, aby zminimalizować zużycie RU.

Partycjonowanie jest fundamentalne. Wybierz klucz partycji o wysokiej kardynalności, który równomiernie rozkłada przechowywanie danych i ruch, unika gorących partycji (hot partitions) i jest zgodny z Twoimi wzorcami dostępu (np. tenantId lub userId dla zapisów w architekturze wielodostępowej lub syntetyczny klucz złożony do zrównoważenia odczytów). Partycje logiczne mają ograniczenia co do rozmiaru i przepustowości; modeluj dane tak, aby utrzymać gorące zestawy robocze (hot working sets) rozproszone. Nie można zmienić klucza partycji kontenera po jego utworzeniu; migracje wymagają nowych kontenerów i przeniesienia danych.

Spójność w Cosmos DB obejmuje pięć konfigurowalnych poziomów: Strong (silna, zlinearyzowana, najwyższe zużycie RU/opóźnienie), Bounded Staleness (ograniczona nieaktualność, przewidywalne opóźnienie lub okno wersji), Session (sesyjna, skoncentrowana na kliencie, zapewnia odczyt własnych zapisów, popularny domyślny wybór), Consistent Prefix (spójny prefiks, brak odczytów w nieprawidłowej kolejności) oraz Eventual (ostateczna, maksymalna dostępność i wydajność z potencjalnymi anomaliami). Wybierz domyślne ustawienia dla konta i nadpisuj je w razie potrzeby dla poszczególnych żądań. Zapisy wieloregionowe (multi-region writes) umożliwiają prawdziwą architekturę multi-master dla globalnych zapisów o niskim opóźnieniu i wyższej dostępności; obsługuj rozwiązywanie konfliktów za pomocą strategii Last-Writer-Wins (na wyznaczonej właściwości), niestandardowych polityk lub logiki aplikacji z procedurami składowanymi i kanałem konfliktów (conflict feed).

Wybierając odpowiedni magazyn danych, dopasuj wymagania do jego możliwości. Ścisła integralność relacyjna, złożone złączenia (joins) i gwarancje transakcyjne przemawiają za Azure SQL Database lub Managed Instance. Ogromna globalna skala, elastyczny schemat i dostęp geograficzny o niskim opóźnieniu faworyzują Cosmos DB. Problemy grafowe (sieci społecznościowe, rekomendacje, topologia sieci) pasują do Cosmos DB Gremlin API lub funkcji grafowych w Azure SQL, gdy kolokacja relacyjna jest korzystna. Przetwarzanie dużych ilości danych telemetrycznych szeregów czasowych (high-ingest), eksploracja ad hoc i analityka w czasie niemal rzeczywistym są zgodne z Azure Data Explorer. Niestrukturalne obiekty blob, media i duże ładunki binarne powinny być przechowywane w Azure Blob Storage lub ADLS Gen2, z metadanymi w uzupełniającej bazie danych.

Magazyny obiektowe i analityczne

Azure Blob Storage jest podstawą dla danych niestrukturalnych. Warstwy dostępu (access tiers) dopasowują koszt przechowywania do wzorców dostępu: Hot dla danych z częstym dostępem, Cool dla danych z rzadkim dostępem z minimalnym 30-dniowym okresem przechowywania, oraz Archive dla długoterminowego przechowywania zimnych danych (cold storage) z minimalnym 180-dniowym okresem przechowywania i wielogodzinnym czasem przywracania (rehydration). Konta Premium block blob na dyskach SSD zapewniają niskie opóźnienia i obsługę obciążeń o wysokiej liczbie transakcji, takich jak potoki pozyskiwania danych (ingestion pipelines). Polityki zarządzania cyklem życia (lifecycle management) automatyzują przenoszenie i usuwanie danych na podstawie reguł — czasu ostatniej modyfikacji, tagów indeksu obiektów blob lub prefiksów — redukując koszty bez ręcznej interwencji.

Replikacja obiektów (object replication) dla blokowych obiektów blob asynchronicznie tworzy lustrzane odbicia obiektów i ich wersji między kontami magazynu (w tych samych lub różnych regionach). Wymaga ona włączonego wersjonowania obiektów blob (blob versioning) na źródle i w miejscu docelowym i jest sterowana polityką dla każdej pary kontenerów, wspierając zgodność z przepisami (compliance) i dystrybucję wieloregionową, zachowując jednocześnie niezależność od opcji nadmiarowości na poziomie konta. Niezmienność (immutability, WORM) jest egzekwowana na poziomie kontenera lub obiektu blob za pomocą retencji opartej na czasie (time-based retention) i blokad prawnych (legal holds), z opcjami takimi jak allowProtectedAppendWrites dla logów typu append-only. Niezmienność na poziomie wersji (version-level immutability) chroni przeszłe stany przed manipulacją i oprogramowaniem ransomware.

Azure Data Lake Storage Gen2 dodaje hierarchiczną przestrzeń nazw do Blob storage, zapewniając prawdziwe katalogi, atomowe zmiany nazw i zoptymalizowane operacje na plikach. Drobnoziarniste listy kontroli dostępu (ACL) w stylu POSIX kontrolują dostęp na poziomie katalogów i plików, z listami Access ACL i Default ACL, i są oceniane razem z Azure RBAC. Uwierzytelnianie odbywa się za pomocą Azure AD i OAuth2 w celu zapewnienia zasady najmniejszych uprawnień (least privilege) i możliwości audytu. Integracja z analityką jest natywna: Azure Synapse Analytics i Azure Databricks uzyskują dostęp do ADLS Gen2 za pośrednictwem sterownika ABFS ze skalowalną przepustowością, podczas gdy usługi takie jak Azure Data Factory, Azure Purview i Azure Machine Learning integrują się w celu orkiestracji, ładu korporacyjnego (governance) i trenowania modeli. Projektuj struktury folderów i dziedziczenie ACL w celu izolowania domen i wspierania zarządzania przez wiele zespołów, a także wykorzystuj funkcje takie jak change feed i soft delete do śledzenia pochodzenia danych (lineage) i odzyskiwania.

Buforowanie i przyspieszanie wydajności

Azure Cache for Redis zapewnia dostęp do danych w czasie poniżej milisekundy, mechanizm pub/sub i rozproszone blokowanie (distributed locking). Warstwy (tiers) odpowiadają potrzebom w zakresie dostępności i skali. Basic to pojedynczy węzeł do celów deweloperskich/testowych. Standard dodaje dwuwęzłową konfigurację primary/replica z automatycznym przełączaniem awaryjnym (failover). Premium wprowadza klastrowanie na wielu fragmentach (shards), trwałość (persistence) (migawki RDB i pliki AOF), wsparcie dla VNet oraz georeplikację w topologii aktywnej-pasywnej. Warstwy Enterprise i Enterprise Flash (Redis Enterprise) dodają georeplikację Active-Active wykorzystującą CRDTs do zapisów wieloregionowych, większe zasoby pamięci, wydajność wielowątkową i wsparcie dla modułów; warstwa Flash rozszerza DRAM o dyski NVMe, aby tworzyć ogromne pamięci podręczne przy niższych kosztach. Wybierz politykę usuwania (eviction policy) pasującą do TTL kluczy i obciążenia: allkeys-lru/allkeys-random, gdy nie wszystkie klucze mają TTL; volatile-lru/volatile-ttl, gdy tylko wygasające klucze powinny być usuwane; oraz noeviction, gdy błędy zapisu są akceptowalne zamiast usuwania kluczy. Trwałość (persistence) redukuje utratę danych podczas przełączania awaryjnego kosztem narzutu na operacje I/O i opóźnienia; włączaj ją tylko wtedy, gdy jest to wymagane, i dostosuj interwały tworzenia migawek.

Integruj Redis jako pamięć podręczną typu cache-aside dla wyników zapytań do bazy danych, stanu sesji i liczników ograniczających szybkość (rate-limit counters). Zapewnij idempotentne wypełnianie pamięci podręcznej, stosuj odpowiednie wartości TTL i implementuj mechanizmy circuit breaker. W przypadku klastrowanych pamięci podręcznych, partycjonuj klucze w sposób deterministyczny; dla konfiguracji Enterprise Active-Active, przetestuj semantykę rozwiązywania konfliktów.

Wzorce bezpieczeństwa, dostępu i odporności

Delegowanie dostępu do Azure Storage wykorzystuje tokeny SAS i zasady. Service SAS przyznaje dostęp o ograniczonym zakresie do określonego zasobu (kontenera, bloba, udziału plików, kolejki lub tabeli). Account SAS obejmuje wiele usług na koncie i jest bardzo potężny; należy go starannie chronić. User delegation SAS (tylko dla usługi Blob) pochodzi z Azure AD i klucza delegowania użytkownika, umożliwiając kontrolę dostępu na poziomie użytkownika bez kluczy konta — co jest idealne dla aplikacji wielodostępnych (multi-tenant) i krótkotrwałych nadań uprawnień. Przechowywane zasady dostępu (dla kontenerów, udziałów, kolejek i tabel) wiążą tokeny SAS z zasadą po stronie serwera, dzięki czemu można odwołać lub skrócić dostęp bez rotacji kluczy konta; SAS bez przechowywanej zasady dostępu można odwołać tylko poprzez wygaśnięcie tokena lub rotację kluczy.

W przypadku szyfrowania, Azure Storage domyślnie używa szyfrowania po stronie usługi. Klucze zarządzane przez klienta (CMK) przechowywane w Azure Key Vault lub Managed HSM zapewniają scentralizowaną kontrolę nad cyklem życia klucza i możliwość audytu. Zakresy szyfrowania (encryption scopes) pozwalają na użycie różnych kluczy CMK w ramach tego samego konta magazynu według kontenera lub prefiksu, wspierając kluczowanie per tenant. Dla kontroli po stronie klienta na poziomie pojedynczego bloba, można dostarczyć klucze dostarczone przez klienta (CPK) w żądaniach. Łącz CMK na poziomie konta lub zakresu z CPK w zależności od potrzeb, aby zapewnić izolację wymaganą przez regulacje.

Bezpieczeństwo i odporność Azure SQL opierają się na już opisanych warstwach platformy i funkcjach replikacji. Używaj grup automatycznego przełączania awaryjnego (auto-failover groups) do skoordynowanego przełączania awaryjnego między regionami i dedykowanych punktów końcowych nasłuchu, a także włączaj redundancję strefową tam, gdzie jest dostępna, aby wytrzymać awarie stref. Dla danych wrażliwych, zastosuj dynamiczne maskowanie danych (dynamic data masking), aby zaciemnić dane PII w wynikach zapytań dla nieuprzywilejowanych użytkowników, i rozważ użycie Always Encrypted z bezpiecznymi enklawami w celu ochrony kolumn po stronie klienta, gdy administratorzy nie mogą mieć dostępu do tekstu jawnego. Monitoruj cele RPO/RTO w odniesieniu do zachowania replikacji w Twojej warstwie i rutynowo testuj przełączanie awaryjne.

Planując kompleksowe architektury, zunifikuj tożsamość (Azure AD dla SQL, magazynu i analityki), stosuj zasadę najmniejszych uprawnień za pomocą RBAC i ACL, używaj Private Link lub integracji z VNet, aby trzymać dane z dala od publicznego internetu, oraz wdrażaj zasady cyklu życia, niezmienności i replikacji, aby spełnić cele retencji i odtwarzania po awarii (DR).

Praktyczny scenariusz problemowy

Firma Contoso Retail uruchamia globalną platformę e-commerce o zmiennym ruchu w ciągu dnia, z rygorystycznymi kontrolami danych PII, multimediami produktowymi na skalę petabajtów i personalizacją w czasie niemal rzeczywistym. Wymagają niskich opóźnień odczytu na całym świecie, minimalnego czasu przestoju i zarządzanej analityki danych.

Umieść transakcyjne bazy danych katalogu i zamówień w Azure SQL Database, używając modelu vCore:

Wybór warstwy: Business Critical dla zamówień (magazyn o niskim opóźnieniu i szybkie przełączanie awaryjne) oraz General Purpose serverless dla katalogu (nagłe wzrosty ruchu z okresami bezczynności).
Dlaczego: vCore zapewnia przewidywalne skalowanie i korzyść Azure Hybrid Benefit; Business Critical spełnia wymagania dotyczące opóźnień/wysokiej dostępności dla zamówień; serverless minimalizuje koszty obliczeniowe podczas niskiej aktywności.

Skonfiguruj grupę automatycznego przełączania awaryjnego (auto-failover group) obejmującą sparowane regiony dla obu baz danych i włącz redundancję strefową:

Dlaczego: Ujednolicony punkt nasłuchu do odczytu/zapisu upraszcza przełączanie awaryjne aplikacji; redundancja strefowa chroni przed awariami stref; repliki w innych regionach spełniają cele DR i oferują skalowalność odczytu dla raportowania.

Przechowuj obrazy i filmy produktów w Azure Blob Storage (general-purpose v2) z zarządzaniem cyklem życia i replikacją obiektów:

Zasada: Hot dla aktywnych elementów, Cool po 30 dniach, Archive po 180 dniach; replikuj do regionu wtórnego za pomocą replikacji obiektów.
Dlaczego: Minimalizuje koszty przechowywania w czasie, zapewniając jednocześnie asynchroniczną dystrybucję regionalną niezależną od redundancji konta; spełnia wymogi retencji dzięki niezmienności dla zasobów prawnych (time-based WORM).

Zbuduj usługę profili klientów i koszyka na Azure Cosmos DB (Core API) z zapisami w wielu regionach i spójnością typu Session:

Projekt: Partycjonowanie według userId w celu dystrybucji zapisów; włącz autoscale RU.
Dlaczego: Multi-master zapewnia zapisy o niskim opóźnieniu dla globalnej publiczności i wysoką dostępność; spójność typu Session zapewnia odczyt własnych zapisów (read-your-writes) dla każdego użytkownika z silnymi gwarancjami UX i efektywnym wykorzystaniem RU.

Wprowadź Azure Cache for Redis Enterprise do obsługi stanu sesji, buforowania szczegółów produktów i ograniczania liczby żądań (rate limiting):

Tryb: Klastrowanie z Active-Active geo dla zapisów w wielu regionach.
Dlaczego: Dostęp w czasie poniżej milisekundy i rozwiązywanie konfliktów oparte na CRDT utrzymują spójność sesji i liczników między regionami bez jednego głównego serwera zapisu.

Przechowuj dane o ścieżkach kliknięć (clickstream) i logi operacyjne w Azure Data Lake Storage Gen2 z hierarchiczną przestrzenią nazw i listami ACL w stylu POSIX:

Integracja: Strumieniowe pozyskiwanie danych zapisuje do dedykowanych folderów; Databricks i Synapse odczytują przez ABFS; włącz change feed i soft delete.
Dlaczego: Precyzyjne listy ACL na poziomie katalogów/plików wspierają zarządzanie przez wiele zespołów; hierarchiczna przestrzeń nazw optymalizuje operacje na plikach; natywna integracja z analityką skraca czas do uzyskania wglądu.

Użyj Azure Database for PostgreSQL Flexible Server dla mikrousługi rekomendacji:

HA: Redundantna strefowo synchroniczna replika standby; utwórz repliki do odczytu na potrzeby eksperymentów z nowymi funkcjami.
Dlaczego: Bogaty ekosystem rozszerzeń Postgres i możliwości JSONB pasują do usługi; zarządzane HA utrzymuje niskie RTO; repliki odciążają odczyty.

Zabezpiecz dostęp za pomocą user delegation SAS do tymczasowego przesyłania multimediów oraz CMK z zakresami szyfrowania (encryption scopes) per tenant:

Dlaczego: Eliminuje ekspozycję kluczy konta i umożliwia izolację kryptograficzną oraz audytowalność dla każdego tenanta.

Zmigruj historyczne dane zamówień z lokalnego SQL Server do Azure SQL Managed Instance w celu przetwarzania archiwalnego i zadań sterowanych przez agenta:

Kroki: Oceń za pomocą Data Migration Assistant; wykonaj migrację online przez DMS; połącz przez ExpressRoute.
Dlaczego: MI zachowuje zadania SQL Agent i operacje międzybazodanowe, ułatwiając modernizację przy jednoczesnym utrzymaniu obciążeń archiwalnych blisko danych w chmurze.

Ten projekt zapewnia globalną wydajność dzięki zapisom w wielu regionach w Cosmos DB i Redis Enterprise, wymusza ład danych za pomocą list ACL w ADLS Gen2 i niezmienności w Storage, dostarcza integralność transakcyjną i szybkie przełączanie awaryjne dzięki warstwom Azure SQL i grupom auto-failover, oraz optymalizuje koszty poprzez zasoby obliczeniowe serverless i zasady cyklu życia.

← Tożsamość · Wszystkie domeny · Obliczenia i architektura aplikacji →

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