A mySQL, Oracle és az MS SQL Server még napjainkban is a legismertebb és legelterjedtebb adatbáziskezelő rendszerek. Alapesetben relációs adatmodellt használnak, azaz az adatokat táblákban tárolják. A tárolt adatok sémája, azaz az oszlopok adattípusai táblánként meghatározandók. Szabványos lekérdező nyelvük az SQL. Az adatbázis műveletek tranzakciókba szervezhetők, így például egy banki fizetési művelet is biztonságosan végrehajtható már adatbázis szinten is. 
Túlzás lenne tehát kijelenteni, hogy ez mind már a múlté, azonban manapság egy informatikai pozícióhoz köthető állásinterjún is elvárhatjuk a jelölttől, hogy ismerjen egyéb, divatos szóval élve NoSQL adatbázisokat, esetleg tudja mi a Big Data.

A továbbiakban néhány olyan jelentős adatkezelési esetet mutatok be, ahol a hagyományos relációs adatbázisok nem használhatók hatékonyan.

Google keresés

A címről sokunknak a rangsorolási rendszer jut eszünkbe, ami szerint a keresőmotor a weboldalainkat előrébb vagy hátrébb sorolja. Ettől függetlenül hangsúlyoznám, hogy mennyire bámulatos, hogy a publikus Internet egészén kereshetünk közel fél másodperc alatt, többmilliós találat szám mellett is. Több hagyományos adatbáziskezelő rendszer is felokosítható a hasonló keresésekhez szükséges full-text search funkcióval, de a problémára léteznek adatbázisnak nem nevezhető, speciális megoldások is, amilyen az Elasticsearch is.

A modern operációs rendszerek is hasonló, fejlett keresési szolgáltatással rendelkeznek. Ezek már jó pár éve, Internet hozzáférés nélkül is képesek a szöveges dokumentumainkban, táblázatainkban előforduló szavak vagy szótöredékek alapján megtalálni azokat, vagy akár böngészőtörténetünk alapján a keresett szavaknak megfelelő weboldalakat.

Technikailag a full-text search vagy szabadszavas keresés a fordított index technikán alapul. A kereső rendszer szabadszavas keresésnél előbb a számára ismert dokumentumok összes szavából szótöveket képez, különböző nyelvi beállításoknak megfelelően. Majd a szótövekhez lementi a kapcsolódó dokumentumok elérhetőségét, és a relevancia mértékét. Minél többször, minél pontosabban fordul elő egy adott kifejezés egy dokumentumban, a dokumentum annál relevánsabb a keresett kifejezés szempontjából. Ha viszont a keresett kifejezés sok dokumentumban szerepel, akkor a relevancia szétoszlik a dokumentumok között, így egyik dokumentum se lesz kimondottan releváns.

A keresőóriás által kezelt dokumentumokra természetesen igen nagy adattömeg is jellemző, valamint a keresések a világ bármely pontján gyorsak kell hogy legyenek. Ezen kritériumoknak megfelelő adatkezelési megoldásokra a későbbi részekben térek ki.

Ünnepi bevásárlás

