Vybrané nové vlastnosti Informix 11

Vybrané nové vlastnosti Informix 11 Jan Musil [email protected]

Informix CEE Technical Sales

1 © 2012 IBM Corporation

Přehlede prezentace Administrace a architektura Rozšíření SQL Bezpečnost Vysoká dostupnost Informix TimeSeries Informix Warehouse Accelerator Informix Genero

2 © 2012 IBM Corporation

Administrace a architektura

Nová správa databázových rozšíření (DataBlade moduly) Nové typy fragmentace (LIST, INTERVAL) On-line správa fragmentů tabulek Automatické přidávání CPU VP při startu serveru Detekce chybných indexů Ukončení nečinných uživatelů Detekce nadměrného počtu In-Place verzí stránek Defragmentace Automatická optimalizace tabulkových prostorů Storage Provisioning Správa sdílené paměti v kritických situacích Privátní non-root instalace © 2012 IBM Corporation

Nová správa databázových rozšíření

Většina základních rozšíření (Data Blade moduly) je k dispozici zdarma Následující rozšíření jsou standardní součástí instalace a do databázového serveru se registrují automaticky – TimeSeries – Spatial – Basic text search – Node data type – Binary data types – Large object locator – MQ messaging – Web feature service Automatická registrace se provede při prvním použití jakékoliv komponenty rozšíření

© 2012 IBM Corporation

Nové typy fragmentace – LIST Fragmentace podle seznamu izolovaných hodnot

Fragmentační klíč může být i výraz nad položkou resp. složený výraz FRAGMENT BY LIST (SUBSTR(phone, 1, 3)) FRAGMENT BY LIST (fname[1,1] || lname[1,1]) V seznamu nejsou dovoleny duplicitní hodnoty a lze lze použít pouze konstanty (nikoliv proměnné) Jsou povoleny fragmenty typu Remainder a NULL © 2012 IBM Corporation

Nové typy fragmentace – RANGE INTERVAL Fragmentace podle intervalu hodnot

Fragmentovaná tabulka má definovaný počáteční seznam fragmentů Pokud nově vkládaný záznam neodpovídá žádnému existujícímu fragmentu, IDS vytvoří automaticky nový fragment v databázovém prostoru ze seznamu (prostory jsou vybírány metodou round robin) Fragmentační klíč může být pouze jedna položka nebo výraz nad jednou položkou Fragmentační klíč může být numerický nebo datového typu DATE nebo DATETIME © 2012 IBM Corporation

On-Line správa fragmentů tabulek

Operace ALTER FRAGMENT ONLINE nezamyká tabulku exklusivně, ale pouze intentexclusive zámkem – to dovoluje uživatelům současně provádět SELECT, UPDATE, DELETE, INSERT a MERGE operace V on-line režimu lze provádět následující operace – ALTER FRAGMENT ONLINE …. ATTACH – ALTER FRAGMENT ONLINE …. DETACH – ALTER FRAGMENT ONLINE …. MODIFY Operace ONLINE … ATTACH, DETACH a MODIFY lze provádět pouze na tabulkách s range interval fragmentací ONLINE DETACH lze provádět pouze na automaticky přidané fragmenty ONLINE MODIFY lze provádět pouze na „hraniční“ hodnotu mezi range fragmenty a automaticky přidanými fragmenty Přidávaný resp. odpojovaný fragment se zamyká stále exklusivně Další podmínky použití – viz Informix SQL Reference Guide


Automatické přidávání CPU VP při startu serveru

Zajišťuje minimální doporučený počet CPU VP k počtu jader počítače optimální pro většinu aplikací – Počet CPU VP = MIN(polovina počtu jader,8) CPU VP se do požadovaného počtu alokují při startu IDS Vypnutí vlastnosti (databáze sysadmin) UPDATE ph_task SET tk_enable = 'F' WHERE tk_name = 'auto_tune_cpu_vps'; Příklad


Detekce chybných indexů

Nový task bad_index_alert() detekuje všechny chybné indexy V tabulce ph_alert databáze sysadmin vytvoří alert Detekce se automaticky spouští jednou denně (lze nastavit jinak) Lze použít místo manuálně spouštěného oncheck –cI SQL příkaz pro detekci chybných příkazů SELECT k.partnum, dbsname, trim(owner)||"."|| tabname AS fullname INTO p_partnum ,p_database , p_fullname FROM sysmaster:sysptnkey k,sysmaster:systabnames t WHERE sysmaster:bitand(flags,"0x00000040") > 0 and k.partnum = t.partnum and dbsname not in ("sysmaster")


Ukončení nečinných uživatelů

