Bazy danych w AWS - od czego zacząć?
Każda aplikacja potrzebuje miejsca na dane. Sklep internetowy przechowuje produkty i zamówienia. Portal społecznościowy trzyma profile użytkowników i posty. Gra online zapisuje wyniki i postępy graczy. Bez bazy danych nie ma aplikacji.
AWS oferuje ponad 15 różnych usług bazodanowych. Brzmi jak dużo? Bo to jest dużo. Ale spokojnie, w tej lekcji uporządkujemy wszystko od podstaw, żebyś wiedział/a czym się różnią poszczególne typy i dlaczego AWS ma ich tyle.
Relacyjne vs nierelacyjne bazy danych
To podstawowy podział, który musisz znać. Zacznijmy od analogii.
Baza relacyjna (SQL) to jak arkusz kalkulacyjny Excel. Masz tabele z kolumnami i wierszami. Każda tabela ma ściśle zdefiniowaną strukturę (schemat). Dane w różnych tabelach łączysz relacjami, np. tabela „zamówienia" odnosi się do tabeli „klienci" przez ID klienta.
Przykłady: MySQL, PostgreSQL, Oracle, Microsoft SQL Server, MariaDB.
Baza nierelacyjna (NoSQL) to jak zbiór dokumentów JSON lub par klucz-wartość. Nie wymuszasz sztywnej struktury. Każdy rekord może wyglądać inaczej. Nie masz JOINów między tabelami (bo zazwyczaj nie masz tabel w tradycyjnym sensie).
Przykłady: DynamoDB, MongoDB, Redis, Cassandra, Neo4j.
| Cecha | Relacyjne (SQL) | Nierelacyjne (NoSQL) |
|---|---|---|
| Struktura danych | Tabele z wierszami i kolumnami | Dokumenty, klucz-wartość, grafy, kolumny |
| Schemat | Sztywny, z góry zdefiniowany | Elastyczny, może się zmieniać |
| Relacje | JOINy między tabelami | Dane zazwyczaj zdenormalizowane |
| Skalowanie | Głównie wertykalne (większa maszyna) | Horyzontalne (więcej maszyn) |
| Kiedy używać? | Złożone zapytania, transakcje, ACID | Duża skala, elastyczny schemat, niska latencja |
| Przykłady w AWS | RDS, Aurora | DynamoDB, ElastiCache, Neptune |
Kiedy relacyjna, kiedy nierelacyjna?
Nie ma jednej odpowiedzi typu „zawsze używaj SQL" albo „NoSQL jest lepszy". To zależy od przypadku użycia:
- Relacyjna sprawdza się, gdy potrzebujesz transakcji ACID (np. przelewy bankowe, systemy ERP), złożonych zapytań z JOINami, lub gdy struktura danych jest dobrze zdefiniowana i stabilna.
- Nierelacyjna wygrywa, gdy masz ogromne ilości danych, potrzebujesz milisekundowych odpowiedzi, schemat danych zmienia się często, lub potrzebujesz skalowalności horyzontalnej.
Managed vs unmanaged - dlaczego zarządzane bazy danych?
To jest kluczowy koncept w AWS i jeden z powodów, dla których chmura jest tak popularna.
Unmanaged (niezarządzana) baza to taka, którą sam instalujesz na EC2. Stawiasz instancję, instalujesz MySQL, konfigurujesz replikację, robisz backupy, patchujesz system, monitorujesz dyski. Wszystko leży na Tobie.
Managed (zarządzana) baza to usługa AWS, która zajmuje się całą infrastrukturą za Ciebie. Ty wybierasz silnik, rozmiar, klikasz „utwórz" i masz działającą bazę. AWS automatycznie robi backupy, patchuje silnik, zarządza failoverem i monitoruje zdrowie instancji.
| Zadanie | Unmanaged (DB na EC2) | Managed (np. RDS) |
|---|---|---|
| Instalacja silnika DB | Ty | AWS |
| Patching systemu | Ty | AWS |
| Backupy | Ty (ręcznie lub skrypty) | AWS (automatyczne) |
| High Availability | Ty (konfiguracja replikacji) | AWS (Multi-AZ jednym kliknięciem) |
| Skalowanie | Ty (ręczna zmiana instancji) | AWS (kilka kliknięć lub auto) |
| Monitoring | Ty (instalacja narzędzi) | AWS (CloudWatch wbudowany) |
| Dostęp do OS | Pełny (SSH) | Brak (tylko endpointy DB) |
Przegląd usług bazodanowych AWS
AWS oferuje usługę dopasowaną do praktycznie każdego typu obciążenia. Oto szybki przegląd głównych usług, które omówimy w kolejnych lekcjach:
Relacyjne:
- Amazon RDS - zarządzane bazy relacyjne (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)
- Amazon Aurora - autorski silnik AWS, kompatybilny z MySQL/PostgreSQL, 5x szybszy od MySQL
Klucz-wartość / NoSQL:
- Amazon DynamoDB - serverless NoSQL, milisekundowa latencja, praktycznie nieograniczona skala
Cache (pamięć podręczna):
- Amazon ElastiCache - zarządzane Redis lub Memcached, sub-milisekundowa latencja
Data warehouse:
- Amazon Redshift - hurtownia danych do analityki (OLAP), petabajty danych
Grafowa:
- Amazon Neptune - baza grafowa do relacji między danymi (social networks, fraud detection)
Dokumentowa:
- Amazon DocumentDB - kompatybilna z MongoDB, do obciążeń dokumentowych
Ledger (księga):
- Amazon QLDB - immutable ledger, kryptograficznie weryfikowalny dziennik zmian
Time series:
- Amazon Timestream - baza do danych szeregów czasowych (IoT, metryki)
Wide column:
- Amazon Keyspaces - zarządzane Apache Cassandra
Startup (3 programistów): Buduje aplikację mobilną. Nie ma zespołu DBA (database administrator). Wybiera Amazon RDS z automatycznymi backupami. Zespół skupia się na kodzie, nie na administracji bazą. Koszt wejścia niski, skalowanie proste.
Korporacja bankowa: Ma 20-osobowy zespół DBA, ale migruje do chmury. Wybiera Aurora Multi-AZ z szyfrowanymi backupami. Uzyskuje high availability i compliance bez budowania własnej infrastruktury replikacji. Oszczędza setki godzin pracy inżynierów miesięcznie.
Wniosek? Managed databases to nie tylko oszczędność dla małych firm. Nawet duże organizacje korzystają z nich, bo pozwalają skupić się na logice biznesowej zamiast na utrzymaniu infrastruktury.
- Bazy relacyjne (SQL) to tabele z JOINami i transakcjami ACID, idealne do złożonych zapytań
- Bazy nierelacyjne (NoSQL) to elastyczny schemat i horyzontalne skalowanie, idealne do dużej skali
- Managed databases w AWS eliminują konieczność zarządzania infrastrukturą, patchowania i backupów
- Jedynym powodem dla bazy na EC2 jest potrzeba pełnej kontroli nad OS lub egzotyczny silnik DB
- AWS ma ponad 15 usług bazodanowych, każda zoptymalizowana pod inny typ obciążenia
Firma chce przechowywać dane zamówień z wieloma relacjami (klienci, produkty, płatności). Który typ bazy danych jest najlepszy?
Jaka jest główna przewaga managed database (np. RDS) nad bazą postawioną na EC2?
Kiedy warto postawić bazę danych na EC2 zamiast użyć usługi managed?