A mai általános adatbázis-kezelők már igen gyorssá tehetők. De vannak olyan környezetek, ahol ez sem elég gyors: oda kellenek a valós idejű adatbázisok.
A valós idejű (real time) működés számos vállalatnál nem pusztán szlogen, hanem kőkemény valóság. A hálózati eszközök gyártói, a távközlési szolgáltatók, a pénzintézetek, a brókercégek, a szállítmányozási vállalatok, no és persze a védelmi és hírszerző ügynökségek a megmondhatói, hogy az azonnali válaszokat adó informatikai rendszer milyen mértékben szükséges a sikeres működéshez.
Ha a múltban az ilyen szervezeteknek valós idejű alkalmazásokra volt szükségük, akkor ahhoz külön valós idejű infra-struktúra-szoftvereket is fejleszteni kellett, merthogy a kereskedelmi forgalomban ilyenek nem léteztek. Az egyedileg fejlesztett szoftverek is lehettek gyorsak, de ezzel együtt általában rugalmatlanok is voltak: mindaddig jól végezték a dolgukat, amíg az alkalmazások követelményei nem változtak. De a mai dinamikus üzleti környezet és az annak megfelelni akaró vállalat gyorsan túllép a statikus alkalmazásokon; az egyedi infrastruktúra-szoftverek fejlesztésének, tesztelésének és üzemeltetésének költségei ritkán igazolhatók, ha létezik kereskedelmi forgalomban is kapható alternatíva.
A valós idejű vállalat
Ahogy egyre nagyobb számban és egyre nagyobb sebességgel zúdulnak rá az információk az üzleti rendszerekre, úgy válik egyre sürgetőbb követelménnyé minden vállalat számára, hogy valós idejű feldolgozással rögzítse és elemezze a kulcsfontosságú eseményeket, hogy aztán megalapozott lépéseket tudjon tenni az információk birtokában. És ez nem csupán a kritikus üzleti folyamatok végrehajtásának és felügyeletének esetében lényeges. Az ügyfelek minél inkább testre szabott együttműködést és a lehető legnagyobb reagálóképességet várják el minden olyan cégtől, amellyel komoly üzleti kapcsolatban állnak.
Mindeközben az adatok rögzítésére és feldolgozására szolgáló alkalmazások már nem feltétlenül a háttérben „meghúzódva” működnek, hanem mintegy a kirakatban, felhasználói pedig nemcsak a vállalat belső dolgozói lehetnek, hanem ügyfelek, üzleti partnerek is. Az ilyen alkalmazások sok esetben dinamikus kapcsolatban állnak egymással egy szolgáltatás-orientált architektúra (SOA) ernyője alatt.
Átrendeződő architektúra
Azok a vállalati architektúrák tudják a leginkább kihasználni a valós idejű feldolgozás kínálta előnyöket, amelyek az alkalmazási rétegben biztosítják az esemény-, adat- és tranzakció-kezelést – mert így lehet minél nagyobb tudással felvértezni az első vonalban álló rendszereket, és így lehet felkészíteni őket a minél gyorsabb válaszokra. Ezek az alkalmazások sok esetben nem a központi rendszereken, hanem a hálózat pereméhez közel működnek, esetleg magán a hálózaton, beágyazott szolgáltatásként.
Mára már elég sok ilyen alkalmazás gyűlt össze a vállalatoknál ahhoz, hogy egy teljesen új – a korábbitól eltérő platform-, teljesítmény- és rendelkezésre állási követelményekkel bíró – alkalmazásréteget alkossanak a vállalati informatikai infrastruktúrában. Az üzleti események hálózati üzenetekben jelennek meg; az alkalmazások „előfizetnek” ezekre az üzenetekre, amelyek valós idejű feldolgozási feladatokat, majd ezek alapján újabb üzeneteket generálnak. Ahhoz, hogy ezeknek az alkalmazásoknak a válaszidőkkel és a méretezhetőséggel kapcsolatos elvárásainak meg lehessen felelni, gyakran velük azonos platformra kell helyezni az infrastruktúrához kapcsolódó szoftvereket és programokat – beleértve az alkalmazások működtetéséhez szükséges adatok egy részét vagy egészét is.
Az már nem elég, amivel oly sokszor próbálkoztak saját erőből a vállalatok, nevezetesen, hogy összegyűjtik és egy átmeneti tárolóban az alkalmazások mellett elérhetővé teszik az adatokat. Az sem praktikus, ha a vállalati háttéradatbázist lemásolják, és alkalmazásként kiteszik a többi mellé. Ehelyett olyan infrastruktúra-szoftverre van szükség, amely ismerős kezelőfelületet és széles körben használt lekérdezőnyelvet kínál; amely könnyedén tud összekapcsolódni a meglévő háttér-adatbázisokkal, üzenetkezelő rendszerekkel és alkalmazásszerverekkel; és amely képes teljes mértékben kihasználni a mai, memóriában gazdag, hálózatba kötött számítógépes platformok teljes számítási teljesítményét.
Adatok a memóriában
A fenti kritériumoknak megfelelő szoftverek közé tartoznak az úgynevezett memóriában futó (in-memory) adatbázis-kezelők (IMDB), például az Oracle által fejlesztett és forgalmazott TimesTen. Az IMDB technológia szerint megvalósított relációs adatbázis futás közben az összes adatot a memóriában (RAM) tárolja, de az adatstruktúrák és a hozzáférési algoritmusok is úgy lettek kialakítva, hogy a minél nagyobb teljesítmény elérése érdekében kihasználhassák ezt a jellemzőt.
Reagálóképesség és sebesség
A technológia annak révén éri el a hagyományoshoz képest többszörös teljesítményt, hogy egészen másképp gondolkodik arról, hol is kell lennie az adatnak működés közben. Azzal, hogy minden adatot a memóriában kezel, és erre a környezetre optimalizálja működését, az IMDB-technológia sokkal hatékonyabb tud lenni, és így drámai javulás érhető el az adatbázis reagálókészségében és átviteli sebességében.
De miben is különbözik ez a technológia attól a hagyományos adatbázisoknál (RDBMS) is ismert eljárástól, hogy az összes adatot beolvassák a központi memóriába? Az RDBMS-ek egész működése arra az alapfeltevésre épül, hogy az adatok alapvetően a merevlemezen tárolódnak. Az optimalizáló algoritmusok, a pufferkezelés, az indexelt adatok előhívásának mechanizmusa mind úgy készült, hogy ezt az alapvető előfeltevést tartották szem előtt.
Az IMDB-technológia ehhez képest tudja, hogy az adatok a központi memóriában vannak, így sokkal közvetlenebbül elérheti az adatokat, egyszerűsítheti mind az algoritmusokat, mind az adatstruktúrákat.
Egy memóriában futó adatbázis sokkal kisebb terhelést jelent a CPU-nak, mert megszünteti azt a „vízfejet”, amelyet a memóriapufferek és a több helyen (lemezen és memóriában) tárolt adatok kezelése jelent. Az IMDB-adatbázisok nem elsődleges tárhelyként használják a merevlemezeket, hanem csupán biztonsági tárolásra és helyreállításra.
Különbségek
Az IMDB és a hagyományos RDBMS-ek architektúrája között több alapvető különbség is van, amelyek jól mutatják, hogyan érhető el a többszörös teljesítménynövekedés. Az RDBMS-ek lekérdezés-optimalizáló algoritmusainak például arra a legrosszabb esetre kell felkészülniük, hogy az adat a merevlemezen van (ezért a lemezműveletek felgyorsítására vannak kihegyezve) – ez viszont nem fog optimális teljesítményt adni, ha az adat mégis már a memóriában van. Az IMDB-technológia nem kénytelen ilyen előfeltevésekkel élni, ezért egyszerűbben tudja optimalizálni a lekérdezéseket, és könynyebben tudja elérni a maximális hatékonyságot.
A hagyományos RDBMS-architektúrában átmeneti tárolót (buffer pool) kell fenntartani a központi memóriában elhelyezett adatok számára. Amikor az SQL-lekérdezésnek szüksége van valamilyen adatra, először az átmeneti tárolóban keresi, de ha még ott meg is találja, sok esetben ki kell másolnia további feldolgozásra. Az IMDB-rendszerekben erre nincs szükség. Minthogy az adatok már eleve a memóriában vannak, nem kell átmenteni tárolót kialakítani. Nincs másolás, az algoritmusok egyszerűbbek, és az adat gyorsabban elérhető az alkalmazás számára.
Elegánsabb működés
A példákból is jól látszik, hogy amikor az adatbázis működéséből eltávolítjuk azt a feltételezést, hogy az adatok a merevlemezen találhatók, nagymértékben leegyszerűsödik a szoftver működése. A gépi utasítások száma minimum a tizedére csökken, eltűnik az átmeneti tár kezelése, nincs szükség további adatmásolatokra, az indexoldalak mérete pedig zsugorodik, struktúrájuk egyszerűsödik. Amikor az adatok memóriában való tárolása a központi, mindent eldöntő alapfeltevés, a működés egyszerűbb, elegánsabb, tömörebb és gyorsabb lesz.
Természetesen számtalan tényezőtől függ, hogy egy tényleges alkalmazás sebességén mennyit javít a memóriában futtatott adatbázis-kezelő alkalmazása. (Ami a nyers teljesítményt illeti: egy négyprocesszoros rendszeren egy másodperc alatt 250 ezer adatbeolvasást vagy 100 ezer adatfrissítést tudott végrehajtani a rendszer; az üzleti alkalmazások működése persze más rendszerkomponenseken is múlik.) A legnagyobb teljesítménynövekedést azok az alkalmazások könyvelhetik el, amelyek közvetlenül (nem ügyfél–kiszolgáló architektúrában) kapcsolódnak az adatkezelő rendszerhez, aszinkron módon tudják naplózni a változásokat, és komoly adatkezelő komponensük van. Tipikusan ilyen alkalmazások a sok keresést használó online helyfoglaló rendszerek, a jelenlétre és helyszínre alapozott kommunikációs szolgáltatások és a contact centerek útválasztó rendszerei.
Összeállította: Schopp Attila
