Amazon CLF-C02: Podstawowe usługi baz danych — Przewodnik do nauki

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Część AWS Cloud Practitioner CLF-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Zarządzane relacyjne bazy danych: Amazon RDS i Amazon Aurora

Amazon RDS dostarcza w pełni zarządzane silniki relacyjne (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) z automatycznymi kopiami zapasowymi, Multi‑AZ dla wysokiej dostępności, replikami do odczytu (read replicas) dla skalowania oraz przywracaniem opartym na migawkach (snapshot). Aurora to specjalnie zaprojektowany silnik kompatybilny z MySQL i PostgreSQL, który oddziela warstwę obliczeniową od rozproszonej, odpornej na awarie warstwy przechowywania danych, aby zapewnić wyższą przepustowość, szybkie odzyskiwanie po awarii oraz funkcje takie jak backtrack i Global Database do replikacji między regionami. Modele cenowe obejmują instancje On-Demand dla elastycznej pojemności, Reserved Instances lub Savings Plans dla przewidywalnych oszczędności oraz modele pojemności serwerowej lub autoskalowania dla Aurora Serverless, aby dostosować koszty do zmiennych obciążeń. Kluczowe decyzje architektoniczne zależą od profilu odczytu/zapisu, wymagań dotyczących opóźnień i tolerancji operacyjnej: wybierz RDS, gdy dominują potrzeby związane z kompatybilnością i licencjonowaniem, a Aurora, gdy potrzebujesz wyższej wydajności, autoskalowania przestrzeni dyskowej lub globalnych odczytów. Częstymi pułapkami dla praktyków są: niedostateczne alokowanie IOPS dla obciążeń z dużą liczbą zapisów, zapominanie o włączeniu Multi‑AZ dla środowisk produkcyjnych, pozostawianie domyślnych poświadczeń administratora (master credentials) i nietestowanie odzyskiwania do punktu w czasie (point-in-time recovery). W celu zapewnienia zgodności (compliance), włącz szyfrowanie w spoczynku (at rest) za pomocą AWS KMS, wymuś użycie TLS do szyfrowania w tranzycie (in-transit) i zweryfikuj, czy automatyczne kopie zapasowe i migawki spełniają cele retencji i odtwarzania po awarii w innym regionie (cross-region DR).

Bazy danych NoSQL, buforujące (caching) i grafowe: DynamoDB, ElastiCache, Amazon Neptune

Dla obciążeń typu klucz-wartość i dokumentowych na masową skalę, Amazon DynamoDB oferuje opóźnienia rzędu pojedynczych milisekund, automatyczne partycjonowanie i dwa tryby pojemności: provisioned (z autoskalowaniem) i on-demand dla nieprzewidywalnego ruchu. Funkcje takie jak DynamoDB Streams, tabele globalne (global tables) i odzyskiwanie do punktu w czasie (PITR) wspierają replikację, przechwytywanie zmian danych (change data capture) i tworzenie kopii zapasowych. Częstą pułapką jest złe projektowanie klucza partycji, co prowadzi do powstawania gorących partycji (hot partitions) i dławienia (throttling); najpierw należy zamodelować wzorce dostępu do danych. Dla obciążeń w pamięci (in-memory) o niskim opóźnieniu użyj ElastiCache: Redis oferuje trwałość (persistence), klastrowanie i mechanizm pub/sub, podczas gdy Memcached to proste, wielowątkowe buforowanie. Użyj DAX dla obciążeń DynamoDB z dużą liczbą odczytów, wymagających buforowania na poziomie mikrosekund. Dla zapytań grafowych skoncentrowanych na relacjach, Amazon Neptune jest w pełni zarządzaną grafową bazą danych obsługującą Gremlin i SPARQL. Decyzje cenowe: DynamoDB on-demand jest łatwy w użyciu, ale droższy przy stałym, wysokim ruchu; tryb provisioned z autoskalowaniem i Reserved Capacity może być znacznie tańszy. W ElastiCache dobór rozmiaru pamięci podręcznej, polityki usuwania danych (eviction policies) i opcje trwałości wpływają na koszt i możliwości odzyskiwania. Oceniając wybór między zarządzanymi bazami NoSQL, pamięciami podręcznymi in-memory i bazami grafowymi, należy wziąć pod uwagę trwałość, modele spójności i złożoność operacyjną.

