Relációs adatbázisoktól a NoSQL-en át a vektor adatbázisokig

Az adatbázisok az informatikai rendszerek alapvető elemei, amelyek lehetővé teszik az adatok hatékony tárolását, visszakeresését, rendezését és módosítását. A modern világban hatalmas mennyiségű adat keletkezik másodpercenként, és ezek strukturált tárolása elengedhetetlen a döntéstámogatáshoz, automatizáláshoz és gépi tanuláshoz.

• Az adatok szervezett tárolása lehetővé teszi azok gyors visszakeresését és elemzését.
• Több felhasználó egyidejűleg dolgozhat ugyanazon adatokkal (konkurens hozzáférés).
• Biztosítani lehet az adatintegritást és a hozzáférés-ellenőrzést. Az adatbázis képes megóvni az adatok helyességét, érvényességét és konzisztenciáját – vagyis azt, hogy az adatok ne legyenek hibásak, hiányosak, vagy egymásnak ellentmondóak.
• Az adatok rendszeres mentése és visszaállítása egyszerűbbé válik.
• Automatizált folyamatokhoz (pl. webalkalmazások, gépi tanulás) szükséges egy megbízható háttértároló.

Példa: Egy webshopban több ezer termék, rendelés és felhasználói adat van. Ezek kereshető tárolása adatbázis nélkül gyakorlatilag lehetetlen lenne.

• Adat: nyers tények, mért vagy rögzített értékek, amelyek még nem feltétlenül bírnak jelentéssel.
  • Példa: `42`, `2025-05-07`, `„Piros”`
• Információ: értelmezett adat, amely kontextusba helyezve új tudást jelent.
  • Példa: „42 éves a felhasználó”, vagy „A rendelés dátuma: 2025-05-07”

Az adat tehát az alap, amiből – megfelelő feldolgozással – információt nyerhetünk. Az adatbázis célja az adatok strukturált tárolása annak érdekében, hogy információvá alakíthassuk őket.

• Strukturált adat:
  • Táblázatos formában rendezett, előre meghatározott sémával rendelkezik.
  • Példa: SQL adatbázisok, Excel-táblák, CRM rendszerek.
  • Jellemző: gyors kereshetőség, jól lekérdezhető.

• Félstrukturált adat:
  • Nincs fix sémája, de tartalmaz címkéket vagy metaadatokat.
  • Példa: XML, JSON, YAML fájlok, logok.
  • Rugalmasabb, de nehezebb indexelni és lekérdezni.

• Strukturálatlan adat:
  • Nincs formázása, nem egyértelmű a tartalma.
  • Példa: szövegfájlok, képek, videók, e-mailek, hangfelvételek.
  • Ezeket általában keresőmotorokkal vagy mesterséges intelligenciával lehet feldolgozni (pl. szöveg- vagy képelemzés).

Az adatbázisok fejlődése szorosan összefügg azzal, hogyan és milyen típusú adatokat akarunk hatékonyan kezelni.

A relációs adatbázisok az egyik legelterjedtebb adatbázis-típusok közé tartoznak. Az adatok táblákban (relációkban) tárolódnak, ahol minden tábla sorokból (rekordokból) és oszlopokból (mezőkből) áll. A relációs modell megbízható és jól definiált struktúrát biztosít az adatok kezeléséhez.

• A relációs modellt Edgar F. Codd matematikus javasolta 1970-ben.
• A modell a halmazelméletre és a predikátumlogikára épül.
• A ’70-es, ’80-as években megjelentek az első RDBMS rendszerek: IBM System R, Ingres, Oracle.
• A SQL (Structured Query Language) nyelv szabványosítása nagyban hozzájárult az elterjedéséhez.

• Adatszerkezet: táblázatos (sorok és oszlopok).
• Szigorú séma: minden táblának előre meghatározott szerkezete van (mezőtípusok, kulcsok stb.).
• Kapcsolatok: táblák között idegen kulcsokon keresztül hozunk létre kapcsolatokat.
• ACID tulajdonságok: Az ACID tulajdonságok biztosítják, hogy az adatbázisban végzett tranzakciók megbízhatóan és konzisztensen hajtódjanak végre, még hiba vagy rendszerleállás esetén is. Ezek különösen fontosak pénzügyi, vállalati vagy bármilyen más üzletkritikus rendszerekben.

