ARCHIV

IBM DB2 historie (4)

Dnes se podíváme na mainframovou verzi DB2 UDB 5 a podělím se o zkušenost jedné české firmy která se snažila prosadit na trhu data warehousing serverů.

30.4.2010 00:00 | Radim Kolář | Články autora | přečteno 8326×

DB2 Server for OS/390 Version 5

Podíváme se trochu podrobněji na mainframovou DB2 UDB 5 pro OS/390 která byla dána do prodeje 27 června 1997 a prodávala se až do 31 prosince 2001. Základní podpora byla ukončena o rok později. Datum ukončení prodeje je zvláštní tím, že se pětka prodávala déle než šestka, která se přestala prodávat 4 prosince 2001. Šestka nenabízela oproti pětce žádná výrazná vylepšení pro stávající aplikace a tak se to s upgrady na šestku moc nepřehánělo. Než byly naprogramovány nové aplikace využívající možností šestky tak už vyšla sedmička a tak se upgradovalo rovnou na ní.

Ačkoliv nemainframová DB2 5 nebyla nikterak významná verze její nedůležitější změnou bylo přebalíčkování a sjednocení platforem tak pětka na MVS byla napěchována důležitými změnami - kupříkladu jako první databáze splňovala standard SQL92 Entry Level plně a další levely částečně. Přibyla úplná podpora rozhraní ODBC, ISO/CLI, dvoufázové potvrzování proti neSQL databázím a FIPS 127-2. Z časových důvodů jsem minule o nemainframové pětce toho moc nenapsal a tak si to vynahradíme dnes. Pětce jsem se rozhodl věnovat tento i následující díl.

Jelikož DB2 5 se začala jmenovat univerzální databáze, tak byla její univerzálnost také patřičně zmíněna v marketingových materiálech. Uvádělo se, že ať už jsou vaše požadavky na databázový systém jakékoliv, tak vám je DB2 splní. Bylo to z velké části pravda. DB2 byla vhodná pro aplikace typu data warehousing, transakční zpracování, klient/server a Internet aplikace.

DB2 5 byla první DB2 verze připravená pro rok 2000 takzvaně Y2K Ready. O Y2K problému se v té době hodně mluvilo a byla to velká výzva pro IT průmysl jako celek. Naštěstí byl vzat Y2K problém dostatečně vážně a tak se katastrofické předpoklady nesplnily. Na 1.1.2000 byly předvídány nejrůznější katastrofy protože většina systémů byla již v té době kompjůterizovaná a očekávalo se že všechny počítače najednou selžou. Pojistky proti Y2K se prodávaly velmi dobre. Očekávaly se totiž výbuchy jaderných elektráren, samovolné odstartování střel s nukleárními hlavicemi, pády letadel, potopení ponorek na dno, selhání komunikačních satelitů, televizních vysílačů. Počítače se doporučovali na silvestra vypnout a zapnout je pak až na nový rok, což bylo hromadně praktikováno. Y2K problém byl také zajímavý z migračního hlediska - při migrace z platformy na platformu se inzerovalo zabití dvou much jednou ranou: Nejenže přejdete na náš produkt který je lepší než váš stávající, ale navíc si vyřešíte Y2K problém! Často byl takto inzerován přechod na Javu a Network computing.

Další historicky důležitou věcí, kterou je potřeba zmínit byl data warehousing. Pro data warehousing je v současnosti IBM stále ještě doporučovaná shared nothing architektura, kterou implementuje nemainframová edice DB2 pod názvem Database Partition Feaure dnes známá jako Inforsphere warehouse. Dříve tomu tak nebylo a DPF se používalo i jako nástroj pro škálování OLTP. Ačkoliv se zdá že jsou nemainframové edice DB2 pro data warehousing vhodnější (a především levnější) tak se data warehousing na mainframech dostatečně dobře zabydlel a provozuje se na nich dodnes. Důvodů je pro to několik - jednak data není potřeba pro zpracování přesouvat do jiného systému a za druhé DB2 je dobře integrována s workload managementem v z/OS (nástupce OS/390) díky čemu lze snížit prioritu analytickým dotazům a provádět tak data warehousing nad současnými (nikoliv historickými) daty.

Data warehousing začal být zajímavý protože se kapacita hardisků a rychlost počítačů zvětšila natolik, že nebylo už nutné stará data z kapacitních důvodů odmazávat a bylo možné je analyticky zpracovávat. Jako vždy když vznikne nová technologie, tak i tentokrát se vyrojilo spoustu startupů nabízejících produkty pro data warehousing a jako vždy jich většina zkrachovala při boji o místo na trhu. Ty vítězné koupily firmy nabízející databáze aby si rozšířily portfolio produktů a zlikvidovaly případnou konkurenci.

Nabízené warehouse produkty obvykle nebyly napsány jako analytický modul k existující databázi, ale byly to specializované databáze s omezenou (pokud vůbec nějakou) podporou jazyka SQL. Naprogramovat data warehouse tak znamenalo v první řadě vytvořit dostatečně spolehlivou a škálovatelnou databázi, což není triviální úloha.

