Millised andmebaasid on olemas

Teel inventuuri juurde pidurdab QUERY hoidla pimeda sektsiooni juures. Klaasi taga on vana Maa nende arhiivide register, mis Suurt Katkestust üle ei elanud: vahemälu-sõlmed kustusid esimesena, dokumendihoidlad jõudsid kohale rebenenud kildudena, analüütikaklastrid vaikivad tervete sektorite kaupa. „Kotomarketi“ relatsiooniline tõmmis aga jäi tervikuna alles — kõigi seostega.

Mitte ainult relatsioonilised

„Kotomarketi“ jaoks on meile eriti mugavad relatsioonilised AB-d: ostjad, tellimused ja kaubad asetuvad loomulikult seostega tabelitesse. Just neile ongi kursus pühendatud. Kuid tööstuses — nii 2024. aastal kui ka praegu — esineb ka teisi lähenemisi:

• võti-väärtus (Redis) — väga kiire formaat „võti → väärtus“, kui on vaja silmapilkselt kätte saada lihtne kirje;
• dokumendipõhised (MongoDB) — hoiavad paindlikke JSON-dokumente, mille struktuur võib kirjest kirjesse erineda;
• veerupõhised (ClickHouse) — tugevad analüütikas, kui on vaja kiiresti arvutada näitajaid hiiglaslike andmemahtude pealt.

Enamik populaarseid DBMS-e tootearenduse jaoks jäävad relatsioonilisteks: PostgreSQL, MySQL, Oracle, MS SQL. Kui õpid siin SQL-i selgeks, suudad enesekindlalt lugeda andmeid väga erinevates ettevõtetes.

QUERY: Igal arhiivil on oma töö: ühele kiirus, teisele paindlikkus, kolmandale analüütika. Sul ja mul on vedanud: meile sattus see, milles kõik on kõigega seotud.

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.

Perekondade register: lahterdame ära

Register klaasi taga on hea põhjus võtta andmebaasiperekonnad tõsiselt ette: „millised AB-d on olemas ja millal millise võtta“ on üks sagedasemaid küsimusi vestlustel. Käime läbi viis perekonda järjest ja iga kohta sama skeemi järgi: hoidmisviis, tugevad ja nõrgad küljed, tooted ja millal võtta.

Relatsioonilised AB-d: range skeem ja seosed

Hoidmisviis: read tabelites eelnevalt deklareeritud skeemiga — igal veerul on tüüp, tabelite vahel kehtivad seosed võtmete kaudu ja DBMS kaitseb terviklikkust ise: tellimust olematult ostjalt kirja panna ei õnnestu. Muudatusi täidetakse tehingutena ACID-garantiidega — „tellimus + jäägi mahaarvamine“ kas kirjutatakse koos või ei kirjutata üldse.

• Tugevad küljed: väljendusrikas SQL (filtrid, tabelite ühendamine, agregaadid), terviklikkus andmebaasi tasemel, tehingud.
• Nõrgad: skeem tuleb läbi mõelda ette ja muudatuste korral migreerida; horisontaalne skaleerimine paljudele serveritele on raskem kui NoSQL-perekondadel.
• Tooted: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Millal võtta: kasutajad, tellimused, raha, ladu — kõikjal, kus andmed on seotud ja kirjutamise viga on lubamatu. Uue toote jaoks on see vaikevalik.

Võti-väärtus andmebaasid: sõnastik maksimumkiirusel

Hoidmisviis: üks hiiglaslik sõnastik „võti → väärtus“, kõige sagedamini muutmälus. Ei mingeid tabeleid ega seoseid: panid võtme järgi sisse — võtsid võtme järgi välja millisekundi murdosaga.

-- See pole SQL, need on Redise käsud
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Tugevad küljed: kiirus, lihtsus, kerge skaleeritavus.
• Nõrgad: päringud ainult täpse võtme järgi — küsimust „leia kõik ostjate sessioonid Moskvast“ sellele formaadile esitada ei saa; väärtuse sisemus on andmebaasile läbipaistmatu.
• Tooted: Redis, Memcached, Amazon DynamoDB.
• Millal võtta: vahemälu, sessioonid, loendurid, järjekorrad, edetabelid — kuumad andmed kõrval põhiandmebaasiga, mitte selle asemel.

Dokumendipõhised AB-d: paindlik JSON

