Timesten 11.2.1 - rengeteg újítással

A TimesTen fejlesztőcsapata új verziót adott ki a memóriarezidens-adatbázisból. Első pillantásra a legszembetűnőbb változás, hogy új számozással látták el a frissített terméket. A legújabb verzió TimesTen 11.2.1.1.0 néven érhető el. A sorszám első három tagja a TimesTen kiadás sorszáma, tehát 11g release 2, az utolsó kettő pedig a patch sorszámára utal. Azt nem tudom, hogy a 7.0.5 után miért lett egyből release 2, de mindenesetre jobb, mintha release 1 lenne, mert sokan csak a 2-től tekintik használhatónak a termékeket. Marketing?

Platformok

Az új verzió egyelőre csak Linux 32/64 biten, ill. Windows 32 biten érhető el, azonban az Oracle-t ismerve meg sem állnak, míg el nem jutnak legalább 10 különböző platformig. Itt olvasható, hogy a jövőben milyen platformokon lesz elérhető az adatbázis: TTplatform

Újdonságok
Nézzünk pár érdekes újdonságot. Először is örömmel jelenthetem, hogy végre a TimesTen is támogatja a PL\SQL nyelvet, de... Sajnos nem minden platformon, a Windows rendszert használók nem élvezhetik a kibővített SQL nyújtotta előnyöket. Ettől eltekintve mindenképp az új verzió egyik mérföldkövének tekintem ezt a fejlesztést.
Új támogatott platformok
Bővült a támogatott platformok listája az alábbiakkal:

• AIX 6.1
• Asianux 3.0
• Monta Vista 5.0
• Windows Vista
• Windows Server 2008.

Itt halkan megjegyzem, hogy volt szerencsém már korábban tesztelni Windows Vistán (32 és 64 bitesen egyaránt) és igaz akkor még nem volt hivatalosan támogatott, de gond nélkül lehetett használni. Természetesen csak teszt célokra érdemes, mert ha egy éles rendszert építünk valamilyen nem támogatott platformra, és valamilyen funkció nem működik megfelelően, akkor az Oracle-s kollégák csak széttárt kézzel azt fogják mondani, hogy ha "...nincs a listán, nincs mit tenni"...
Cache Grid
További érdekes újítás, hogy a TimesTen Cache-t tovább gondolták és az Oracle Coherencehez hasonlóan egy speciális grid funkcióval látták el - Cache Grid. Ennek segítségével az egy csoportba tartozó TimesTen példányok elosztottan képesek együttműködni, ezzel is növelve a megbízhatóságot, rendelkezésre állást és nem utolsó sorban a teljesítményt, ráadásul lehetővé válik a horizontális skálázhatóság is. A dokumentációkat olvasgatva úgy találtam, hogy a fejlesztők egy olyan eszközt adtak ki a kezükből, ami egy kezdő TimesTen felhasználó számára sem okozhat gondot. Erősen ajánlott a Cache Grid funkciót automatikus beállításokkal használni, azaz dinamikus betöltéssel és az Asynchronous writethrough (AWT) funkció bekapcsolásával. Ekkor szinte semmiféle további hangolásra nincsen szükség.
Clusterware
Az újdonságokat mazsolázva még egy fontos dolgot emelnék ki. Mostantól a TimesTen adatbázisokat is lehet Clusterware-rel együtt használni, ami tovább növeli az integrálhatóságát Oracle rendszerekbe. Ennek segítségével egy olyan köztes réteg jön létre, amin keresztül a node-okat monitorozhatjuk és azonnal beavatkozhatunk, ha valami probléma lépne fel. Ráadásul az alkalmazások szemszögéből egyetlen szervernek látszik a kiszolgáló rendszer, így jól skálázható, lehet használni több, olcsóbb szervert is akár, nem kell egy nagyteljesítményű, drágát vásárolni.

Természetesen további újdonságok is megjelentek, én csak a legérdekesebbeket emeltem ki. Ezekről bővebben Sárecz Lajos blogjában olvashattok, részeltesen pedig itt: TimesTen Release Notes 11.2.1

Ezzel a verzióval úgy érzem sokat tett az Oracle afelé, hogy a TimesTent befogadják szélesebb körben is a rendszerfejlesztők, ne csak úgy tekintsenek rá, mint egy jópofa, de semmire sem jó játékra. Látszik, hogy eltökélt szándéka a terméket közös alapokra helyezni más termékeivel, így is elősegítve az integrációt már szoftvereivel. Összességében elmondható, hogy egy nagyobb mérföldkőhöz érkezett a TimesTen a korábban felsorolt újdonságok miatt, és érdemes számításba venni rendszertervezéskor, mert felahsználása immár rengeteg előnnyel jár.

Tank War 3D