Pamatuji si na jednu českou firmu v které pracovali moji přátelé, kteří se rozhodli že naprogramují data warehouse. Po dvou letech vývoje to vzdali, protože poznali že si ukousli příliš velké sousto a jejich malý vývojový tým byl již vyčerpán. Jako cílovou platformu si vybrali OS Unix. V té době nebyly Unixy navzájem moc portabilní a tak museli podporovat pomocí #ifdef asi 4 nejběžnější Unixy, což jim zvyšovalo náklady na vývoj, podporu a testování. V první řadě si museli naprogramovat databázi (SQL nepodporovali), což jim zabralo asi 3/4 roku a pak teprve mohli začít pracovat na multidimenzionální analýze dat. Úplný propadák to nebyl, našli se zákazníci co si jejich první verzi koupili protože to byla horká novinka a tak se chtěli s touto technologií seznámit a popřemýšlet jak by ji prakticky využili. Po uvedení jejich první verze se začaly vynořovat problémy. Předně unixů bylo v té době docela dost a zákazník obvykle požadoval verzi pro unix, který ještě neměli podporován. Podpora dalšího unixu znamenala další náklady, navíc unixy byly často dost zabugované a to co chodilo na jednom nechodilo na druhém a C překladače dodávané výrobcem za mnoho nestály. Zejména IRIX a HPUX se svou zabugovaností proslavily. Pak to byl nedpodporovaný jazyk SQL - přirozeně že ho zákazníci požadovali. Dodělat alespoň základní podporu SQL nebyla jednoduchá záležitost, ale za necelý půlrok to zvládli. Podpora SQL měla ale dva základní problémy - předně zdaleka ne všechny vymoženosti příkazu SELECT byly podporovány a za druhé neuměli optimalizovat spojení více tabulek, takže veškeré netriviální dotazy nad větším objemem dat byly velmi pomalé, prakticky nepoužitelné. Protože jejich produkt uměl načítat data k analýze jen z CSV tak se dalo očekávat že s tím zákazníci moc spokojení nebudou, dělat přesun CSV souboru pomocí FTP na unix, překonvertovat znakovou sadu a spustit loader moc netáhlo. Měli totiž svá data již někde uložené a přistupovali k ním z Windows přes ODBC. Proto by si představovali importér (nejlépe inkrementální) z ODBC zdroje a taky by měli rádi ODBC driver pro warehouse, aby si mohli naprogramovat zákaznické aplikace. Dalším požadavkem byl nástroj na tvorbu reportů a nástroj pro tvorbu aplikací - editor formulářů, protože někdo chtěl jejich warehouse používat i jako klasickou databázi. Tady v tomto bodě se rozhodli projekt zastavit, protože jim došlo že by museli vytvořit vlastně celý ekosystém a to je hodně velká práce a jejich malý tým již dost vyčerpán náročným vývojem a dál se jim už pokračovat nechtělo. Jak se říká stokrát nic umořilo osla. Navíc se začaly na českém trhu prosazovat už i konkurenční produkty z kterých si vzpomínám na teradata database a podniky slyšeli na renomovaná jména produktů lépe než na ten jejich. Řekl bych že jejich největším nedostatkem byla neznalost podnikového prostředí - co v podnikách od podobného software očekávají a jakým stylem se v nich pracuje s daty.

