Aké druhy databáz existujú

Cestou k súpisu QUERY pribrzdí pri tmavej sekcii úložiska. Za sklom — register archívov starej Zeme, ktoré neprežili Veľký zlom: cache-uzly zhasli prvé, dokumentové úložiská došli v roztrhaných útržkoch, analytické klastre mlčia celými sektormi. No relačná snímka «Kotomarketu» prežila celá — so všetkými väzbami.

Nielen relačné

Pre «Kotomarket» sa nám obzvlášť hodia relačné databázy: zákazníci, objednávky a tovary prirodzene zapadnú do tabuliek s väzbami. Práve im je venovaný kurz. No v odvetví — či už v roku 2024, alebo dnes — sa stretneš aj s inými prístupmi:

• kľúč-hodnota (Redis) — veľmi rýchly formát «kľúč → hodnota», keď treba okamžite vytiahnuť jednoduchý záznam;
• dokumentovo orientované (MongoDB) — uchovávajú flexibilné JSON dokumenty, kde sa štruktúra môže záznam od záznamu líšiť;
• stĺpcové (ClickHouse) — silné v analytike, keď treba rýchlo počítať ukazovatele nad obrovskými objemami dát.

Väčšina populárnych DBMS pre produktový vývoj zostáva relačná: PostgreSQL, MySQL, Oracle, MS SQL. Keď si tu osvojíš SQL, dokážeš sebavedomo čítať dáta vo veľmi rôznych firmách.

QUERY: Každému archívu jeho práca: jednému rýchlosť, druhému flexibilita, tretiemu analytika. My dvaja sme mali šťastie: dostali sme ten, v ktorom je všetko prepojené so všetký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.

Register rodín: rozobrané do detailov

Register za sklom je dôvod rozobrať rodiny databáz naozaj poriadne: «aké druhy databáz existujú a kedy ktorú zvoliť» je jedna z najčastejších otázok na pohovoroch. Prejdeme päť rodín za sebou a každú podľa rovnakej schémy: spôsob ukladania, silné a slabé stránky, produkty a kedy ju zvoliť.

Relačné databázy: prísna schéma a väzby

Spôsob ukladania: riadky v tabuľkách s vopred deklarovanou schémou — každý stĺpec má typ, medzi tabuľkami platia väzby cez kľúče a DBMS sama stráži integritu: objednávku od neexistujúceho zákazníka zapísať nepôjde. Zmeny sa vykonávajú transakciami so zárukami ACID — «objednávka + odpis zo skladu» sa buď zapíšu spolu, alebo vôbec.

• Silné stránky: výrazný jazyk SQL (filtre, spájanie tabuliek, agregáty), integrita na úrovni databázy, transakcie.
• Slabé: schému treba premyslieť vopred a pri zmenách migrovať; horizontálne škálovanie na mnoho serverov je ťažšie než pri rodinách NoSQL.
• Produkty: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kedy zvoliť: používatelia, objednávky, peniaze, sklad — všade, kde sú dáta prepojené a chyba zápisu je neprípustná. Pre nový produkt je to predvolená voľba.

Databázy kľúč-hodnota: slovník na maximálnej rýchlosti

Spôsob ukladania: jeden obrovský slovník «kľúč → hodnota», najčastejšie v operačnej pamäti. Žiadne tabuľky, žiadne väzby: vložil podľa kľúča — vytiahol podľa kľúča za zlomok milisekundy.

-- Toto nie je SQL, sú to príkazy Redisu
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Silné stránky: rýchlosť, jednoduchosť, ľahké škálovanie.
• Slabé: dotazy len podľa presného kľúča — otázku «nájdi všetky relácie zákazníkov z Moskvy» tomuto formátu nepoložíš; vnútro hodnoty je pre databázu nepriehľadné.
• Produkty: Redis, Memcached, Amazon DynamoDB.
• Kedy zvoliť: cache, relácie, počítadlá, fronty, rebríčky — horúce dáta vedľa hlavnej databázy, nie namiesto nej.

Dokumentové databázy: flexibilný JSON

