Kādas mēdz būt datubāzes

Ceļā uz aprakstu QUERY piebremzē pie tumšas glabātavas sekcijas. Aiz stikla — vecās Zemes arhīvu reģistrs, kas nepārdzīvoja Lielo Pārrāvumu: kešmezgli izdzisa pirmie, dokumentu glabātavas atnāca plīstošos fragmentos, analītiskie klasteri klusē veseliem sektoriem. Bet relāciju „Kotomarket” momentuzņēmums saglabājies pilnībā — ar visām saitēm.

Ne tikai relāciju

„Kotomarket” mums īpaši ērtas ir relāciju DB: pircēji, pasūtījumi un preces dabiski ieguļ tabulās ar saitēm. Tieši tām veltīts kurss. Bet nozarē — gan 2024. gadā, gan tagad — sastopamas arī citas pieejas:

• atslēga-vērtība (Redis) — ļoti ātrs formāts „atslēga → vērtība”, kad vajag acumirklī izvilkt vienkāršu ierakstu;
• dokumentorientētas (MongoDB) — glabā elastīgus JSON dokumentus, kuru struktūra var atšķirties no ieraksta uz ierakstu;
• kolonnu (ClickHouse) — spēcīgas analītikā, kad ātri jāaprēķina rādītāji milzīgos datu apjomos.

Lielākā daļa populāro DBVS produktu izstrādei paliek relāciju: PostgreSQL, MySQL, Oracle, MS SQL. Apgūsi SQL šeit — varēsi pārliecināti lasīt datus ļoti dažādos uzņēmumos.

QUERY: Katram arhīvam — savs darbs: vienam ātrums, citam elastība, trešajam analītika. Mums abiem paveicies: mums tika tas, kurā viss ir saistīts ar visu.

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.

Saimju reģistrs: izšķirstīts pa plauktiņiem

Reģistrs aiz stikla ir iemesls nopietni izpētīt datubāzu saimes: „kādas mēdz būt DB un kuru kad ņemt” ir viens no biežākajiem jautājumiem darba intervijās. Iziesim cauri piecām saimēm pēc kārtas, un par katru — pēc vienas shēmas: glabāšanas veids, stiprās un vājās puses, produkti un kad ņemt.

Relāciju DB: stingra shēma un saites

Glabāšanas veids: rindas tabulās ar iepriekš deklarētu shēmu — katrai kolonnai ir tips, starp tabulām darbojas saites pa atslēgām, un DBVS pati sargā integritāti: pasūtījumu no neeksistējoša pircēja ierakstīt neizdosies. Izmaiņas tiek izpildītas kā transakcijas ar ACID garantijām — „pasūtījums + atlikuma norakstīšana” vai nu tiek ierakstīti kopā, vai netiek ierakstīti vispār.

• Stiprās puses: izteiksmīgs SQL (filtri, tabulu savienojumi, agregāti), integritāte datubāzes līmenī, transakcijas.
• Vājās: shēma jāpārdomā iepriekš un jāmigrē pie izmaiņām; horizontālā mērogošana uz daudziem serveriem padodas grūtāk nekā NoSQL saimēm.
• Produkti: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Kad ņemt: lietotāji, pasūtījumi, nauda, noliktava — visur, kur dati ir saistīti un ieraksta kļūda nav pieļaujama. Jaunam produktam tā ir izvēle pēc noklusējuma.

Atslēga-vērtība datubāzes: vārdnīca maksimālajā ātrumā

Glabāšanas veids: viena milzīga vārdnīca „atslēga → vērtība”, visbiežāk operatīvajā atmiņā. Ne tabulu, ne saišu: ieliki pēc atslēgas — izņēmi pēc atslēgas milisekundes daļās.

-- Tas nav SQL, tās ir Redis komandas
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Stiprās puses: ātrums, vienkāršība, viegla mērogošana.
• Vājās: vaicājumi tikai pēc precīzas atslēgas — jautājumu „atrodi visas pircēju sesijas no Maskavas” šim formātam uzdot nevar; vērtības iekšiene datubāzei ir necaurspīdīga.
• Produkti: Redis, Memcached, Amazon DynamoDB.
• Kad ņemt: kešs, sesijas, skaitītāji, rindas, reitingi — karstie dati blakus galvenajai datubāzei, nevis tās vietā.

Dokumentu DB: elastīgs JSON

