DynamoDB - NoSQL w skali Amazona
DynamoDB to jedna z najbardziej rozpoznawalnych usług AWS. To w pełni zarządzana, serverless baza NoSQL typu klucz-wartość, która zapewnia jednocyfrową milisekundową latencję niezależnie od skali. Czy masz 10 rekordów, czy 10 miliardów, DynamoDB odpowiada tak samo szybko.
To jest baza, na której Amazon.com obsługuje swój sklep. Miliony requestów na sekundę podczas Prime Day? Żaden problem. I ta sama technologia jest dostępna dla Ciebie.
Czym DynamoDB różni się od bazy relacyjnej?
Zapomnij o tabelach z wieloma kolumnami i JOINach. W DynamoDB:
- Masz tabele, ale każda tabela jest niezależna (brak JOINów)
- Każdy rekord to item (odpowiednik wiersza w SQL)
- Każdy item składa się z atrybutów (odpowiednik kolumn, ale elastycznych)
- Nie musisz definiować wszystkich atrybutów z góry, każdy item może mieć inne
- Jedyne co musisz zdefiniować to klucz główny (primary key)
Klucze w DynamoDB
To fundament, który musisz zrozumieć. DynamoDB obsługuje dwa typy kluczy głównych:
1. Partition Key (klucz partycji) - prosty klucz główny
Jeden atrybut, który jednoznacznie identyfikuje item. DynamoDB używa go do obliczenia, na której wewnętrznej partycji przechowywać dane. Musi być unikalny w tabeli.
Przykład: tabela „Users" z partition key = user_id. Każdy user ma unikalne ID.
2. Partition Key + Sort Key (klucz złożony)
Kombinacja dwóch atrybutów. Partition key nie musi być unikalny sam w sobie, ale kombinacja partition key + sort key musi być unikalna. Sort key pozwala na sortowanie i zakresowe zapytania w ramach jednej partycji.
Przykład: tabela „Orders" z partition key = customer_id i sort key = order_date. Jeden klient może mieć wiele zamówień, posortowanych po dacie.
DynamoDB wewnętrznie dzieli dane na partycje. Partition key jest haszowany, a wynik determinuje, na której partycji ląduje item. Dlatego dobry partition key to taki, który równomiernie rozkłada dane.
Zły partition key: „country" (jeśli 80% userów jest z Polski, jedna partycja dostanie 80% ruchu = hot partition)
Dobry partition key: „user_id" (każdy user ma unikalne ID, ruch rozkłada się równomiernie)
Hot partition to najczęstszy problem wydajnościowy w DynamoDB. Unikaj kluczy o niskiej kardynalności (mało unikalnych wartości).
Tryby pojemności (Capacity Modes)
DynamoDB daje Ci dwa sposoby na zarządzanie przepustowością:
1. On-Demand (na żądanie)
- Płacisz za każdy odczyt i zapis (per request)
- Zerowa konfiguracja, DynamoDB automatycznie skaluje się do Twoich potrzeb
- Idealne, gdy nie znasz wzorca ruchu lub ruch jest nieprzewidywalny
- Droższe per-request niż Provisioned, ale nie płacisz za niewykorzystaną pojemność
2. Provisioned (zarezerwowana)
- Definiujesz z góry ile odczytów (RCU - Read Capacity Units) i zapisów (WCU - Write Capacity Units) na sekundę potrzebujesz
- Tańsze per-request, ale musisz dobrze oszacować obciążenie
- Możesz włączyć Auto Scaling, który automatycznie dostosowuje RCU/WCU do ruchu
- Jeśli przekroczysz limit, requesty zostają throttlowane (odrzucone)
| Cecha | On-Demand | Provisioned |
|---|---|---|
| Konfiguracja | Zero, DynamoDB zarządza | Definiujesz RCU/WCU |
| Skalowanie | Automatyczne, natychmiastowe | Auto Scaling lub ręczne |
| Koszt per-request | Wyższy | Niższy |
| Idealne dla | Nieprzewidywalny ruch, nowe aplikacje | Przewidywalny ruch, optymalizacja kosztów |
| Ryzyko throttlingu | Minimalne | Tak, jeśli przekroczysz limit |
DynamoDB Accelerator (DAX)
DAX to w pełni zarządzany cache w pamięci dedykowany dla DynamoDB. Zmniejsza czas odpowiedzi z jednocyfrowych milisekund do mikrosekund (tysięcznych milisekund).
Jak to działa?
- DAX siedzi między aplikacją a DynamoDB
- Aplikacja łączy się z DAX zamiast bezpośrednio z DynamoDB
- DAX sprawdza cache: jeśli ma dane, zwraca je natychmiast (cache hit)
- Jeśli nie ma (cache miss), pobiera z DynamoDB, cachuje i zwraca
- API jest kompatybilne z DynamoDB, więc zmiana w kodzie jest minimalna
DynamoDB Global Tables
Global Tables pozwalają na multi-region, multi-active replikację tabel DynamoDB. To oznacza, że ta sama tabela jest replikowana do wybranych regionów AWS i w każdym regionie możesz zarówno czytać, jak i zapisywać dane.
Kluczowe cechy:
- Multi-active - zapis możliwy w każdym regionie (nie ma jednego primary)
- Automatyczna replikacja - zmiany w jednym regionie są replikowane do pozostałych
- Rozwiązywanie konfliktów - ostatni zapis wygrywa (last writer wins)
- Niższa latencja - użytkownicy łączą się z najbliższym regionem
Firma tworzy grę mobilną z graczami w Europie, USA i Azji. Wyniki graczy muszą być dostępne globalnie z niską latencją. Gracze w Tokio nie mogą czekać na odpowiedź z serwera w Irlandii.
Rozwiązanie: DynamoDB Global Table replikowana do eu-west-1 (Irlandia), us-east-1 (Virginia) i ap-northeast-1 (Tokio). Każdy gracz łączy się z najbliższym regionem. Wyniki są synchronizowane automatycznie między regionami. Jeśli jeden region padnie, gracze kontynuują grę przez inny region.
Dodatkowe funkcje DynamoDB
DynamoDB Streams: Rejestruje chronologiczny log zmian w tabeli (insert, update, delete). Możesz podpiąć Lambda function, która reaguje na każdą zmianę. Idealne do event-driven architectures.
TTL (Time To Live): Automatycznie usuwa itemy po upływie określonego czasu. Ustawiasz atrybut z timestampem wygaśnięcia, DynamoDB sam usunie item. Świetne do danych tymczasowych (sesje, tokeny, cache).
Point-in-Time Recovery (PITR): Pozwala przywrócić tabelę do dowolnego momentu w ciągu ostatnich 35 dni. Chroni przed przypadkowym usunięciem danych.
Szyfrowanie: Encryption at rest jest włączone domyślnie (AWS owned key, lub możesz użyć swojego klucza KMS).
- DynamoDB to serverless NoSQL z jednocyfrową milisekundową latencją, skalujący się do milionów requestów/sekundę
- Dane identyfikujesz przez partition key (opcjonalnie + sort key)
- On-Demand mode nie wymaga konfiguracji, Provisioned mode jest tańszy przy stałym obciążeniu
- DAX to dedykowany cache DynamoDB, zmniejszający latencję do mikrosekund
- Global Tables replikują dane multi-region z możliwością zapisu w każdym regionie
- DynamoDB Streams umożliwia reagowanie na zmiany danych (event-driven)
Aplikacja potrzebuje bazy danych z latencją poniżej 10ms obsługującej miliony requestów na sekundę. Schemat danych zmienia się często. Co wybierzesz?
Firma chce obniżyć latencję odczytów DynamoDB z milisekund do mikrosekund. Co powinna wdrożyć?
Jaka jest główna różnica między trybem On-Demand a Provisioned w DynamoDB?