Jakie są rodzaje baz danych

W drodze do inwentarza QUERY przystaje przy ciemnej sekcji magazynu. Za szybą — rejestr archiwów starej Ziemi, które nie przetrwały Wielkiego Zerwania: węzły pamięci podręcznej zgasły jako pierwsze, magazyny dokumentowe ocalały tylko w postrzępionych fragmentach, klastry analityczne milczą całymi sektorami. A relacyjna migawka „Kotomarketu” przetrwała w całości — ze wszystkimi powiązaniami.

Nie tylko relacyjne

Dla „Kotomarketu” szczególnie wygodne są bazy relacyjne: kupujący, zamówienia i towary naturalnie układają się w tabele z powiązaniami. To właśnie im poświęcony jest kurs. Ale w branży — zarówno w 2024 roku, jak i dziś — spotyka się także inne podejścia:

• klucz-wartość (Redis) — bardzo szybki format „klucz → wartość”, gdy trzeba błyskawicznie pobrać prosty rekord;
• dokumentowe (MongoDB) — przechowują elastyczne dokumenty JSON, których struktura może różnić się między rekordami;
• kolumnowe (ClickHouse) — świetne w analityce, gdy trzeba szybko liczyć wskaźniki na ogromnych ilościach danych.

Większość popularnych DBMS-ów w aplikacjach produktowych pozostaje relacyjna: PostgreSQL, MySQL, Oracle, MS SQL. Tutaj opanujesz SQL — i będziesz pewnie czytać dane w bardzo różnych firmach.

QUERY: Każde archiwum ma swoją robotę: jedno daje szybkość, drugie elastyczność, trzecie analitykę. My mieliśmy szczęście: trafiło nam się to, w którym wszystko łączy się ze wszystkim.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Rejestr rodzin: porządek na półkach

Rejestr za szybą to dobry pretekst, żeby na poważnie zająć się rodzinami baz danych. „Jakie są rodzaje baz i kiedy którą wybrać” to jedno z najczęstszych pytań na rozmowach kwalifikacyjnych. Przejdziemy przez pięć rodzin po kolei, a każdą według tego samego schematu: sposób przechowywania, mocne i słabe strony, produkty oraz sytuacje, w których warto po nią sięgnąć.

Bazy relacyjne: ścisły schemat i powiązania

Sposób przechowywania: wiersze w tabelach o z góry zadeklarowanym schemacie — każda kolumna ma typ, między tabelami działają powiązania po kluczach, a DBMS sam strzeże spójności: zamówienia od nieistniejącego kupującego nie da się zapisać. Zmiany wykonywane są jako transakcje z gwarancjami ACID — „zamówienie + odpisanie stanu magazynu” zapisują się razem albo wcale.

• Mocne strony: bogaty SQL (filtry, łączenia tabel, agregaty), spójność na poziomie bazy, transakcje.
• Słabe strony: schemat trzeba przemyśleć z góry i migrować przy zmianach; skalowanie poziome na wiele serwerów jest trudniejsze niż w rodzinach NoSQL.
• Produkty: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kiedy wybrać: użytkownicy, zamówienia, płatności, magazyn — wszędzie tam, gdzie dane są powiązane, a błąd zapisu jest niedopuszczalny. Dla nowego produktu to wybór domyślny.

Bazy klucz-wartość: słownik na maksymalnej prędkości

Sposób przechowywania: jeden gigantyczny słownik „klucz → wartość”, najczęściej trzymany w pamięci operacyjnej. Bez tabel i bez powiązań: zapisujesz coś pod kluczem, odczytujesz po kluczu w ułamku milisekundy.

-- To nie SQL, to polecenia Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Mocne strony: szybkość, prostota, łatwe skalowanie.
• Słabe strony: zapytania tylko po dokładnym kluczu — pytania „znajdź wszystkie sesje kupujących z Moskwy” temu formatowi nie zadasz; baza nie widzi wnętrza wartości.
• Produkty: Redis, Memcached, Amazon DynamoDB.
• Kiedy wybrać: pamięć podręczna, sesje, liczniki, kolejki, rankingi — gorące dane obok głównej bazy, a nie zamiast niej.

Bazy dokumentowe: elastyczny JSON

