Hvilke slags databaser findes der

På vej mod indekset bremser QUERY op ved en mørk sektion af hvælvingen. Bag glasset ligger registret over den gamle Jords arkiver, som ikke overlevede Den Store Adskillelse: cache-knuderne gik først i sort, dokumentlagrene nåede frem som flossede fragmenter, de analytiske klynger tier hen over hele sektorer. Men det relationelle Kotomarket-snapshot overlevede helt — med alle forbindelser i behold.

Ikke kun relationelle

Til Kotomarket er relationelle databaser særligt praktiske for os: kunder, ordrer og varer falder naturligt ind i tabeller med forbindelser imellem. Det er netop dem, kurset handler om. Men i branchen — både i 2024 og nu — støder man også på andre tilgange:

• nøgle-værdi (Redis) — et lynhurtigt format »nøgle → værdi«, når du øjeblikkeligt skal hente en enkel post;
• dokumentorienterede (MongoDB) — gemmer fleksible JSON-dokumenter, hvor strukturen kan være forskellig fra post til post;
• kolonnebaserede (ClickHouse) — stærke til analyse, når du hurtigt skal regne nøgletal ud på enorme datamængder.

De fleste populære databasesystemer til produktudvikling er fortsat relationelle: PostgreSQL, MySQL, Oracle, MS SQL. Lærer du SQL her, kan du trygt læse data i vidt forskellige virksomheder.

QUERY: Hvert arkiv har sin egen opgave: ét går efter fart, et andet efter fleksibilitet, et tredje efter analyse. Vi to var heldige: vi fik det, hvor alt er forbundet med alt.

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.

Familieregistret: orden i tingene

Registret bag glasset er en god anledning til at tage databasefamilierne alvorligt: »hvilke slags databaser findes der, og hvornår vælger man hvilken« er et af de hyppigste spørgsmål til jobsamtaler. Vi går de fem familier igennem på stribe, og hver beskrives på samme måde: lagringsmåde, stærke og svage sider, produkter, og hvornår man vælger den.

Relationelle databaser: et stramt skema og forbindelser

Lagringsmåde: rækker i tabeller med et skema, der er erklæret på forhånd — hver kolonne har en type, mellem tabellerne gælder forbindelser via nøgler, og DBMS'en vogter selv integriteten: en ordre fra en ikke-eksisterende kunde kan ikke registreres. Ændringer udføres som transaktioner med ACID-garantier — »ordre + fratrækning af lagerbeholdning« skrives enten sammen eller slet ikke.

• Stærke sider: udtryksfuld SQL (filtre, sammenføjninger af tabeller, aggregater), integritet på databaseniveau, transaktioner.
• Svage: skemaet skal gennemtænkes på forhånd og migreres ved ændringer; vandret skalering over mange servere er sværere end for NoSQL-familierne.
• Produkter: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Hvornår man vælger den: brugere, ordrer, penge, lager — overalt, hvor dataene er forbundne, og en fejlskrivning er uacceptabel. Til et nyt produkt er det standardvalget.

Nøgle-værdi-databaser: en ordbog ved topfart

Lagringsmåde: én gigantisk ordbog »nøgle → værdi«, oftest i arbejdshukommelsen. Hverken tabeller eller forbindelser: lagt ind efter nøgle — hentet ud efter nøgle på brøkdele af et millisekund.

-- Det er ikke SQL, det er Redis-kommandoer
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Stærke sider: fart, enkelhed, let skalering.
• Svage: forespørgsler kun via en præcis nøgle — spørgsmålet »find alle sessioner for kunder fra Moskva« kan man ikke stille dette format; værdiens indre er ugennemsigtigt for databasen.
• Produkter: Redis, Memcached, Amazon DynamoDB.
• Hvornår man vælger den: cache, sessioner, tællere, køer, ratings — varme data ved siden af hoveddatabasen, ikke i stedet for den.

Dokumentdatabaser: fleksibel JSON