Mit jelent az ACID?

A – Atomicity (Atomszerűség) Egy tranzakció vagy teljes egészében végrehajtódik, vagy semennyire. Ha a tranzakció közben hiba történik (pl. áramszünet), az adatbázis visszaállítja a korábbi állapotot.

• Példa: Ha egy banki utalás során először levonjuk a pénzt A számláról, majd jóváírjuk B számlán, akkor ezek vagy együtt történnek meg, vagy egyik sem.

C – Consistency (Konzisztencia) A tranzakció nem sértheti meg az adatbázis szabályait. Csak olyan állapot maradhat fenn, amely megfelel a megszorításoknak (kulcsok, ellenőrzések, hivatkozások).

• Példa: Egy megrendelés nem lehet úgy eltárolva, hogy nem tartozik hozzá létező vásárló.

I – Isolation (Elkülönítés) A párhuzamosan futó tranzakciók nem zavarhatják egymást. Egy felhasználó nem láthatja egy másik félkész változtatásait.

• Példa: Ha két ügyintéző módosítja ugyanazt az ügyfélrekordot, a rendszer biztosítja, hogy ezek ne írják felül egymást hibásan.

D – Durability (Tartósság) Ha egy tranzakció véglegesen befejeződik, annak hatása tartósan megmarad – még rendszerleállás után is.

• Példa: Ha egy utalás sikeresen lefutott, a pénzmozgás nem veszhet el újraindítás után sem.

• Adatintegritás: kulcsok, megszorítások és szabályok segítségével biztosítható.
• Lekérdezhetőség: a SQL nyelv rendkívül erős és kifejező eszköztárat ad.
• Stabilitás és érettség: hosszú távon kipróbált, optimalizált rendszerek.
• Többfelhasználós működés: jogosultságkezelés, tranzakciókezelés.

• Skálázhatóság: nagy adatmennyiség és sok párhuzamos felhasználó esetén nehezen osztható szét több gépre (horizontális skálázás).
• Rugalmatlanság: séma módosítása bonyolult lehet, különösen ha az adatstruktúra gyakran változik.
• Strukturálatlan adatok kezelése: szöveg, kép, videó típusú adatok kezelésére nem ideális.

• MySQL – nyílt forráskódú, népszerű webalkalmazások körében (pl. WordPress).
• PostgreSQL – fejlett funkciók, szabványos SQL támogatás, objektum-orientált kiegészítések.
• Oracle Database – robusztus vállalati megoldás, fejlett biztonság és replikációs lehetőségek.
• Microsoft SQL Server – integráció Microsoft-technológiákkal, könnyű használat.

Tábla: `diakok`

SQL lekérdezés:

SELECT nev FROM diakok WHERE szuletesi_ev < 2003;

Ez a lekérdezés visszaadja azoknak a diákoknak a nevét, akik 2003 előtt születtek.

A NoSQL adatbázisok a relációs modellek alternatívájaként jelentek meg, amikor az internetes alkalmazások, a Big Data és a valós idejű feldolgozások új követelményeket támasztottak az adatkezeléssel szemben. A „NoSQL” nem feltétlenül jelenti azt, hogy nem használható benne SQL, hanem inkább azt, hogy nem relációs modell alapján működik.

• Az adatok mennyisége gyorsan növekedett (pl. közösségi média, szenzoradatok).
• Az adatszerkezet egyre rugalmasabb lett – gyakran változó mezők, új attribútumok.
• Szükség volt horizontális skálázásra – sok szerver párhuzamos futtatása.
• Alkalmazásoknak nagy sebességre és alacsony késleltetésre volt szüksége.

• Sémanélküli modell: nincs előre rögzített mezőszerkezet.
• BASE modell:
  • *Basically Available* – mindig elérhető adatbázis
  • *Soft state* – az adat idővel változhat
  • *Eventually consistent* – idővel elérhető a konzisztencia (nem garantált azonnal)