Sposób przechowywania: rekordy są dokumentami JSON pogrupowanymi w kolekcje. Schemat nie jest deklarowany z góry: smartwatch ma pole „czas pracy baterii”, bluza — „tabelę rozmiarów”, a oba dokumenty mogą spokojnie leżeć w jednej kolekcji. Struktury zagnieżdżone przechowuje się bezpośrednio w dokumencie, bez osobnych tabel.

• Mocne strony: elastyczna struktura, możliwość odczytania całego dokumentu jednym odwołaniem, wygoda przy katalogach o różnorodnych atrybutach i przy szybkich prototypach.
• Słabe strony: powiązania między dokumentami trzeba obsłużyć w aplikacji, pełnoprawnych JOIN-ów prawie nie ma; bez dyscypliny kolekcja szybko zamienia się w zbiór niezgodnych formatów.
• Produkty: MongoDB, Couchbase, Firestore.
• Kiedy wybrać: treść, katalogi o mocno różniących się polach, profile i ustawienia.

Granica między rodzinami jest zresztą rozmyta: PostgreSQL potrafi przechowywać dokumenty w kolumnie typu jsonb i budować na nich indeksy — często wystarcza to do zaspokojenia „dokumentowej” potrzeby bez drugiej bazy:

-- Przykład spoza naszej migawki: attrs — kolumna typu jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Bazy kolumnowe: analityka po miliardach wierszy

Sposób przechowywania: wartości leżą nie wierszami, lecz kolumnami: wszystkie ceny obok siebie, wszystkie daty obok siebie. Zapytanie „średni rachunek wg miesięcy” czyta z dysku tylko dwie kolumny zamiast całej tabeli, a jednorodne wartości świetnie się kompresują. Stąd szybkość przy agregatach.

-- Ulubiony gatunek bazy kolumnowej (dialekt ClickHouse: toYYYYMM to jego funkcja)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Mocne strony: agregaty i skanowanie miliardów wierszy, silna kompresja.
• Słabe strony: punktowe aktualizacje i usunięcia są kosztowne; odczytanie jednego pełnego wiersza jest wolniejsze niż w bazie wierszowej; do obciążeń transakcyjnych nie są przeznaczone.
• Produkty: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kiedy wybrać: analityka, raporty, zdarzenia, logi, metryki — zwykle obok „bojowej” bazy relacyjnej.

Tu pojawiają się dwa terminy, które często padają na rozmowach kwalifikacyjnych: OLTP (online transaction processing — dużo krótkich operacji zapisu i odczytu, świat PostgreSQL) oraz OLAP (online analytical processing — ciężkie analityczne odczyty po całej historii, świat ClickHouse). Produkt zapisuje dane do bazy OLTP, a analityka czyta kopię OLAP.

I ostatnia rodzina — bazy grafowe

Gdy powiązania są ważniejsze niż same rekordy — „znajomi znajomych”, trasy dostaw, łańcuchy rekomendacji — sięga się po bazy grafowe (Neo4j, Memgraph). Dane w nich to węzły (czyli rekordy) i krawędzie (czyli powiązania między rekordami); przechodzenie po powiązaniach dowolnej głębokości jest tam naturalną operacją. W bazie relacyjnej takie przejście oznacza drabinkę łączeń tabel, która z każdym poziomem robi się coraz cięższa.

Mini-przewodnik: jak wybrać bazę pod projekt

1. Zacznij od pytań, a nie od danych. Jakie zapytania będzie zadawał produkt: punktowe „po kluczu”, powiązane „kto co kupił”, analityczne „ile w ciągu miesiąca”?
2. Domyślnie — relacyjna. Powiązane dane plus wysoka cena błędu (zamówienia, płatności, stany magazynowe) — to PostgreSQL. Najbezpieczniejszy start dla niemal każdego produktu.
3. Bazy wyspecjalizowane — pod konkretne zadanie, a nie „na zapas”. Masz gorące odczyty — dodaj pamięć podręczną na Redis. Urosła analityka — replikuj zdarzenia do ClickHouse. Pola są bardzo zmienne — najpierw jsonb w PostgreSQL, a dopiero gdy go zabraknie, baza dokumentowa.
4. Licz koszt drugiej bazy. Każdy nowy DBMS to synchronizacja danych, kopie zapasowe, monitoring i kolejna technologia, którą zespół musi utrzymywać.