Az elmúlt időszakban az időm nagyrészét az kötötte le, hogy teljesítsem a maradék egy tárgyat, amit a diploma előtt még meg kell csinálnom. Igen, a Számítógépes grafikáról van szó. Ez a negyedik félév, hogy hallgatom. Aláírást már az elsőben szereztem és minden félévben ott voltam legalább két vizsgán, de nem sikerült átugranom Szirmay tanárúr lécét. Vagy a léc volt rossz, vagy a tanár gonosz. Nekem mindig úgy tűnt, hogy az utóbbi.
Ebben a félévben mindent egy lapra feltéve az összes kötelező és opcionális évközi feladatot megcsináltam, hogy jó eséllyel pályázzak megajánlott jegyre, elkerülve a vizsgán való számonkérés gyötrelmeit. Ez négy kisházit és egy nagyházit jelent. A kisházik szigorúan specifikált feladatok megoldását jelenti, a nagyházi pedig egy teljesen önálló ötlet megvalósítását.
A félév elején egy látványos fizikával megáldott tereprallli-szerű játékot akartam csinálni, azonban ez változott, és az utolsó kisházi után úgy döntöttem, hogy egy egyszerűbb fizikával megáldott tankos-lövöldözős játék fejlesztésébe fogok. A határidőig 3 nap volt hátra, így nem sokat pepecselhettem. A terepet úgy oldottam meg, hogy rombolható legyen, valamint bármilyen domborzatot elő lehessen álíltani egy egyszerű képfájlból. A tankok irányzékot tudnak állítani, valamint tűzerőt. A kilőtt lövedék ballisztikus pályán repül a becsapódási pontig és figyelembe veszi a szélirányt és erősséget. A játékmenet a klasszikus 2D-s játékkal megegyezik, tehát egymás után célozhatnak és lőhetnek a tankok. Az nyer, amelyik hamarabb találja el a másikat. Szerintem elég jóra sikerült figyelembe véve, hogy ilyen kevés idő alatt kellett valamit prezentálnom.

Két videó a játékból:
Tank War 3D terep
Tank War 3D ingame

Külső program hívása adatbázis-kezelőből

Oracle

Az Oracle adatbázis-kezelője elérhető programozói interfészeken keresztül, mint például C-ből az OCI (Oracle Call Interface) segítségével, Javaból JDBC API-n (Java Database Connectivity) keresztül, .NET környezetből ODP.NET felhasználásával, vagy más programnyelvek esetén ODBC (Oracle Database Connectitity) segítségével. Az Oracle fejlesztők törekednek arra, hogy a napjainkban használt, szinte összes programnyelvből elérhető legyen az adatbázis, szállítóként pedig nem tehetik meg, hogy ne szenteljenek ennek elegendő figyelmet. Az egyes programnyelvekhez készített programozói interfészeken (API) keresztül azonban csak kliens-szerver architektúrában képesek a programok kommunikálni az adatbázis-kezelővel, tehát minden esetben csak a kliens kezdeményezhet, a szerver passzív szerepet tölt be. Szerepcsere ezzel a technológiával nem lehetséges.

