Koje vrste baza podataka postoje

Na putu do popisa QUERY usporava kraj tamne sekcije spremišta. Iza stakla je registar arhiva stare Zemlje koji nisu preživjeli Veliki Lom: predmemorijski čvorovi ugasili su se prvi, dokumentna spremišta stigla su u poderanim ulomcima, analitički klasteri šute u čitavim sektorima. A relacijska snimka Kotomarketa preživjela je u cijelosti — sa svim vezama.

Ne samo relacijske

Za Kotomarket osobito su nam zgodne relacijske baze: kupci, narudžbe i proizvodi prirodno se slažu u tablice s vezama. Upravo su njima posvećene ove lekcije. No u industriji — i 2024. i danas — susreću se i drugi pristupi:

• ključ-vrijednost (Redis) — vrlo brz format „ključ → vrijednost”, kad jednostavan zapis treba dohvatiti istog trena;
• dokumentno orijentirane (MongoDB) — čuvaju fleksibilne JSON dokumente, u kojima se struktura može razlikovati od zapisa do zapisa;
• stupčane (ClickHouse) — snažne u analitici, kad treba brzo izračunati pokazatelje nad golemim količinama podataka.

Većina popularnih DBMS-ova za razvoj proizvoda ostaje relacijska: PostgreSQL, MySQL, Oracle, MS SQL. Svladaš li SQL ovdje, moći ćeš pouzdano čitati podatke u vrlo različitim tvrtkama.

QUERY: Svakom arhivu svoj posao: jednima brzina, drugima fleksibilnost, trećima analitika. Tebi i meni se posrećilo: zapao nas je onaj u kojem je sve povezano sa svime.

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.

Registar obitelji: redom na police

Registar iza stakla povod je da se obitelji baza podataka razlože ozbiljno: „koje vrste baza postoje i kad koju uzeti” jedno je od najčešćih pitanja na razgovorima za posao. Proći ćemo kroz pet obitelji zaredom, a svaku po istoj shemi: način pohrane, jake i slabe strane, proizvodi i kad je uzeti.

Relacijske baze: stroga shema i veze

Način pohrane: redci u tablicama s unaprijed objavljenom shemom — svaki stupac ima tip, među tablicama vrijede veze po ključevima, a DBMS sam čuva cjelovitost: narudžbu od nepostojećeg kupca neće biti moguće zapisati. Izmjene se izvršavaju transakcijama s ACID jamstvima — „narudžba + otpis zalihe” ili se zapišu zajedno ili se ne zapišu uopće.

• Jake strane: izražajan SQL (filtri, spajanja tablica, agregati), cjelovitost na razini baze, transakcije.
• Slabe: shemu treba osmisliti unaprijed i migrirati pri izmjenama; horizontalno skaliranje na mnogo poslužitelja teže ide nego kod NoSQL obitelji.
• Proizvodi: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kad je uzeti: korisnici, narudžbe, novac, skladište — svugdje gdje su podaci povezani i pogreška pri zapisivanju nije dopuštena. Za novi proizvod to je zadani izbor.

Baze ključ-vrijednost: rječnik na najvećoj brzini

Način pohrane: jedan golemi rječnik „ključ → vrijednost”, najčešće u radnoj memoriji. Ni tablica ni veza: spremiš po ključu — dohvatiš po ključu u djeliću milisekunde.

-- Ovo nije SQL, ovo su naredbe Redisa
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Jake strane: brzina, jednostavnost, lako skaliranje.
• Slabe: upiti samo po točnom ključu — pitanje „nađi sve sesije kupaca iz Moskve” ovom se formatu ne može postaviti; nutrina vrijednosti za bazu je neprozirna.
• Proizvodi: Redis, Memcached, Amazon DynamoDB.
• Kad je uzeti: predmemorija, sesije, brojači, redovi, ljestvice — vrući podaci uz glavnu bazu, a ne umjesto nje.

Dokumentne baze: fleksibilan JSON

