Milyen adatbázisok léteznek

A jegyzék felé tartva a QUERY lelassít a raktár egyik sötét szekciójánál. Az üveg mögött a régi Föld archívumainak nyilvántartása, azoké, amelyek nem élték túl a Nagy Szakadást: a gyorsítótár-csomópontok hunytak ki elsőként, a dokumentumtárolók szakadt töredékekben érkeztek meg, az elemzési fürtök egész szektorokon át hallgatnak. A „Kotomarket” relációs pillanatképe viszont épségben maradt fenn — minden kapcsolatával együtt.

Nemcsak relációsak

A „Kotomarket”-hez különösen jól jönnek a relációs adatbázisok: a vásárlók, a rendelések és a termékek természetesen rendeződnek kapcsolatokkal összekötött táblákba. Pontosan ezekről szól ez a kurzus. De az iparágban — akár 2024-ben, akár ma — más megközelítésekkel is találkozol:

• kulcs-érték (Redis) — nagyon gyors „kulcs → érték” formátum, amikor egy egyszerű rekordot kell azonnal előhúzni;
• dokumentumorientált (MongoDB) — rugalmas JSON-dokumentumokat tárol, amelyek szerkezete rekordról rekordra eltérhet;
• oszlopos (ClickHouse) — erős az elemzésben, amikor hatalmas adatmennyiségen kell gyorsan mutatókat számolni.

A termékfejlesztéshez használt népszerű DBMS-ek többsége relációs marad: PostgreSQL, MySQL, Oracle, MS SQL. Ha itt elsajátítod az SQL-t, nagyon különböző cégeknél is magabiztosan tudsz majd adatokat olvasni.

QUERY: Minden archívumnak megvan a maga dolga: az egyiknek a sebesség, a másiknak a rugalmasság, a harmadiknak az elemzés. Nekünk szerencsénk volt: az jutott nekünk, amelyben minden mindennel össze van kötve.

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.

A családok nyilvántartása: polcokra rendezve

Az üveg mögötti nyilvántartás jó alkalom arra, hogy komolyan szétszedjük az adatbázis-családokat: a „milyen adatbázisok léteznek, és mikor melyiket válasszuk” az egyik leggyakoribb interjúkérdés. Sorra vesszük az öt családot, mindegyiket ugyanazon séma szerint: a tárolás módja, erős és gyenge oldalak, termékek, és mikor érdemes választani.

Relációs adatbázisok: szigorú séma és kapcsolatok

A tárolás módja: sorok táblákban, előre deklarált sémával — minden oszlopnak van típusa, a táblák között kulcsok mentén futnak kapcsolatok, és a DBMS maga őrzi az integritást: nem létező vásárlótól nem lehet rendelést rögzíteni. A változtatások tranzakciókként, ACID-garanciákkal hajtódnak végre — a „rendelés + a készlet csökkentése” vagy együtt rögzül, vagy egyáltalán nem.

• Erős oldalak: kifejező SQL (szűrők, táblák összekapcsolása, aggregátumok), adatbázis-szintű integritás, tranzakciók.
• Gyenge oldalak: a sémát előre át kell gondolni, és változáskor migrálni; a vízszintes, sok szerverre való skálázás nehezebben megy, mint a NoSQL-családoknál.
• Termékek: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Mikor érdemes választani: felhasználók, rendelések, pénz, raktár — mindenhol, ahol az adatok kapcsolódnak, és egy hibás írás megengedhetetlen. Új termékhez ez az alapértelmezett választás.

Kulcs-érték adatbázisok: szótár maximális sebességen

A tárolás módja: egyetlen óriási „kulcs → érték” szótár, legtöbbször a memóriában. Sem táblák, sem kapcsolatok: kulcs alapján beteszed — kulcs alapján kiveszed, ezredmásodperc töredéke alatt.

-- Ez nem SQL, ezek Redis-parancsok
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Erős oldalak: sebesség, egyszerűség, könnyű skálázhatóság.
• Gyenge oldalak: lekérdezés csak pontos kulcs alapján — a „keresd meg az összes moszkvai vásárló munkamenetét” kérdést ennek a formátumnak nem lehet feltenni; az érték belseje az adatbázis számára átláthatatlan.
• Termékek: Redis, Memcached, Amazon DynamoDB.
• Mikor érdemes választani: gyorsítótár, munkamenetek, számlálók, sorok, ranglisták — forró adatok a fő adatbázis mellett, nem helyette.

Dokumentumadatbázisok: rugalmas JSON