• Horizontálisan skálázható: könnyen bővíthető több gépre.
• Nagy teljesítmény: ideális valós idejű alkalmazásokhoz.

• Dokumentum-orientált adatbázisok
  • Minden rekord egy önálló dokumentum (pl. JSON formátumban).
  • Rugalmas szerkezet, ideális REST API-khoz.
  • Példa: MongoDB, CouchDB

• Kulcs-érték tárolók
  • Egyszerű szerkezet: kulcs → érték (mint egy szótár).
  • Nagyon gyors, kiváló gyorsítótárazásra.
  • Példa: Redis, Amazon DynamoDB

• Oszlop-orientált adatbázisok
  • Az adatok nem sorokban, hanem oszlopokban tárolódnak.
  • Hatékony analitikai feldolgozás nagy adattáblákon.
  • Példa: Apache Cassandra, HBase

• Gráf adatbázisok
  • Adatok és azok kapcsolatai gráfként ábrázolva (csomópontok és élek).
  • Nagyon hasznos hálózati elemzésekhez, pl. közösségi hálók, útvonalkeresés.
  • Példa: Neo4j, ArangoDB

• Nagy teljesítmény, alacsony válaszidő.
• Könnyen skálázható horizontálisan.
• Rugalmas adatszerkezet – ideális gyorsan változó alkalmazásokhoz.
• Néhány esetben beépített replikáció, sharding, elosztott feldolgozás.

• Nincs szabványos nyelv (mint az SQL).
• Az adatintegritás és konzisztencia nem mindig garantált.
• Alkalmazásfejlesztéskor a logika egy része az adatbázis helyett a kódban jelenik meg.
• Komplex lekérdezések megvalósítása nehézkes lehet.

Egy MongoDB kollekcióban tárolt dokumentum példája:

{
  "_id": "u123",
  "nev": "Kiss János",
  "eletkor": 29,
  "cim": {
    "varos": "Budapest",
    "iranyitoszam": "1111"
  }
}

Egy lekérdezés: azokat a felhasználókat kérdezzük le, akik életkora nagyobb mint 25:

db.felhasznalok.find({ "eletkor": { "$gt": 25 } })

A NewSQL adatbázisok a relációs adatbázisok továbbfejlesztett változatai, amelyek célja, hogy megtartsák a klasszikus RDBMS rendszerek előnyeit (pl. SQL, ACID), ugyanakkor képesek legyenek a modern alkalmazások által megkövetelt horizontális skálázásra és magas teljesítményre, mint a NoSQL rendszerek.

• A vállalatok továbbra is igénylik a strukturált, relációs adatsémát és az ACID garanciákat.
• Ugyanakkor szükség van a modern skálázhatóságra, amit a NoSQL rendszerek nyújtanak.
• A cél: „legyen meg a torta és együk is meg” – relációs modell + felhőbarát architektúra.

• Relációs modell: táblák, kulcsok, SQL nyelv
• ACID tranzakciók: konzisztencia és megbízhatóság
• Elosztott architektúra: több szerveren futó adatbázis
• Skálázhatóság: automatikus sharding, load balancing
• Magas rendelkezésre állás: beépített replikáció, hibatűrés

• Kombinálja a relációs adatbázisok előnyeit a NoSQL skálázhatóságával
• Alkalmas nagy forgalmú, üzletkritikus alkalmazásokhoz
• Használható ismerős SQL nyelvvel, nem igényel új tanulási görbét

• Bonyolultabb architektúra és üzemeltetés, mint egy egyszerű SQL adatbázisnál
• Még viszonylag fiatal technológia – kisebb ökoszisztéma, kevesebb szakember
• Néhány megoldás zárt forráskódú, kereskedelmi licenc alatt áll

• Google Spanner
  • A Google saját globálisan elosztott relációs adatbázisa.
  • Világszintű szinkronizációval garantálja a konzisztenciát.