Glabāšanas veids: ieraksti ir JSON dokumenti, sagrupēti kolekcijās. Shēma netiek deklarēta iepriekš: viedpulkstenim ir lauks „baterijas darbības laiks”, hūdijam — „izmēru tabula”, un abi dokumenti mierīgi atrodas vienā kolekcijā. Iegultās struktūras tiek glabātas tieši dokumenta iekšienē, bez atsevišķām tabulām.

• Stiprās puses: elastīga struktūra, dokuments tiek nolasīts viss vienā piegājienā, ērti katalogiem ar neviendabīgiem atribūtiem un ātriem prototipiem.
• Vājās: saites starp dokumentiem ir lietotnes rūpe, pilnvērtīga JOIN gandrīz nav; bez disciplīnas kolekcija pārvēršas par nesaderīgu formātu zvērnīcu.
• Produkti: MongoDB, Couchbase, Firestore.
• Kad ņemt: saturs, katalogi ar ļoti atšķirīgiem laukiem, profili un iestatījumi.

Starp citu, saimju robeža ir izplūdusi: PostgreSQL prot glabāt dokumentus jsonb tipa kolonnā un veidot pa tiem indeksus — bieži tas aizpilda „dokumentu” vajadzību bez otras datubāzes:

-- Piemērs ārpus mūsu momentuzņēmuma: attrs — jsonb tipa kolonna
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Kolonnu DB: analītika pa miljardiem rindu

Glabāšanas veids: vērtības atrodas nevis pa rindām, bet pa kolonnām: visas cenas — blakus, visi datumi — blakus. Vaicājums „vidējais čeks pa mēnešiem” nolasa no diska tikai divas kolonnas visas tabulas vietā, un viendabīgas vērtības lieliski saspiežas. No tā arī ātrums uz agregātiem.

-- Kolonnu datubāzes iemīļotais žanrs (ClickHouse dialekts: toYYYYMM — tā funkcija)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Stiprās puses: agregāti un miljardu rindu skenēšana, spēcīga saspiešana.
• Vājās: punktveida atjauninājumi un dzēšana ir dārgi; nolasīt vienu rindu pilnībā ir lēnāk nekā rindu datubāzē; transakciju slodze — tādai slodzei tās nav paredzētas.
• Produkti: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Kad ņemt: analītika, atskaites, notikumi, žurnāli, metrikas — parasti blakus „kaujas” relāciju datubāzei.

Tepat arī pāris termini, ko mīl darba intervijās: OLTP (online transaction processing — daudz īsu rakstīšanas un lasīšanas operāciju, PostgreSQL pasaule) un OLAP (online analytical processing — smagi analītiski lasījumi pa visu vēsturi, ClickHouse pasaule). Produkts raksta OLTP datubāzē, analītika lasa OLAP kopiju.

Un pēdējā saime — grafu DB

Kad saites svarīgākas par pašiem ierakstiem — „draugu draugi”, piegādes maršruti, ieteikumu ķēdes — ņem grafu DB (Neo4j, Memgraph). Dati tajās ir mezgli (tie ir ieraksti) un šķautnes (tās ir saites starp ierakstiem); jebkura dziļuma saišu apiešana ir to dzimtā operācija. Relāciju datubāzē tāda apiešana ir tabulu savienojumu kāpnes, kas ar dziļumu kļūst smagākas.

Minigids: kā izvēlēties datubāzi projektam

1. Sāc ar jautājumiem, nevis ar datiem. Kādus vaicājumus uzdos produkts: punktveida „pēc atslēgas”, saistītus „kurš ko nopirka”, analītiskus „cik mēnesī”?
2. Pēc noklusējuma — relāciju. Saistīti dati plus kļūdas cena (pasūtījumi, maksājumi, atlikumi) — tas ir PostgreSQL. Visdrošākais sākums gandrīz jebkuram produktam.
3. Specializētas datubāzes — konkrētam uzdevumam, nevis „par rezervi”. Spiež karstie lasījumi — pievieno kešu uz Redis. Izauga analītika — replicē notikumus uz ClickHouse. Mežonīga lauku mainība — vispirms jsonb PostgreSQL, un tikai tad, kad ar to nepietiek — dokumentu datubāze.
4. Rēķini otras datubāzes cenu. Katra jauna DBVS ir datu sinhronizācija, dublējumi, monitorings un vēl viena tehnoloģija, kas komandai jāuztur.