DynamoDB vs RDS/Aurora: DynamoDB dla masowej skali, elastycznego schematu, projektowania opartego na jednej tabeli (single-table design); RDS/Aurora dla złożonych zapytań SQL, transakcji i integralności relacyjnej.
ElastiCache (Redis) vs DAX: Redis dla ogólnych obciążeń in-memory i trwałości; DAX to specyficzna dla DynamoDB pamięć podręczna do odczytu z integracją po stronie klienta.
Neptune: Używaj, gdy przechodzenie po grafie (traversals) i analityka grafowa są kluczowe dla aplikacji.

Wzorce analityczne i data lake: Amazon Redshift, Athena i wybór klas przechowywania S3

Amazon Redshift to kolumnowa hurtownia danych o skali petabajtów, zoptymalizowana pod kątem złożonych zapytań analitycznych i wysokiej współbieżności. Nowoczesny Redshift (węzły RA3) oddziela warstwę obliczeniową od zarządzanej przestrzeni dyskowej, co pozwala na niezależne skalowanie mocy obliczeniowej i redukcję kosztów poprzez wykorzystanie S3 jako zarządzanej pamięci masowej; Redshift Spectrum odpytuje dane bezpośrednio w S3 w celu integracji z data lake. Do zapytań SQL ad-hoc na plikach, Amazon Athena oferuje bezserwerową analitykę w modelu pay-per-query (opłata za przeskanowany TB) i jest idealna dla plików CSV/Parquet/JSON na S3; optymalizacja formatów i kompresji drastycznie redukuje koszty. S3 oferuje wiele klas przechowywania: dla nieznanych wzorców dostępu, S3 Intelligent‑Tiering automatycznie przenosi obiekty między warstwami dostępu, aby zminimalizować koszty bez opłat za odczyt; dla archiwów długoterminowych rozważ S3 Glacier lub Glacier Deep Archive, gdzie obowiązują opóźnienia i opłaty za odzyskiwanie danych. Kompromisy kosztowe obejmują relację między przechowywaniem a mocą obliczeniową: kompresuj, partycjonuj i używaj formatów kolumnowych, aby zmniejszyć ilość skanowanych danych; rozważ użycie Redshift concurrency scaling i workload management dla przewidywalnej wydajności. Dla obciążeń uczenia maszynowego powiązanych z analityką, intensywny trening może wymagać rodzin instancji EC2 z GPU (serie P lub G), ale większość obciążeń analitycznych baz danych opiera się na zoptymalizowanym CPU i wykonaniu kolumnowym, a nie na GPU.

Migracja, kopie zapasowe, bezpieczeństwo i najlepsze praktyki operacyjne

