Archív a PostgreSql trezory

Do tretice blog venujúci sa problematike archívu na platforme databázy PostgreSQL. V minulých blogoch 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). Dnešný článok s predchádzajúcimi súvisí a týka sa niekoľkomesačných skúseností s prevádzkovaním veľkého archívu a trezorov na platforme PostgreSQL.

Aplikácia

Takže – o akých veľkých trezoroch hovoríme? Aplikácia u konkrétneho klienta má zapnuté trezorové segmenty (segmenty 0 – 4, t.j. vytvára sa päť trezorových databáz s periódou jeden mesiac). Obrázok nižšie ukazuje veľkosť jednotlivých databáz ako aj celkovú veľkosť 135 GB trezorových dát.

Obr 1: adresáre reprezentujúce trezorové segmenty za apríl 2018

Konfigurácia aplikácie obsahuje cca 59000 archívnych objektov. Z nich 292 je štruktúrovaných, takže celkový počet archívnych objektov so zarátaním položiek štruktúrovaných archívov je vyše 96000.

Obr 2: výpisy zo štartu archívu ukazujúce počet štruktúrovaných archívov (292)
a celkový počet inicializovaných archívov včítane položiek štruktúrovaných (96632)

Každú sekundu sa do archívnej databázy vkladá medzi 700 až 1200 hodnotami. Väčšina archívnych objektov je aj trezorovaná. Pri predpoklade 50 bajtov na uloženie jednej hodnoty a priemerne 1000 hodnotách za sekundu vychádza veľkosť 30-dňového trezoru ako
50 bajtov/hodnotu * 1000 hodnôt/sekundu * 86400 sekúnd/deň * 30 dní = 129.6 GB
čo zhruba zodpovedá veľkosti aprílových trezorov (135 GB ).

Obr 3: v stĺpci PerformedDatabaseRequest vidieť priemer počtu hodnôt
vložených do archívnej databázy za posledných 10 sekúnd

Záťaž archívu cca 1000 hodnôt/sekundu je typická pre rozsiahle SCADA aplikácie. Vďaka optimalizovanému využitiu kombinácie pamäťových (aplikačná cache archívu v móde izochrónnej cache) a databázových operácií v D2000 Archíve je systém D2000 schopný vo výkonnom (enterprise) server & storage prostredí zvládnuť niekoľko tisíc zápisov za sekundu bez znateľného spomalenia operácií čítania, ktoré majú prioritu (rýchla odozva diagramov).

Problémy

Počas prevádzky archívu sa viackrát ukázalo, že uvedený dátový tok (cca 1000 hodnôt za sekundu) zapisovaný do piatich trezorových segmentoch nie je vždy realizovateľný. Sčasti môže za to umiestnenie trezorov na relatívne menej výkonnom dátovom úložisku NAS RS2416RP+, sčasti periodické údržbové operácie PostgreSQL servera (vacuuming), sčasti neoptimalizovaný dávkový zápis v PostgreSQL ODBC ovládači.

Dôsledkom bol postupný nárast pamäte archívu spotrebovanej archívom na buffrovanie neuložených hodnôt a následný pád.

Riešenie

Určite by pomohlo presťahovať trezory na rýchlejšie diskové úložisko (prípadne použiť technológiu SSD). Dokážeme ale z existujúcej hardvérovej konfigurácie vyťažiť väčší výkon? Ukazuje sa, že áno.

Použili sme to isté riešenie ako v prípade zrýchlenia napĺňania trezorov utilitou arcsynchro popísané v blogu Arcsynchro a PostgreSQL trezory. Keďže princíp je rovnaký, rovnaké sú aj obmedzenia a požiadavky na realizáciu – archív musí byť spustený na tom istom serveri ako databáza PostgreSQL, resp. musí existovať spoločný adresár prístupný pre archív aj pre databázu.

K parametrom archívu pribudol nový s názvom PG_TrezorFilePath. Tento udáva adresár, v ktorom bude archív vytvárať súbory s hodnotami pre zápis do trezoru. Adresár musí byť zapisovateľný pre archív (štandardne spustený pod užívateľom SYSTEM) aj pre databázový server PostgreSQL (štandardne spustený pod užívateľom NETWORK SERVICE). Súbory budú mať názvy archiv_<TrezorId>_<SegmentId>.txt (napr. archiv_4_1.txt).

Pokiaľ je parameter PG_TrezorFilePath zadaný, archív namiesto vkladania hodnôt cez ODBC rozhranie (ako parametre pre dávkové INSERT resp. UPSERT príkazy) bude hodnoty vkladať do súborov pre príslušné trezorové segmenty. Pokiaľ je do súboru vložený dostatočný počet hodnôt alebo uplynula perióda (daná konfiguračným parametrom CommitTime), archív vykoná vloženie hodnôt (UPSERT) zo vzdialenej tabuľky reprezentovanej príslušným súborom na disku (použitie príkazu UPSERT znamená, že je vyžadovaný PostgreSQL 9.5 a vyšší).

