Millaisia tietokantoja on olemassa

Matkalla luetteloa kohti QUERY hidastaa arkiston pimeän osaston kohdalla. Lasin takana on vanhan Maan arkistojen rekisteri – niiden, jotka eivät selvinneet Suuresta Katkoksesta: välimuistisolmut sammuivat ensimmäisinä, dokumenttivarastot saapuivat repaleisina sirpaleina, analyyttiset klusterit vaikenevat kokonaisten sektoreiden verran. Mutta Kotomarketin relaatiovedos säilyi kokonaisena – kaikkine yhteyksineen.

Ei pelkästään relaatiotietokantoja

Kotomarketille relaatiotietokannat sopivat erityisen hyvin: ostajat, tilaukset ja tuotteet asettuvat luontevasti tauluihin yhteyksineen. Juuri niistä tämä kurssi kertoo. Mutta alalla – niin vuonna 2024 kuin nytkin – tapaa muitakin lähestymistapoja:

• avain-arvo (Redis) – erittäin nopea muoto ”avain → arvo”, kun yksinkertainen tietue pitää saada hetkessä;
• dokumenttipohjaiset (MongoDB) – säilyttävät joustavia JSON-dokumentteja, joiden rakenne voi vaihdella tietueesta toiseen;
• sarakemuotoiset (ClickHouse) – vahvoja analytiikassa, kun mittareita pitää laskea nopeasti valtavista datamääristä.

Suurin osa tuotekehityksen suosituista DBMS:istä pysyy relaatiopohjaisina: PostgreSQL, MySQL, Oracle, MS SQL. Kun opit SQL:n täällä, osaat lukea dataa varmasti hyvin erilaisissa yrityksissä.

QUERY: Jokaisella arkistolla on oma työnsä: yksi tarjoaa nopeutta, toinen joustavuutta, kolmas analytiikkaa. Meillä kävi tuuri: meille jäi se, jossa kaikki liittyy kaikkeen.

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.

Perheiden rekisteri: kaikki kohdilleen

Lasin takana oleva rekisteri on hyvä tilaisuus käydä tietokantaperheet läpi tosissaan: ”millaisia tietokantoja on ja milloin mikäkin valitaan” on yksi yleisimmistä haastattelukysymyksistä. Käymme viisi perhettä läpi peräkkäin, ja jokaisesta saman kaavan mukaan: tallennustapa, vahvuudet ja heikkoudet, tuotteet ja milloin valita.

Relaatiotietokannat: tiukka skeema ja yhteydet

Tallennustapa: rivejä tauluissa, joiden skeema on julistettu etukäteen – jokaisella sarakkeella on tyyppi, taulujen välillä on yhteyksiä avainten kautta, ja DBMS vartioi eheyttä itse: tilausta olemattomalta ostajalta ei voi kirjata. Muutokset ajetaan transaktioina ACID-takeineen – ”tilaus + saldon vähennys” joko kirjoitetaan yhdessä tai ei lainkaan.

• Vahvuudet: ilmaisuvoimainen SQL (suodattimet, taulujen liitokset, aggregaatit), eheys tietokannan tasolla, transaktiot.
• Heikkoudet: skeema pitää miettiä etukäteen ja migroida muutosten yhteydessä; vaakasuora skaalaus monelle palvelimelle on vaikeampaa kuin NoSQL-perheillä.
• Tuotteet: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Milloin valita: käyttäjät, tilaukset, raha, varasto – kaikkialla, missä data on yhteydessä toisiinsa ja virheellinen kirjoitus on mahdoton. Uudelle tuotteelle tämä on oletusvalinta.

Avain-arvo-tietokannat: sanakirja täydellä vauhdilla

Tallennustapa: yksi jättimäinen sanakirja ”avain → arvo”, useimmiten keskusmuistissa. Ei tauluja, ei yhteyksiä: panit avaimella sisään – haet avaimella ulos sekunnin murto-osassa.

-- Tämä ei ole SQL, nämä ovat Redis-komentoja
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Vahvuudet: nopeus, yksinkertaisuus, helppo skaalaus.
• Heikkoudet: kyselyt vain tarkalla avaimella – kysymystä ”etsi kaikki Moskovan ostajien istunnot” ei tälle muodolle voi esittää; arvon sisältö on tietokannalle läpinäkymätön.
• Tuotteet: Redis, Memcached, Amazon DynamoDB.
• Milloin valita: välimuisti, istunnot, laskurit, jonot, tulostaulut – kuumaa dataa päätietokannan vierellä, ei sen sijasta.

Dokumenttitietokannat: joustava JSON