Já jsem se sice na vývoji jejich warehouse produktu nepodílel ale radil jsem jim jak by to bylo nejlepší udělat. Zajímavé je, že jsem jim navrhoval aby to udělali tak jak v současnosti pracuje Infosphere warehouse od IBM. Moje nejdůležitější rada, kterou si nevzali k srdci přestože jsem ji mnohokrát opakoval byla: nepište to jako samostatnou databázi, ale jako modul do Oracle či DB2 abyste mohli využít jednak možností databází, ale především již jejich existujícího ekosystému skládajícího se z nástrojů, driverů a know how vývojářů a administrátorů. To se jim nezamlouvalo z několika důvodů - jednak to byla cena databáze o kterou by se zvýšila hodnota jejich výsledného produktu a jednak by bylo získávání dat pomocí SQL příkazu místo čtení ze souboru příliš pomalé. Původně jsem jim navrhoval ať to napíší jako modul do Oracle, ale po vyslechnutí jejich připomínek mně přišla DB2 varianta lepší. Jednak byla DB2 v té době levnější než Oracle, jednak uměla direct load dat přímo do tablespaces, což Oracle v té době ještě neuměl a jednak měla dokumentovaný formát datových stránek a poskytovala API pro přímé čtení stránek. Direct load do tablespaces příkazem LOAD byla velmi rychlá záležitost. Ještě dodnes si vzpomínám že mi DB2/2 2.1.0 (odpovídající zhruba DB2 4) na OS/2 Warp 486/25 s 24 MB RAM uměla nahrát a naindexovat něco přes 100 tisíc záznamů za 19 sekund z čehož asi prvních 5 sekund se flushoval obsah existující database cache na disk než se mohlo začít nahrávat. Z tohoto výsledku jsem byl nadšen a ukazoval jsem to všem zejména když jsem to porovnal s naším mnohem hardwarově nadupanějším serverem s Oraclem 6.5, kterému to i po odpojení všech uživatelů trvalo asi tři a půl minuty. Dneska je LOAD na mainframech vysoce optimalizován a jeho rychlost se pohybuje v milionech záznamů za sekundu. LOAD by tak splnilo jejich požadavky na rychlé nahrávání dat. Pak by ještě potřebovali od DB2 funkcionalitu pro rychlé čtení dat jinak než přes SELECT. Tato funkcionalita byla později dodávána v samostatném balíku High Performance Unload, který uměl přímo načítat bloky dat či zálohy aniž by k tomu potřeboval běžící DB2. Toto by si museli naprogramovat sami. ale vzhledem k tomu že formát dat byl dokumentovaný a jejich team nebyl neschopný by to nebyl problém. Dále mně také napadlo, že by mohli dodávat již hotové řešení - tedy společně s hardwarem - dodávali by OS/2, DB2/2 a jejich produkt. OS/2 byla levný operační systém a běžela na většině IBM PC x86 hardwaru a DB2/2 byla vyloženě cenově dostupná edice. Většina lidí do hardware moc nevidí a přestože jim navrhnete nějaké doporučené sestavy, tak si je nekoupí. Když už nerozhodnou o hardware sami podle momentálních nálad, tak to nechají na svém oblíbeném hw prodejci, což nedopadne o moc lépe. Je to škoda, protože správně zvolený hardware má u databází velmi vysoký vliv na výkon, mohou to být i stovky procent. Podobný nápad jako já dostali časem i u IBM a pojmenovali to IBM Infosphere Balanced Warehouse. Nyní zase zpět k DB2.

Nejdůležitější změnou která souvisela s rozvojem data warehouse aplikací na mainframové DB2 bylo zvětšení maximální velikosti tabulek. Ve verzi 5 bylo možné rozdělit tabulku na 254 partitions o velikosti 4GB - dohromady to dalo 1 TB. To bylo v té době opravdu hodně. Dále byla zvětšena velikost indexu na 512GB skládajících se ze 128 datasetů po 4 GB. Table partitioning se začal doporučovat a stalo se na mainframu víceméně standardem rosekávat tabulky na partitions po čtvrtletích. Snadněji se s nimi totiž pracovalo kupříkladu archivace se dělala pomocí roll out - stačilo příslušnou partition odpojit od hlavní tabulky. Optimalizér SQL dotazů uměl od minulé verze V4 vynechávat při tablescanech partitions v kterých data nevyhovovala podmínce ve WHERE a poté zpracovávat partitions současně na různých procesorech v rámci jednoho dotazu. Nově se ale naučil zamykat per partition, což výrazně zvýšilo dostupnost dat.

Rozdělení dotazu na dílčí části vykonávané současně uměla již čtyřka, pětka šla ještě dál a umožnila jednotlivé části dotazu posílat k vykonání ostatním uzlům v data sharing group clusteru. To byl docela neobvyklý koncept, protože narozdil od MPP clusteru popisovaného minule měl každý uzel přístup ke všem datům v databázi a jedinou motivací pro rozdělování zátěže tak zůstalo využití procesorů na potencionálně nevyužitých uzlech. Byla otázka jak moc tato nová vlastnost pomůže výkonu jelikož databáze bývají IO bound aplikace a vzájemná komunikace uzlů byla pomalejší než při běhu na stejném uzlu, kde se komunikovalo přes sdílenou paměť. Marketing nad tím ale moc neuvažoval a často inzeroval tuto technickou novinku jako nejlepší vlastnost databázového serveru pro dvacáté první století.

Byla zlepšena dostupnost v data sharing group clusteru. Předně algoritmus pro obnovu při havárii uzlů, který jsem popsal zhruba v dílu o verzi 4 byl vylepšen. Uměl provádět potřebnou obnovu při havárii uzlu již zcela automaticky bez zásahu operátora, uvolňoval zámky při obnově uzlů dříve a uměl stěhovat sdílený bufferpool z jednoho CF uzlu na druhý aby se na původním mohla udělat údržba nebo pokud selhalo vzájemné spojení CF uzlů. Uzly si totiž nebyly zcela rovnocenné na jednom nebo více z nich běží Coupling Facility - kombinace hardware a software synchronizující jednotlivé uzly. A posledním vylepšením v oblasti dostupnosti byla možná koexistence dvou posledních verzí DB2 v rámci jednoho data sharing group clusteru. To umožnilo dělat rolling upgrades i mezi major DB2 verzemi. Zde bych rád připomenul že mluvíme o době před více než deseti lety a Oracle DB neumí v rámci svého Real Application Clusteringu dělat spolehlivé rolling upgrades nevyžadující odstávku clusteru dodnes.

Verze pro tisk