Hoidmisviis: kirjed on JSON-dokumendid, koondatud kollektsioonidesse. Skeemi ette ei deklareerita: nutikellal on väli „aku tööaeg“, kapuutsiga pusal „suurusvõrgustik“ ja mõlemad dokumendid lebavad rahulikult ühes kollektsioonis. Pesastatud struktuurid hoitakse otse dokumendi sees, ilma eraldi tabeliteta.

• Tugevad küljed: paindlik struktuur, dokument loetakse tervikuna ühe pöördumisega, mugav heterogeensete atribuutidega kataloogide ja kiirete prototüüpide jaoks.
• Nõrgad: dokumentide vahelised seosed on rakenduse mure, täisväärtuslikku JOIN-i peaaegu polegi; ilma distsipliinita muutub kollektsioon kokkusobimatute formaatide loomaaiaks.
• Tooted: MongoDB, Couchbase, Firestore.
• Millal võtta: sisu, väga erinevate väljadega kataloogid, profiilid ja seaded.

Perekondade piir on muide hägune: PostgreSQL oskab hoida dokumente jsonb tüüpi veerus ja ehitada nende järgi indekseid — sageli katab see „dokumendipõhise“ vajaduse ilma teise andmebaasita:

-- Näide väljaspool meie tõmmist: attrs — jsonb tüüpi veerg
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Veerupõhised AB-d: analüütika miljardite ridade pealt

Hoidmisviis: väärtused ei leba mitte ridade kaupa, vaid veergude kaupa: kõik hinnad kõrvuti, kõik kuupäevad kõrvuti. Päring „keskmine tšekk kuude lõikes“ loeb kettalt vaid kaks veergu kogu tabeli asemel ning ühetüübilised väärtused pakitakse suurepäraselt kokku. Sellest tulebki kiirus agregaatide pealt.

-- Veerupõhise andmebaasi lemmikžanr (ClickHouse'i dialekt: toYYYYMM on tema funktsioon)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Tugevad küljed: agregaadid ja miljardite ridade skaneerimine, tugev pakkimine.
• Nõrgad: punktuaalsed uuendused ja kustutamised on kallid; ühe rea tervikuna lugemine on aeglasem kui reapõhises andmebaasis; tehinguline koormus — sellise koormuse jaoks pole need mõeldud.
• Tooted: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Millal võtta: analüütika, aruanded, sündmused, logid, mõõdikud — tavaliselt „lahingulise“ relatsioonilise andmebaasi kõrval.

Siinsamas paar terminit, mida vestlustel armastatakse: OLTP (online transaction processing — palju lühikesi kirjutamise ja lugemise operatsioone, PostgreSQL-i maailm) ja OLAP (online analytical processing — rasked analüütilised lugemised kogu ajaloo pealt, ClickHouse'i maailm). Toode kirjutab OLTP-andmebaasi, analüütika loeb OLAP-koopiat.

Ja viimane perekond — graafilised AB-d

Kui seosed on tähtsamad kui kirjed ise — „sõprade sõbrad“, tarnemarsruudid, soovitusahelad — võetakse graafilised AB-d (Neo4j, Memgraph). Andmed neis on sõlmed (need on kirjed) ja servad (need on seosed kirjete vahel); mis tahes sügavusega seoste läbimine on neile loomulik operatsioon. Relatsioonilises andmebaasis on selline läbimine tabeliühenduste redel, mis sügavusega aina raskemaks muutub.

Minijuhend: kuidas valida projektile andmebaas

1. Alusta küsimustest, mitte andmetest. Milliseid päringuid hakkab toode esitama: punktuaalseid „võtme järgi“, seostatud „kes mida ostis“, analüütilisi „kui palju kuu jooksul“?
2. Vaikimisi — relatsiooniline. Seotud andmed pluss vea hind (tellimused, maksed, jäägid) — see on PostgreSQL. Kõige turvalisem algus peaaegu iga toote jaoks.
3. Spetsialiseeritud andmebaasid — konkreetse ülesande jaoks, mitte „tagavaraks“. Pingestavad kuumad lugemised — lisa vahemälu Redise peale. Analüütika kasvas — replikeeri sündmused ClickHouse'i. Väljade metsik varieeruvus — esmalt jsonb PostgreSQL-is ja alles siis, kui sellest ei piisa — dokumendipõhine andmebaas.
4. Arvesta teise andmebaasi hinda. Iga uus DBMS on andmete sünkroniseerimine, varukoopiad, monitooring ja veel üks tehnoloogia, mida meeskonnal tuleb ülal pidada.