Vilka sorters databaser finns det

På vägen till förteckningen saktar QUERY in vid en mörklagd sektion av valvet. Bakom glaset finns ett register över det gamla Jordens arkiv som inte överlevde Stora Bristningen: cache-noderna slocknade först, dokumentförråden anlände som trasiga fragment, de analytiska klustren tiger över hela sektorer. Men den relationella ögonblicksbilden av «Kotomarket» överlevde i sin helhet — med alla kopplingar intakta.

Inte bara relationella

För «Kotomarket» passar relationsdatabaser oss särskilt bra: köpare, ordrar och varor faller naturligt in i tabeller med kopplingar mellan sig. Det är dem kursen handlar om. Men i branschen — såväl 2024 som idag — stöter man också på andra ansatser:

• nyckel-värde (Redis) — ett blixtsnabbt format «nyckel → värde», när man behöver hämta en enkel post på direkten;
• dokumentorienterade (MongoDB) — lagrar flexibla JSON-dokument, där strukturen kan skilja sig från post till post;
• kolumnära (ClickHouse) — starka på analys, när man snabbt behöver räkna fram nyckeltal över enorma datamängder.

De flesta populära DBMS för produktutveckling förblir relationella: PostgreSQL, MySQL, Oracle, MS SQL. Lär du dig SQL här kan du tryggt läsa data på väldigt olika företag.

QUERY: Varje arkiv har sitt eget jobb: ett prisar hastighet, ett annat flexibilitet, ett tredje analys. Du och jag hade tur: vi ärvde det där allt hänger ihop med allt.

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.

Familjeregistret: ordnat på hyllorna

Registret bakom glaset är en god ursäkt att gå igenom databasfamiljerna på allvar: «vilka sorters databaser finns det och när väljer man vilken» är en av de vanligaste intervjufrågorna. Vi går igenom fem familjer i rad, var och en efter samma mall: lagringssätt, styrkor och svagheter, produkter och när man väljer den.

Relationella databaser: strikt schema och kopplingar

Lagringssätt: rader i tabeller med ett i förväg deklarerat schema — varje kolumn har en typ, mellan tabellerna gäller kopplingar via nycklar, och DBMS:et vakar självt över integriteten: en order från en köpare som inte finns går inte att skriva in. Ändringar körs som transaktioner med ACID-garantier — «order + avdrag från lagersaldot» skrivs antingen tillsammans eller inte alls.

• Styrkor: uttrycksfull SQL (filter, tabellsammanfogningar, aggregat), integritet på databasnivå, transaktioner.
• Svagheter: schemat måste tänkas igenom i förväg och migreras vid ändringar; horisontell skalning över många servrar är svårare än för NoSQL-familjerna.
• Produkter: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• När man väljer den: användare, ordrar, pengar, lager — överallt där data hänger ihop och en felaktig skrivning är oacceptabel. För en ny produkt är det standardvalet.

Nyckel-värde-databaser: en ordbok i toppfart

Lagringssätt: en enda gigantisk ordbok «nyckel → värde», oftast i arbetsminnet. Inga tabeller, inga kopplingar: lade in via nyckel — hämtade via nyckel på bråkdelen av en millisekund.

-- Det här är inte SQL, det är Redis-kommandon
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Styrkor: hastighet, enkelhet, lätt att skala.
• Svagheter: frågor bara via exakt nyckel — frågan «hitta alla sessioner för köpare i Moskva» går inte att ställa till det här formatet; värdets insida är ogenomskinlig för databasen.
• Produkter: Redis, Memcached, Amazon DynamoDB.
• När man väljer den: cache, sessioner, räknare, köer, topplistor — heta data bredvid huvuddatabasen, inte i stället för den.

Dokumentdatabaser: flexibel JSON

Lagringssätt: posterna är JSON-dokument grupperade i samlingar. Schemat deklareras inte i förväg: en smartklocka har ett fält «batteritid», en hoodie har ett «storleksdiagram», och båda dokumenten ligger lugnt i samma samling. Nästlade strukturer lagras direkt inuti dokumentet, utan separata tabeller.

• Styrkor: flexibel struktur, ett dokument läses i sin helhet med en enda hämtning, behändigt för kataloger med heterogena attribut och för snabba prototyper.
• Svagheter: kopplingar mellan dokument är applikationens ansvar, fullvärdiga JOIN finns nästan inte; utan disciplin förvandlas en samling till en djurpark av oförenliga format.
• Produkter: MongoDB, Couchbase, Firestore.
• När man väljer den: innehåll, kataloger med kraftigt skiftande fält, profiler och inställningar.

Gränsen mellan familjerna är förresten suddig: PostgreSQL kan lagra dokument i en kolumn av typen jsonb och bygga index över dem — ofta täcker det ett «dokumentartat» behov utan en andra databas:

-- Ett exempel utanför vår ögonblicksbild: attrs — en kolumn av typen jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Kolumnära databaser: analys över miljarder rader

Lagringssätt: värdena ligger inte rad för rad, utan per kolumn: alla priser bredvid varandra, alla datum bredvid varandra. Frågan «genomsnittlig orderstorlek per månad» läser bara två kolumner från disken i stället för hela tabellen, och likartade värden komprimeras utmärkt. Därav hastigheten på aggregat.

-- Den kolumnära databasens favoritgenre (ClickHouse-dialekt: toYYYYMM — dess funktion)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Styrkor: aggregat och svep över miljarder rader, kraftig komprimering.
• Svagheter: punktvisa uppdateringar och borttagningar är dyra; att läsa en hel rad är långsammare än i en radbaserad databas; transaktionell last — för sådan last är de helt enkelt inte byggda.
• Produkter: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• När man väljer den: analys, rapporter, händelser, loggar, mätvärden — vanligen bredvid den «skarpa» relationsdatabasen.

Här passar två termer som intervjuare gärna tar upp: OLTP (online transaction processing — många korta skrivningar och läsningar, PostgreSQL:s värld) och OLAP (online analytical processing — tunga analytiska läsningar över hela historiken, ClickHouse:s värld). Produkten skriver till OLTP-databasen, analysen läser en OLAP-kopia.

Och den sista familjen — grafdatabaser

När kopplingarna är viktigare än posterna själva — «vänners vänner», leveransrutter, rekommendationskedjor — tar man grafdatabaser (Neo4j, Memgraph). Data i dem är noder (det är posterna) och kanter (det är kopplingarna mellan posterna); att traversera kopplingar på vilket djup som helst är en inbyggd operation. I en relationsdatabas är samma traversering en trappa av tabellsammanfogningar som blir tyngre för varje nivå.

Miniguide: hur du väljer databas för ett projekt

1. Börja med frågorna, inte med data. Vilka frågor kommer produkten att ställa: punktvisa «via nyckel», relaterade «vem köpte vad», analytiska «hur mycket på en månad»?
2. Som standard — relationell. Sammanlänkade data plus kostnaden för ett fel (ordrar, betalningar, lagersaldon) — det är PostgreSQL. Den tryggaste starten för nästan vilken produkt som helst.
3. Specialiserade databaser — till en konkret uppgift, inte «i reserv». Pressas de heta läsningarna — lägg till en cache på Redis. Växte analysen — replikera händelser till ClickHouse. Vild variation i fälten — först jsonb i PostgreSQL, och först när det inte räcker — en dokumentdatabas.
4. Räkna in priset för en andra databas. Varje nytt DBMS innebär datasynkronisering, säkerhetskopior, övervakning och ännu en teknik som teamet ska underhålla.