Nový task idle_user_timeout() zajišťuje automatické ukončení nečinných uživatelů Doba nečinnosti se nastavuje parametrem IDLE TIMEOUT z tabulky ph_threshold Nečinný uživatel je odstraněn spuštěním příkazu onmode –z Pro zajištění požadované funkcionality se volají následující SQL příkazy SELECT value FROM ph_threshold WHERE name = "IDLE TIMEOUT"; SELECT admin("onmode","z",A.sid), A.username, A.sid, hostname FROM sysmaster:sysrstcb A , sysmaster:systcblst B , sysmaster:sysscblst C WHERE A.tid = B.tid AND C.sid = A.sid AND LOWER(name) IN ("sqlexec") AND CURRENT - DBINFO("utc_to_datetime",last_run_time) > time_allowed UNITS MINUTE AND LOWER(A.username) NOT IN( "informix", "root")


Detekce nadměrného počtu In-Place verzí stránek

Některé DDL operace se provádí In-Place nebo-li po provedení operace se vytvoří nová verze stránek s novým schématem Každá další In-Place operace se provádí nad všemi aktivními verzemi stránek a je tedy méně efektivní (a trvá déle) Task check_for_ipa() detekuje tabulky s nadměrným počtem verzí stránek Nadměrný počet verzí stránek (tzv. outstanding In-Place Alters) vede k výraznému zpomalení dalších In-Place DDL, nikoliv však k výkonnosti SQL dotazů Detekce se provádí na základě výrazu:

SELECT dbsname, trim(owner)||"."|| tabname AS fullname FROM sysmaster:sysactptnhdr h,sysmaster:systabnames t WHERE h.partnum = t.partnum and dbsname not in ("sysmaster") and pta_totpgs != 0 © 2012 IBM Corporation

Defragmentace Operace spojení extentů tabulek (resp. extentů fragmentů) – Doplňuje operace komprese, repack, shrink Operace defragmentace pomáhá řešit problém přetečení stránky partition header a vede ke zlepšení výkonnosti Příklad spuštění přes SQL Admin API EXECUTE FUNCTION task(“defragment”,“stores_demo:informix.customer"); EXECUTE FUNCTION admin(“defragment”,“stores_demo:informix.customer"); EXECUTE FUNCTION task(“defragment partnum”,“2097154”); EXECUTE FUNCTION admin(“defragment partnum”,“2097154”); EXECUTE FUNCTION task(“defragment partnum”, “16777217,28477346"); EXECUTE FUNCTION admin(“defragment partnum”, “16777217,28477346");

Soušasně nelze spustit více než jeden defragmentační požadavek na jednu tabulku/fragment a v jednom dbspace Tabulku nelze defragmentovat, když současně běží – DDL operace – TRUNCATE – komprese resp. dekomprese – vytváření indexu v ONLINE režimu Defragmentovat nelze – VTI pseudo tabulky – Tabulky s VII indexy a se složenými indexy – Dočasné tabulky – Třídící soubory a soubory s optickými bloby © 2012 IBM Corporation

Automatická optimalizace tabulkových prostorů Prostřednictvím auto_crsd úlohy plánovače lze naplánovat automatické spouštění všech operací optimalizace tabulkových prostorů (komprese, repack, shrink, defrag) Zapnutí úlohy UPDATE ph_task SET tk_enable = ’T’ WHERE tk_name = ’auto_crsd’;

Vypnutí dílčích operací optimalizace UPDATE ph_threshold SET value = ’F’ WHERE name = ’AUTODEFRAG_ENABLED’; (resp. AUTOCOMPRESS_ENABLED, AUTOREPACK_ENABLED, AUTOSHRINK_ENABLED)

Nastavení hraničních hodnot pro spuštění úloh optimalizace UPDATE ph_threshold SET value = ’5000’ WHERE name = ’AUTOCOMPRESS_ROWS’;

Parametry pro nastavení hraničních hodnot – AUTOCOMPRESS_ROWS • Počet nekomprimovaných záznamů (Default 10 000 záznamů) – AUTOREPACK_SPACE • Procentuální nespojitost alokovaného prostoru pro tabulku/fragmment (Default 90%) – AUTOSHRINK_UNUSED • Procento nevyužitého alokovaného prostoru (Default 50%) – AUTODEFRAG_EXTENTS © 2012 IBM Corporation • Počet extentů (Default 100)

Storage Provisioning

Zajišťuje automatické rozšíření databázových prostorů při jejich zaplní, případně po dosažení hraniční hodnoty Možné zajistit automaticky (případně manuálně) výběrem ze storage poolu – Storage pool = množina předem definovaných oblastí, které budou použity pro rozšíření prostorů SP_AUTOEXPAND [1|0] – Zapnutí/vypnutí automatického SP Rozšíření databázových prostorů lze provést – Zvětšením („nafouknutím“) chunků – Přidáním dalšího chunku ze storage poolu Storage Provisioning lze používat i v prostředí HA klastru