Lagringsmåde: poster er JSON-dokumenter samlet i kollektioner. Skemaet erklæres ikke på forhånd: et smartur har et felt »batteritid«, en hættetrøje har en »størrelsesguide«, og begge dokumenter ligger uden problemer i den samme kollektion. Indlejrede strukturer gemmes lige inde i dokumentet, uden separate tabeller.

• Stærke sider: fleksibel struktur, et dokument læses helt i én opslag, praktisk til kataloger med uensartede attributter og til hurtige prototyper.
• Svage: forbindelser mellem dokumenter er programmets ansvar, fuldgyldige JOIN findes næsten ikke; uden disciplin bliver en kollektion til en zoologisk have af uforenelige formater.
• Produkter: MongoDB, Couchbase, Firestore.
• Hvornår man vælger den: indhold, kataloger med vidt forskellige felter, profiler og indstillinger.

Grænsen mellem familierne er i øvrigt udvisket: PostgreSQL kan gemme dokumenter i en kolonne af typen jsonb og bygge indekser over dem — det dækker ofte et »dokument«-behov uden en database nummer to:

-- Et eksempel uden for vores snapshot: attrs — en kolonne af typen jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Kolonnebaserede databaser: analyse over milliarder af rækker

Lagringsmåde: værdierne ligger ikke rækkevis, men kolonnevis: alle priser ved siden af hinanden, alle datoer ved siden af hinanden. En forespørgsel »gennemsnitlig ordrestørrelse pr. måned« læser kun to kolonner fra disken i stedet for hele tabellen, og ensartede værdier komprimeres fremragende. Deraf farten på aggregater.

-- Kolonnedatabasens yndlingsgenre (ClickHouse-dialekt: toYYYYMM — dens funktion)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Stærke sider: aggregater og scanninger over milliarder af rækker, kraftig komprimering.
• Svage: punktvise opdateringer og sletninger er dyre; at læse én hel række er langsommere end i en rækkebaseret database; transaktionsbelastning — det er de ikke beregnet til.
• Produkter: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Hvornår man vælger den: analyse, rapporter, hændelser, logs, metrikker — som regel ved siden af den »kørende« relationelle database.

Her er også et par begreber, man holder af til jobsamtaler: OLTP (online transaction processing — mange korte skrive- og læseoperationer, PostgreSQL's verden) og OLAP (online analytical processing — tunge analytiske læsninger over hele historikken, ClickHouses verden). Produktet skriver til OLTP-databasen, analysen læser fra en OLAP-kopi.

Og den sidste familie — grafdatabaser

Når forbindelserne er vigtigere end posterne selv — »venners venner«, leveringsruter, anbefalingskæder — griber man til grafdatabaser (Neo4j, Memgraph). Dataene i dem er knuder (det er poster) og kanter (det er forbindelser mellem poster); at gennemløbe forbindelser af enhver dybde er en indbygget operation. I en relationel database er et sådant gennemløb en trappe af sammenføjninger, der bliver tungere med dybden.

Miniguide: sådan vælger du database til projektet

1. Begynd med spørgsmålene, ikke med dataene. Hvilke forespørgsler kommer produktet til at stille: punktvise »via nøgle«, forbundne »hvem købte hvad«, analytiske »hvor meget på en måned«?
2. Som standard — relationel. Forbundne data plus prisen for en fejl (ordrer, betalinger, lagerbeholdning) — det er PostgreSQL. Den sikreste start for næsten ethvert produkt.
3. Specialiserede databaser — til en konkret opgave, ikke »på lager«. Klemmer de varme læsninger — tilføj en cache på Redis. Er analysen vokset — replikér hændelserne til ClickHouse. Vild variation i felterne — først jsonb i PostgreSQL, og kun når det ikke længere slår til — en dokumentdatabase.
4. Regn prisen for en database nummer to. Hver ny DBMS er datasynkronisering, backups, overvågning og endnu en teknologi, som teamet skal vedligeholde.