Vybrané nové vlastnosti Informix 11 Jan Musil jan_musil@cz.ibm.com Informix CEE Technical Sales 1
Přehlede prezentace Administrace a architektura Rozšíření SQL Bezpečnost Vysoká dostupnost Informix TimeSeries Informix Warehouse Accelerator Informix Genero 2
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
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í
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
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
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
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
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 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
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, Rootnode ON security(s_symb, s_co_id ) IN dbs 1,20,40,... 100,...,199 200,... Twigs 1,2,3... 80,81,...99 100,101,... 180,...199 200,201,... 280,... Leaves Problém lze odstranit rozložením indexu na menší indexy (podstromy) Hash on key value to pick a bucket /rootnode Bucket 1 Bucket 2 Bucket 3 CREATE UNIQUE INDEX security_idx ON security(s_symb, s_co_id ) IN dbs HASH ON (s_symb ) with 1000 buckets; 2,189,... 1,198,... 4,201,... 2,... 189,... 1,... 198,... 4,... 201,... Key Value Bucket 1 2 2 1 3 2...... 47 3 221 1 Rootnodes 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ů
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 Čas potřebný pro load dat z 1,000,000 měřidel Informix 18 minut 7 hodin Konkurenční technologie 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 Vyžadov adována z důvodu d omezené velikosti RAM Ukládání dat po záznamech vs. po položkách Transakční zpracování = ukládání dat po záznamech z znamech (řádc( dcích) ch) Analytické zpracování = ukládání dat po položkách (sloupcích) ch) Optimalizovaný vektorový algoritmus v prostředí více jader Řešen ení problému zamykání či synchronizace 6 7 1 2 Paměťová databáze Databázov zové technologie 3. generace eliminují I/O diskové operace. Komprese dovoluje, aby celá databáze byla v paměti rezidentně Vyhodnocování výběrových podmínek se provádí nad komprimovanými daty Čast asté sekvenční čten tení nevyžaduje dekompresi dat 5 4 3 Frekvenční partitioning Umožň žňuje efektivně paralelně přistupovat ke komprimovaným datům, která jsou fragmentovaná horizontáln lně i vertikáln lně Masivní paralelismus Všechna dostupná jádra se využívaj vají pro zpracování dotazu
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 Aplikace Dotaz USE_DWA SQL Opt. Dotaz IWA Výsledek Výsledek Dotaz Výsledek 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) Vol Prod Origin Histogram na Product Počet výskytů často se vyskytující hodnoty Histogram na Origin Výskyt nejčastěji prodávaných 64 produktů 6 bit kód Zbytek řídce se vyskytující hodnoty Product China USA Cell 1 Cell 2 Položkový partitioning GER, FRA, Cell 3 Cell 5 Origin Rest Cell 4 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 08/10/06 Mango Michael 4.2% Input tuple David 3.8% James 3.6% Robert 3.5% Column 1 Column 2 John 3.5% Column 3 Male/John/Sat Sat 2006 w35 p = 1/512 p = 1/8 p = 1/512 w35/mango 101101011 001 01011101 Co-code transform Column 1 & 2 Huffman Encode Column Code Dict William 2.5% Mark 2.4% Column 3.A Richard 2.3% Thomas 1.9% Huffman Dict Encode Steven 1.5% Column Code Type specific transform Column 3.B Huffman Encode Column Code Mon Tue Wed Thu Fri Sat Sun Male 3% 4% 10% 6% 23% 42% 12% Female 4% 5% 9% 15% 17% 28% 22% Dict 10110101100101011101 TupleCode
Proces komprese: krok 2 Tuplecode 10110101110001011101 10110101110001011111 101101011100001100 1011010111000011101 0000000000000000001 00000000000000000001 0000000000000000101 000 010 1110 Previous Tuplecode 1 Sorted Tuplecodes Delta Huffman Encode Delta Code Append First tuple code Dict 101101011100010111010000101110 000 010 1110 Compression Block
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ů A 1 D 1 G 1 B 1 E 1 F 1 C 1 H 1 A 2 D 2 G 2 A 3 D 3 G 3 A 4 D 4 G 4 Bank β1 (32 bits) B 2 E 2 F 2 B 3 E 3 F 3 B 4 E 4 F 4 Bank β2 (32 bits) C 2 H 2 Operand Operand Operand Operand 32 bits 32 bits 32 bits 32 bits Vector Operation C 3 H 3 C 4 H 4 Result 1 Result 2 128 bits Result 3 Result 4 Bank β3 (16 bits) Cell Block
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== CA && Quarter == Q4 Zakódování hodnot v podmínkách State==01001 && Quarter==1110 State Quarter & 11111 0 1111 0 == 01001 0 1110 0 Záznam Maska Aplikace podmínky
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í proces Výkonný proces
IWS Design Studio
Distribuce dat z IDS (tabulka faktů) Tabulka faktů Data Fragment Data Fragment Data Fragment Data Fragment IDS Stored Procedures UNLOAD UNLOAD UNLOAD UNLOAD Koordinační proces 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. Výkonný proces Compressed Data Copy Výkonný proces Compressed Data Výkonný proces Compressed Data Compressed Data Compressed Data Compressed Data
Distribuce dat z IDS (tabulky dimenzí) IDS Dimension Tabulka dimenzí Table IDS Stored Procedure Dimension Tabulka dimenzí Table Dimension Tabulka dimenzí Table UNLOAD UNLOAD UNLOAD UNLOAD Koordinační proces 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 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 set
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 Growth Warehouse S > 250 GB to 400 GB 192 GB 12-16 XS 100 GB to 250 GB 96 GB 8-12 * 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
Provozní architektura Aplikační server Webový server Firewall Firewall Webový prohlížeč GWC GDCax Webové služby Databázový server Pracovní stanice 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í 207 175 řádek kódu 344 formulářů 2 vývojáři Pouze konverze, bez změn v uživatelském rozhraní a beze změn aplikace 1 174 100 řádek kódu 625 formulářů 2 vývojáři
Jan Musil jan_musil@cz.ibm.com