Idény jelleggel előfordul, hogy az informatikai rendszerek terhelése hirtelen többszörösére nő, egy ünnep közeledte vagy egy jól sikerült marketing kampány hatására. Ekkor a megnövekedett teljesítmény igény kiszolgálása kulcsfontosságú a vállalatok presztízsének és bevételének megóvása érdekében. Azonban a magas kapacitás folyamatos, idényen kívüli fenntartása rendkívül gazdaságtalan, abba is tönkremehet egy cég. A megoldás az informatikai rendszerek dinamikus skálázhatóságának biztosítása. Az adatkezelő megoldások sem jelenthetnek kivételt. A megnövekedett teljesítmény igény adatbáziskezelők esetén sok adatelérési műveletet jelent. Ekkor az adatok gyorsan is változhatnak, tehát önmagában a memóriát használó gyorsítótárak nem jelentenek megoldást. Az adatvesztés elkerülése érdekében ilyenkor is tartósan és biztonságosan kell kezelni az adatokat. Az adatok replikálása, particionálása, automatikus szilánkosítása (sharding), egy szóval az elosztott adattárolás szükséges a megnövekedett igények kiszolgálásához. Minél inkább a hasonló szélsőséges esetek figyelembevételével terveznek egy adatbáziskezelő rendszert, annál inkább kapunk egy biztonságos, relatív egyszerűen konfigurálható és olcsó megoldást. Így születtek a NoSQL (not only SQL, nem csak SQL) adatbázisok. A név kissé félrevezető lehet, hiszen az SQL lekérdező nyelv használatát érinti általában legkevésbé az adattárolás elosztott mivolta. A tranzakciókezelés ezáltali megváltozásáról a Banki tranzakciók fejezetben írok. A NoSQL adatbázisok esetén gyakorta a relációs adatmodellt is elvetik. A rögzített sémájú sor-oszlop felépítésű táblák olykor rugalmatlanok, mivel megkövetelik az adatsémák előzetes definiálását, valamint kevésbé illeszkednek a feldolgozandó összetett, gyakorta hierarchikus rendben felépített objektumok/dokumentumok szerkezetéhez. Ilyenkor egy dokumentum tár áll kézre, amilyen a MongoDB is. Máskor szükség lehet az adatok közti kapcsolatok bonyolultabb ábrázolására, több lépésben összekapcsolt elemek bejárására. Ekkor egy gráf adatbázis használható hatékonyan, például a Neo4j. Gyorsítótárként való alkalmazáshoz és strukturálatlan adatok gyors eléréséhez viszont egy kulcs-érték tár lehet a legmegfelelőbb. Ilyen NoSQL adatbázisok egyike a Redis.

A világ túloldalán

Hiába gyors a rendszerem helyileg, ha az ügyféligények több régión átívelő, integrált szolgáltatást követelnek. A NoSQL adatbázisok elosztott adattárolást tesznek lehetővé. Ezt érdemes kihasználni különböző földrajzi régióra kiterjedően is, ha az üzleti érdek úgy kívánja. Természetesen a több régiós jelenlét nem csak technikai, hanem jogi, gazdasági és biztonsági kérdéseket is felvethet. Ezek egy részét megoldhatják vagy egyszerűbbé tehetik az úgynevezett felhőszolgáltatók. A felhőben az üzemeltetés jelentős részét a szolgáltató veszi át, jól tervezhető költségek mellett. Vannak szabványos és egyedibb megoldások is. Például az Azure CosmosDB egy többmodelles NoSQL adatbáziskezelő rendszer, ami csak a Microsoft felhőjében érhető el valós üzemi használatra. Azonban rendszerint az egyénileg is telepíthető, elterjedt adatbáziskezelő rendszereket is megkaphatjuk felügyelten, szolgáltatásként. A legtöbb adattárolási mód és adatbázis elérhető így a jelentősebb felhő szolgáltatóknál.

Banki tranzakciók

Amikor egy ATM automatából készpénzt veszünk fel, az egy több műveletes tranzakció. A tranzakció több ponton is félbeszakadhat. Ekkor nem történik egyenlegváltozás. Ha viszont sikeresen végbemegy a tranzakció, annak hatása azonnal megjelenik a bankszámlánkon. A felvett összeggel már nem rendelkezünk a bankszámlánkon. A világ akármelyik másik automatájánál próbáljuk azt újra felvenni, az csak akkor fog sikerülni, ha maradt még elegendő összeg a számlán. Az ACID (atomicitás, konzisztencia, izoláció, tartósság) tulajdonságokat egy hagyományos relációs adatbáziskezelő rendszer rendszerint önmagában teljesíteni tudja. Több, tranzakcióba foglalt műveletnek ezáltal csak együttesen van hatása. Egy sikertelen művelet hatására a tranzakció összes addig lefuttatott művelete visszavonásra kerül. Egy félig lefutott tranzakció műveleteinek hatása egy másik, párhuzamos tranzakcióból rendszerint még nem látszik.

