Kakšne so podatkovne baze

Na poti do popisa QUERY zavre pri zatemnjenem oddelku shrambe. Za steklom je register arhivov stare Zemlje, ki niso preživeli Velikega preloma: predpomnilniška vozlišča so ugasnila prva, dokumentne shrambe so prispele kot raztrgani drobci, analitične gruče molčijo cele sektorje. Relacijski posnetek Kotomarketa pa je preživel v celoti — z vsemi povezavami.

Ne le relacijske

Za Kotomarket so nam še posebej priročne relacijske baze: kupci, naročila in izdelki se naravno uležejo v tabele s povezavami. Prav njim je posvečen tečaj. A v industriji — tako leta 2024 kot zdaj — srečaš tudi druge pristope:

• ključ-vrednost (Redis) — zelo hitra oblika »ključ → vrednost«, ko moraš v hipu izvleči preprost zapis;
• dokumentno usmerjene (MongoDB) — hranijo prilagodljive dokumente JSON, kjer se struktura lahko razlikuje od zapisa do zapisa;
• stolpčne (ClickHouse) — močne v analitiki, ko moraš hitro računati kazalnike po ogromnih količinah podatkov.

Večina priljubljenih DBMS-ov za produktni razvoj ostaja relacijskih: PostgreSQL, MySQL, Oracle, MS SQL. Če osvojiš SQL tukaj, boš znal samozavestno brati podatke v zelo različnih podjetjih.

QUERY: Vsak arhiv ima svojo nalogo: enemu hitrost, drugemu prilagodljivost, tretjemu analitiko. Midva sva imela srečo: pripadel nama je tisti, v katerem je vse povezano z vsem.

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 družin: razvrščeno po policah

Register za steklom je dober povod, da resno razčlenimo družine podatkovnih baz: »kakšne baze obstajajo in kdaj katero vzeti« je eno najpogostejših vprašanj na razgovorih. Šli bomo skozi pet družin zapored in vsako po isti shemi: način shranjevanja, prednosti in slabosti, izdelki in kdaj jo vzeti.

Relacijske baze: stroga shema in povezave

Način shranjevanja: vrstice v tabelah z vnaprej objavljeno shemo — vsak stolpec ima tip, med tabelami veljajo povezave prek ključev, celovitost pa varuje DBMS sam: naročila od neobstoječega kupca ne bo mogoče zapisati. Spremembe se izvajajo kot transakcije z jamstvi ACID — »naročilo + odpis zaloge« se bodisi zapišeta skupaj bodisi sploh ne.

• Prednosti: izrazni SQL (filtri, spajanja tabel, agregati), celovitost na ravni baze, transakcije.
• Slabosti: shemo je treba premisliti vnaprej in jo ob spremembah migrirati; vodoravno skaliranje na več strežnikov je težje kot pri družinah NoSQL.
• Izdelki: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kdaj vzeti: uporabniki, naročila, denar, skladišče — povsod, kjer so podatki povezani in je napaka pri zapisu nedopustna. Za nov produkt je to privzeta izbira.

Baze ključ-vrednost: slovar pri najvišji hitrosti

Način shranjevanja: en orjaški slovar »ključ → vrednost«, najpogosteje v delovnem pomnilniku. Ne tabel ne povezav: vstaviš po ključu — izvlečeš po ključu v delčku milisekunde.

-- To ni SQL, to so ukazi Redisa
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Prednosti: hitrost, preprostost, lahkotno skaliranje.
• Slabosti: poizvedbe le po točnem ključu — vprašanja »najdi vse seje kupcev iz Moskve« tej obliki ne moreš zastaviti; notranjost vrednosti je za bazo nepregledna.
• Izdelki: Redis, Memcached, Amazon DynamoDB.
• Kdaj vzeti: predpomnilnik, seje, števci, vrste, lestvice — vroči podatki ob glavni bazi, ne namesto nje.

Dokumentne baze: prilagodljiv JSON