Rezervování paměti pro dokončení kritických úloh

Rezervuje od 128 kB do 2 GB paměti, ale ne více než 20% virtuálního segmentu SHM pro dokončení kritických úloh (např. rollback), pokud je nedostatek SHM Nastavení – ONCONFIG: LOW_MEMORY_RESERVE – onmode –wm/-wf


Správa databázového serveru při kritickém nedostaku sdílené paměti

Definuje hraniční hodnoty dostupné volné paměti, kdy se zapínají mechanizmy za účelem uvolnění paměti – Parametry LMM START THRESHOLD, LMM STOP THRESHOLD • Udávají procentuální resp. absolutní hodnoty vstažené k SHMTOTAL Uvolňování paměti se provádí v následujícím pořadí činností – Ukončení uživatelských nečinných relací (parametr LMM IDLE TIME) – Ukončení uživatelských relací s nadměrným čerpáním paměti – Vypnutí VP cache, vypnutí SQL trasování a uvolnění paměti (onmode –F) ONCONFIG: LOW_MEMORY_MGR [0|1] – onmode –wf LOW_MEMORY_MGR = [0|1] a restart serveru ! – onmode –wm nelze použít task()/admin()


Privátní non-root instalace

Nevyžaduje instalaci databázového serveru pod superuser (root) uživatelem a nezakládá se uživatel/skupina informix Administrátorem a vlastníkem databázového serveru (DBSA) je non-root „obyčejný“ uživatel, pod kterým se provádí instalace DBSA zakládá a spravuje databázové uživatele – CREATE USER, GRANT ACCESS, REVOKE ACCESS, RENAME USER, ALTER USER, DROP USER Autentizace databázových uživatelů provádí databázový server, nikoliv OS Pokud na serveru s privátní non-root instalací je založen uživatel informix, nemá vůči této instalaci žádná speciální práva Není (zatím) implementované – MACH-11 a ER – Separace rolí – OpenAdmin Tool pro Informix (OAT) – OnBar, OnPerf © 2012 IBM Corporation

SQL Rozšíření

Multi-Index scan Rozložení indexu na podstromy Optimalizace provádění Update Statistics Nové plány pro vykonávání SQL analytických dotazů Implicitní PDQ Case Insensitive databáze


Multi Index Scan

Dovoluje použít více indexů v jednom dotazu Zavádí metodu skip scan výběru odpovídajících datových stránek Může redukovat počet potřebných indexů Příklad – Složený index - např. (c1,c2) • Select * from tab where c1=100 and c2 between 10 and 20; Index nad (c1,c2) lze použít • Select * from tab where c2=100 and c1 between 10 and 20; Index nad (c1,c2) NELZE použít, je nutné vytvořit nový složený index (c2,c1) – Více indexů – např. (c1) a (c2) • Select * from tab where c1=100 and c2 between 10 and 20; • Select * from tab where c2=100 and c1 between 10 and 20; Oba SQL dotazy využijí indexy (c1) a (c2) + SKIP SCAN


Rozložení indexu na podstromy

Použití rozsáhlého indexu velkým počtem současně přistupujících uživatelů může vést k přetížení kořenové indexové stránky CREATE UNIQUE INDEX security_idx 1,100,200,

1,20,40,...

1,2,3...

80,81,...99

100,...,199

100,101,...

ON security(s_symb, s_co_id ) IN dbs

Rootnode

180,...199

200,...

200,201,...

Twigs

280,...

Leaves

Problém lze odstranit rozložením indexu na menší indexy (podstromy) Hash on key value to pick a bucket / rootnode

CREATE UNIQUE INDEX security_idx ON security(s_symb, s_co_id ) IN dbs HASH ON (s_symb ) with 1000 buckets;

2,...

Bucket 1

Bucket 2

Bucket 3

2,189,...

1,198,...

4,201,...

189,...

1,...

198,...

Key Value 1 2

Bucket 2 1

3 ... 47 221

2 ... 3 1

4,...

Rootnodes

201,...

Leaves


Optimalizace provádění Update Statistics

UPDATE STATISTICS vytváří distribuce buď nad celou tabulkou nebo nad jednotlivými fragmenty (distribuce nad tabulkou je „součtem“ distribucí fragmentů) Lze nastavit, že US se provede až po určitém počtu modifikací dat nad tabulkou/fragmentem AUTO_STAT_MODE [0|1] [CREATE | ALTER] TABLE ... STATLEVEL [TABLE | FRAGMENT | AUTO] [CREATE | ALTER] TABLE ... STATCHANGE [integer | AUTO] UPDATE STATISTICS FOR TABLE … AUTO UPDATE STATISTICS FOR TABLE … FORCE


