Amazon DynamoDB
Amazon DynamoDB
W pełni zarządzana baza danych NoSQL o wydajności jednocyfrowych milisekund przy dowolnej skali - od aplikacji startupowej po globalny serwis obsługujący miliony żądań na sekundę.
Amazon DynamoDB to w pełni zarządzana baza danych NoSQL typu klucz-wartość i dokumentowa, zaprojektowana do obsługi aplikacji wymagających jednocyfrowych milisekund opóźnienia przy dowolnej skali. DynamoDB automatycznie replikuje dane w trzech strefach dostępności w regionie, zapewniając trwałość i wysoką dostępność bez konieczności konfigurowania replikacji. Nie musisz zarządzać serwerami, patchami, backupami ani skalowaniem - DynamoDB robi to wszystko automatycznie.
DynamoDB różni się fundamentalnie od relacyjnych baz danych. Zamiast tabel ze schematem, joinów i złożonych zapytań SQL, DynamoDB opiera się na kluczu partycji i opcjonalnym kluczu sortowania do organizacji danych. Dzięki temu dostęp do danych jest błyskawicznie szybki i przewidywalny - ale wymaga przemyślanego modelowania danych z góry. DynamoDB jest doskonałym wyborem dla aplikacji serverless (z Lambda), gier, IoT, sesji użytkowników i wszędzie tam, gdzie potrzebujesz stałej, niskiej latencji niezależnie od ilości danych.
Amazon DynamoDB powstał na bazie wewnętrznego systemu Amazon.com o nazwie Dynamo, opisanego w legendarnym artykule naukowym z 2007 roku. Dzisiaj DynamoDB obsługuje koszyk zakupowy Amazon.com, który przetwarza ponad 89,2 miliona żądań na sekundę w szczycie (Prime Day).
Projektuj schemat DynamoDB od wzorców dostępu (access patterns), a nie od struktury danych! Najpierw spisz wszystkie zapytania, jakie Twoja aplikacja będzie wykonywać, a dopiero potem dobierz Partition Key, Sort Key i GSI. W DynamoDB zmiana schematu po fakcie jest znacznie trudniejsza niż w SQL. Używaj single-table design dla zaawansowanych przypadków.
Hot partition to najczestszy problem wydajnosciowy. Jesli jeden partition key dostaje nieproporcjonalnie duzo requestow, DynamoDB throttluje mimo wolnej pojemnosci na innych partycjach. Scan pelnej tabeli jest kosztowny (czyta kazdy item) i moze wyczerpac RCU. On-Demand pricing jest wygodny, ale przy stalym ruchu 5-7x drozszy niz Provisioned z auto-scalingiem.
DynamoDB to baza NoSQL, ktora wymaga innego podejscia niz relacyjne bazy danych. Zamiast normalizacji i joinow, projektujesz tabele pod konkretne wzorce dostepu (access patterns). Ponizej kluczowe etapy pracy z DynamoDB.
Tworzenie tabeli i wybor kluczy
Kazda tabela wymaga klucza partycji (Partition Key) - to on determinuje, na ktorej fizycznej partycji trafia rekord. Opcjonalnie dodajesz klucz sortowania (Sort Key), ktory pozwala przechowywac wiele rekordow pod jednym kluczem partycji i odpytywac je zakresowo (begins_with, between). Wybor kluczy to najwazniejsza decyzja - zle zaprojektowane klucze prowadza do hot partitions i throttlingu.
Tryby pojemnosci - On-Demand vs Provisioned
On-Demand (pay-per-request) automatycznie skaluje sie do potrzeb - idealny gdy ruch jest nieprzewidywalny lub dopiero startujesz. Provisioned pozwala zarezerwowac konkretna liczbe RCU (Read Capacity Units) i WCU (Write Capacity Units) z Auto Scalingiem - tanszy o 50-70% przy stabilnym ruchu. Mozesz przelaczac tryb raz na 24h. Provisioned z Reserved Capacity to najtansza opcja dla dojrzalych workloadow.
Operacje odczytu i zapisu
GetItem pobiera rekord po pelnym kluczu glownym (PK + SK). Query odpytuje rekordy z jednej partycji - mozesz filtrowac po Sort Key. Scan przeszukuje cala tabele - kosztowny, unikaj w produkcji. PutItem zapisuje caly rekord, UpdateItem modyfikuje wybrane atrybuty. BatchWriteItem pozwala zapisac do 25 rekordow w jednym wywolaniu, ale bez atomowosci - nieudane pozycje wracaja jako UnprocessedItems. Transakcje (TransactWriteItems) gwarantuja ACID dla max 100 operacji.
Indeksy wtorne (GSI i LSI)
Global Secondary Index (GSI) to osobna projekcja tabeli z innym kluczem partycji i sortowania - pozwala odpytywac dane w zupelnie inny sposob niz tabela glowna. GSI ma wlasna pojemnosc (RCU/WCU) i moze zawierac tylko wybrane atrybuty (projekcja). Local Secondary Index (LSI) uzywa tego samego klucza partycji co tabela, ale innego klucza sortowania - trzeba go zdefiniowac przy tworzeniu tabeli.
DynamoDB Streams
Streams rejestruja kazda zmiane w tabeli (insert, update, delete) w porzadku chronologicznym i przechowuja je przez 24h. Mozesz podpiac Lambda function do streama - reaguje na zmiany w czasie rzeczywistym. Typowe zastosowania: replikacja do ElasticSearch, wysylanie notyfikacji, materializowanie widokow, audyt zmian. Stream moze zawierac stary obraz rekordu, nowy lub oba.
TTL - automatyczne usuwanie danych
Time To Live pozwala automatycznie usuwac rekordy po okreslonym czasie. Wskazujesz atrybut z timestampem (epoch seconds) - DynamoDB w tle usuwa wygasle rekordy bez zuzycia WCU. Idealne dla sesji uzytkownikow, tokenow, cache i danych tymczasowych. Usuniete rekordy pojawiaja sie w Streams, wiec mozesz je zarchiwizowac do S3 przed utrata.
DynamoDB nagrodzi Cie wydajnoscia, ale wymaga przemyslanego modelowania danych. Te wskazowki pomoga Ci uniknac typowych pulapek i wycisnac maksimum z NoSQL.
Projektuj klucz partycji pod rownomierne rozlozenie
Hot partition to najczestszy problem DynamoDB - jeden klucz partycji dostaje nieproporcjonalnie duzo ruchu. Unikaj kluczy typu "status" (kilka wartosci) czy "date" (caly dzien na jednej partycji). Dobre klucze: userId, orderId, deviceId. Jesli musisz uzywac klucza o niskiej kardynalnosci, dodaj losowy suffix (np. status#1, status#2) i odpytuj rownolegle - to write sharding.
PoczatkujacyGSI - unikaj over-projekcji atrybutow
Kazdy GSI to kopia danych z wlasna pojemnoscia. Jesli projektujesz GSI z ALL attributes, platisz podwojnie za storage i WCU (kazdy zapis do tabeli glownej replicuje sie do GSI). Uzywaj projekcji KEYS_ONLY lub INCLUDE z konkretnymi atrybutami. Jesli GSI throttluje, tabela glowna tez zacznie throttlowac zapisy - to tzw. GSI back pressure.
ZaawansowanySingle-Table Design - rozwaznie
Single-Table Design (wszystkie encje w jednej tabeli) redukuje liczbe zapytan i pozwala pobierac powiazane dane jednym Query. Sprawdza sie w serverless (Lambda + API Gateway), gdzie kazde wywolanie to osobne polaczenie. Ale komplikuje migracje, utrudnia zrozumienie modelu i wymaga zaawansowanej wiedzy o access patterns. Dla prostszych aplikacji - osobne tabele per encja sa OK.
ZaawansowanyDAX - cache na sterydach
DynamoDB Accelerator (DAX) to w pelni zarzadzany cache in-memory, ktory redukuje latency z milisekund do mikrosekund. DAX jest API-kompatybilny z DynamoDB - wystarczy zmienic endpoint w SDK. Uzyj DAX gdy: masz read-heavy workload (90%+ read), potrzebujesz sub-milisekundowych odpowiedzi, chcesz zredukowac koszty RCU. Nie uzywaj DAX dla write-heavy workloadow ani strongly consistent reads.
ZaawansowanyProvisioned + Auto Scaling = oszczednosci
On-Demand jest wygodny, ale drogi przy stałym ruchu. Przeanalizuj metryki CloudWatch (ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits) przez 2 tygodnie. Jesli ruch jest przewidywalny, przejdz na Provisioned z Auto Scaling (target tracking 70%). Dla bazowego obciazenia rozważ Reserved Capacity - oszczedzisz dodatkowe 53% vs Provisioned on-demand pricing.
PoczatkujacyTTL + Streams = tani archiwizator
Zamiast recznie usuwac stare dane, ustaw TTL na atrybucie expireAt. Podepnij Lambda do DynamoDB Streams, ktora zapisuje usuniete rekordy do S3 (np. w formacie Parquet). Masz automatyczna archiwizacje bez zadnych kosztow WCU za usuwanie. Dane w S3 mozesz pozniej analizowac przez Athena. To standardowy wzorzec dla logów, eventow i danych IoT.
PoczatkujacyScreenshoty z AWS Console
Wkrotce pojawia sie tu zrzuty ekranu pokazujace jak korzystac z Amazon DynamoDB bezposrednio w konsoli AWS.
Do czego sluzy Amazon DynamoDB?
Backend aplikacji serverless
Naturalne połączenie z AWS Lambda - zero zarządzania serwerami, automatyczne skalowanie, model pay-per-request. Idealny stos: API Gateway + Lambda + DynamoDB.
Przechowywanie sesji użytkowników
Szybki odczyt i zapis sesji HTTP z TTL do automatycznego usuwania wygasłych sesji. Milisekundowy dostęp niezależnie od liczby aktywnych użytkowników.
Gaming - leaderboardy i stan gry
Przechowywanie wyników graczy, postępów i stanów gier z globalną replikacją (Global Tables) dla graczy z całego świata.
IoT - dane z urządzeń
Pozyskiwanie i przechowywanie milionów zdarzeń z czujników IoT na sekundę. Klucz partycji = ID urządzenia, klucz sortowania = timestamp - naturalny wzorzec time-series.
Co musisz wiedziec?
Partition Key (klucz partycji)
Główny klucz identyfikujący element w tabeli. DynamoDB używa go do określenia fizycznej partycji, na której przechowywane są dane. Musi być unikalny (lub w połączeniu z Sort Key).
Sort Key (klucz sortowania)
Opcjonalny drugi komponent klucza głównego. Pozwala przechowywać wiele elementów z tym samym Partition Key, posortowanych po Sort Key. Np. userId (PK) + orderDate (SK).
GSI (Global Secondary Index)
Dodatkowy indeks z innym kluczem partycji i sortowania niż tabela główna. Pozwala odpytywać dane po innych atrybutach bez skanowania całej tabeli. Można mieć do 20 GSI na tabelę.
Tryb On-Demand
DynamoDB automatycznie obsługuje dowolną liczbę żądań bez konfigurowania pojemności. Płacisz za każde żądanie odczytu/zapisu. Idealny dla nieprzewidywalnego ruchu.
Tryb Provisioned
Sam definiujesz liczbę odczytów (RCU) i zapisów (WCU) na sekundę. Tańszy przy stałym, przewidywalnym obciążeniu. Może korzystać z Auto Scaling.
TTL (Time to Live)
Automatyczne usuwanie elementów po określonym czasie. Definiujesz atrybut z timestampem expiracji - DynamoDB usuwa wygasłe elementy bez dodatkowych kosztów.
Architektura: Serverless API z DynamoDB
Klasyczna architektura serverless z DynamoDB jako baza danych, wzbogacona o przetwarzanie eventow przez Streams. Ten wzorzec skaluje sie od zera do milionow zapytan bez zarzadzania infrastruktura.
Porównanie: DynamoDB vs RDS vs ElastiCache
| Cecha | DynamoDB | RDS | ElastiCache |
|---|---|---|---|
| Typ bazy | NoSQL (klucz-wartość, dokument) | SQL (relacyjna) | In-memory (klucz-wartość) |
| Latencja | Jednocyfrowe milisekundy | Kilka-kilkanaście ms | Sub-milisekundowa |
| Skalowanie | Automatyczne, nieograniczone | Vertical (większa instancja) | Horizontal (klaster) |
| Schemat danych | Elastyczny (schemaless) | Sztywny (schemat SQL) | Brak (klucz-wartość) |
| Joiny/relacje | Brak natywnych joinów | Pełne wsparcie SQL | Brak |
| Zarządzanie | Fully serverless | Zarządzane instancje | Zarządzane instancje |
| Typowe zastosowanie | Serverless, gaming, IoT, sesje | Aplikacje CRUD, e-commerce, ERP | Cache, sesje, kolejki, real-time |
| Free Tier | 25 GB, 25 WCU/RCU (always free) | 750 godz. db.t3.micro (12 mies.) | Brak Free Tier |
Ile kosztuje Amazon DynamoDB?
On-Demand
Płacisz za każde żądanie odczytu i zapisu. Brak minimalnej pojemności i zobowiązań.
Zapis: $0.625/mln żądań, Odczyt: $0.125/mln żądań
Provisioned
Definiujesz RCU (read capacity units) i WCU (write capacity units). Tańszy przy stałym obciążeniu.
1 WCU: ~$0.47/mies., 1 RCU: ~$0.09/mies.
Reserved Capacity
Rezerwujesz pojemność Provisioned na 1 lub 3 lata. Znacząca oszczędność dla dużych, stałych obciążeń.
Do 77% taniej niż Provisioned On-Demand
Free Tier
25 GB storage, 25 WCU i 25 RCU (Provisioned) - bezterminowo (always free). Wystarczy na ~200 mln żądań/miesiąc.
Wystarczy na małą aplikację produkcyjną
Przyklady AWS CLI
Utwórz tabelę DynamoDB
Tworzy tabelę z Partition Key (userId) i Sort Key (orderDate) w trybie On-Demand
aws dynamodb create-table \
--table-name Zamowienia \
--attribute-definitions \
AttributeName=userId,AttributeType=S \
AttributeName=orderDate,AttributeType=S \
--key-schema \
AttributeName=userId,KeyType=HASH \
AttributeName=orderDate,KeyType=RANGE \
--billing-mode PAY_PER_REQUESTDodaj element do tabeli
Wstawia nowy element (rekord) do tabeli
aws dynamodb put-item \
--table-name Zamowienia \
--item '{"userId":{"S":"user123"},"orderDate":{"S":"2024-06-15"},"total":{"N":"299.99"},"status":{"S":"shipped"}}'Odpytaj elementy po kluczu
Pobiera wszystkie zamówienia konkretnego użytkownika
aws dynamodb query \
--table-name Zamowienia \
--key-condition-expression "userId = :uid" \
--expression-attribute-values '{":uid":{"S":"user123"}}' \
--output tableSkanuj tabelę z filtrem
Znajduje wszystkie zamówienia o statusie "shipped" (skan całej tabeli - kosztowne!)
aws dynamodb scan \
--table-name Zamowienia \
--filter-expression "#s = :status" \
--expression-attribute-names '{"#s":"status"}' \
--expression-attribute-values '{":status":{"S":"shipped"}}'Quiz: Amazon DynamoDB
Sprawdz czy dobrze rozumiesz podstawy. Kliknij odpowiedz — feedback pojawi sie od razu.
1. Czym różni się tryb On-Demand od Provisioned w DynamoDB?
2. Co to jest GSI (Global Secondary Index)?
3. Ile stref dostępności DynamoDB używa do replikacji danych?
4. Która operacja jest kosztowniejsza: Query czy Scan?
Czesto uzywane razem z Amazon DynamoDB
Czytaj więcej o Amazon DynamoDB
Chcesz poznac Amazon DynamoDB w praktyce?
Darmowy kurs "AWS od podstaw" pokazuje jak uzywac Amazon DynamoDB krok po kroku. Teoria + praktyka od zera.