• CockroachDB
• Nyílt forráskódú, elosztott relációs adatbázis.
• Automatikus skálázás és replikáció.
• PostgreSQL-kompatibilis SQL interfész.

• VoltDB
  • Főként valós idejű analitikára és tranzakciókra specializált.
  • Nagy sebesség, memóriabeli működés.

CREATE TABLE felhasznalok (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  nev TEXT NOT NULL,
  regisztralt TIMESTAMP DEFAULT now()
);
 
SELECT * FROM felhasznalok WHERE nev LIKE 'K%';

A fenti példa egy CockroachDB tábla létrehozását és egyszerű lekérdezését mutatja be, PostgreSQL-kompatibilis SQL nyelven.

A vektor adatbázisok új generációs adatbázis-rendszerek, amelyek a mesterséges intelligencia és a gépi tanulás elterjedésével váltak népszerűvé. Céljuk nem strukturált adatok – például szövegek, képek, hangok – jelentés szerinti keresése, amelyet az ún. *embedding* (beágyazott vektorreprezentáció) segítségével valósítanak meg.

• A hagyományos adatbázisok nem alkalmasak jelentésalapú keresésre.
• Az LLM-ek, képfeldolgozók, hangfelismerők vektorokat állítanak elő, amelyek geometriailag összehasonlíthatók.
• Példa: „melyik másik dokumentum tartalmilag hasonlít ehhez a kérdéshez?”

• Az objektumokat (pl. szöveg, kép) embedding-gé alakítjuk egy neurális háló segítségével.
• Az így kapott vektorokat egy vektoradatbázis tárolja.
• Keresés során szintén vektort képezünk, majd megkeressük a legközelebbi (használatos: k-NN – *k Nearest Neighbors*) vektorokat.
• A hasonlóságot általában koszinusz-hasonlóság, euklideszi távolság vagy más metrika alapján számítják.

• Nincs klasszikus SQL – speciális API vagy Python/REST kliensek használatosak.
• Beépített indexelési módszerek a gyors kereséshez (pl. HNSW, IVF, PQ).
• Gyors és hatékony nagy dimenziójú adatok keresése.

• Jelentésalapú keresés – szöveg vagy kép jelentésének megértése
• Ideális LLM-alapú rendszerekhez, mint pl. kérdés-válasz vagy dokumentumkeresés
• Kiváló teljesítmény nagy adathalmazokon is

• Nem hagyományos adatmodell – nem tárol klasszikus táblákat, kapcsolatokkal
• A „miért kaptuk ezt a találatot?” kérdésre nehezebb választ adni (black-box jelleg)
• A pontosság függ az embedding minőségétől és a választott metrikától

• FAISS (Facebook AI Similarity Search) – nagy teljesítményű, Python-könyvtárként is elérhető
• Milvus – nyílt forráskódú, skálázható, GPU-t is támogató vektor DB
• Weaviate – REST API + GraphQL támogatás, integrált gépi tanulási pipeline
• Pinecone – felhőalapú, egyszerűen használható szolgáltatás
• Chroma – egyszerű integráció LangChain/RAG rendszerekhez

1. Szöveg → embedding: `“Milyen magas a Mount Everest?”` → `[0.12, -0.45, …, 0.33]` 2. A vektoradatbázisban tárolt több ezer dokumentum embeddingje közül kiválasztjuk a legközelebbit:

query_vector = model.encode("Milyen magas a Mount Everest?")
results = vector_db.search(query_vector, top_k=5)

3. Eredmény: olyan dokumentumokat kapunk, amelyek tartalmilag legközelebb állnak a kérdéshez – még akkor is, ha szó szerint nem egyeznek meg.

• Multimodális adatbázisok (szöveg + kép + struktúrált adatok)
• Hybrid keresés: SQL + vektoros keresés együtt
• AI-native rendszerek: LLM + adatbázis integráció (pl. LangChain)

Az alábbi példák bemutatják, hogyan tér el az adatok kezelése a különböző adatbázistípusokban. A példák egyszerűek, mégis jól szemléltetik az eltérő adatmodelleket és lekérdezési módokat.

