--- id: 2bc35fc657eb35eb5dbcb7286c1033ba author: gosunuts title: 'Adatbázis-kiszolgálók és beágyazott adatbázisok: architektúra és I/O-jellemzők összehasonlítása' description: Ez a tanulmány a független folyamatalapú RDBMS-eket és a SQLite, RocksDB, BadgerDB, PebbleDB és más folyamaton belüli (in-process) beágyazott adatbázisokat hasonlítja össze az NVMe SSD I/O késleltetés, az MSA adatizolálás és a telepítési architektúra szempontjából. language: hu date: 2025-08-21T12:11:23.268337247Z path: /blog/posts/database-servers-and-embedded-databases-zd4cb799f category: database --- ## Adatbázisszerver Az adatbázisszerver olyan adatbázist jelent, amely önálló szerverfolyamatként fut, és hálózaton keresztül dolgozza fel az alkalmazások kéréseit. A MySQL, a PostgreSQL, az Oracle DB és más, számunkra jól ismert RDBMS-ek nagy része ebbe a modellbe tartozik. Az adatbázisszerver a következő előnyökkel rendelkezik. - **Központosított kezelés**: Az adatok egy helyen, egységesen kezelhetők, ami megkönnyíti a konzisztencia, a biztonság, valamint a biztonsági mentés és a helyreállítás kezelését. - **Erőforrás-függetlenség**: Saját CPU-, memória- és tárolókapacitást kap, így az alkalmazás állapotától függetlenül is stabil teljesítményt biztosít. - **Magas párhuzamosság és skálázhatóság**: Optimalizált a sok felhasználó egyidejű hozzáférésére, és fürtözéssel vagy replikációval viszonylag egyszerűen skálázható vízszintesen. Ezeknek a jellemzőknek köszönhetően az adatbázisszerver az elmúlt évtizedekben a szoftverinfrastruktúra szabványává vált. A technológiai fejlődés és a környezeti változások miatt azonban bizonyos környezetekben kezdenek megmutatkozni az adatbázisszerverek hátrányai, és ennek alternatívájaként a beágyazott adatbázisok ismét figyelmet kapnak. ## Új irányvonal: a beágyazott adatbázisok A beágyazott adatbázis külön szerverfolyamat nélkül, könyvtár formájában épül be az alkalmazásba, és ugyanabban a folyamatban fut. Az SQLite, a LevelDB és a RocksDB a legismertebb beágyazott adatbázisok. Az, hogy ezek a beágyazott adatbázisok a mai technológiai környezetben erős alternatívaként jelentek meg, a következő okokra vezethető vissza. - **Az SSD megjelenése** A korábbi, HDD-alapú rendszerekben a véletlen hozzáférési teljesítmény jelentősen elmaradt a szekvenciális olvasási és írási teljesítménytől. Ezért a teljesítményoptimalizálás kulcsa a lemez I/O-műveleteinek minimalizálása és a memóriagyorsítótárazás maximalizálása volt. Az adatbázisszerverek ennek megfelelően nagy méretű gyorsítótárat működtettek, és az írási műveleteket csoportosítva dolgozták fel, így küzdöttek meg a HDD fizikai korlátaival. Az SSD megjelenése azonban alapjaiban változtatta meg ezt a kiindulópontot. Az SSD véletlen I/O teljesítménye többezerszer gyorsabb a HDD-énél, késleltetése pedig jelentősen kisebb. Ennek eredményeként megszűnt a korábbi felfogás, miszerint a „lemez I/O a legnagyobb szűk keresztmetszet”, és a hálózaton keresztüli távoli adatbázis-hozzáférésből származó késleltetés kezdett új szűk keresztmetszetként megjelenni. - **MSA és az adatfüggetlenség** Korábban az volt a jellemző, hogy egyetlen nagy monolitikus alkalmazás egyetlen központosított adatbázistól függött. Ez a megoldás egyszerű volt, de a szolgáltatások méretének növekedésével nehézzé vált az adatsémák módosítása, és az összes szolgáltatás közös adatbázisának használata túlzottan erős csatolást eredményezett. A modern mikroszolgáltatás-architektúrában ezeknek a problémáknak a megoldására a „Database per Service” elv a meghatározó. Minden szolgáltatás a saját, kizárólagos adattárolóját birtokolja és egységbe zárja, ami biztosítja a szolgáltatások közötti függetlenséget, és megkönnyíti a hibák elszigetelését és a skálázást. Ebben a folyamatban a beágyazott adatbázis ideális választássá válik a szolgáltatásszintű adattárolóként. Könnyű és gyors, valamint a szolgáltatás kódjával együtt telepíthető, ezért kiválóan illeszkedik az MSA környezetbe. Kubernetes környezetben például széles körben alkalmazzák azt a megoldást, amikor szidekár-mintával az alkalmazáskonténer mellé helyeznek egy beágyazott adatbázist, így optimalizálva a helyi adatfeldolgozást. Ez csökkenti a hálózati szűk keresztmetszeteket, és minimalizálja az adatelérési késleltetést. - **Egyszerűsödő üzemeltetés** Az adatbázisszerverek üzemeltetése elengedhetetlenül összetett műveleteket igényel, például telepítést, javítócsomagok alkalmazását, biztonsági mentést, hibaelhárítást, replikációt és teljesítményfigyelést, ami dedikált DBA-kat és szakképzett üzemeltetési munkatársakat tesz szükségessé. Különösen nagy környezetekben ez a terhelés rendkívül nagy. A beágyazott adatbázis ezeket a problémákat jelentősen enyhíti. Ha az adatbázis az alkalmazáson belül integrálódik, az egységteszt, az építés, a verziókezelés és a telepítés együtt történik, így külön szerverüzemeltetésre nincs szükség. Emellett az alkalmazás vízszintes skálázásakor a beágyazott adatbázis is vele együtt skálázódik, és a DevOps kultúra és a CI/CD folyamatok révén automatizált kezelés válik lehetővé. Különösen startupok, kisebb szolgáltatások és prototípus-fejlesztési környezetek esetén a beágyazott adatbázis drasztikusan csökkenti az üzemeltetési komplexitást, és jelentősen gyorsítja a fejlesztést és a telepítést. - **Nagy teljesítményű rendszernyelvek és az ökoszisztéma fejlődése** Korábban jellemző volt, hogy az adatbázis és az alkalmazás eltérő nyelveken készült. Például a nagy teljesítményt igénylő adatbázismotorokat főként C-ben és C++-ban írták, az alkalmazásokat pedig Java, Python, PHP és más nyelveken fejlesztették. Ez a megközelítés hatékony volt a teljesítményoptimalizálás szempontjából, ugyanakkor korlátokat jelentett a memóriabiztonság, a bonyolult párhuzamosságkezelés, a késleltetés, valamint a könyvtárak integrálásának és a telepítésnek a terén. Az utóbbi időben azonban a Go és a Rust típusú modern rendszerprogramozási nyelvek térnyerése jelentősen enyhítette ezeket a korlátokat. A Go különösen alkalmas nagy teljesítményű alkalmazások, valamint adatbázismotorok és más alacsony szintű programok írására, így az adatbázis és az alkalmazás egyetlen nyelvi ökoszisztémán belül is kezelhető. A Golang környezetben például a [BadgerDB](https://github.com/hypermodeinc/badger) és a [PebbleDB](https://github.com/cockroachdb/pebble) típusú nagy teljesítményű beágyazott adatbázisok széles körben használatosak. Ez azt jelzi, hogy a beágyazott adatbázis már nemcsak az adatbázisszerver könnyű alternatívájaként működik, hanem saját versenyképességgel rendelkező, fontos választási lehetőséggé vált. ## Következtetés Nagy mennyiségű adat központi kezelése, összetett tranzakciók és magas párhuzamosság szükségessége esetén az adatbázisszerver továbbra is a legerősebb megoldás. Az MSA környezet egyes szolgáltatásaiban, az IoT peremeszközökön, a gyors prototípuskészítésben és olyan projektekben, ahol az üzemeltetési hatékonyság kiemelten fontos, azonban a beágyazott adatbázis hatékonyabb és észszerűbb választás lehet. Végső soron a lényeg az, hogy az adott helyzethez és követelményekhez legjobban illeszkedő optimális eszközt válasszuk ki, a beágyazott adatbázisok fejlődése pedig szélesebb és sokszínűbb választási lehetőségeket kínál számunkra.