Adatbázis szerverek és beágyazott adatbázisok

Adatbázis szerver

Az adatbázis szerver olyan adatbázist jelent, amely független szerverfolyamatként fut, és a hálózaton keresztül kezeli az alkalmazások kéréseit. A legtöbb, számunkra ismert RDBMS, mint például a MySQL, PostgreSQL, Oracle DB, ebbe a modellbe tartozik. Az adatbázis szerverek a következő előnyökkel rendelkeznek:

Központosított kezelés: Az adatok egy helyen vannak integráltan kezelve, ami megkönnyíti a konzisztenciát, a biztonságot, a biztonsági mentést és a helyreállítást.
Erőforrás-függetlenség: Saját CPU-t, memóriát és tárhelyet kap, garantálva a stabil teljesítményt az alkalmazás állapotától függetlenül.
Magas konkurens kezelés és skálázhatóság: Optimalizálva van nagyszámú felhasználó egyidejű hozzáférésére, és viszonylag könnyű a horizontális skálázás clustering vagy replikáció révén.

Ezen jellemzőknek köszönhetően az adatbázis szerverek az elmúlt évtizedekben a szoftverinfrastruktúra szabványává váltak. Azonban a technológiai fejlődés és a környezeti változások miatt egyes környezetekben az adatbázis szerverek hátrányai is megmutatkoztak, és alternatívaként újra előtérbe kerültek az embedded adatbázisok.

Új trend: Embedded adatbázisok

Az embedded adatbázis egy olyan adatbázis engine, amely külön szerverfolyamat nélkül, library formájában az alkalmazásba integrálva, ugyanabban a folyamatban fut. A SQLite, LevelDB, RocksDB tipikus embedded adatbázisok. Az embedded adatbázisok a következő okok miatt váltak erős alternatívává a legújabb technológiai környezetben:

Az SSD megjelenése
A korábbi, HDD-központú rendszerekben a szekvenciális adat olvasási/írási teljesítményhez képest a véletlen hozzáférés teljesítménye jelentősen elmaradt. Ezért a teljesítmény optimalizálásának kulcsa a disk I/O minimalizálása és a memória caching maximalizálása volt. Az adatbázis szerverek ehhez igazodva nagy cache-eket működtettek, és az írási műveleteket csoportosítva dolgozták fel, ezzel leküzdve a HDD fizikai korlátait.
Az SSD megjelenése azonban teljesen megváltoztatta ezt a feltételezést. Az SSD-k ezerszer gyorsabb random I/O teljesítményt nyújtanak, és drasztikusan rövidebb késleltetési idővel rendelkeznek a HDD-khez képest. Ennek eredményeként eltűnt az a korábbi felfogás, miszerint „a disk I/O a legnagyobb szűk keresztmetszet”, és ehelyett a hálózaton keresztül történő távoli DB szerver hozzáférésből eredő késleltetés vált új szűk keresztmetszetté.
MSA és adatfüggetlenség
Korábban általános volt az a struktúra, amelyben egyetlen hatalmas monolitikus alkalmazás egyetlen központosított adatbázisra támaszkodott. Ez a megközelítés egyszerű volt, de a szolgáltatás méretének növekedésével a séma módosítása nehézkessé vált, és a túl erős összekapcsolódás problémát jelentett, mivel minden szolgáltatás ugyanazt az adatbázist használta.
A modern mikroszolgáltatás architektúrákban ezen problémák megoldására a „Database per Service” elv hangsúlyos. Azáltal, hogy minden szolgáltatás saját dedikált adattárolóval rendelkezik és azt kapszulázza, biztosítottá válik a szolgáltatások közötti függetlenség, és könnyebbé válik a hibaelhárítás és a skálázás. Ebben a folyamatban az embedded DB ideális választássá válik szolgáltatás-szintű adattárolóként. Könnyű, gyors, és a szolgáltatáskóddal együtt telepíthető, így nagyon jól illeszkedik az MSA környezethez.
Jellemzően a Kubernetes környezetben széles körben alkalmazott a sidecar pattern, ahol az embedded DB-t az alkalmazás konténer mellé helyezik a lokális adatfeldolgozás optimalizálása érdekében. Ez csökkenti a hálózati szűk keresztmetszeteket és minimalizálja az adathozzáférési késedelmet.
Egyszerűsített üzemeltetési környezet
Az adatbázis szerverek komplex üzemeltetési eljárásokat igényelnek, mint például telepítés, patch-elés, biztonsági mentés, hibaelhárítás, replikáció, teljesítményfigyelés, és ehhez dedikált DBA-ra és szakértő üzemeltető személyzetre van szükség. Különösen nagy léptékű környezetekben ez a kezelési terhelés rendkívül jelentős.
Az embedded DB-k nagymértékben enyhítik ezeket a problémákat. Ha az adatbázis integrálva van az alkalmazásba, az egységtesztelés, a buildelés, a verziókezelés és a telepítés együtt történik, így nincs szükség külön szerverüzemeltetésre. Emellett, amikor az alkalmazás scale-out-ol, az embedded DB is vele együtt skálázódik, és automatizált kezelés válik lehetővé DevOps kultúra és CI/CD pipeline-ok révén. Különösen startupok, kis szolgáltatások és prototípus fejlesztési környezetek esetében az embedded adatbázisok drasztikusan csökkentik az üzemeltetési komplexitást, és jelentősen növelik a fejlesztési és telepítési sebességet.
Nagy teljesítményű rendszer nyelvek és ökoszisztéma fejlődése
Korábban az volt a jellemző, hogy az adatbázis és az alkalmazás különböző nyelveken íródott. Például a nagy teljesítményt igénylő adatbázis engine-ek főként C, C++ nyelven íródtak, míg az alkalmazásokat olyan nyelveken fejlesztették, mint a Java, Python, PHP. Ez a megközelítés hatékony volt a teljesítmény optimalizálásában, de voltak korlátai, mint például a memória stabilitási problémák, a komplex konkurens kezelés, a késleltetési idő, valamint a library integráció és telepítés nehézségei.
Azonban a modern rendszerprogramozási nyelvek, mint például a Go és a Rust megjelenésével ezek a korlátok jelentősen enyhültek. Különösen a Go alkalmas nagy teljesítményű alkalmazásokhoz, valamint alacsony szintű programok, például adatbázis engine-ek írásához is, így az adatbázis és az alkalmazás egy nyelvi ökoszisztémán belül kezelhetővé vált.
Valóban, a Golangban olyan nagy teljesítményű embedded adatbázisok, mint a BadgerDB és a PebbleDB aktívan használatosak. Ez azt jelenti, hogy az embedded adatbázisok már nem csupán az adatbázis szerverek könnyű alternatívái, hanem saját versenyképességgel rendelkező, fontos választási lehetőséggé váltak.

Összefoglalás

A nagyméretű adatok központosított kezelése, a komplex tranzakciók és a magas konkurens kezelés esetén továbbra is az adatbázis szerver a legerősebb megoldás. Azonban az MSA környezet egyedi szolgáltatásai, az IoT edge eszközök, a gyors prototípus készítés, valamint az üzemeltetési hatékonyság szempontjából fontos projektek esetében az embedded adatbázis hatékonyabb és racionálisabb választás lehet. Végül is a lényeg az, hogy a adott helyzethez és követelményekhez legjobban illő optimális eszközt válasszuk, és az embedded adatbázisok fejlődése szélesebb és változatosabb választékot kínál számunkra.