Nové plány pro vykonávání SQL analytických dotazů

Multi-Index scan Skip scan „Push down“ hash-join

Původní metoda

Nová metoda


Implicitní PDQ

Explicitní PDQ – SET PDQPRIORITY – Všechny dotazy v aktuální relaci mají stejné nastavení Implicitní PDQ – Požadavky na zdroje určuje databázový server na základě odhadů optimalizátoru – Každý dotaz může mít tedy jiné nastavení – Pokud není nastaveno BOUND_IMPL_PDQ, nastavení PDQPRIORITY se ignoruje Nastavení – SET ENVIRONMENT IMPLICIT_PDQ OFF/ON/hodnota • OFF Zdroje se alokují podle nastavení PDQPRIORITY a nastavení BOUND_IMPL_PDQ se ignoruje • ON Zdroje se alokují mezi dotazy rovnoměrně podle jejich aktuální dostupnosti • Hodnota (1-100) Zdroje se alokují podle nastavené hodnoty – vyšší hodnota = více zdrojů – SET ENVIRONMENT BOUND_IMPL_PDQ ON • Nastavení PDQPRIORITY se bere jako horní hranice pro určení dostupných zdrojů © 2012 IBM Corporation

Case Insensitive databáze

Od verze 11.70.xC2 lze vytvářet case insensitive databáze – CREATE DATABASE .... NLSCASE INSENSITIVE Case sensitive databáze – 11.70.xC2 a výše • CREATE DATABASE .... NLSCASE SENSITIVE • CREATE DATABASE .... – Všechny verze do 11.70.xC2 • CREATE DATABASE .... V případě case insensitive vyhledávání musí být data v NCHAR nebo NVARCHAR Pro data v položkách CHAR, VARCHAR resp. LVARCHAR platí stále case sensitive vyhledávání, i když je databáze vytvořena jako case insensitive


Case insensitive databáze - příklady


Case insensitive databáze - příklady


Bezpečnost

Selektivní audit na úrovni tabulek Ochrana databázového serveru před nechtěnou inicializací Mapovaní uživatelé Trusted Context


Selektivní audit na úrovni tabulek

Nové auditní masky – UPRW – Update Row – DLRW – Delete Row – RDRW – Select Row – INRW – Insert Row [CREATE|ALTER] TABLE ….. [with| add| drop] AUDIT; ADTROWS – 0 (default): audit se provádí pro všechny tabulky – 1: audit se provádí pouze pro tabulky s SQL AUDIT – 2: stejné jako 1, ale v auditním záznamu je navíc primární klíč auditovaného tabulkového záznamu onaudit –R [0|1|2] onaudit –a –u sippl –e UPRW


Ochrana databázového serveru před nechtěnou inicializací

ONCONFIG: FULL_DISK_INIT – 0 (default): oninit –i inicializuje diskové struktury pouze tehdy, pokud první stránka primárního chunku rootdbs (page Zero) neobsahuje platnou strukturu – 1: oninit –i inicializuje diskové struktury bez ohledu na page Zero • Po inicializaci se FULL_DISK_INIT automaticky změní na hodnotu 0 online.log 05:49:50 DISK INITIALIZATION ABORTED: potential instance overwrite detected. To disable this check, set FULL_DISK_INIT to 1 in your config file and retry. 05:49:50

oninit: Fatal error in shared memory initialization

05:49:50

IBM Informix Dynamic Server Stopped.

05:49:50

mt_shm_remove: WARNING: may not have removed all/correct segments


Mapovaní uživatelé

Mapovaní uživatelé se neautentizují prostřednictvím účtu operačního systému, ale prostřednictvím interní autentizace nebo externích mechanizmů, jako je – Single sign-on (SSO) nebo – Pluggable authentication module (PAM) ONCONFIG: USERMAPPING OFF|ADMIN|BASIC – OFF – původní chování, autentizace možná pouze prostřednictvím OS uživatele – ADMIN – uživatelům je možné přidělit privilegované činnosti, jako DBSA, DBSSO, AAO – BASIC – uživatelé bez možnosti privilegovaného přístupu


Mapovaní uživatelé - Příklad Vytváření mapovaných uživatelů a jejich interní autentizace Existující uživatel operačního systému: honza


Trusted Context (důvěryhodné připojení)