A tárolás módja: a rekordok JSON-dokumentumok, gyűjteményekbe csoportosítva. A séma nincs előre deklarálva: az okosóránál van „akkumulátor-üzemidő” mező, a kapucnis pulóvernél „mérettáblázat”, és mindkét dokumentum nyugodtan megfér egyazon gyűjteményben. A beágyazott szerkezetek közvetlenül a dokumentumon belül tárolódnak, külön táblák nélkül.

• Erős oldalak: rugalmas szerkezet, a dokumentum egyetlen lekéréssel, egészben olvasható, kényelmes a heterogén attribútumú katalógusokhoz és a gyors prototípusokhoz.
• Gyenge oldalak: a dokumentumok közötti kapcsolatok az alkalmazás gondja, teljes értékű JOIN szinte nincs; fegyelem nélkül a gyűjtemény összeférhetetlen formátumok állatkertjévé válik.
• Termékek: MongoDB, Couchbase, Firestore.
• Mikor érdemes választani: tartalom, erősen eltérő mezőjű katalógusok, profilok és beállítások.

A családok határa egyébként elmosódott: a PostgreSQL képes dokumentumokat tárolni egy jsonb típusú oszlopban, és indexeket építeni rájuk — ez gyakran lefedi a „dokumentumszerű” igényt egy második adatbázis nélkül:

-- Példa a pillanatképünkön kívülről: az attrs egy jsonb típusú oszlop
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Oszlopos adatbázisok: elemzés milliárdnyi soron

A tárolás módja: az értékek nem soronként, hanem oszloponként fekszenek: minden ár egymás mellett, minden dátum egymás mellett. A „havi átlagos kosárérték” lekérdezés a teljes tábla helyett csak két oszlopot olvas be a lemezről, az egynemű értékek pedig kiválóan tömöríthetők. Innen a sebesség az aggregátumokon.

-- Az oszlopos adatbázis kedvenc műfaja (ClickHouse-dialektus: a toYYYYMM az ő függvénye)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Erős oldalak: aggregátumok és milliárdnyi sor átfésülése, erős tömörítés.
• Gyenge oldalak: a pontszerű frissítések és törlések drágák; egyetlen sort egészben kiolvasni lassabb, mint egy soros adatbázisban; a tranzakciós terhelésre egyszerűen nem ezeket tervezték.
• Termékek: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Mikor érdemes választani: elemzés, riportok, események, naplók, mutatók — rendszerint az „éles” relációs adatbázis mellett.

Itt mindjárt két fogalom is, amelyeket szeretnek az interjúkon: OLTP (online transaction processing — sok rövid írási és olvasási művelet, a PostgreSQL világa) és OLAP (online analytical processing — nehéz, a teljes előzményt átfogó elemzési olvasások, a ClickHouse világa). A termék az OLTP-adatbázisba ír, az elemzés az OLAP-másolatból olvas.

És az utolsó család — a gráfadatbázisok

Amikor a kapcsolatok fontosabbak maguknál a rekordoknál — „barátok barátai”, szállítási útvonalak, ajánlási láncok —, gráfadatbázisokat választanak (Neo4j, Memgraph). Bennük az adatok csomópontok (ezek a rekordok) és élek (ezek a rekordok közötti kapcsolatok); a tetszőleges mélységű kapcsolatbejárás itt natív művelet. Egy relációs adatbázisban ugyanez a bejárás táblaösszekapcsolások lépcsője, amely a mélységgel egyre nehezebbé válik.

Miniútmutató: hogyan válassz adatbázist a projekthez

1. A kérdésekből indulj ki, ne az adatokból. Milyen lekérdezéseket fog feltenni a termék: pontszerűeket „kulcs szerint”, kapcsolódókat „ki mit vett”, elemzőket „mennyi volt egy hónap alatt”?
2. Alapértelmezésben relációs. Kapcsolódó adatok plusz a hiba ára (rendelések, fizetések, készletek) — ez a PostgreSQL. A legbiztonságosabb indulás szinte bármilyen termékhez.
3. A specializált adatbázisok egy-egy konkrét feladatra valók, nem „tartalékba”. Szorítanak a forró olvasások — tégy mellé egy Redis-gyorsítótárat. Megnőtt az elemzés — replikáld az eseményeket a ClickHouse-ba. Vadul változó mezők — előbb jsonb a PostgreSQL-ben, és csak ha az már nem elég — dokumentumadatbázis.
4. Számold ki egy második adatbázis árát. Minden új DBMS adatszinkronizációt, biztonsági mentéseket, monitorozást és még egy technológiát jelent, amelyet a csapatnak karban kell tartania.