A NoSQL és Big Data rendszerek ilyen erős garanciákat rendszerint nem tudnak biztosítani, pont az elosztott adattárolásból adódóan. A CAP-tétel szerint a konzisztencia - rendelkezésre állás - partícionálhatóság háromszög által kijelölt tulajdonságokból egyszerre csak kettő teljesülhet biztosan. Ez azt jelenti, hogy egy elosztott rendszerben tárolt adatok esetén, meg kell várnunk az adatok szinkronizációját, így előfordulhat, hogy nem kapunk azonnal választ, azaz a rendszer nem lesz mindig elérhető. Vagy belátható időn belül mindig válaszol a rendszer, de ekkor az elosztott komponensek között ideiglenes inkonzisztencia lehet. Egyes esetekben viszont pont az adatok elosztottságát, a partíconálhatóságot adhatjuk fel az adatok ésszerű szervezésével. Ugyanis adódhatnak olyan adatok, amelyeket elegendő helyhez, régióhoz vagy időhöz kötötten hatékonyan kezelni.

A fokozatos (vagy esetleges) konzisztencia, eventual consistency elmélete szerint egy becsülhető maximális időn belül a rendszeren belül minden olvasási művelet az aktuális állapotnak megfelelő eredményt adja majd, amennyiben nem hajt végre a rendszer további írási műveletet.

A szigorú konzisztencia és tranzakciókezelés még nem jelenti azt, hogy egy korszerű NoSQL rendszerben nem lehet pénzügyi vagy banki adatokat tárolni. Csupán körültekintően kell eljárnunk a fejlesztéseknél. Tisztában kell lennünk azzal, hogy a rendszerünk milyen garanciákat biztosít alapesetben és a továbbiakat milyen módszerekkel és milyen áron tudjuk pótolni.

Volumen, változatosság, gyorsaság

A Big Data rendszerek nagy méretű, változatos, gyorsan érkező és továbbítandó adatok feldolgozására képesek, a korábbi, kevésbé speciális rendszerekkel szemben. Ilyen adatok lehetnek például az IoT eszközök, szenzorok által gyűjtött adatok. Ipari, értékesítési, államigazgatási és egyéb területeken is jellemző napjainkban, a nagy mennyiségű adatok gyűjtése és elemzése. Hagyományosan az adattárolás és adatelemző feldolgozás gyakran külön válik, a számítások és az adatok szétosztása külön történik meg. Számítások során az adatot mozgatjuk a feldolgozó egységek között. A Big Data elve ettől eltér. A számítást viszi az adatokhoz. Célja, hogy adatok helyben feldolgozhatók legyenek, minél kevesebbet kelljen őket mozgatni. Az adatokat redundánsan olyan elosztott fájlrendszerben tárolja, amely részegységenként képes műveleteket végrehajtani rajtuk. Az egyes adatrészek mozgatását hatékonyan tudja koordinálni a feldolgozás, elemzés során. Az elosztott fájlrendszer fölött különböző adattárolási formátumok támogatására képes. Táblás (Bigtable, HBase), oszlopos szervezésű (Parquet), felsőbb szintű adatformátumok elérhetők. Egyes megoldások célja az volt, hogy nagy adattömegeket hasonlóan lehessen kezelni, mint a relációs adatbáziskezelő rendszerek esetében. Big Data rendszernél gyakori, hogy az adatokat már az elosztott fájlrendszeren tároljuk, de még nem rendelkeznek meghatározott adatsémával. A sémát kézzel vagy automatikus elemzés révén társítjuk az adatokhoz, majd ha ez megtörtént, SQL vagy ahhoz hasonló lekérdező nyelven alakíthatók az adatok tovább, majd betölthetők egy másik adatkezelő rendszerbe. A Big Data rendszerekben végrehajtott műveletek, átalakítások során az adatok tömege, változatossága, gyorsasága lecsökken, szűrések, közös sémára alakítás, aggregáció révén, így azok alkalmasak lesznek tartós megőrzésre, valamint relációs és NoSQL adatbáziskezelő rendszerekben való tárolásra és további feldolgozásra.