V prostředí aplikačních serverů se koncoví uživatelé připojují k databázi prostřednictvím univerzálního uživatele Tento univerzální uživatel musí mít k databázovým objektům přidělena všechna práva, která potřebují koncoví uživatelé Na úrovni databázového auditu nelze přiřadit monitorované SQL příkazy konkrétním koncovým uživatelům (činnost ve skutečnosti provádí univerzální uživatel) Trusted Context (důvěryhodné připojení) poskytuje prostředek, jak umožnit skutečným koncovým uživatelům se připojit k databázi s jejich skutečnou identitou Audit se tedy provádí na skutečné koncové uživatele V rámci jednoho důvěryhodného připojení lze přidělit různé úrovně privilegií a rolí různým uživatelům


Vysoká dostupnost

MACH-11 rozšíření Informix Flexible Grid


MACH-11 rozšíření

Spouštění DDL příkazů na sekundárních serverech Vytváření HDR resp. ER uzlů klonováním primárního serveru Dokončení transakce na sekundárním uzlu i přes probíhající failover Rolling upgrade klastru dbexport, dbimport, dbchema na sekundárních serverech


Informix Flexible Grid Technologie rozšiřující funkcionalitu Informix ER Replikace dat pomocí Informix ER bez primárního klíče Vytváření replik nad tabulkou již při jejím vytváření Replikace DDL příkazů mezi uzly – create table, create index, create procedure . . . Změna konfigurace instancí zařazených v gridu – Přidávání/mazání logických logů, chunků, db prostorů, změny konfigurace $ONCONFIG a podobně Podpora oncmsm connection manageru v gridu Replikování požadavku na spuštění příkazu (např. uložené procedury) mezi uzly gridu – Požadavek se nejprve replikuje a pak dojde k lokálnímu spuštění na každém uzlu v gridu Zapínání resp. vypínání ER v transakci (nikoliv pouze na úrovni celé transakce)


Informix Time Series

Správa dat pořizovaných v pravidelných nebo nepravidelných časových řadách Specializovaný způsob ukládání dat a architektura s důrazem na vysokou výkonnost Poskytuje bohatou knihovnu funkcí pro provádění analýz zaznamenaných dat v časových řadách Podpora formou nativního datového typu TimeSeries s definicí libovolné struktury spravovaných dat Podpora JDBC a C API Technologie je zdarma součástí všech edicí Informix


Informix Time Series – Případová studie Výsledky byly získány na základě měření US elektrárenské společnosti

Informix

Konkurenč ční technologie

Čas potřebný pro load dat z 1,000,000 měřidel

18 minut

7 hodin

Sestavy

Od vteřin do 11 minut

2-7 hodin

Diskový prostor pro data z 1,000,000 měřidel

350GB

1.3 TB


Informix Warehouse Accelerator

Architektura Administrace Edice Přibližný sizing


Databázové technologie třetí generace

Podle článku IDC (Carl Olofson) z února 2010 lze databázové technologie rozdělit na technologie – První generace: • Vlastní zákaznické databázové technologie – Druhé generace: • Relační databázové technologie (RDBMS) s diskovými vstupně-výstupními operacemi • Ladění výkonnosti spočívá ve vytváření distribučních statistik, vytváření/mazání indexů, fragmentaci (partitioning) dat, vytváření tabulek s předem vypočítanými hodnotami a vytváření „kostek“ pro analytické dotazy, vynucení optimalizačních plánů nebo řízené přidělování zdrojů – Třetí generace (IDC je předpovídá během příštích 5 let): • Většina dat datových skladů bude uložena po položkách • Většina OLTP databází bude rozšířena o technologie paměťových databází (IMDB) s možností rezidentního uložení celé databáze v paměti • Většina databázových serverů bude horizontálně škálovatelných prostřednictvím klastrování


Informix Warehouse Accelerator Databázová technologie třetí generace je zde!

Akcelerátor je vytvořen na třech klíčových principech – Akcelerace bez ručního ladění jakékoliv zátěže – Podpora existujících business nástrojů a aplikací – Práce s existující warehouse infrastrukturou


Použité technologie zajišťující vysokou výkonnost Extrémní míra komprese

Ukládání dat po záznamech vs. po položkách

Vyž Vyžadová adována z dů důvodu omezené omezené velikosti RAM

