info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
22.11.2024
Archív a PostgreSql trezory - kompresia
Archív a PostgreSql trezory - kompresia
V predchádzajúcich blogoch o archíve na platforme databázy PostgreSQL som písal o zrýchľovaní utility Arcsynchro pri napĺňaní PostgreSQL trezorov (Arcsynchro a PostgreSQL trezory) a o výsledkoch migrácie (Migrácia trezorov na PostgreSQL v praxi) a o optimalizácii zápisu do trezorov (Archív a PostgreSql trezory). V dnešnom článku sa pozrieme na zúbok najnovšej vlastnosti D2000 archívu.
Trezory – čo s nimi?
Trezory sú vo väčšine SCADA a MES aplikácií položkou, ktorá má najväčšie nároky na disky. Je to logické – konfiguračná databáza je spravidla malá (desiatky až stovky megabajtov), monitorovacia tiež (maximálne gigabajty, keďže má definovanú časovú hĺbku). Archívy môžu byť veľké (v praxi až niekoľko terabajtové), ale opäť - vďaka definovaniu časovej hĺbky jednotlivých archívnych objektov (spravidla mesiace až roky) po čase dosiahnu svoju „cieľovú“ veľkosť a ďalej rastú iba skromne, v dôsledku rozširovania aplikácie.
No nie tak trezory. Tieto databázy vytvára D2000 Archív pravidelne (s konfigurovateľnou periódou) a stále iba pribúdajú. V minulosti (ešte na platforme Sybase SQL Anywhere) bol trend naplnené trezorové databázy odpájať a „niekam“ presúvať (napr. napáliť na CD a uschovať do trezoru – odtiaľ vlastne získali svoje meno). S nárastom dostupnej diskovej kapacity a s požiadavkami užívateľov na dostupnosť historických dát pribudla možnosť D2000 Archívu ponechať trezory k dispozícii (na čítanie).
Takže dnes sa ocitá správca D2000 aplikácie medzi dvoma kameňmi. Z jednej strany užívatelia chcú mať „všetky dáta dostupné“, z druhej strany musí bojovať so správcami infraštruktúry (alebo rozpočtu, v prípade, že si infraštruktúru spravuje sám) o pravidelné rozširovanie diskového priestoru.
Možnosti technológie
Vie mu nejak pomôcť samotná D2000?
Ukazuje sa, že áno. Pri použití databázového servera Sybase SQL Anywhere bol trezor po naplnení skomprimovaný prostriedkami Sybase. Z databázového súboru (s príponou .db) vznikla komprimovaná databáza (s príponou .cdb). V neskorších verziách SQL Anywhere (verzia 11, 12) táto vlastnosť bohužiaľ zanikla. Navyše, Sybase SQL Anywhere nebola vhodná pre databázy s veľkosťou nad niekoľko desiatok GB.
Keď sme začali nasadzovať väčšie riešenia postavené na databáze Oracle, tak sme veľkosť trezorov v podstate neriešili. Oracle síce ponúka vlastnosti ako Compression alebo Advanced Compression, ale nikdy sme ich nepoužili – keďže to boli platené opcie, dostupné iba v príliš drahej Enterprise verzii.
Dnes je preferovanou platfomou technológie D2000 databáza PostgreSQL – najpokročilejšia open source databáza. Obľúbili sme si ju pre jednoduché spravovanie, vysokú stabilitu a dobrú škálovateľnosť.
Jedna vec, ktorá mi osobne na PostgreSQL chýbala, je absencia IOT tabuliek (index-organized-tables). Je to vlastnosť, ktorú má Oracle aj Microsoft SQL server – schopnosť ukladať v jednej dátovej štruktúre index spolu s dátami. Jednak to zrýchľuje prácu s dátami a jednak dochádza k úspore miesta. Táto vlastnosť pomáha šetriť miesto v Oracle archívoch a trezoroch. Navyše, formát dát používaný PostgreSQL obsahuje 23-bajtovú hlavičku riadku. Suma sumárum, archív sa po konverzii z Oracle na PostgreSQL zväčší aj dvakrát.
Čo s tým? S obľubou sme na platforme Windows nastavovali kompresiu adresárov, v ktorých bola archívna databáza uložená. Kompresia dosahovala pomer asi 2.2:1 a podľa našich testov mala minimálny vplyv na rýchlosť a výkon PostgreSQL.
Ale v prípade trezorov vieme urobiť niečo ešte lepšie.
Kompresia dát v PostgreSQL
Ako vyzerá tabuľka DATA, do ktorej sa ukladajú všetky dáta v trezore? Obsahuje tieto stĺpce:
• Id – číselný identifikátor objektu
• Row – pre štruktúrované archívy číslo riadku
• Col - pre štruktúrované archívy číslo stĺpca
• Cas – časová značka
• Value – hodnota
• Status, LimitStatus, ArchivStatus, Flags - rôzne príznaky hodnoty
Pre všetky hodnoty konkrétneho objektu (prípadne položky štruktúrovaného archívu) sú v tabuľke tie isté hodnoty Id, Row a Col. Dokážeme tieto duplicity odstrániť a tak zredukovať veľkosť dát?
Odpoveď je áno. PostgreSQL podporuje stĺpce typu pole – v takomto stĺpci sa nenachádza jedna hodnota, ale celé pole (vektor). Navyše umožňuje definovať „štruktúrované typy“ – zložené z jednoduchých. No a kombináciou týchto dvoch vlastností dostaneme stĺpec, do ktorého zapíšeme pole štruktúr. A to je presne to, čo potrebujeme na zredukovanie veľkosti trezorov.
Takže čo robí D2000 Archív na optimalizovanie štruktúry trezorovej databázy?
• Zadefinuje užívateľský typ d2trzitem, ktorý pozostáva zo zložiek dTime, Value, Status, LimitStatus, ArchivStatus, Flags. Jednotlivé zložky zodpovedajú príslušným stĺpcom v tabuľke DATA. Výnimkou je dTime – o tom neskôr.
• Vytvorí tabuľku CDATA so stĺpcami Id, Row, Col, Cas0, CValue. Posledný stĺpec je definovaný ako pole štruktúr typu d2trzitem. Všetky hodnoty jedného archívneho objektu (alebo jednej položky štruktúrovaného archívu) sa budú nachádzať v jednom riadku tabuľky CDATA.
• Vykoná samotnú konverziu - naplní tabuľku CDATA dátami z tabuľky DATA a následne tabuľku DATA vymaže. Tento tretí krok je najdlhší a najnáročnejší na CPU aj I/O operácie.
Pozorný čitateľ si všimne, že tabuľka CDATA obsahuje stĺpec Cas0, nie Cas. Nejedná sa o preklep, ale o zámerné odlíšenie názvu stĺpca od stĺpca Cas v tabuľke DATA. Stĺpec Cas0 obsahuje čas prostriedku intervalu, pre ktorý je trezor vytváraný. Prečo prostriedku? Lebo sme zaviedli ďalšiu optimalizáciu –položka dTime užívateľského typu d2trzitem udáva offset (v milisekundách) od Cas0. A keďže štandardné numerické typy PostgreSQL sú znamienkové, je vhodné definovať Cas0 ako stred intervalu trezorovania. Ak máme trezor za obdobie kratšie ako 49.7 dňa (väčšina našich zákazníkov používa mesačné, týždňové, 2-týždňové alebo 10-dňové trezory), postačí definovať dTime ako 4-bajtový typ integer (a ušetríme 4 bajty na každej časovej značke). V opačnom prípade D2000 Archív definuje dTime ako 8-bajtový bigint (a neušetríme nič voči 8-bajtovému dátovému typu timestamp).
Kvôli optimalizácii čítania obsahujú trezory aj hodnoty objektov, ktoré mali, keď trezor vznikal. Tieto hodnoty sú staršie ako čas začiatku trezorovania. Preto sú pri kompresii trezora tieto staršie hodnoty presunuté do tabuľky DATA0, ktorá má rovnaký formát ako pôvodná tabuľka DATA.
PostgreSQL a toasty
PostgreSQL implementuje techniku pre ukladanie „veľkých“ stĺpcov, ktorá sa volá TOAST (The Oversized-Attribute Storage Technique). Obsah veľkých stĺpcov (v našom prípade stĺpec CValue v tabuľke CDATA) je transparentne skomprimovaný a uložený ako bloky konštantnej veľkosti (štandardne 2kB). Táto vlastnosť prispeje k ďalšiemu zmenšeniu veľkosti trezora.
Kedy komprimovať?
D2000 Archív dokáže trezory komprimovať automaticky po naplnení (pokiaľ je parameter TrezorCompress nastavený na hodnotu 1). Staré trezory je možné tiež skomprimovať – na to slúži príkaz TREZOR COMPRESS. Existuje aj varianta TREZOR DECOMPRESS, ktorá vykonáva reverzný proces – rozbalenie dát z tabuľky CDATA do tabuľky DATA.
Kompresiu je možné vykonať v „cvičnom“ móde – ak je parameter TrezorCompressKeep nastavený na hodnotu 1, pôvodná tabuľka DATA nie je vymazaná. Následne sa dá aj v prípade veľkých trezorov TELL príkazom TREZOR DECOMPRESS za niekoľko sekúnd prejsť do pôvodného stavu.
Čo je komprimované?
Tell príkaz LIST_TREZORS bol rozšírený, aby vypisoval informáciu, že trezor je komprimovaný (v obrázku nižšie príznak cps).
Obmedzenia
D2000 Archív ani utilita D2000 Arcsynchro nevie modifikovať komprimované trezory. Dokážu z nich iba čítať. Preto v prípade, že by bolo nutné do komprimovaných trezorov napr. dopĺňať dáta, je nutné ich najskôr dekomprimovať.
Keby sme aj dokázali modifikovať riadky v rámci tabuľky CDATA, bolo by to príliš drahé – zápisy by generovali veľké REDO logy a kvôli „multiversion“ architektúre PostgreSQL by zostávali na disku aj staré riadky. Takže kompresia je jednoznačne na mieste po naplnení a uzavretí trezora.
Aké sú obmedzenia PostgreSQL? Existuje obmedzenie na 1GB dát v rámci jednej položky v tabuľke. Preto pokiaľ by trezory obsahovali príliš veľa hodnôt jedného objektu, nebudú sa dať skomprimovať. Jedna možnosť je zmenšiť periódu trezorovania. Druhá je rekonfigurovať problematický archívny objekt (napr. nastaviť zmenové filtre, prípadne časový filter pri vypočítaných zmenových archívoch).
Existujú aj nejaké obmedzenia pre užívateľov? Kompresia trezorov je vykonávaná na pozadí popri iných činnostiach D2000 Archívu. Keď sa komprimuje konkrétny trezor, stále funguje aj čítanie z neho – číta sa z pôvodnej nekomprimovanej tabuľky. Užívatelia si teda túto aktivitu vôbec nevšimnú – iba čítanie z diskov zaťažených kompresiou môže trvať dlhšie.
Rýchlosť
Pri nasadzovaní kompresie na produkčné systémy sme si všimli, že trvanie kompresie výrazne závisí od toho, ako sú dáta v trezore „upratané“. Preto bol zavedený ďalší parameter TrezorCompressReorg, ktorého prednastavená hodnota 1 znamená, že D2000 Archív pred kompresiou trezora vykoná jeho upratanie (reorganizáciu – clustrovanie dát v tabuľke DATA podľa indexu). Reorganizácia v produkčnom systéme skrátila čas kompresie cca 40 GB mesačného trezora z 24 hodín na cca 1.5 hodiny.
Ako je ovplyvnená rýchlosť čítania? Rýchla odpoveď je, že bežný užívateľ nič nezbadá. Na jednej strane sa skráti čas čítania dát z disku, na druhej strane pribudne nutnosť dekompresie dát. Tieto dva vplyvy sa viacmenej vykompenzujú (aj keď v konkrétnej aplikácii sme zaznamenali zrýchlenie na úrovni milisekúnd). Spomalenie čítania môže byť v špecifických scenároch – ak potrebujeme jednu alebo niekoľko hodnôt z konkrétneho času v trezore, tak kvôli ním musia byť načítané a dekomprimované všetky hodnoty zvoleného archívneho objektu. Ak chcete otestovať prácu s komprimovanými trezormi, môžete vyskúšať kompresiu v „cvičnom“ móde popisovanú vyššie.
Výsledky a prínos
Tento parameter bude pre správcov D2000 trezorov asi najzaujímavejší. Takže o koľko sa zmenšili trezorové databázy po ich kompresii? O štvrtinu? Alebo až o polovicu?
Po implementácii kompresie trezorov a testovaní na „umelých“ dátach sme síce namerali aj 10-násobné zmenšenie veľkosti trezorov, ale tieto čísla sme brali s rezervou. Každopádne sme boli zvedaví na výsledky a tak sme priamo do výpisov D2000 Archívu o kompresii trezorov doplnili zisťovanie veľkost tabuľky DATA pred kompresiou a CDATA po kompresii (pomocou PostgreSQL funkcie pg_total_relation_size, ktorá vracia veľkosť tabuľky včítane indexov a TOAST-ových dát).
Kompresia zmenšila veľkosť niektorých trezorov 12-násobne, iných 15 alebo 17-násobne. V prípade niektorých trezorov došlo až k 20-násobnému zmenšeniu veľkosti, ale je možné, že dáta v týchto trezoroch boli „rozbité“ a neupratané.
Na predchádzajúcom obrázku je možné vidieť, že kompresia trezora 131 trvala takmer 24 hodín, ale kompresia trezora 132 už iba cca 1.5 hodiny – medzi týmito dvoma kompresiami bolo implementované už spomínané upratovanie trezora pred kompresiou.
Ďalší obrázok ukazuje obsadenie miesta na 460 GB disku s trezormi. V dôsledku kompresie (23.3. až 9.4.) sa zmenšilo obsadené miesto z cca 65% (300 GB) na 60 GB. Voľné miesto postačí pri 2.5 GB komprimovaných trezorových dát mesačne na viac ako 12 rokov. Bez kompresie (pri 30 GB trezorových dát mesačne) by disk vystačil iba 1 rok. Toto je konkrétny a hmatateľný prínos pre správcu D2000, prípadne pre správcu diskových polí.
Záver
Kompresia trezorov na platforme PostgreSQL je jedna zo zaujímavých vlastností, ktoré prináša aplikačný server reálneho času Ipesoft D2000 v novej verzii existujúcim aj novým užívateľom. Verím, že kompresiu využije veľa našich zákazníkov a OEM partnerov a teším sa na spätnú väzbu od nich.
4.5.2021, Ing. Peter Humaj, www.ipesoft.com
Iné blogy