Jaké druhy databází existují

Cestou k soupisu QUERY přibrzdí u tmavé sekce archivu. Za sklem je rejstřík archivů staré Země, které nepřežily Velký rozkol: cache uzly zhasly první, dokumentová úložiště dorazila jako roztrhané fragmenty, analytické clustery mlčí celými sektory. A relační snímek «Kotomarketu» přežil celý — se všemi vazbami.

Nejen relační

Pro «Kotomarket» se nám obzvlášť hodí relační DB: zákazníci, objednávky a zboží přirozeně zapadají do tabulek s vazbami. Právě jim je kurz věnován. V branži — ať v roce 2024, nebo dnes — ale narazíš i na jiné přístupy:

• klíč-hodnota (Redis) — velmi rychlý formát «klíč → hodnota», když je potřeba okamžitě vytáhnout jednoduchý záznam;
• dokumentové (MongoDB) — uchovávají pružné JSON dokumenty, jejichž struktura se může záznam od záznamu lišit;
• sloupcové (ClickHouse) — jsou silné v analytice, když je potřeba rychle spočítat ukazatele nad obrovskými objemy dat.

Většina populárních DBMS pro produktový vývoj zůstává relačních: PostgreSQL, MySQL, Oracle, MS SQL. Když tu zvládneš SQL, dokážeš sebejistě číst data v nejrůznějších firmách.

QUERY: Každý archiv má svou práci: jednomu jde o rychlost, druhému o pružnost, třetímu o analytiku. My dva jsme měli štěstí: dostali jsme ten, ve kterém všechno souvisí se vším.

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.

Rejstřík rodin: pěkně po pořádku

Rejstřík za sklem je důvod probrat rodiny databází doopravdy: «jaké druhy DB existují a kdy kterou vzít» je jedna z nejčastějších otázek na pohovorech. Projdeme pět rodin za sebou a každou podle jedné šablony: způsob uložení, silné a slabé stránky, produkty a kdy ji vzít.

Relační DB: striktní schéma a vazby

Způsob uložení: řádky v tabulkách s předem deklarovaným schématem — každý sloupec má typ, mezi tabulkami platí vazby přes klíče a DBMS sama střeží integritu: objednávku od neexistujícího zákazníka zapsat nepůjde. Změny se provádějí jako transakce se zárukami ACID — «objednávka + odpis ze skladu» se zapíšou buď spolu, nebo vůbec.

• Silné stránky: výrazové SQL (filtry, spojení tabulek, agregace), integrita na úrovni databáze, transakce.
• Slabé: schéma je nutné promyslet předem a při změnách migrovat; horizontální škálování na mnoho serverů jde hůř než u NoSQL rodin.
• Produkty: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kdy vzít: uživatelé, objednávky, peníze, sklad — všude, kde jsou data provázaná a chyba v zápisu je nepřípustná. Pro nový produkt je to výchozí volba.

Databáze klíč-hodnota: slovník na maximální rychlost

Způsob uložení: jeden obří slovník «klíč → hodnota», nejčastěji v operační paměti. Žádné tabulky ani vazby: uložil jsi podle klíče — vytáhl podle klíče za zlomek milisekundy.

-- Tohle není SQL, tohle jsou příkazy Redisu
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Silné stránky: rychlost, jednoduchost, snadné škálování.
• Slabé: dotazy jen podle přesného klíče — otázku «najdi všechny relace zákazníků z Moskvy» tomuto formátu nepoložíš; vnitřek hodnoty je pro databázi neprůhledný.
• Produkty: Redis, Memcached, Amazon DynamoDB.
• Kdy vzít: cache, relace, čítače, fronty, žebříčky — žhavá data vedle hlavní databáze, ne místo ní.

Dokumentové DB: pružný JSON

Způsob uložení: záznamy jsou JSON dokumenty seskupené do kolekcí. Schéma se předem nedeklaruje: chytré hodinky mají pole «výdrž baterie», mikina «velikostní tabulku» a oba dokumenty si klidně leží v jedné kolekci. Vnořené struktury se uchovávají přímo uvnitř dokumentu, bez zvláštních tabulek.

• Silné stránky: pružná struktura, dokument se přečte celý jedním sáhnutím, hodí se na katalogy s různorodými atributy a rychlé prototypy.
• Slabé: vazby mezi dokumenty jsou starost aplikace, plnohodnotný JOIN skoro chybí; bez disciplíny se z kolekce stane zvěřinec nekompatibilních formátů.
• Produkty: MongoDB, Couchbase, Firestore.
• Kdy vzít: obsah, katalogy se silně odlišnými poli, profily a nastavení.

Hranice rodin je mimochodem rozmazaná: PostgreSQL umí uchovávat dokumenty ve sloupci typu jsonb a stavět nad nimi indexy — to často pokryje «dokumentovou» potřebu bez druhé databáze:

-- Příklad mimo náš snímek: attrs — sloupec typu jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Sloupcové DB: analytika nad miliardami řádků

Způsob uložení: hodnoty neleží po řádcích, ale po sloupcích: všechny ceny pohromadě, všechna data pohromadě. Dotaz «průměrná útrata po měsících» přečte z disku jen dva sloupce místo celé tabulky a stejnorodé hodnoty se výborně komprimují. Odtud ta rychlost na agregacích.

-- Oblíbený žánr sloupcové databáze (dialekt ClickHouse: toYYYYMM je jeho funkce)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Silné stránky: agregace a skenování miliard řádků, silná komprese.
• Slabé: bodové aktualizace a mazání jsou drahé; přečíst jeden řádek celý je pomalejší než v řádkové databázi; transakční zátěž — na tu nejsou určené.
• Produkty: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kdy vzít: analytika, reporty, události, logy, metriky — obvykle vedle «ostré» relační databáze.

Hned tu jsou i dva pojmy, které se na pohovorech mají v oblibě: OLTP (online transaction processing — mnoho krátkých operací zápisu a čtení, svět PostgreSQL) a OLAP (online analytical processing — těžká analytická čtení nad celou historií, svět ClickHouse). Produkt zapisuje do OLTP databáze, analytika čte OLAP kopii.

A poslední rodina — grafové DB

Když jsou vazby důležitější než samotné záznamy — «přátelé přátel», doručovací trasy, řetězce doporučení — sahá se po grafových DB (Neo4j, Memgraph). Data v nich jsou uzly (to jsou záznamy) a hrany (to jsou vazby mezi záznamy); procházení vazeb libovolné hloubky je rodná operace. V relační databázi je takové procházení žebřík ze spojení tabulek, který s hloubkou těžkne.

Mini-průvodce: jak vybrat databázi pro projekt

1. Začni otázkami, ne daty. Jaké dotazy bude produkt klást: bodové «podle klíče», vazební «kdo co koupil», analytické «kolik za měsíc»?
2. Ve výchozím stavu — relační. Provázaná data plus cena chyby (objednávky, platby, zůstatky) — to je PostgreSQL. Nejbezpečnější start skoro pro každý produkt.
3. Specializované databáze — na konkrétní úlohu, ne «do zásoby». Tlačí žhavá čtení — přidej cache na Redisu. Vyrostla analytika — replikuj události do ClickHouse. Divoká rozmanitost polí — nejdřív jsonb v PostgreSQL, a teprve když nestačí — dokumentová databáze.
4. Počítej s cenou druhé databáze. Každá nová DBMS znamená synchronizaci dat, zálohy, monitoring a další technologii, kterou tým musí udržovat.