Način shranjevanja: zapisi so dokumenti JSON, združeni v zbirke. Shema ni objavljena vnaprej: pametna ura ima polje »čas delovanja baterije«, hudica »tabelo velikosti«, in oba dokumenta mirno ležita v isti zbirki. Gnezdene strukture se hranijo kar znotraj dokumenta, brez ločenih tabel.

• Prednosti: prilagodljiva struktura, dokument se prebere v celoti z enim dostopom, primerno za kataloge z raznorodnimi atributi in za hitre prototipe.
• Slabosti: povezave med dokumenti so skrb aplikacije, pravih JOIN-ov skoraj ni; brez discipline se zbirka spremeni v živalski vrt nezdružljivih oblik.
• Izdelki: MongoDB, Couchbase, Firestore.
• Kdaj vzeti: vsebine, katalogi z močno različnimi polji, profili in nastavitve.

Meja med družinami je, mimogrede, zabrisana: PostgreSQL zna hraniti dokumente v stolpcu tipa jsonb in nad njimi graditi indekse — pogosto to pokrije »dokumentno« potrebo brez druge baze:

-- Primer zunaj našega posnetka: attrs — stolpec tipa jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Stolpčne baze: analitika po milijardah vrstic

Način shranjevanja: vrednosti ne ležijo po vrsticah, ampak po stolpcih: vse cene — skupaj, vsi datumi — skupaj. Poizvedba »povprečen znesek po mesecih« z diska prebere le dva stolpca namesto cele tabele, istovrstne vrednosti pa se odlično stisnejo. Od tod hitrost pri agregatih.

-- Najljubši žanr stolpčne baze (dialekt ClickHouse: toYYYYMM — njegova funkcija)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Prednosti: agregati in pregledovanje milijard vrstic, močno stiskanje.
• Slabosti: točkovne posodobitve in brisanja so draga; prebrati eno vrstico v celoti je počasneje kot v vrstični bazi; za transakcijsko obremenitev preprosto niso namenjene.
• Izdelki: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kdaj vzeti: analitika, poročila, dogodki, dnevniki, metrike — običajno ob »bojni« relacijski bazi.

Tu pa še dva izraza, ki ju na razgovorih obožujejo: OLTP (online transaction processing — veliko kratkih operacij zapisa in branja, svet PostgreSQL) in OLAP (online analytical processing — težka analitična branja po vsej zgodovini, svet ClickHouse). Produkt piše v bazo OLTP, analitika bere kopijo OLAP.

In zadnja družina — grafovske baze

Kadar so povezave pomembnejše od samih zapisov — »prijatelji prijateljev«, dostavne poti, verige priporočil — vzamemo grafovske baze (Neo4j, Memgraph). Podatki v njih so vozlišča (to so zapisi) in povezave (to so vezi med zapisi); obhod povezav poljubne globine je domača operacija. V relacijski bazi je tak obhod stopnišče iz spajanj tabel, ki z globino postaja vse težje.

Mini vodič: kako izbrati bazo za projekt

1. Začni z vprašanji, ne s podatki. Kakšne poizvedbe bo zastavljal produkt: točkovne »po ključu«, povezovalne »kdo je kaj kupil«, analitične »koliko na mesec«?
2. Privzeto — relacijska. Povezani podatki plus cena napake (naročila, plačila, zaloge) — to je PostgreSQL. Najvarnejši začetek za skoraj vsak produkt.
3. Specializirane baze — za konkretno nalogo, ne »za zalogo«. Pritiskajo vroča branja — dodaj predpomnilnik na Redisu. Zrasla je analitika — repliciraj dogodke v ClickHouse. Divja raznolikost polj — najprej jsonb v PostgreSQL, in šele ko ta ne zadošča — dokumentna baza.
4. Računaj ceno druge baze. Vsak nov DBMS pomeni sinhronizacijo podatkov, varnostne kopije, nadzor in še eno tehnologijo, ki jo mora ekipa vzdrževati.