Migracja i ochrona baz danych wymagają odpowiedniej kombinacji usług i polityk. AWS Database Migration Service (DMS) obsługuje migracje homogeniczne i heterogeniczne z minimalnym czasem przestoju; Schema Conversion Tool pomaga konwertować schematy baz danych podczas przenoszenia między różnymi typami silników. Do tworzenia kopii zapasowych i ochrony opartej na politykach używaj natywnych funkcji silników (automatyczne kopie zapasowe i migawki RDS, DynamoDB PITR) wraz z AWS Backup do scentralizowanych, wielousługowych polityk backupu oraz kopii między kontami lub regionami. Bezpieczeństwo musi obejmować polityki IAM o najniższych uprawnieniach, szyfrowanie w tranzycie (TLS) i w spoczynku (KMS) oraz kontrole sieciowe: grupy bezpieczeństwa (security groups) to stanowe zapory sieciowe na poziomie hosta, które dołączasz do instancji, podczas gdy sieciowe listy ACL (network ACLs) to bezstanowe filtry na poziomie podsieci — obie są komplementarne, ale różnią się w działaniu. W ramach modelu współdzielonej odpowiedzialności (shared responsibility) AWS zarządza infrastrukturą chmury, podczas gdy klienci zarządzają danymi, IAM, poprawkami na poziomie systemu operacyjnego na samodzielnie zarządzanych instancjach oraz rotacją kluczy dla sekretów i poświadczeń dostępowych. Automatyzacja operacyjna przy użyciu CloudFormation, AWS CLI lub SDK umożliwia powtarzalne provisionowanie środowisk; częste pułapki to poleganie na koncie root, pozostawianie zbyt szerokich polityk IAM, zaniedbywanie rotacji kluczy oraz brak monitorowania za pomocą CloudWatch, VPC Flow Logs czy AWS Config. W przypadku transferu dużych ilości danych rozważ użycie AWS Snowball lub DataSync do bezpiecznego przenoszenia terabajtów/petabajtów danych z szyfrowaniem w tranzycie i walidacją integralności.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma AcmeRetail prowadzi sezonową platformę e-commerce z lokalną bazą danych MySQL OLTP oraz dużymi historycznymi plikami CSV ze sprzedażą na lokalnym udziale NFS. Ich konto AWS posiada VPC z prywatnymi podsieciami i Transit Gateway do ich centrum danych. Muszą zmigrować transakcyjną bazę danych z minimalnym czasem przestoju i udostępnić dane historyczne do zapytań dla systemów BI.

Wyzwanie: Przeniesienie produkcyjnej bazy danych z niemal zerowym czasem przestoju, umożliwienie skalowalnej analityki na historycznych plikach CSV oraz zapewnienie kopii zapasowych, szyfrowania i dostępu opartego na zasadzie najniższych uprawnień.

Zalecane podejście:

Użyj AWS Database Migration Service (DMS) wraz z Schema Conversion Tool (w razie potrzeby), aby zmigrować MySQL do Amazon Aurora (kompatybilnej z MySQL), konfigurując ciągłą replikację w celu zminimalizowania czasu przestoju.
Przenieś historyczne pliki CSV do Amazon S3 za pomocą AWS DataSync lub Snowball (dla bardzo dużych wolumenów), przechowuj je w S3 używając warstwy Intelligent-Tiering i przekonwertuj do formatu Parquet za pomocą AWS Glue ETL w celu zwiększenia wydajności zapytań.
Uruchom Amazon Redshift (RA3) lub użyj Amazon Athena do wykonywania zapytań BI na danych w S3 (w formacie Parquet); użyj Redshift Spectrum, jeśli łączysz zapytania do hurtowni danych i data lake.
Wdróż zautomatyzowane kopie zapasowe (automatyczne backupy i migawki RDS), włącz szyfrowanie za pomocą kluczy KMS, ogranicz dostęp za pomocą ról IAM i grup bezpieczeństwa o najniższych uprawnieniach oraz scentralizuj polityki backupu za pomocą AWS Backup.

Uzasadnienie: Ciągła replikacja w DMS umożliwia migrację systemów transakcyjnych z niemal zerowym czasem przestoju; S3 + Parquet + Athena/Redshift minimalizuje koszty analityki i rozmiar skanowanych danych; KMS, kopie zapasowe i IAM oparte na najniższych uprawnieniach są zgodne z modelem współdzielonej odpowiedzialności i najlepszymi praktykami operacyjnymi w zakresie dostępności, bezpieczeństwa i kontroli kosztów.

← Podstawowe usługi przechowywania danych · Wszystkie domeny · Sieci i dostarczanie treści →

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