Tallennustapa: tietueet ovat JSON-dokumentteja, jotka on ryhmitelty kokoelmiin. Skeemaa ei julisteta etukäteen: älykellolla on kenttä ”akun kesto”, hupparilla ”kokotaulukko”, ja molemmat dokumentit makaavat rauhassa samassa kokoelmassa. Sisäkkäiset rakenteet säilytetään suoraan dokumentin sisällä, ilman erillisiä tauluja.

• Vahvuudet: joustava rakenne, dokumentti luetaan kokonaan yhdellä haulla, kätevä luetteloille, joissa on erilaisia attribuutteja, ja nopeisiin prototyyppeihin.
• Heikkoudet: dokumenttien väliset yhteydet ovat sovelluksen huolena, täysiveristä JOINia ei juuri ole; ilman kuria kokoelmasta tulee yhteensopimattomien muotojen eläintarha.
• Tuotteet: MongoDB, Couchbase, Firestore.
• Milloin valita: sisältö, luettelot, joissa on hyvin erilaisia kenttiä, profiilit ja asetukset.

Perheiden raja on muuten häilyvä: PostgreSQL osaa säilyttää dokumentteja jsonb-tyyppisessä sarakkeessa ja rakentaa niille indeksejä – usein tämä kattaa ”dokumenttimaisen” tarpeen ilman toista tietokantaa:

-- Esimerkki vedoksemme ulkopuolelta: attrs on jsonb-tyyppinen sarake
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Sarakemuotoiset tietokannat: analytiikkaa miljardeista riveistä

Tallennustapa: arvot eivät ole riveittäin vaan sarakkeittain: kaikki hinnat vierekkäin, kaikki päivämäärät vierekkäin. Kysely ”keskiostos kuukausittain” lukee levyltä vain kaksi saraketta koko taulun sijaan, ja samantyyppiset arvot pakkautuvat erinomaisesti. Siitä syntyy nopeus aggregaateissa.

-- Sarakemuotoisen tietokannan lempilaji (ClickHouse-murre: toYYYYMM on sen funktio)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Vahvuudet: aggregaatit ja miljardien rivien skannaus, voimakas pakkaus.
• Heikkoudet: täsmälliset päivitykset ja poistot ovat kalliita; yhden rivin lukeminen kokonaan on hitaampaa kuin riviperustaisessa tietokannassa; transaktiokuormaa varten niitä ei ole tarkoitettu.
• Tuotteet: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Milloin valita: analytiikka, raportit, tapahtumat, lokit, mittarit – yleensä ”tuotannon” relaatiotietokannan vierellä.

Tässä samalla pari termiä, joista haastatteluissa pidetään: OLTP (online transaction processing – paljon lyhyitä kirjoitus- ja lukuoperaatioita, PostgreSQL:n maailma) ja OLAP (online analytical processing – raskaita analyyttisiä lukuja koko historiasta, ClickHousen maailma). Tuote kirjoittaa OLTP-tietokantaan, analytiikka lukee OLAP-kopiota.

Ja viimeinen perhe – graafitietokannat

Kun yhteydet ovat tärkeämpiä kuin tietueet itse – ”ystävien ystävät”, toimitusreitit, suositusketjut – otetaan käyttöön graafitietokannat (Neo4j, Memgraph). Niissä data on solmuja (ne ovat tietueita) ja kaaria (ne ovat tietueiden välisiä yhteyksiä); minkä tahansa syvyisten yhteyksien läpikäynti on niille luontainen operaatio. Relaatiotietokannassa sama läpikäynti on liitosten tikapuut, jotka raskautuvat syvyyden myötä.

Miniopas: miten valita tietokanta projektiin

1. Aloita kysymyksistä, älä datasta. Mitä kyselyitä tuote esittää: täsmällisiä ”avaimella”, yhdistäviä ”kuka osti mitä”, analyyttisiä ”paljonko kuukaudessa”?
2. Oletuksena relaatiotietokanta. Yhteydessä oleva data plus virheen hinta (tilaukset, maksut, saldot) – se on PostgreSQL. Turvallisin lähtö lähes mille tahansa tuotteelle.
3. Erikoistuneet tietokannat tiettyyn tehtävään, ei ”varmuuden vuoksi”. Kuumat luvut painavat – lisää Redis-välimuisti. Analytiikka kasvoi – replikoi tapahtumat ClickHouseen. Villi kenttien vaihtelu – ensin jsonb PostgreSQL:ssä, ja vasta kun se ei riitä – dokumenttitietokanta.
4. Laske toisen tietokannan hinta. Jokainen uusi DBMS tarkoittaa datan synkronointia, varmuuskopioita, valvontaa ja vielä yhden teknologian, jota tiimin pitää ylläpitää.