Która baza danych? Drzewo decyzyjne
Poznałeś/aś już wszystkie główne usługi bazodanowe AWS. Teraz pora na najważniejszą umiejętność: szybkie wybieranie właściwej usługi na podstawie wymagań. Dokładnie to sprawdza egzamin Cloud Practitioner.
W tej lekcji przejdziemy przez drzewo decyzyjne i przerobimy scenariusze typowe dla egzaminu. Po tej lekcji będziesz wiedzieć, jakie słowa kluczowe wskazują na jaką usługę.
Drzewo decyzyjne: wybór bazy danych
Zadaj sobie te pytania po kolei:
Pytanie 1: Czy potrzebujesz relacji między tabelami (JOINy, transakcje ACID)?
- Tak → Baza relacyjna → Pytanie 2
- Nie → Baza nierelacyjna → Pytanie 3
Pytanie 2: Jaki poziom wydajności i dostępności potrzebujesz?
- Standardowa baza relacyjna → Amazon RDS
- Wysoka wydajność, cloud-native, auto-scaling storage → Amazon Aurora
- Nieprzewidywalne obciążenie, nie chcesz zarządzać instancjami → Aurora Serverless
Pytanie 3: Jaki typ danych lub obciążenia?
- Klucz-wartość z ogromną skalą i niską latencją → DynamoDB
- In-memory cache (przyspieszenie odczytów z innej bazy) → ElastiCache
- Analityka na petabajtach (OLAP, data warehouse) → Redshift
- Relacje między danymi (grafy, social network) → Neptune
- Dokumenty JSON (kompatybilność z MongoDB) → DocumentDB
- Niezmienialna księga zmian, audit trail → QLDB
- Dane szeregów czasowych (IoT, metryki) → Timestream
- Kompatybilność z Apache Cassandra → Keyspaces
Słowa kluczowe i powiązane usługi
| Słowa kluczowe w pytaniu | Usługa AWS |
|---|---|
| Relational database, SQL, ACID, transactions | RDS lub Aurora |
| High performance relational, cloud-native, 5x faster | Aurora |
| Auto-scaling relational, unpredictable workload | Aurora Serverless |
| Key-value, NoSQL, millisecond latency, millions of requests | DynamoDB |
| Microsecond latency for DynamoDB, in-memory cache for DynamoDB | DAX |
| In-memory cache, session store, sub-millisecond | ElastiCache |
| Data warehouse, OLAP, analytics, petabytes, BI | Redshift |
| Graph, social network, fraud detection, knowledge graph | Neptune |
| Document database, MongoDB, JSON documents | DocumentDB |
| Immutable ledger, audit trail, cryptographic verification | QLDB |
| Time series, IoT sensors, metrics over time | Timestream |
| Cassandra compatible, wide column | Keyspaces |
Scenariusze egzaminacyjne
Przerobimy teraz typowe scenariusze, które możesz spotkać na egzaminie. Przy każdym wyjaśniam tok rozumowania.
Wymagania: Firma buduje sklep internetowy. Potrzebuje bazy danych do przechowywania produktów, zamówień i klientów. Zamówienia muszą być transakcyjne (ACID). Relacje między tabelami są kluczowe.
Analiza: Transakcje ACID + relacje = baza relacyjna. Standardowe obciążenie e-commerce.
Odpowiedź: Amazon RDS (lub Aurora, jeśli potrzebna wyższa wydajność).
Dlaczego nie DynamoDB? Bo DynamoDB nie obsługuje JOINów ani transakcji ACID w tradycyjnym sensie. Złożone relacje między zamówieniami, produktami i klientami wymagają bazy relacyjnej.
Wymagania: Startup buduje aplikację mobilną. Miliony użytkowników. Profile mają różne atrybuty (elastyczny schemat). Kluczowe to niska latencja i automatyczne skalowanie. Brak złożonych relacji.
Analiza: Miliony użytkowników + elastyczny schemat + niska latencja + brak JOINów = NoSQL.
Odpowiedź: Amazon DynamoDB. Serverless, skaluje się automatycznie, jednocyfrowa milisekundowa latencja.
Wymagania: Firma zbiera dane sprzedażowe od 5 lat (terabajty). Zespół analityczny chce tworzyć raporty SQL i dashboardy w narzędziach BI. Zapytania skanują miliony wierszy.
Analiza: Terabajty danych historycznych + analityka SQL + BI = hurtownia danych (OLAP).
Odpowiedź: Amazon Redshift. Columnar storage przyspiesza zapytania analityczne. SQL jest obsługiwany, więc narzędzia BI się podłączą bez problemu.
Dlaczego nie RDS? RDS jest zoptymalizowany do transakcji (OLTP), nie do skanowania milionów wierszy. Redshift z kolumnowym storage jest wielokrotnie szybszy dla zapytań analitycznych.
Wymagania: Strona ładuje się wolno, bo każdy request trafia do bazy danych RDS. Te same dane (np. lista kategorii, popularne produkty) są odczytywane tysiące razy na minutę.
Analiza: Powtarzające się odczyty tych samych danych = idealny przypadek na cache.
Odpowiedź: Amazon ElastiCache (Redis). Cache przed RDS redukuje obciążenie bazy i obniża latencję z milisekund do mikrosekund.
Wymagania: Bank chce wykrywać podejrzane transakcje, analizując powiązania między kontami, kartami płatniczymi i adresami IP. Kluczowe są relacje między encjami.
Analiza: Powiązania między encjami + fraud detection = baza grafowa.
Odpowiedź: Amazon Neptune. Grafy modelują powiązania naturalnie: konto A jest powiązane z kartą B, która była użyta z IP C, które jest też powiązane z kontem D flagowanym jako podejrzane.
Wymagania: Regulowany sektor (finanse, medycyna). Każda zmiana danych musi być zapisana w niezmienialnym dzienniku. Audytorzy muszą móc zweryfikować, że żadna historyczna transakcja nie została zmodyfikowana.
Analiza: Immutable + audit trail + kryptograficzna weryfikacja = ledger.
Odpowiedź: Amazon QLDB. Immutable journal z kryptograficznym haszem, który gwarantuje integralność danych.
Wymagania: Firma monitoruje fabrykę z 10,000 sensorami. Każdy sensor wysyła temperaturę i ciśnienie co 5 sekund. Dane muszą być przechowywane i analizowane w kontekście czasu.
Analiza: Dane IoT + timestamped + analiza trendów w czasie = time series.
Odpowiedź: Amazon Timestream. Zoptymalizowany do zapytań typu „pokaż średnią temperaturę z ostatnich 24 godzin dla sensora X". Automatycznie przenosi stare dane na tańszy storage.
Pułapka 1: Pytanie o „database" nie zawsze oznacza RDS. Czytaj wymagania: jeśli mówią o elastycznym schemacie i milionach requestów, to DynamoDB.
Pułapka 2: Multi-AZ to nie skalowanie. Jeśli pytanie dotyczy skalowania odczytów, odpowiedzią jest Read Replica, nie Multi-AZ.
Pułapka 3: ElastiCache to nie to samo co DAX. ElastiCache to ogólny cache, DAX jest dedykowany dla DynamoDB.
Pułapka 4: Redshift to nie RDS. Jeśli pytanie mówi o analytics/OLAP, to Redshift. Jeśli o transakcjach/OLTP, to RDS.
Pułapka 5: QLDB to nie blockchain. QLDB jest scentralizowany (AWS go kontroluje). Blockchain jest zdecentralizowany. Oba zapewniają niezmienialność, ale różnią się architekturą.
Porównanie kosztowe
Generalna zasada cenowa w AWS databases:
- RDS - płacisz za instancję (per hour) + storage + I/O. Najtańsza opcja relacyjna.
- Aurora - droższe niż RDS (10-20%), ale lepsza wydajność i architektura. Storage płatny per GB.
- Aurora Serverless - płacisz za ACU per second. Droższy per-unit niż provisioned Aurora, ale oszczędzasz gdy baza nie jest aktywna 24/7.
- DynamoDB On-Demand - płacisz za każdy odczyt/zapis. Prosty model, ale może być drogi przy dużym ruchu.
- DynamoDB Provisioned - tańszy per-request, ale ryzykujesz nadpłatę lub throttling.
- ElastiCache - płacisz za node (per hour). Redis jest droższy od Memcached (więcej funkcji).
- Redshift - płacisz za klaster (per hour). Redshift Serverless płatny per RPU (Redshift Processing Unit).
Na egzaminie Cloud Practitioner pytania kosztowe są ogólne. Pamiętaj: managed = płacisz więcej za usługę, ale oszczędzasz na administracji. Serverless = płacisz per use, idealne dla zmiennych obciążeń.
Scenariusze migracji baz danych
Na egzaminie mogą się pojawić pytania o migrację baz danych do AWS. Dwie kluczowe usługi:
- AWS DMS (Database Migration Service) - migracja baz danych do AWS z minimalnym downtime. Obsługuje migracje homogeniczne (MySQL → MySQL) i heterogeniczne (Oracle → Aurora).
- AWS SCT (Schema Conversion Tool) - konwersja schematów bazodanowych przy migracji między różnymi silnikami (np. Oracle → PostgreSQL).
- Na egzaminie kluczowe jest rozpoznawanie słów kluczowych w pytaniu i mapowanie ich na odpowiednią usługę
- Relacyjna z ACID → RDS/Aurora; NoSQL z ogromną skalą → DynamoDB; Cache → ElastiCache; Analityka → Redshift
- Neptune = grafy, DocumentDB = MongoDB, QLDB = immutable ledger, Timestream = time series
- Multi-AZ = HA, Read Replica = skalowanie odczytów, Aurora Serverless = auto-scaling compute
- DAX to cache tylko dla DynamoDB, ElastiCache to cache ogólnego przeznaczenia
- AWS DMS migruje bazy do AWS z minimalnym downtime, SCT konwertuje schematy między silnikami
Firma chce przechowywać dane z 50,000 sensorów IoT i analizować trendy temperaturowe w czasie. Jaka usługa jest najlepsza?
Firma migruje bazę Oracle z on-premises do Aurora PostgreSQL w AWS z minimalnym downtime. Jakich usług AWS użyje?
Aplikacja webowa korzysta z RDS PostgreSQL. Te same dane (lista kategorii) są odczytywane 10,000 razy na minutę. Jak obniżyć latencję?