Spôsob ukladania: záznamy sú JSON dokumenty zoskupené do kolekcií. Schéma sa nedeklaruje vopred: smart hodinky majú pole «výdrž batérie», mikina «tabuľku veľkostí» a oba dokumenty pokojne ležia v jednej kolekcii. Vnorené štruktúry sa uchovávajú priamo vnútri dokumentu, bez samostatných tabuliek.

• Silné stránky: flexibilná štruktúra, dokument sa prečíta celý jediným prístupom, hodí sa pre katalógy s rôznorodými atribútmi a rýchle prototypy.
• Slabé: väzby medzi dokumentmi sú starosťou aplikácie, plnohodnotný JOIN takmer nie je; bez disciplíny sa z kolekcie stane zverinec nekompatibilných formátov.
• Produkty: MongoDB, Couchbase, Firestore.
• Kedy zvoliť: obsah, katalógy so silno odlišnými poľami, profily a nastavenia.

Hranica medzi rodinami je mimochodom rozmazaná: PostgreSQL vie uchovávať dokumenty v stĺpci typu jsonb a budovať nad nimi indexy — to často pokryje «dokumentovú» potrebu bez druhej databázy:

-- Príklad mimo našej snímky: attrs — stĺpec typu jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Stĺpcové databázy: analytika nad miliardami riadkov

Spôsob ukladania: hodnoty neležia po riadkoch, ale po stĺpcoch: všetky ceny vedľa seba, všetky dátumy vedľa seba. Dotaz «priemerný účet po mesiacoch» číta z disku len dva stĺpce namiesto celej tabuľky a rovnaké hodnoty sa skvele komprimujú. Odtiaľ pochádza rýchlosť pri agregátoch.

-- Obľúbený žáner stĺpcovej databázy (dialekt ClickHouse: toYYYYMM je jeho funkcia)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Silné stránky: agregáty a skenovanie miliárd riadkov, silná kompresia.
• Slabé: bodové aktualizácie a mazania sú drahé; prečítať jeden riadok celý je pomalšie než v riadkovej databáze; transakčná záťaž — na takú záťaž nie sú určené.
• Produkty: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kedy zvoliť: analytika, reporty, udalosti, logy, metriky — zvyčajne vedľa «bojovej» relačnej databázy.

A hneď tu pár pojmov, ktoré majú na pohovoroch radi: OLTP (online transaction processing — veľa krátkych operácií zápisu a čítania, svet PostgreSQL) a OLAP (online analytical processing — ťažké analytické čítania naprieč celou históriou, svet ClickHouse). Produkt zapisuje do OLTP databázy, analytika číta OLAP kópiu.

A posledná rodina — grafové databázy

Keď sú väzby dôležitejšie než samotné záznamy — «priatelia priateľov», doručovacie trasy, reťazce odporúčaní — siahne sa po grafových databázach (Neo4j, Memgraph). Dáta v nich sú uzly (to sú záznamy) a hrany (to sú väzby medzi záznamami); prechod väzbami ľubovoľnej hĺbky je rodná operácia. V relačnej databáze je taký prechod schodisko zo spájania tabuliek, ktoré s hĺbkou ťažkne.

Mini-návod: ako vybrať databázu pre projekt

1. Začni otázkami, nie dátami. Aké dotazy bude produkt klásť: bodové «podľa kľúča», súvislé «kto čo kúpil», analytické «koľko za mesiac»?
2. Predvolene — relačná. Prepojené dáta plus cena chyby (objednávky, platby, zostatky) — to je PostgreSQL. Najbezpečnejší štart takmer pre každý produkt.
3. Špecializované databázy — na konkrétnu úlohu, nie «do zásoby». Tlačia horúce čítania — pridaj cache na Redise. Narástla analytika — replikuj udalosti do ClickHouse. Divoká rozmanitosť polí — najprv jsonb v PostgreSQL a až keď nebude stačiť — dokumentová databáza.
4. Počítaj cenu druhej databázy. Každá nová DBMS znamená synchronizáciu dát, zálohy, monitoring a ďalšiu technológiu, ktorú musí tím udržiavať.