Kokios būna duomenų bazės

Pakeliui į aprašą QUERY pristabdo prie tamsaus saugyklos skyriaus. Už stiklo — senosios Žemės archyvų, neišgyvenusių Didžiojo Lūžio, registras: talpyklos mazgai užgeso pirmieji, dokumentinės saugyklos atkeliavo skeveldromis, analitiniai klasteriai tyli ištisais sektoriais. O reliacinė „Kotomarket“ kopija išliko visa — su visais ryšiais.

Ne tik reliacinės

„Kotomarket“ mums ypač patogios reliacinės DB: pirkėjai, užsakymai ir prekės natūraliai sugula į lenteles su ryšiais. Būtent joms ir skirtas kursas. Bet industrijoje — tiek 2024-aisiais, tiek dabar — pasitaiko ir kitų požiūrių:

• raktas-reikšmė (Redis) — labai greitas formatas „raktas → reikšmė“, kai reikia akimirksniu ištraukti paprastą įrašą;
• dokumentinės (MongoDB) — saugo lanksčius JSON dokumentus, kurių struktūra įraše gali skirtis;
• stulpelinės (ClickHouse) — stiprios analitikoje, kai reikia greitai suskaičiuoti rodiklius iš milžiniškų duomenų kiekių.

Dauguma populiarių DBVS produktų kūrimui lieka reliacinės: PostgreSQL, MySQL, Oracle, MS SQL. Įvaldysi SQL čia — galėsi užtikrintai skaityti duomenis pačiose įvairiausiose įmonėse.

QUERY: Kiekvienam archyvui — savas darbas: vieniems greitis, kitiems lankstumas, tretiems analitika. Mums su tavimi pasisekė: gavome tą, kuriame viskas susiję su viskuo.

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.

Šeimų registras: išsiaiškinkim viską po lentynėles

Registras už stiklo — proga rimtai išnagrinėti duomenų bazių šeimas: „kokios būna DB ir kada kurią rinktis“ — vienas dažniausių klausimų pokalbiuose. Pereisime penkias šeimas iš eilės, ir kiekvieną — pagal vieną schemą: saugojimo būdas, stipriosios ir silpnosios pusės, produktai ir kada rinktis.

Reliacinės DB: griežta schema ir ryšiai

Saugojimo būdas: eilutės lentelėse su iš anksto paskelbta schema — kiekvienas stulpelis turi tipą, tarp lentelių veikia ryšiai per raktus, o DBVS pati saugo vientisumą: užsakymo iš neegzistuojančio pirkėjo įrašyti nepavyks. Pakeitimai vykdomi transakcijomis su ACID garantijomis — „užsakymas + likučio nurašymas“ arba įrašomi kartu, arba neįrašomi visai.

• Stipriosios pusės: išraiškinga SQL (filtrai, lentelių sujungimai, agregatai), vientisumas bazės lygiu, transakcijos.
• Silpnosios: schemą reikia apgalvoti iš anksto ir migruoti įvykus pakeitimams; horizontalusis mastelio keitimas į daugelį serverių sekasi sunkiau nei NoSQL šeimoms.
• Produktai: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kada rinktis: naudotojai, užsakymai, pinigai, sandėlis — visur, kur duomenys susiję ir įrašymo klaida nepriimtina. Naujam produktui tai pasirinkimas pagal nutylėjimą.

Raktas-reikšmė bazės: žodynas maksimaliu greičiu

Saugojimo būdas: vienas milžiniškas žodynas „raktas → reikšmė“, dažniausiai operatyviojoje atmintyje. Nei lentelių, nei ryšių: įdėjai pagal raktą — pasiėmei pagal raktą per milisekundės dalis.

-- Tai ne SQL, tai Redis komandos
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Stipriosios pusės: greitis, paprastumas, lengvas mastelio keitimas.
• Silpnosios: užklausos tik pagal tikslų raktą — klausimo „rask visas pirkėjų iš Maskvos sesijas“ šiam formatui neužduosi; reikšmės vidus bazei nepermatomas.
• Produktai: Redis, Memcached, Amazon DynamoDB.
• Kada rinktis: talpykla, sesijos, skaitikliai, eilės, reitingai — karšti duomenys šalia pagrindinės bazės, o ne vietoj jos.

Dokumentinės DB: lankstus JSON

