Közel valós idejű adattárházat egy hagyományos adattárház módosításával hozhatunk létre. Ahhoz, hogy megfeleljen az elvárásoknak, és az üzleti igényeket ki tudja szolgálni, alapvetően három feltételnek kell eleget tennie:
Folyamatos adatintegráció, mely az adatforrásokból az adatokat közel valós időben gyűjti és tölti az adattárházba. [1][2]
Nagy rendelkezésre-állású analitikai környezet, melynek feladata a valós idejű adattárházra támaszkodva az üzleti döntéseket elősegítő összegzések és származtatott értékek előkészítése. Továbbá a felhasználóknak gyors hozzáférést biztosítani ezekhez az adatokhoz. [1][2]
Szabály alapú döntéshozó komponens, melynek feladata, hogy az analitikai komponensre támaszkodva bizonyos szabályrendszert felh asználva üzleti ajánlásokat kínáljon, valamint automatikus eseményeket generáljon üzleti alkalmazások számára. [1][2]
A CTF technológia bemutatása adattárház környezetben [3 old.: 5]
A folyamatos adatintegráció (1.) az adattárházak kezdetétől jelenlévő ETL (Extract, Transform & Load) folyamatot váltja le. Az ETL alapvetően kötegelt végrehajtásra lett kitalálva, ami a közel valós idejű megvalósításban nem kaphatott szerepet. Helyette egy CTF (Capture, Transform and Flow) modellt kell implementálni, ami a keletkezett adatokat begyűjti a forrásrendszerből, transzformálja a megfelelő formába, majd továbbítja a valós idejű adattárház felé. Ezt a harmadik fázist tekinthetjük úgy, mintha a sok különböző adatforrásból kinyert adatot egyetlen csőbe, adatfolyamként öntenénk. Természetesen a folyam célja nem csak egyetlen adattárház lehet, tetszőleges adattárak feliratkozhatnak rá, így többen is valós idejű adatokat kapnak. [3]
Mivel a CTF leváltotta az ETL-t, ezért az adattárházakban használatos egyik alapvető komponensre nincsen szükség, mégpedig az állomásoztató területre. A CTF modell a transzformációt „on-the-fly” végzi el, így nincsen szükség adattároló egységre, ahol a transzformáció előtt az adatokat tároljuk. A CTF technológia azért képes tárolás nélkül elvégezni ezt a műveletet, mert az ETL-el ellentétben nem kötegelten hajtja végre egyszerre sok adaton a transzformációt, hanem mindig csak egyen.
A valós idejű adattárház megvalósításnak a kulcsa, hogy míg az adatokat folyamatosan gyűjtjük egy valós-idejű partícióra, addig a forrásrendszerekből periodikusan érkező pillanatképeket is tároljuk egy statikus partíción. (ábra) A valós idejű partíción a forrásrendszerekből érkező adatok alapján az üzleti elemzésekhez szükséges aggregátumokat készítjük el inkrementális jelleggel. Ez a megvalósítás nem más, mint egy hagyományos adattárház, amit kiegészítünk egy valós idejű környezettel, így egyszerre van lehetőség részletekbe menő adatokat és előkészített aggregátumokat gyorsan felhasználni. [2]
A három komponensből a legfontosabb a folyamatos adatintegrációt (1.) végző folyamat. E nélkül nem lehetne megvalósítani a közel valós idejű adattárházat. Az analitikai komponens (2.) és a döntéshozó komponens (3.) nem feltétlenül szükséges a működéshez, de ha az összegyűjtött információt fel is szeretnénk használni, akkor mindenképpen érdemes implementálni őket.
Forrás: [1]. White, Colin. Real-Time Data Warehousing Heats Up. DM Review Magazine. augusztus, 2002. [2]. Araque, Francisco.Real-time Data Warehousing with temporal requirements. Granada, Spain, 2003. [3]. Vandermay, john.Considerations for Building a Real-time Data Warehouse. : DataMirror, 2002.
A memóriarezidens adatbázis-kezelők (Main Memory Database System - MMDS) bemutatására a legjobb módszer, ha a tulajdonságait a diszk rezidens, „hagyományos” adatbázis-kezelőkéhez (Disk Resident Database System - DRDB) hasonlítjuk, mert így válnak egyértelművé azok a képességek, melyek jellemzik ezeket a rendszereket.
Első közelítésben azt gondolhatnánk, hogy egy memória-adatbázis és egy diszk rezidens adatbázis között csak annyi a különbség, hogy az előbbi az adatokat a memóriában tartja, míg utóbbi a háttértáron. Ahhoz azonban, hogy a különbséget a kettő működése között ténylegesen megértsük, mélyebbre kell ásnunk. A két rendszer sajátosságait alapvetően a kétféle adattároló médium tulajdonságai határozzák meg, ezért ezek ismerete elengedhetetlen a működés megértéséhez.
A memória és a merevlemez különböző tulajdonságokkal rendelkezik mind az adattárolás, mind az adatok hozzáférése terén.
·A memória kikapcsolás után elfelejti tartalmát, a lemez nem.
·A memóriához való hozzáférési idő legalább egy nagyságrenddel rövidebb, mint a merevlemezé, ami teljesítmény kritikus rendszerek esetében fontos tulajdonság.
·A háttértár blokkszervezésű, ami a működéséből adódik, míg a memória direkt hozzáférésű. Éppen ezért a memória minden egyes megcímezhető egységnyi tartományát ugyan annyi idő alatt érhetjük el, míg a lemez alapú tárolás esetében ez az idő változó, ráadásul még egyazon blokk esetében sem tekinthető állandónak.
·A merevlemezen tárolt adatok szervezése fontos, mivel a lemez szekvenciális hozzáférés esetén jobb átlagos teljesítményre képes, mint véletlen hozzáférés esetén. A memóriában nem annyira fontos az adatok elrendezése a teljesítmény szempontjából.
·A processzor a memóriában lévő adatokhoz közvetlenül hozzá tud férni, míg a merevlemezen tárolt adatokhoz nem. Emiatt a memória-adatbázisban lévő adatok sérülékenyebbek ebből a szempontból.
Ezek a tulajdonságok alakították ki a memóriarezidens adatbázis-kezelő rendszer felépítését és működését. [1]
Az alábbiakban bemutatom, hogy egy memóriarezidens adatbázis-kezelő hogyan teljesíti egy adatbázis-kezelő jellemző funkcionális feladatait:
Konkurens adathozzáférés - Zárkezelés ugyanúgy megvalósítható, mint a diszkrezidens adatbázis-kezelő rendszerek esetében, azonban erre nem minden esetben van szükség. Mivel a memóriában sokkal gyorsabban férhetünk az adatokhoz mintha merevlemezen tárolnánk őket, ezértaz egyes műveletek is rövidebb ideig tartanak . Ez pedig azt jelenti, hogy a konkurens műveleteknek a valószínűsége is kisebb. Ebben az esetben megfontolandó a műveletek szekvenciális végrehajtása, mert a zárkezelés megvalósítása egy ilyen rendszerben jelentős overhead-et jelent.
Commit kezelés, tranzakciós naplózás - Mivel a memória sérülékeny, rendszerhiba esetén az adatok elveszhetnek. Ennek elkerülésére a tranzakciós műveleteket naplózni (tranzakciós log) kell és ezt a naplót olyan helyen tárolni, ahol védve van egy kritikus rendszerleállástól. A tároló média elsősorban merevlemez lehet, ami azt jelenti, hogy a költséges I/O műveletek teljes egészében nem eliminálhatóak egy memóriarezidens adatbázis rendszerből. Minden egyes commit előtt a változásokat ki kell írni a log (napló) fájlba.
Alternatív megoldásként szóba jöhet egy olyan architektúra, ahol a napló legfrissebb részét egy nem felejtő, kis kapacitású memóriában tároljuk. Onnan pedig egy független folyamat rendszeresen átmozgatja a bejegyzéseket a merevlemezen tárolt végleges log fájlba. A funkcionalitás mit sem változott, a tranzakciónak azonban sokkal kevesebbet kell a naplózás miatt várnia.
Adathozzáférés - A keresett rekordok megtalálásához az adatbázis-kezelő rendszerek indexelési technikát használnak. Diszkrezidens adatbázisokban B-fa indexet használnak, mert ez az indexelési eljárás a legmegfelelőbb a merevlemez adattárolási struktúrájához. Ez azonban a memóriában való kereséshez nem a legoptimálisabb. A T-fa kifejezetten a memória-adatbáziskezelők részére lett kifejlesztve. A legjobb megoldás azonban arra, hogy egy rekordot megtaláljunk a memóriában, hash táblák használata. Ezzel azonban intervallumkeresés nem hajtható végre. [2]
Adatkezelés - Minden egyes adatnak az adatbázisban van egy memóriacíme, mely a memória egy területére mutat. Ezzel könnyen lehet kezelni akár változó méretű mezőket is, mert egy rekordot a memóriában egy pointer gyűjtemény reprezentál. Ha egy táblának kicsi a kardinalitása, akkor az azonos értékeket csak egyszer kell tárolnunk, és elegendő csak erre a címre hivatkozni az érintett rekordoknak. Ez nagy adatméret esetén rendkívül hatékony adattárolást jelent.
Lekérdezés optimalizálás - A diszkrezidens adatbázis-kezelők lekérdezés optimalizálója a költséges I/O műveletek minimalizálását tartja elsődlegesen szem előtt.Ehhez költség alapú elemzéseket végez, mielőtt kiválasztani azt a végrehajtási tervet, mely a legrövidebb végrehajtási idővel kecsegtet. A memória-adatbáziskezelőkben ez a stratégia nem biztos, hogy a legjobb megoldást adja, mivel a legnagyobb költséget nem feltétlenül az adatok elérése jelenti. Sokkal inkább az egyes műveletek számítási ideje.Éppen ezért érdemes ezeket a műveleteket a lehető legjobban csökkenteni, úgymint indexek építése, felesleges adatmásolatok készítése. A lekérdezések optimalizálása ezért memória-adatbázisokban javarészt rendszerfüggő.
Helyreállítás kezelés - A biztonsági mentés és helyreállítás ugyanúgy működik, mint egy hagyományos adatbázis-kezelő rendszer esetében. A rendszer működéséről teljes mentést készíthetünk, amit a merevlemezen tárolunk. Ha ezt a tranzakciós naplózással kombináljuk, akkor egy teljesen megbízható rendszert kapunk, mert kritikus rendszerhiba esetén a memória tartalma törlődhet ugyan, de a biztonsági menésként tárolt checkpoint fájlból és az azóta eltelt tranzakciós naplóból a hiba előtti állapot teljes mértékben visszaállítható. Egy memóriarezidens adatbázis-kezelőnek a háttértárat kezelni csak naplózáskor és biztonsági mentés készítésekor kell, valamint helyreállításkor.
Teljesítmény - A hagyományos adatbázisrendszerek a teljesítményt elsősorban az I/O műveletek alapján becslik meg. Memória-adatbáziskezelő esetén alapvetően a műveletek processzorideje számít, tehát más metrika alapján számítható a teljesítmény, ennek ellenére a háttértárműveletek is befolyásolják azt. Ha a teljesítmény előbbre való, mint az adatok integritása, akkor nem kell tranzakciós naplózás. Ekkor azonban rendkívül sérülékeny a rendszer, és adatok veszhetnek el. Ha a legfőbb szempont az adatok biztonsága, akkor ezeket a háttértárigényes folyamatokat be kell kapcsolni, ami viszont a teljesítmény rovására megy. Természetesen a biztonsági mentés gyakoriságának állításával az átlagos teljesítmény mértéke befolyásolható, de a maximális teljesítményt a tranzakciós naplózás miatt biztosan nem érheti el.
API és védelem - Egy memória-adatbázisnak meg van az az előnye a diszkrezidenssel szemben, hogy a még nagyobb teljesítmény érdekében direkt kapcsolódási módot biztosítson a programozónak. Ez azt jelenti, hogy az adatbázis-kezelő a program rendelkezésére bocsátja az általa használt memóriaterületet, és objektumok helyett memóriacímeket küld ad át, így a program közvetlenül olvashatja ki a rekordokat. Ennek a módszernek az előnye, hogy nincs szükség felesleges objektummásolatokra a küldő pufferbe, hanem egyből kiolvasható az eredmény. Ez azonban a hátránya is, mivel csak körülményesen garantálható a többi adat biztonsága a memóriában. Ráadásul ez csak akkor használható, ha a program és az adatbázis-szerver egyazon hoszton helyezkedik el, mert közös memóriaterületet használnak. Természetesen a programok kapcsolódhatnak az adatbázishoz az egységes programozói interfészen (ODBC - Open Database Connenctivity) is.
Adatcsoportosítás – klaszterezés - Memóriarezidens adatbázis esetén nincsen szükség az adatok csoportosítására, mert a rekordokat egy-egy memóriacím azonosít a memóriában. Mindegy, hogy hol helyezkedik el, mert az nem befolyásolja az adathozzáférési időt. Ez azonban egy problémát is felvet, amikor diszkrezidens adatbázisba szeretnénk migrálni a memória-adatbázist, mert nem egyszerű eldönteni, hogy mely rekordok kerüljenek egy klaszterbe. [1]
Felmerülhet a kérdés, hogy ha egy memóriarezidens adatbázis-kezelőnek nem kell megküzdenie a rendkívül költséges háttértárműveletekkel, akkor miért nem használjuk őket a diszk alapúak helyett? Erre egyszerű a válasz. Azért nem, mert egy adatbázis sok esetben olyan nagymennyiségű adatot kezel, ami nem fér el a memóriában. Ez azonban nem azt jelenti, hogy ez a megvalósítás teljesen működésképtelen és használhatatlan. A memória előállításának költsége napjainkra drasztikusan lecsökkent, ezért a kereskedelmi forgalomban kapható modulok ára egyre alacsonyabbak lettek. A mai rendszerekben már nem ritka a 128GB, 256GB vagy akár az 512GB memória sem (ezek nagyon szerény becslések, mert vannak olyan top konfigurációk, melyekben akár 4096GB memória is lehet). Éppen ezért megfontolandó, hogy egy adatbázist memóriarezidens adatbázis-kezelőre bízzunk, vagy sem. Mivel a tárolási kapacitás egyre kevésbé jelent problémát, a minél jobb teljesítmény érdekében egyre több memória-adatbázis fog megjelenni.
Jelenleg sok esetben fordul elő, hogy egy hagyományos adatbázis ugyan nagy méretű, de szükség lenne a felgyorsítására memória-adatbázis segítségével. Ekkor az adatokat csoportosítani kell, hogy melyek azok az adatok, amelyeket sűrűn, rendszeresen használnak, és melyek azok, amelyeket csak ritkán. Ezek közül a gyakoribb adatokat érdemes a memória-adatbázisba tölteni, hogy azokat gyorsan el lehessen érni. Ha az adatbázisunk nem csak olvasható, akkor szinkronizációs problémák léphetnek fel a két adatbázis között, melyeket meg kell oldani (ez azonban implementációs kérdés). Az így létrejött architektúra tekinthető a hagyományos adatbázis kiterjesztésének egy memória-cache segítségével.
Mi a különbség egy memória-adatbázis és egy nagy pufferel rendelkező diszkrezidens adatbázis között?
Ha egy hagyományos adatbázisnak elegendő memória áll a rendelkezésére, hogy minden adatot a memóriában tartson, akkor gondolhatnánk, hogy így elérhetjük egy memória-adatbázis teljesítményét. Ez azonban tévedés, mert ekkor még mindig egy diszkrezidens adatbázis-kezelő kezeli az adatokat. Ahhoz, hogy egy alkalmazás hozzáférjen egy rekordhoz először a kezelő kiszámítja a diszken lévő helyét, utána a pufferkezelő lekérdezni, hogy esetleg a memóriában van-e? Mivel ott van, onnan átmásolja a küldő pufferbe, ahonnan az alkalmazás már elérheti a kívánt rekordot. Ehhez természetesen a blokkszervezésű, lemezre optimalizált B-fa indexet is fel kellett használni.
Ezzel szemben a memóriarezidens adatbázis-kezelő miután megkapta, hogy melyik rekordra van szükség, a hash táblával meghatározza a memóriacímet és ezt átadja az alkalmazásnak (direkt hozzáférés esetén). Ebből is látszik, hogy ez mennyi felesleges számítást spórol meg.
Forrás
[1]. Main Memory Database Systems: An Overview. Garcia-Molina, Hector és Salem, Kenneth. 1992., IEEE Transactions on Knowledge and Data Engineering, old.: 509-516.
Nagy örömömre szolgál, hogy az idei HOUG-on (nagy valószínűséggel) előadóként fogok részt venni. Az előadás a TDK-ra készített IPTV rendszerhez készített kiszolgáló rendszer prototípusát, a tervezés nehézségeit és a megvalósítást mutatja be. Az előadást természetesen nem egyedül fogom tartani, mivel a megoldás, amivel pályáztunk több embert is érint a tanszékről, a társam Kardkovács Zsolt lesz. A félév eleji megbeszélésekkor Sárecz Lajos leszögezte, hogy az idei HOUG részvétel feltétele lesz egy TDK dolgozat megírása, azt azonban remélni sem mertem volna, hogy ilyen szorosan fog kapcsolódni a HOUG-hoz. Számomra ez mindenképp nagy lehetőség, hogy gyakoroljam és fejlesszem előadási képességeimet nagyközönség előtt (reméljük sokan kíváncsian lesznek ránk), ráadásul a gyenge TDK szóbeli szereplésemet is javíthatom. Ezek az információk még nem hivatalosak, mert csak a pályázatot adta le Zsolt, a program még nem készült el az idei HOUG-ra. Ha majd ott szerepel a nevünk és témánk a programban, akkor válik véglegessé. Addig is érdemes néha ránézni a HOUG hivatalos honlapjára, hátha felkerült már a program.
A minap bukkantam erre a kis Viewlet-re, amely összesen 64 állomáson keresztül segíti a kezdő TimesTen telepítőket. A bemutató windows környezetben lett felvéve és nagyon szemléletesen mutatja be, hogy nem is kell olyan bonyolult utat bejárnunk ahhoz, hogy egy működőképes TT példányunk legyen kedvenc operációs rendszerünkön. Felhívnám a figyelmet azonban arra, hogy a telepítés egyszerűségével szemben a TimesTen példányunk és a DataStore-ok kezelése velősebb feladat. Ehhez segítséget itt találhatsz, a hivatalos dokumentációk között. Jó szórakozást!
Mint minden évben, idén is megrendezésre kerül a HOUG (Hungarian Oracle User Group) konferenciája április 6-9-ig. Az eseményre lehetőség van előadóként pályázni, melyről már több hírportál is beszámolt: computerworld, hwsw. A pályázat menetéről, feltételeiről és pontos kiírásáról a HOUG hivatalos weboldalán kaphatsz tájékoztatást. A helyszín a régi, a Balaton partján lévő Hotel Azúr, Siófok ad otthont a találkozónak. A tavalyi tapasztalatok alapján idén is érdekes és szakmai tartalomban gazdag előadásokat hallgathatunk végig, melyet az igényes környezet és a szálloda szolgáltatásai még kellemesebbé tesznek.
Ez a félév is eltelt és nem is kevés munkával. A korábbi bejegyzésemben beszámoltam a TDK-n belül végzett munkámról, tapasztalataimról. Ezen kívül az Önálló laboratóriumot is teljesíteni kellett, amihez nagyon jó alapnak szolgált a félév közben megírt dolgozat. A szóbeli beszámolót megúsztam, mert a TDK-val kiváltható volt, de az írásbelit meg kellett írnom. A legtöbb munkám nem a tartalommal, sokkal inkább a formai követelmények betartásával volt. 10-12 oldal terjedelmű beszámolót kellett írni. Nekem kb. 16 oldal lett volna kényelmes, ez azonban talán a 2-es jegyet sem érte volna el, ezért beltuszkoltam 12 oldalba. Visszajelzést majd csak a neptunból kapok, ha beírják a jegyet. A dolgozat itt érhető el.
Egy hónapja, hogy nem írtam a webnaplómba. Az elmúlt időszakban nem volt sajnos túl sok szabadidőm, mert a legfontosabb dolog a TDK munkám megírása volt. Ez azonban minden fáradtságot megért, mert a 2008-as TDK konferencián 3. díjat nyertem. A felkészülési időszakban nem telt el úgy nap, hogy ne foglalkoztam volna vele. A leadási határidő közelében pedig egyenesen "ennek éltem". Nem azért, mert szörnyen élveztem, hanem azért, mert elhatároztam, hogy megcsinálom. Ha már majdnem egy hónapnyi munkám benne volt, akkor az a két-három átdolgozott éjszaka nem számított. Az utolsó napokban nem sokat aludtam, a leadás előtti éjjel pedig semennyit. Mivel elég kevés idő alatt terveztük meg és írtam meg a dokumentációt, ezért nem lett tökéletes, de a körülményekhez képest szerintem egészen jól sikerült. Egy korábbi bejegyzésemben már említettem a témát, azonban részletesebben még nem mutattam be a tervezett rendszert, amely egyébként két Oracle11g adatbázisra épült, és mindegyikhez tartozott egy-egy TimesTen cache is. Egy egyoldalas összefoglaló itt olvasható: absztrakt. A TDK dolgozat leadása után kicsit szusszanhattam, de a munkának még koránt sem volt vége. Következett a konferencia, ahol szóban, 20 percben kellett bemutatni, hogy mit csináltam. Erre összesen két hét felkészülési időm volt. Mivel hátra volt még némi implementáció is, ezért az előadás előkészítésére szánt idő körülbelül megfeleződött. Az implementáció technikai akadályokba ütközött, így az előadásra nem tudtam elkészülni bizonyos mérésekkel. A Szoftver szekcióba kaptam jegyet, melynek elnöke a konferencián Dr. Pataricza András volt a MIT tanszékről. A részletes szekció program itt olvasható: Szoftver szekció, TDK, 2008 Szerencsére névsorrenben következtek egymás után az előadások, így harmadikként adhattam elő. Nagyon izgultam előtte, ezért nem éreztem magam magabiztosnak előadás közben. Ezt a 15 perces prezentáció utáni 5 percnyi kérdésnél tovább rombolták a jobbnál jobb kérdésekkel. Zsolt véleménye szerint a szóbeli előadásom előtt jobb helyen szerepelhettem a szekció rangsorban, mint utána. Van benne valami. Inkább túléltem, mint megéltem a prezentációmat. Se' baj, tanulópénz. Egy biztos, nagyon sokat tanultam belőle. És nem csak a szóbeliből, hanem a teljes 4+2 hétnyi munkával töltött időszakból.
A Budapesti Műszaki és Gazdaságtudományi Egyetem (BME) Távközlési és Médiainformatikai Tanszék (TMIT) Internet és Infokommunikációs Alkalmazásai szakirány VI. évfolyamos hallgatója.