Idősoros adatok

Ipari és banki környezetben gyakoriak az időrendben tárolt és idő szerint kezelt adatok. Az IoT, az Ipar 4.0 rendszerek szenzor adatai, a bankok által vezetett számlatörténetek, portfólió és árfolyam adatok mind idősorként tárolhatók és elemezhetők. A hagyományos adatbáziskezelő rendszerek nehezen birkóznak meg efféle adatok kezelésével. Szükség lehet egy kifejezetten erre a célra tervezett megoldás használatára a hatékony adatkezeléshez. Ennek kapcsán különböző gyártók kezdtek saját idősoros adatbáziskezelő rendszer fejlesztésébe, vagy már egy meglévő rendszer kiterjesztésébe idősoros adatkezelési funkciókkal.

Térképi adatok

Az idősoros adatok mellett, a térinformatikai (GIS), helyhez köthető adatok tárolása is tartogat néhány kihívást. GIS esetén jellemzőbbek az adatbázis kiegészítők, mint a különálló dobozos megoldások. Az általános lekérdezések mellett egy térinformatikai rendszerben megjelenik a “pont része-e egy sokszögnek?”, “milyen messze van két objektum egymástól?”, “hogyan és milyen elemeken keresztül juthatunk el egyik pontból a másikba” típusú kérdések is. Nem egyszer része a térinformatikai rendszernek a koordináták mellett a térképek grafikus biztosítása, megjelenítése is.

Fontos megemlíteni, hogy a kültéri, globális koordináták mellett épületek belsejében is használhatók térinformatikai megoldások. Amikor egy szoba felszereltségét, wifi hálózattal való lefedettségét, egy raktár árukészletét, egy gyártósor termelését vizsgáljuk, szintén kapóra jönnek az adatbázisok térinformatikai funkciói.

Létezik csodafegyver?

Felmerülhet a kérdés, hogy a fent felsorolt külön célokra mind különböző adattárolási és feldolgozási megoldást kell választanunk vagy létezik olyan adatbáziskezelő rendszer, amelyik valamennyi szempontnak és alkalmazási területnek megfelel?

Leginkább azzal járhatunk jól, ha követjük az ipari trendeket, bevett szokásokat és nem maradunk az innovációs versenyben sem. A kiválasztandó megoldást meghatározhatja az annak alkalmazásához szükséges szakember igény is, a meglévő szakemberek ismeretei is, az egyéb költségek mellett.

Az üzemeltetési költség nagyon fontos tényező.

Konkrét megoldásként megemlíteném a PostgreSQL adatbáziskezelő rendszert. A PostgreSQL rendelkezik a hagyományos relációs adatmodellel, de emellett képes szabadszavas keresésre is a megfelelő indexek hozzáadásával. Képes dokumentumokat kezelni, JSON és JSONB formátumban. A dokumentumok nem kell, hogy rögzített sémával rendelkezzenek, mégis azokat mező szinten tudja a rendszer indexelni.

A nyílt forráskódú PostgreSQL-hez ingyen beszerezhető térinformatikai és idősoros adatokat kezelő modul is. Egy érdekes, új változata, gráf adatok kezelésének képességével egészíti ki a rendszert. Ha nem is létezik csodafegyver, a PostgreSQL rendszer a rengeteg testreszabási és bővítési lehetőségével, hatékonyságával és particionálhatóságával többféle szempontnak és felhasználási területnek is megfelel. Felhőben szolgáltatásként is elérhető, ám egyénileg is testre szabható. Jó dokumentációval és széles felhasználói bázissal, támogató közösséggel rendelkezik.