Saugojimo būdas: įrašai — JSON dokumentai, sugrupuoti į kolekcijas. Schema neskelbiama iš anksto: išmanusis laikrodis turi lauką „baterijos veikimo laikas“, džemperis su gobtuvu — „dydžių lentelę“, ir abu dokumentai ramiai guli toje pačioje kolekcijoje. Įdėtinės struktūros saugomos tiesiog dokumento viduje, be atskirų lentelių.

• Stipriosios pusės: lanksti struktūra, dokumentas perskaitomas visas vienu kreipiniu, patogu katalogams su nevienarūšiais atributais ir greitiems prototipams.
• Silpnosios: ryšiai tarp dokumentų — programos rūpestis, pilnaverčių JOIN beveik nėra; be disciplinos kolekcija pavirsta nesuderinamų formatų zoologijos sodu.
• Produktai: MongoDB, Couchbase, Firestore.
• Kada rinktis: turinys, katalogai su labai skirtingais laukais, profiliai ir nustatymai.

Beje, riba tarp šeimų išplaukusi: PostgreSQL moka saugoti dokumentus jsonb tipo stulpelyje ir kurti pagal juos indeksus — dažnai tai uždengia „dokumentinį“ poreikį be antros bazės:

-- Pavyzdys už mūsų kopijos ribų: attrs — jsonb tipo stulpelis
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Stulpelinės DB: analitika per milijardus eilučių

Saugojimo būdas: reikšmės guli ne eilutėmis, o pagal stulpelius: visos kainos — greta, visos datos — greta. Užklausa „vidutinis čekis pagal mėnesius“ nuskaito iš disko tik du stulpelius vietoj visos lentelės, o vienarūšės reikšmės puikiai suspaudžiamos. Iš čia ir greitis su agregatais.

-- Mėgstamiausias stulpelinės bazės žanras (ClickHouse dialektas: toYYYYMM — jo funkcija)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Stipriosios pusės: agregatai ir milijardų eilučių skenavimas, stiprus suspaudimas.
• Silpnosios: taškiniai atnaujinimai ir trynimai brangūs; perskaityti vieną eilutę visą — lėčiau nei eilutinėje bazėje; transakcinė apkrova — tokiai apkrovai jos neskirtos.
• Produktai: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kada rinktis: analitika, ataskaitos, įvykiai, žurnalai, metrikos — paprastai šalia „kovinės“ reliacinės bazės.

Čia pat ir pora terminų, kuriuos mėgsta pokalbiuose: OLTP (online transaction processing — daug trumpų įrašymo ir skaitymo operacijų, PostgreSQL pasaulis) ir OLAP (online analytical processing — sunkūs analitiniai skaitymai per visą istoriją, ClickHouse pasaulis). Produktas rašo į OLTP bazę, analitika skaito OLAP kopiją.

Ir paskutinė šeima — grafinės DB

Kai ryšiai svarbesni už pačius įrašus — „draugų draugai“, pristatymo maršrutai, rekomendacijų grandinės — renkasi grafines DB (Neo4j, Memgraph). Duomenys jose — mazgai (tai įrašai) ir briaunos (tai ryšiai tarp įrašų); bet kokio gylio ryšių apėjimas — gimtoji operacija. Reliacinėje bazėje toks apėjimas — lentelių sujungimų laiptai, kurie su gyliu vis sunkėja.

Minigidas: kaip pasirinkti bazę projektui

1. Pradėk nuo klausimų, o ne nuo duomenų. Kokias užklausas užduos produktas: taškines „pagal raktą“, susietines „kas ką pirko“, analitines „kiek per mėnesį“?
2. Pagal nutylėjimą — reliacinė. Susiję duomenys plius klaidos kaina (užsakymai, mokėjimai, likučiai) — tai PostgreSQL. Saugiausias startas beveik bet kuriam produktui.
3. Specializuotos bazės — konkrečiai užduočiai, o ne „atsargai“. Spaudžia karšti skaitymai — pridėk talpyklą su Redis. Išaugo analitika — replikuok įvykius į ClickHouse. Pašėlęs laukų kintamumas — pirmiausia jsonb PostgreSQL, ir tik kai jo nebeužteks — dokumentinė bazė.
4. Skaičiuok antros bazės kainą. Kiekviena nauja DBVS — tai duomenų sinchronizacija, atsarginės kopijos, stebėsena ir dar viena technologija, kurią komandai reikia prižiūrėti.