Tábla létrehozása:

CREATE TABLE diakok (
  id SERIAL PRIMARY KEY,
  nev TEXT NOT NULL,
  szuletesi_ev INTEGER
);

Adatok beszúrása:

INSERT INTO diakok (nev, szuletesi_ev)
VALUES ('Kiss Anna', 2002), ('Nagy Péter', 2001);

Lekérdezés: ki született 2001 előtt?

SELECT nev FROM diakok WHERE szuletesi_ev < 2001;

Dokumentum beillesztése:

db.diakok.insertOne({
  nev: "Kiss Anna",
  szuletesi_ev: 2002
});

Lekérdezés: azok a diákok, akik 2001 előtt születtek:

db.diakok.find({ szuletesi_ev: { $lt: 2001 } });

Tegyük fel, hogy szövegeket átalakítunk vektorokká egy nyelvi modell (pl. `sentence-transformers`) segítségével, majd ezekben keresünk.

Embedding előállítás (példa):

from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
 
model = SentenceTransformer('all-MiniLM-L6-v2')
dokumentumok = ["A kutya ugat.", "A macska nyávog.", "Az autó gyors."]
 
vektorok = model.encode(dokumentumok)
index = faiss.IndexFlatL2(vektorok.shape[1])
index.add(np.array(vektorok))

Keresés hasonló szöveg alapján:

kerdes = "Melyik állat nyávog?"
kerdes_vektor = model.encode([kerdes])
_, eredmenyek = index.search(np.array(kerdes_vektor), k=1)
 
print("Legjobban illeszkedő dokumentum:", dokumentumok[eredmenyek[0][0]])

Eredmény: Legjobban illeszkedő dokumentum: A macska nyávog.

1. Mi a relációs adatbázis egyik alapvető jellemzője?

• ( ) Az adatok képek és hangfájlok formájában tárolódnak
• (x) Az adatokat táblákban tároljuk sorok és oszlopok formájában
• ( ) Az adatbázisok nem rendelkeznek előre meghatározott szerkezettel

2. Mi biztosítja az adatintegritást egy relációs adatbázisban?

• ( ) A dokumentumalapú adattárolás
• ( ) Az adatok titkosítása
• (x) Az elsődleges kulcsok, idegen kulcsok és megszorítások

3. Melyik adatbázis típus ideális gyakran változó adatszerkezetekhez?

• (x) NoSQL
• ( ) Relációs (RDBMS)
• ( ) CSV fájl

4. Mit jelent az ACID mozaikszó „A” betűje az adatbázis tranzakciók esetében?

• (x) Atomicity – oszthatatlanság
• ( ) Availability – elérhetőség
• ( ) Access – hozzáférhetőség

5. Melyik adatbázis típusban használunk embeddingeket és k-NN keresést?

• ( ) Relációs adatbázisban
• ( ) Gráf adatbázisban
• (x) Vektor adatbázisban

6. Melyik állítás igaz a MongoDB-re?

• ( ) Táblák és relációk alapján tárol adatokat
• (x) JSON-szerű dokumentumokban tárolja az adatokat
• ( ) Kizárólag numerikus adatokat képes kezelni

7. Mi a referenciális integritás szerepe egy adatbázisban?

• (x) Biztosítja, hogy az idegen kulcs által hivatkozott rekord létezzen
• ( ) Az adatokat titkosítja
• ( ) Lehetővé teszi a képek tárolását

8. Melyik igaz a NewSQL adatbázisokra?

• ( ) Nem támogatják az SQL nyelvet
• (x) ACID tulajdonságokat nyújtanak skálázható módon
• ( ) Strukturálatlan adatokat tárolnak kizárólag

9. Melyik nem vektor adatbázis?

• (x) MySQL
• ( ) FAISS
• ( ) Milvus

10. Mi a BASE modell egyik jellemzője NoSQL rendszereknél?

• (x) Eventually consistent – idővel konzisztenssé válik az adat
• ( ) A lekérdezések mindig pontos, teljes adatot adnak vissza
• ( ) Az adatok nem igényelnek tárolást