Način pohrane: zapisi su JSON dokumenti grupirani u kolekcije. Shema se ne objavljuje unaprijed: pametni sat ima polje „trajanje baterije”, hudica ima „tablicu veličina”, i oba dokumenta mirno leže u istoj kolekciji. Ugniježđene strukture čuvaju se izravno unutar dokumenta, bez zasebnih tablica.

• Jake strane: fleksibilna struktura, dokument se cijeli čita jednim dohvatom, zgodno za kataloge s raznorodnim atributima i za brze prototipe.
• Slabe: veze među dokumentima briga su aplikacije, punopravnog JOIN-a gotovo da nema; bez discipline se kolekcija pretvori u zoološki vrt nespojivih formata.
• Proizvodi: MongoDB, Couchbase, Firestore.
• Kad je uzeti: sadržaj, katalozi s vrlo različitim poljima, profili i postavke.

Granica među obiteljima, usput, mutna je: PostgreSQL zna čuvati dokumente u stupcu tipa jsonb i graditi indekse nad njima — često to pokriva „dokumentnu” potrebu bez druge baze:

-- Primjer izvan naše snimke: attrs — stupac tipa jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Stupčane baze: analitika nad milijardama redaka

Način pohrane: vrijednosti ne leže po retku, nego po stupcu: sve cijene — jedna uz drugu, svi datumi — jedan uz drugi. Upit „prosječan iznos po mjesecima” čita s diska samo dva stupca umjesto cijele tablice, a istovrsne se vrijednosti izvrsno sažimaju. Otud brzina na agregatima.

-- Omiljeni žanr stupčane baze (dijalekt ClickHousea: toYYYYMM — njegova funkcija)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Jake strane: agregati i skeniranje milijardi redaka, snažno sažimanje.
• Slabe: točkasta ažuriranja i brisanja skupa su; pročitati jedan redak u cijelosti — sporije je nego u retčanoj bazi; transakcijsko opterećenje — za takvo opterećenje nisu namijenjene.
• Proizvodi: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kad je uzeti: analitika, izvještaji, događaji, dnevnici, metrike — obično uz „borbenu” relacijsku bazu.

Tu su i dva pojma koja se vole na razgovorima za posao: OLTP (online transaction processing — mnogo kratkih operacija zapisivanja i čitanja, svijet PostgreSQL-a) i OLAP (online analytical processing — teška analitička čitanja po cijeloj povijesti, svijet ClickHousea). Proizvod piše u OLTP bazu, a analitika čita OLAP kopiju.

I posljednja obitelj — grafovske baze

Kad su veze važnije od samih zapisa — „prijatelji prijatelja”, dostavni pravci, lanci preporuka — uzimaju se grafovske baze (Neo4j, Memgraph). Podaci su u njima čvorovi (to su zapisi) i bridovi (to su veze među zapisima); obilazak veza bilo koje dubine prirodna je operacija. U relacijskoj bazi takav obilazak su ljestve od spajanja tablica koje s dubinom postaju sve teže.

Mini-vodič: kako odabrati bazu za projekt

1. Kreni od pitanja, a ne od podataka. Koje će upite postavljati proizvod: točkaste „po ključu”, vezane „tko je što kupio”, analitičke „koliko za mjesec”?
2. Po zadanome — relacijska. Povezani podaci plus cijena pogreške (narudžbe, plaćanja, zalihe) — to je PostgreSQL. Najsigurniji početak gotovo za svaki proizvod.
3. Specijalizirane baze — za konkretan zadatak, a ne „za svaki slučaj”. Pritišću li vruća čitanja — dodaj predmemoriju na Redisu. Narasla je analitika — repliciraj događaje u ClickHouse. Divlja raznolikost polja — najprije jsonb u PostgreSQL-u, a tek kad on ne bude dovoljan — dokumentna baza.
4. Računaj cijenu druge baze. Svaki novi DBMS znači sinkronizaciju podataka, sigurnosne kopije, nadzor i još jednu tehnologiju koju tim mora održavati.