Archivácia - najrýchlejšie auto na svete

Pred časom som videl video, v ktorom autori jedného SCADA systému demonštrovali funcionalitu ich historianu (archívu) na platforme Raspberry Pi. Ukazovali, ako dokáže archivovať 10-tisíc hodnôt za sekundu do MS SQL databázy bežiacej na vzdialenom Windows serveri. Dáta sa ukladali do 200 tabuliek, z ktorých každá mala dáta 500 objektov (obsahovala jeden časový stĺpec a 500 dátových).

Na prvý pohľad bola táto demonštrácia pôsobivá. Historian bežiaci na Raspberry Pi a stíhajúci 10-tisíc hodnôt za sekundu ... paráda, nie?

Až po chvíli mi začali dochádzať širšie súvislosti.

Po prvé – Raspberry Pi v tomto príklade zapisuje do vzdialenej MS SQL databázy. Takže v podstate iba volá raz za sekundu vkladanie (predkompilovaný insert) do 200 tabuliek. A samozrejme predtým musí nastaviť vkladaných 500 hodnôt a časovú značku pre každú tabuľku. Ale všetky ostatné operácie vykonáva vzdialený MS SQL server - na rozdiel od našich výkonnostných testov v blogu „Čo zvláda Raspberry Pi“, kde bol celkový tok do PostgreSQL archívnej databázy spustenej na tom istom Raspberry Pi ako D2000 na úrovni 1250-1450 požiadaviek za sekundu.

Navyše, hodnoty boli získavané simuláciou. Keby mali pochádzať z komunikácie (ako počas našich výkonnostných testov), je otázka, aký výkon procesora by vyčítanie stotisíc meraných bodov za sekundu spotrebovalo ...

Po druhé – ukladá sa iba spoločná časová značka a hodnoty. Žiadne príznaky (validita, alarmy, limity, užívateľské príznaky), ktoré D2000 Archív štandardne ukladá spolu s hodnotou. Navyše sa jedná o periodické ukladanie a teda presnosť časovej značky je jedna sekunda.

Po tretie – každú sekundu sa ukladajú hodnoty všetkých 500 objektov v rámci jednej tabuľky hodnôt. Bez ohľadu na to, či sa zmenili, alebo nie. Takže každú sekundu pribúdajú do archívnej databázy ďalšie dáta. Mám otázku: aká bude veľkosť takejto tabuľky a ako pohodlne sa s ňou bude robiť? Navyše, keďže sú hodnoty 500 objektov v jednej tabuľke, musia mať spoločnú hĺbku archivácie. Ak budem chcieť zväčšiť hĺbku archivácie jedného z objektov, zmením ju všetkým.

D2000 Archív ide na vec z úplne opačného konca. Jednak každý objekt je v samostatnej tabuľke v archívnej databáze – môže mať nezávislú hĺbku archivácie. Navyše sa snaží minimalizovať počet zápisov do tabuľky a teda šetriť aj výkon databázového servera aj jeho disky. V prípade zmenových archívov je možné nastaviť filter - dokonca je možné definovať až 3 pásma a nastaviť iný filter v každom z nich. V prípade periodických archívov má implementované zmenové ukladanie periodických hodnôt – hodnota je uložená iba vtedy, ak sa zmení. Takže ak je napr. celý deň hodnota objektu konštantná a archivuje sa s 1-minútovou periódou, tak sa do databázy uloží spomenutá konštanta iba raz. Pochopiteľne, pri čítaní musí D2000 Archív „rozvinúť“ načítanú hodnotu (všetky „rozvinuté“ hodnoty majú nastavený archívny flag ‚K‘).

Po štvrté – ak sa v jednej tabuľke ukladá 500 objektov, ako funguje práca s oneskorenými hodnotami? Je bežné, že z komunikácie prichádzajú hodnoty aj s časovými značkami. Ak sú tieto oneskorené o niekoľko sekúnd, tak musí historian aktualizovať hodnoty v už vložených riadkoch. No, musí .. nemusí, ak definuje, že nerieši oneskorené hodnoty. D2000 Archív samozrejme takéto korekcie vykonáva. V prípade periodických archívov vďaka zmenovému ukladaniu spomenutému vyššie nejde o korekciu - update, ale o jednoduché vloženie – insert. V prípade archívov archivovaných na zmenu sa hodnota vloží do databázy, keď príde. D2000 Archív navyše dokáže automaticky prepočítať aj hodnoty štatistických a vypočítaných archívov, ktoré závisia na archívnom objekte s oneskorenými hodnotami.

Takže to zhrniem: myslím si, že demonštrovaná konfigurácia je dosť vzdialená od reality. Nepoznám zákazníka a projekt, ktorý by potreboval ukladať stovky alebo tisícky hodnôt do databázy, s periódou sekunda alebo niekoľko sekúnd. Na druhej strane, viacero aplikácií postavených na D2000 obsahuje aj viac ako stotisíc archívnych objektov, ale aj vďaka optimalizáciám sa ukladá do databázy iba niekoľko stoviek až niekoľko tisíc hodnôt za sekundu.

Možno Vás napadne otázka, či by dokázal D2000 Archív ukladať údaje v podobnom „širokom“ formáte ako popisovaný historian. Odpoveď znie: nie, D2000 Archív to nedokáže. Dokáže to ale D2000 DbManager (samozrejme s trochou programovania v ESL alebo Jave). Riadky je možné vkladať po jednom alebo niekoľko naraz.

Prečo má tento blog provokatívny názov „najrýchlejšie auto na svete“? Keby niekto ponúkal na predaj takéto auto, tak na prvý pohľad je to veľmi príťažlivé. Až po preštudovaní podkladov a zamyslení sa, načo vlastne auto potrebuje, by si záujemca uvedomil, že takéto auto asi nie je veľmi praktické, má vysokú spotrebu a cenu podstatne vyššiu ako u bežného sériového auta. Asi sa doň nezmestí aj s deťmi a na nákupy tiež nebude najvhodnejšie... Podobne aj v prípade archívnych subsystémov a historianov – užívatelia v praxi viac ako rýchlosť ocenia vlastnosti ako funkcionalita (v prípade D2000 Archívu sú to napr. štatistické, vypočítané a skriptom plnené archívy), stabilita, možnosti ladenia a diagnostiky, vysoká dostupnosť (redundancia archivácie), bezúdržbovosť (D2000 Archív vykonáva aj mazanie dát, prípadne upratovanie a reorganizáciu archívnych databáz, takže v praxi je nutné iba poskytnúť databáze dostatok diskového priestoru). A keď už spomíname diskový priestor, tak ani kompresia trezorových databáz (dostupná v najnovšej verzii D2000), ktorá niekoľkonásobne redukuje miesto potrebné na ukladanie dlhodobých archívov, nie je na zahodenie.

Rýchlosť je teda iba jedným z viacerých parametrov, ktoré je nutné pri výbere archívneho systému zvážiť. A podľa môjho názoru ani nie tým najdôležitejším.

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

‍

Archivácia - najrýchlejšie auto na svete

Peter Humaj

Archivácia - najrýchlejšie auto na svete

Iné blogy

Komunikácia - Mitsubishi MELSEC protokol

Komunikácia - Bernecker & Rainer PLC

D2000 a výkonnostné ladenie skriptov