Transakč Transakční zpracová zpracování = uklá ukládání dat po zá záznamech (ř (řádcí dcích) Analytické Analytické zpracová zpracování = uklá ukládání dat po polož položkách (sloupcí (sloupcích)

Optimalizovaný vektorový algoritmus v prostředí více jader

Paměťová databáze

Řešení ení problé problému zamyká zamykání či synchronizace

7

1

6 Vyhodnocování výběrových podmínek se provádí nad komprimovanými daty

2

5

Databá Databázové zové technologie 3. generace eliminují eliminují I/O diskové diskové operace. Komprese dovoluje, aby celá celá databá databáze byla v pamě paměti rezidentně rezidentně

3 4

Frekvenční partitioning Umožň Umožňuje žňuje efektivně efektivně paralelně paralelně přistupovat ke komprimovaným datů datům, která která jsou fragmentovaná fragmentovaná horizontá horizontálně lně i vertiká vertikálně lně

Časté asté sekvenč sekvenční čtení tení nevyž nevyžaduje dekompresi dat

Masivní paralelismus Všechna dostupná dostupná jádra se využ využívají vají pro zpracová zpracování dotazu © 2012 IBM Corporation

Způsoby ukládání dat Řádkově orientované ukládání dat – Jednotlivé záznamy se ukládají sekvenčně •Optimalizovaná pro I/O operace nad celým záznamem •Vždy se načte (případně dekomprimuje) celý záznam •Velmi efektivní pro transakční zpracování •Ne vždy efektivní pro analytické zpracování Sloupcové (položkové) ukládání dat – Data se ukládají sekvenčně po položkách •Výhodné pro sekvenční zpracování dat určitých položek (analytické zpracování) •Nevhodné pro náhodný přístup (OLTP) •Pokud nejsou některé položky v dotazu použity, jsou přeskočeny


Architektura Informix Warehouse Accelerator

Informix Dotaz USE_DWA

Aplikace Výsledek

Dotaz

SQL Opt. Výsledek

IWA Výsledek Dotaz

ISAO Studio

JDBC CLI


Architektura Informix Warehouse Accelerator

Lze konfigurovat více procesů, které se nazývají uzly Dva typy uzlů – Koordinační uzel (Coordinator) – Výkonný uzel (Worker) Uzly využívají POSIX multithreading Tabulková data se ukládají po položkách (sloupcích) v komprimovaném tvaru Tabulková data se ukládají ve sdílené paměti (přes /dev/shm) Řídící informace a dočasná data se zpracovávají v lokální paměti procesů IWA a IDS komunikují prostřednictvím DRDA protokolu – Vždy TCP/IP připojení Řízení a diagnostika IWA se provádí přes ondwa a telnet


Přehled technologie Informix Warehouse Accelerator (IWA)

IWA je paměťový databázový server IWA ukládá tabulky v paměti – Po položkách (nikoliv po záznamech) – Komprimovaně – SQL podmínky se vyhodnocují nad komprimovanými daty IWA je optimalizovaný pro analytické dotazy – Analýzy trendů, obchodní analýzy, … – Podpora zpracování rozsáhlých objemů dat • Pro OLTP zpracování stále vhodnější tradiční IDS – Vhodný pro zpracování agregací, group by a podobně IWA vyžaduje následující datová schémata a relace mezi tabulkami – Hvězdice – Sněhová vločka IWA zpracovává statická data


Komprese: Frekvenční partitioning Obchodní informace (objem, produkt, země ě pů ůvodu)

Histogram na Origin

Počet výskytů

China GER, USA FRA, …

často se vyskytující hodnoty

řídce se vyskytující hodnoty

Výskyt nejčastěji prodávaných 64 produktů – 6 bit kód

Zbytek

Histogram na Product

Rest

Origin

Product

Vol Prod Origin

Položkový partitioning

Cell 1

Cell 3

Cell 4

Cell 2

Cell 5

Cell 6

Tabulka fragmentovaná do buněk

•

Délky komprimovaných záznamů se mění mezi buňkami • Vyšší výskyt hodnot Kratší kód hodnoty (approximativní Huffmanův algoritmus)

•

Délky komprimovaných záznamů jsou stejné v rámci jedné buňky


Proces komprese: krok 1 Male, John, 08/10/06, Mango Male

John Sat

08/10/06 2006

p = 1/8

101101011

Column 1&2

w35/Mango

001

p = 1/512

Input tuple

4.2%

David

3.8%

James

3.6%

Robert

3.5%

Column 2

Co-code transform

w35

Male/John/Sat Male/John p = 1/512

Column 1

Mango

Michael

Column 3

John

3.5%

William

2.5% Type

Mark

specific transform 2.4%

Column Richard

2.3%Column

3.A

Thomas

1.9%

3.B

Huffman Dict Steven Huffman Dict1.5%Huffman Dict Encode Encode Encode

Mon 01011101

Tue

Column Wed Code

Thu

Column Fri Code

Sat

Column Sun Code

Male

3%

4%

10%

6%

23%

42%

12%

Female

4%

5%

9%

15%

17%

28%

22%

10110101100101011101

TupleCode © 2012 IBM Corporation

Proces komprese: krok 2 Tuplecode

10110101110001011101 10110101110001011111 101101011100001100 1011010111000011101

First tuple code

— —

1

—

Previous Tuplecode

0000000000000000001 00000000000000000001 0000000000000000101 000 010 1110

Sorted Tuplecodes — Delta Huffman Encode

Dict

Delta Code Append

10110101110001011101 000 010 1110 101101011100010111010000101110

Compression Block © 2012 IBM Corporation

Paralelní SIMD operace na úrovni registrů Pracuje pouze s bankami (množina položek) použitých v dotazu: – SELECT SUM (T.G) – FROM T – WHERE T.A > 5 – GROUP BY T.D Uspořádá více záznamů jedné banky do 128-bitového registru SIMD (Single-Instruction, Multiple-Data) zpracování je paralelní na úrovni záznamů

D1

G1

B1

E1

F1

C1

H1

A2

D2

G2

B2

E2

F2

C2

H2

A3

D3

G3

F3

C3

H3

F4

C4

H4

Operand 32 bits

Operand 32 bits

B3

Operand 32 bits E3

Operand 32 bits

Vector Operation A4

Result1

D4

B4

G4

Bank β1 (32 bits)

Result2

E4

128 bits Result3

Bank β2 (32 bits)

Cell Block

A1

Result4

Bank β3 (16 bits)


Současné vyhodnocení podmínek na rovnost CPU pracuje s 128-bit jednotkami • Většina zakódovaných položek se vejde do 128 bitů – Tyto položky mají pevnou dálku a pozici ve 128-bit jednotce – Podmínka se aplikuje na všechny položky současně

State …

State==‘CA’ && Quarter == ‘Q4’ Zakódování hodnot v podmínkách

State==01001 && Quarter==1110 Quarter

…

…

…

Záznam

1111

0

Maska

& 11111

0

== 01001

0

1110

0

Aplikace podmínky © 2012 IBM Corporation

Definice Data Martu Data Mart je logická množina tabulek se vzájemnými referenčními vazbami. – Například, všechny tabulky hvězdicového schématu budou patřit do jednoho Data Martu. Administrátor používá bohaté klientské rozhraní pro definici tabulek patřících do Data Martu, včetně informací o referenčních vazbách IDS vytváří definici o Data Martu ve vlastním katalogu. Odpovídající data se čtou z tabulek IDS a přenášejí se do IWA IWA transformuje data do vysoce komprimovaného tvaru tak, aby čtení bylo optimalizované a všechna data byla držena lokálně v paměti akcelerátoru

IDS + IWA

Definice

Koordinační

Výkonný

proces

proces © 2012 IBM Corporation

IWS Design Studio


Distribuce dat z IDS (tabulka faktů) Tabulka faktů

IDS Stored Procedures

Data Fragment

Koordinační proces

UNLOAD UNLOAD UNLOAD UNLOAD

Data Fragment Data Fragment Data Fragment

Kopie dat tabulky faktů z IDS je přenesena k výkonným procesům. Každý výkonný proces si drží podmnožinu komprimovaných dat v hlavní paměti a zpracovává dotaz nad touto podmnožinou dat. Data jsou rovnoměrně rozdělena mezi CPU.

Copy

Výkonný proces

Výkonný proces

Výkonný proces

Compressed Data

Compressed Data

Compressed Data

Compressed Data

Compressed Data

Compressed Data © 2012 IBM Corporation

Distribuce dat z IDS (tabulky dimenzí) IDS Dimension Tabulka dimenzí Table

IDS Stored Procedure

Dimension Tabulka dimenzí Table

Koordinační proces

UNLOAD UNLOAD UNLOAD UNLOAD

Dimension Tabulka dimenzí Table Dimension Tabulka dimenzí Table

Každý výkonný proces má k dispozici všechna data ze všech tabulek dimenzí

Výkonný proces

Výkonný proces

Výkonný proces


Možné způsoby aktualizace dat v IWA

Aktualizace (upload) celého data martu Aktualizace pouze na úrovni jednotlivých tabulek nebo fragmentů tabulek data martu – dropPartMart() : Smazání fragmentu • EXECUTE FUNCTION dropPartMart('SLSACC', 'salesmart', 'dmuser', 'salesfact', 'p1'); • ALTER FRAGMENT ON TABLE salesfact DETACH p1 salesfact_p1;

– loadPartMart() : Připojení a aktualizace dat fragmentu • CREATE TABLE p4 (sk1_cust INT,sk2_store INT,id INT,val DECIMAL(9,2),CHECK (id = 4)); • ALTER FRAGMENT ON TABLE salesfact ATTACH p4 AS (id = 4) AFTER p3; • EXECUTE FUNCTION loadPartMart('SLSACC', 'salesmart', 'dmuser', 'salesfact', 'p4');


Řízení akcelerace dotazů

set environment use_dwa ’accelerate on’; environment use_dwa ’fallback on’; – Dotaz se akceleruje na IWA – Pokud nelze dotaz zpracovat na IWA, zpracuje se na původním IDS

set

set environment use_dwa ’accelerate on’; set environment use_dwa ’fallback off’; – Dotaz se akceleruje na IWA – Pokud nelze dotaz zpracovat na IWA, končí s chybou set environment use_dwa ’accelerate off’; – Dotaz se neakceleruje a spouští se přímo na IDS


Možné konfigurace (jeden počítač)


Možné konfigurace (oddělená architektura)


IWA na sekundárních serverech klastru vysoké dostupnosti

Vytváření data martů, load dat a akcelerace dotazů je možná také na jednom nebo více serverech klastru vysoké dostupnosti – HDR, RSS nebo SDS Poskytuje vyšší flexibilitu v prostředí se smíšeným typem zpracování (OLTP vs. analytické dotazy) – Např. snažší implementace IWA tam, kde byl původně primární server určen pro OLTP zpracování a záložní server pro analytické dotazy Konfigurace – ONCONFIG • UPDATABLE_SECONDARY 1 • VPCLASS dwavp,num=1 – Dále stejně jako u konfigurace na primárním serveru


Informix Warehouse Edice


Přibližný sizing IWA platformy

Velikost

Objem surových dat *

Paměť

Počet Intel jader (X7560)

XL

>1.5 TB to 3 TB

1 TB

24-32

L

>750 GB to 1.5 TB

512

20-24

M

> 400 GB to 750 GB

256 GB

16-20

S

> 250 GB to 400 GB

192 GB

12-16

XS

≥ 100 GB to 250 GB

96 GB

8-12

Growth Warehouse

* Objem surových dat reprezentuje pouze data tabulek, nikoliv data indexů, dočasných tabulek a podobně


Porovnání výkonnosti

Dotaz

XPS 8.31

IDS 11.7

IWA

1

90 min

40 min

67 vteřin

•Microstrategy report měl 667 SQL příkazů s 537 SELECT dotazy •Data mart měl 250 tabulek s objemem 30 GB dat •XPS běželo na Sun Sparc M9000 •IDS 11.7 a IWA were běží na Linux Intel

Dotaz

IDS 11.5

IDS 11.7 IWA

1

22 min

4 vteřiny

2

1 min 3 sec

2 vteřiny

3

3 min 40 sec

2 vteřiny

4

30 min & up

4 vteřiny

5

2 min

2 vteřiny

6

30 min

2 vteřiny

7

45 min & up

2 vteřiny

•7 nejvíce časově náročných dotazů v BI a Warehouse maloobchodní aplikaci •Tabulka faktů má 1 miliardu záznamů


Informix Genero

Přehled technologie Komponenty řešení Provozní architektura


Přehled technologie

Technologie Informix Genero nabízí rychlý převod stávající znakové Informix-4GL aplikace do grafického prostředí s využitím moderních stanardů (např. webové služby) Informix Genero programovací jazyk (Business Development Language – BDL) je plně kompatibilní s Informix-4GL BDL nabízí další rozšíření, zejména směrem k využití grafických komponent – Grafické komponenty: • Multiple Dialogs • Drag ‘n’ Drop • Tree Views • Rich Text • Multiple Selects • Picture Flow – Web Services – Java Interface Rozsáhlá podpora reportování (Report Writer)


Komponenty řešení

Abstract User Interface (AUI) Dynamic Virtual Machine (DVM) Open Database Interface (ODI) Web Services


Webový server

Firewall

GWC

GDCax

Webové služby

Pracovní stanice

Databázový server

Firewall

Aplikační server

Webový prohlížeč

Provozní architektura

GDC

GDCax

ASCII


Případové studie migrace z Informix-4GL do Informix-Genero

Gestevision Telecinco (Channel TV)

Adaptris (Software company)

– Vylepšení uživatelského rozhraní – Přidávání nových funkcí

– Pouze konverze, bez změn v uživatelském rozhraní a beze změn aplikace

– 207 175 řádek kódu – 344 formulářů – 2 vývojáři

– 1 174 100 řádek kódu – 625 formulářů – 2 vývojáři


Jan Musil [email protected]


Vybrané nové vlastnosti Informix 11

Recommend Documents