Oracle Database In-Memory

In-Memory adatbázis lényege, hogy (nem on-storage :)) mivel a memóriában tárolja az adatokat, iszonyat gyors. Ajánlják OLTP és OLAP (adattárház) adatbázisokhoz is. És pont ez az újdonság az új Oracle 12c-ben, hogy egyaránt optimalizálja az analitikus és OLTP munkaterületeket is, egy adatbázisban. Kimagasló teljesítményt ígér a tranzakciós műveleteknek, miközben ezzel párhuzamosan az analitikus feladatokat is ellátja.

Fontos megjegyezni, hogy ez nem egy új termék, csupán az adatbázis kezelő egy új funkciója az SGA-ban. Ha telepíted a 12c verziót, akkor telepítve lesz ez a feature is. A fontos kérdés az (annak, aki ki szeretné próbálni), hogy be van-e kapcsolva. Alapértelmezetten nincs, tehát be kell kapcsolni.


SQL > show parameter INMEMORY;

Az eredményben a inmemory_size sort kell keresni. Értéke 0 lesz. Be kell kapcsolni, azaz inicializálni:

alter system set inmemory_size = 20G scope=spfile;

Row Format vs. Column Format

Az Oracle hagyományosan sorokban (row format) tárolja az adatokat. Minden új bejegyzés egy tábla sorában tárolódik. A sornak oszlopai vannak, amik reprezentálják egy sor attribútumát, tulajdonságát. Ez ideális megoldás az online tranzakciós rendszerekben (OLTP), ahol gyorsan hozzá kell férni egy-egy oszlop értékéhez az adott sorban.

Column format, ami számomra újdonság. Ez tipikusan az analitikus lekérdezéseknek fekszik, kvázi arra való. Egy bejegyzés nem egy sorban tárolódik, hanem minden attribútum egy különálló mező struktúra. Lehetővé teszi gyorsabban kinyerni pár mező értékét viszonylag nagy adatbázisban is. 

Mi történik, ha egy DML művelet történik mindkét formátumon? 

Row format hatékonyan dolgozza fel az insert, update és delete műveletet. Column format viszont már kevésbé. Az In-Memory nyújt erre megoldást, hogy egyszerre lehetnek az adatok row és column formátumban tárolva. Fontos megjegyezni, hogy a dupla formátumú tárolás nem igényel dupla memória mennyiséget! 

Az egyedi dual-format architektúra igen jónak tűnik első hallásra, és nem kell aggódni a konzisztencia miatt, mert az adatbázis felügyeli a két formátum közt a teljes tranzakciós konzisztenciát, valamint az indexek és táblák is konzisztensek maradnak. 

Az Oracle Optimizer tudja, és felismeri a query-t, hogy az egy analitikus lekérdezés vagy egy OLTP művelet és a megfelelő formátum felé irányítja azt, biztosítva a megfelelő teljesítményt és az adatok konzisztenciáját.

Új formátum, új tárolási megoldást hozott

Column store az SGA egy új területét használja, aminek a neve In-Memory Area. Méretét az INMEMORY_SIZE inicializáló paraméter értéke adja meg (default 0). Ha nem tudjuk a pillanatnyi méretét, könnyen ellenőrizhetjük itt V$SGA. Mivel ez egy static pool az SGA-ban, az értéke nem módosítható restart nélkül. In-Memory area minimális mérete 100MB kell legyen. Két részre van felosztva: 1MB -ot használ a column formátumú adat tárolására a memóriában és 65K-on tárolja a metaadatokat, vagyis, hogy hol található az adat az IM column store-ban. Részletesebben: V$INMEMORY_AREA.

Erről kicsit részletesebben írtam itt

Korlátlanul skálázható

Az Oracle Database In-Memory nem követeli meg, hogy mindent adatot, amit az adatbázisban tárolunk, a memóriában kelljen tárolni, ez teljesen szabadon variálható mező szinten is (lást később). Amit nem akarunk memóriában tárolni, azokat egyéb eszközökön tárolhatjuk, a bővítési lehetőség szabhat csak határt. A felhasználó szempontjából ez teljesen transzparens.

Egyszerű lesz használni

Elvileg nagyon egyszerű lesz használni, beállítani, teljesen kompatibilis a megszokott Oracle adatbázis kezelőnkkel. Csak be kell állítani a memória méretét az SGA-ban, és fel kell paraméterezni az újonnan kapott területen tárolni kívánt objektumokat.

Mit érdemes tárolni IM column store-ban? 

Az ajánlás szerint nem szükséges minden adatot IM column store-ban tárolni, csak a teljesítmény szempontjából kritikus adatokat. A kevésbé teljesítményérzékeny adat továbbra is maradhat flash meghajtón illetve lemezen. Ahhoz, hogy egy tábla vagy nézet IM területen legyen, fel kell vértezni egy új attribútummal őket: INMEMORY. INMEMORY attribútum használható: táblatér, tábla (al)partíció vagy materializált nézeten. Értelemszerűen, ha táblatérre van beállítva ez a tulajdonság, akkor minden, ami ezen a táblatéren van, bekerül. Pl.:

alter tablespace tbs_comp_data INMEMORY;

Fenti példa, hogyan lehet bekapcsolni az INMEMORY tulajdonságot egy táblatéren. Ha egy táblát szeretnénk IM column területben tárolni, de nem minden oszlopot, akkor erre is lehetőség van:

alter table sales INMEMORY NO INMEMORY (prod_id);

Ebben az esetben a prod_id oszlop kimarad. Ugyan így, partíciókra is megadható egyenként, mert lehet, hogy vannak olyan partícióink, amiket már nem használunk, vagy csak nagyon ritkán, mert pl.: havi partíciók, és már nem szeretnénk hipergyorsan elérni.

Kivételek

Néhány megszorítás, amiket nem tudunk IM column-ban tárolni:

• SYS user tulajdonában lévő objektumokat
• Index szervezett táblákat
• Klaszterezett táblákat

Összefoglalva, az alapötlet, miszerint egy adatbázisban jól elfér egymás mellett OLTP és analitikus munkaterület, nekem nagyon tetszik, hiszen ez életszerű igény. Nem minden esetben engedhetik meg maguknak cégek, hogy külön adattárházuk legyen, és nem is szükséges minden esetben. Ezzel egyszerűsödik a hálózati topológia is, hiszen nincs(ennek) újabb dedikált szerver(ek).

További információkat találhattok a blogs.oracle.com-on vagy a weboldalon.