ODP.NET (pl. C#) használata esetén lehetőségünk van a Database Change Notification featuret kihasználni, aminek a segítségével azonnal értesülhetünk az adatbázisban bekövetkezett változásokról. Ehhez a kliens oldali alkalmazásnak folyamatos kapcsolatban kell lennie az adatbázissal, így tudja feldolgozni az onnan kapott üzeneteket.

http://download.oracle.com/docs/cd/B28359_01/win.111/b28375/featChange.htm#CJAGGGHA

Van lehetőség szerveroldalon, az Oracle példány címtartományán belül Java alkalmazás futtatására. Ezen lehetőség felhasználásával összetettebb üzleti logikát lehet megvalósítani adatbázisoldalon, ráadásul jelentős IPC (Inter Process Comunication) és hálózati overheadet spórolhatunk meg vele. További előnye a megoldásnak, hogy az alkalmazás indítását szerveroldalon kezdeményezhetjük, így tetszőleges adatbázis esemény hatására lefuttathatjuk, például triggerek segítségével. A hátránya azonban az, hogy csak a Java nyelven implementált programjaink használhatóak.

Létezik azonban egy univerzális megoldás arra a problémára, hogy adatbázis oldalon kezdeményezve tetszőleges programnyelven implementált alkalmazást lefuttathassunk. Az Oracle a fejlesztők rendelkezésére bocsát egy olyan technikát, amivel mindezt megvalósíthatják. Lehetőséget biztosít arra, hogy C (vagy Java) nyelven implementált eljárásokat PL/SQL eljárásként meghívhassunk. Ez a technika a külső eljárásnak (External Procedure) hívása, ami nem más, mint DLL (Dynamic Link Library) hívás PL/SQL kódból. Ha pedig van rá mód, hogy akármikor meghívjunk egy C függvényt, akkor minden olyan más programnyelven implementált kódot képesek vagyunk futtatni, ami futtatható az adott környezetben, vagy egy szkript segítségével működésre lehet bírni.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#ADFNS1402

External procedure használata

Ahhoz, hogy egy C vagy Java nyelven implementált programot meghívhassunk Oracle környezetből, három feladatot kell helyesen megvalósítani: Load, Publish & Call.

Load

Először be kell tölteni a szükséges DLL-t vagy java osztályt, másképp nem tudjuk meghívni.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#i1006311

Publish

Utána rögzíteni kell a meghívható függvények nevét, paraméterlistáját és a visszatérési érték típusát. Ezek után szinte ugyanúgy kezelhető, mint egy belső PL/SQL tárolt eljárás.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#i1006405

Call

Nincs más hátra, mint a PL/SQL környezetből meghívni az így elérhetővé tett külső eljárásokat.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#i1007572

 
Microsoft SQL Server

Ugyan úgy, mint az Oracle adatbázis, az SQL Server is elérhető különféle adatbáziskapcsolat-kezelő API-kon keresztül (például ODBC). Java nyelvből a JDBC API, C# esetén pedig az ADO.NET használható. Ezeken keresztül azonban csak a kliens kezdeményezheti a kapcsolatot.

A .NET CLR (Common Language Runtime) integrálva van az SQL Server-be, így könnyen lehet olyan menedzselt .NET kódot (pl. C#) írni, amit tárolt eljárásként (Managed (CLR) Stored Procedure) lehet közvetlenül hívni a szerveroldali T-SQL kódból. Ennek a technikának az alkalmazásával elérhetjük, hogy bonyolultabb üzleti logikát is bele lehessen csempészni a szerveroldali programozásba. Értem itt ezalatt, hogy az adatkezelést a T-SQL-re bízzuk, azonban az adatok feldolgozását .NET kóddal végezzük, így mindenki azt csinálhatja amire kitalálták. .NET-ből akár más, tetszőleges program hívható/indítható.

http://msdn.microsoft.com/en-us/library/ms131045.aspx

Az SQL Server lehetőséget ad arra, hogy Microsoft Visual C vagy C++ kódot lehessen hívni szerver oldalról (Extended Stored Procedure). Ehhez kódunkból az Opends60.lib fájllal linkelt DLL-t kell készíteni, majd a sp_addextendedproc T-SQL tárolt eljárással regisztrálni. Ezek után már ugyan úgy használható, mint egy belső tárolt eljárás. A kód annak a címtartományában fog futni, ahonnan meghívták. Kezelése nagyon hasonló az Oracle External Procedure-éhez.

http://support.microsoft.com/kb/190987

HOUG '09

Véget ért az idei HOUG konferencia, melyen az elejétől a végéig részt vettem. Sajnálatosan az előadásom rajtam kívülálló okok miatt meghiúsult, azonban így is jól óreztem magam ez alatt a néhány nap alatt. Ezt nem csak a környezet alapozta meg, hanem a programok igényessége és szakmai változatossága is.
Azt hiszem a legnépszerűbb előadást Mocsai Lajos tartotta első nap, aki a sikeres vezetőről, és annak ismérveiről beszélt. Úgy gondolom a közönség nagyon évezte a beszédet, a tréner a végén vastapsot kapott.
Ezalatt a pár nap alatt sok ismerősöm tartott előadást, többek között Marton József Ernő (BME), Kocsis István (BME), Müller János (BME), Izsák Tamás (Független szakértő), Kardkovács Zsolt Tivadar (BME, U1 Kutató Központ), Sárecz Lajos (Oracle). Ha még engem is hozzávennénk a felsoroláshoz, akkor látható, hogy ezen a konferencián a Budapesti Műszaki és Gazdaságtudományi Egyetem (BME) egyre nagyobb számban képviselteti magát, ami az Oracle Hungary és az egyetem jó kapcsolatát mutatja. Misem bizonyítja ezt jobban, minthogy egy új, diákszekció is indult (Jövünk! címmel), ahol kizárólag diákok meséltek eddigi tapasztalataikról.
A szervezők gondoskodtak a szórakozásról is, minden este szponzorált programok voltak, melyek közül nekem a kedd esti GuitarHero tetszett a legjobban. Időt és energiát nem kímélve bandában zenélve szórakoztattuk magunkat és egymást (dobszekció rulez :D).
Az idei konferencia nagyon tetszett, rengeteg pozitív élménnyel és tapasztalattal tértem haza.

A közel valós idejű adattárház létrejöttének feltételei

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.

Memóriarezidens adatbázis-kezelő

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ért az 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.

[2]. Oracle Corporation. Oracle TimesTen Products and Technologies. Redwood Shores, California, U.S.A. : Oracle Corporation, 2007.

HOUG előadás

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.