Čo ale znamená „vložený dostatočný počet hodnôt“ ? Pri vkladaní hodnôt do archívnej alebo trezorových databáz sa štandardne vykonáva COMMIT po vložení CommitCount hodnôt (prednastavená hodnota je 1000) resp. po uplynutí periódy CommitTime (prednastavená hodnota je 60 sekúnd). V prípade vkladania hodnôt zo vzdialených tabuliek v arcsynchro sa ukázalo, že vkladanie môže byť realizované aj po oveľa väčších dávkach (napr. 100 000 hodnôt).

Preto pribudol ďalší parameter PG_TrezorFileMulti prednastavený na pomerne konzervatívnu hodnotu 10), ktorý udáva multiplikátor pre vkladanie do trezoru. Archív vykoná UPSERT na vloženie dát zo vzdialenej tabuľky do trezoru, pokiaľ sa vo vzdialenej tabuľke nazhromaždilo CommitCount * PG_TrezorFileMulti hodnôt (tj. štandardne 10 000).

Zároveň bol rozšírený tell príkaz SET_OPTION, aby hodnota parametra PG_TrezorFileMulti mohla byť upravovaná aj počas behu archívu a tell príkaz SHOW_CONFIG vypisujúci hodnoty všetkých konfiguračných parametrov archívu .

Ladenie

Pri implementácii vkladania hodnôt zo vzdialených tabuliek sme natrafili na jednu vlastnosť UPSERT-u, ktorá sa pri utilite arcsynchro neprejavila. Pokiaľ sa vykonáva UPSERT viacerých riadkov, ktoré sú duplicitné (majú ten istý primárny kľúč), tak operácia zlyhá. V prípade arcsynchro takáto možnosť nebola, keďže dáta sú čítané zo zdrojovej tabuľky, kde je definovaný rovnaký kľúč ako v cieľovej tabuľke. V prípade archívu ale bežne dochádza k „oprave“ hodnôt vypočítaných alebo štatistických archívov po príchode oneskorenej hodnoty.

Čo s tým? Riešene bolo pomerne jednoduché – namiesto okamžitého vkladania hodnôt do súboru sa tieto dočasne ukladajú do binárneho stromu v pamäti. Ten má implementovaný rovnaký kľúč (ID, ROW, COLUMN, TIME) ako tabuľka v databáze. Pokiaľ teda príde nová hodnota s tým istým kľúčom, nahradí v strome predchádzajúcu a k duplicite tak nemôže dôjsť. Keď je v strome viac ako CommitCount * PG_TrezorFileMulti hodnôt, vykoná sa ich zápis do súboru a zavolá sa UPSERT.

Keďže namiesto vloženia hodnoty a jej následnej aktualizácie sa vykoná iba vloženie novšej hodnoty (pokiaľ obe hodnoty boli vložené v rámci jednej dávky), zároveň sa zníži záťaž databázy – generuje sa menej WAL dát (write ahead log, obdoba REDO logov Oracle) a vkladá sa aj menej dát do dátových tabuliek. Menej dát v tabuľkách súvisí s tým, že PostgreSQL implementuje tzv. MVCC model (Multiversion concurrency control), čo znamená, že v tabuľke sa nachádza riadok s pôvodne vloženou hodnota ako aj riadok so zmenenou hodnotou a až pravidelné upratovanie – vacuuming – odstráni neaktuálne hodnoty, ktoré už nepotrebuje vidieť žiadna z prebiehajúcich transakcií.

Záver

Po otestovaní v laboratórnych podmienkach beží upravený archív už týždeň na produkcii. Počas tohto obdobia nedošlo k žiadnemu nárastu pamäte archívu spôsobenému nestíhaním zápisov do trezorov – napriek tomu, že niekoľko dní prebiehalo aj upratovanie dát v starších trezoroch. Zároveň došlo k zníženiu I/O operácií na disku s trezormi a percentu času, počas ktorého je disk aktívny – spomínané ukazovatele sú zisťované pomocou programu Resource Monitor, ktorý je súčasťou inštalácie Windows Server 2008 R2 alebo 2012.

Optimalizácia zápisu do PostgreSQL trezorov s využitím externých tabuliek je ďalšia z úprav, ktoré prispievajú k zvyšovaniu výkonu archívneho subsystému D2000 a posúvajú ďalej hranice možností databázy PostgreSQL ako úložiska archívnych a trezorových dát vhodného aj tie pre najrozsiahlejšie MES aplikácie, aké sú v súčasnosti na technológii D2000 postavené.

Odkaz pre našich zákazníkov –či malých alebo veľkých – je jasný: kombinácia D2000 Archívu s databázovým serverom PostgreSQL je dnes dostatočne výkonná na absolútnu väčšinu aplikácií – aj pri použití štandardného hardvéru.

15.5.2018, Ing. Peter Humaj, www.ipesoft.com