Archivácia - podpora TimescaleDB

Dnes by som chcel napísať o ďalšom vylepšení archivačného procesu v rámci aplikačného servera reálneho času Ipesoft D2000 – o podpore databázy (či skôr extenzie) TimescaleDB.

Na čo je to dobré

Ak prevádzkujete SCADA alebo MES systémy, viete, že archivácia procesných dát má svoje špecifiká. Ipesoft D2000 zbiera hodnoty z tisícov meracích bodov, často v sekundových či subsekundových intervaloch, a tieto dáta je potrebné dlhodobo ukladať, rýchlo dotazovať a efektívne agregovať. Práve pre takéto scenáre vznikla TimescaleDB.

Čo je TimescaleDB

TimescaleDB je extenzia (rozšírenie) pre PostgreSQL, nie samostatná databáza. To je kľúčový rozdiel oproti iným time-series databázam ako InfluxDB alebo Prometheus – TimescaleDB beží priamo v PostgreSQL, používa štandardné SQL, plne všetky nástroje, ktoré už s PostgreSQL poznáte (pg_dump, replikáciu, monitoring). Zjednodušene: dostanete výkon špecializovanej time-series databázy, ale bez straty relačného modelu a bez nutnosti udržiavať dva oddelené databázové systémy vedľa seba.

Pre prostredie D2000 je táto vlastnosť dôležitá – jednak nemusíme robiť zložité prepojenia medzi dvomi rôznymi databázovými technológiami a jednak využijeme databázovú podporu PostgreSQL, ktorá je už v procese D2000 Archív obsiahnutá.

Ako to funguje – hypertabuľky a chunky

Srdcom TimescaleDB je koncept hypertable (hypertabuľka). Navonok sa hypertabuľka správa ako obyčajná PostgreSQL tabuľka – rovnaké SQL príkazy, rovnaké dotazy. Pod kapotou ju však TimescaleDB automaticky rozdeľuje na menšie fyzické tabuľky nazývané chunks, typicky podľa časového intervalu (napr. jeden chunk = jeden mesiac alebo týždeň dát).

Prečo je to výhodné?

Rýchlejšie zápisy – index nového chunku je oveľa menší než index jednej obrovskej tabuľky s miliardami riadkov, takže inserty zostávajú rýchle aj po rokoch archivácie.

Rýchlejšie čítanie – ak pri dotaze na dáta z konkrétneho časového okna vie TimescaleDB preskočiť chunky, ktoré do daného okna nespadajú, a prehľadať len relevantnú časť dát.

Jednoduchšia správa – staré chunky sa dajú efektívne komprimovať, presunúť na lacnejšie úložisko alebo zmazať bez toho, aby to zaťažilo zvyšok tabuľky (napríklad DELETE nad starým chunkom je prakticky okamžitý DROP, nie riadkové mazanie).

Toto delenie je transparentné – z pohľadu D2000 archívu stále existuje jedna logická tabuľka s historickými hodnotami.

Kompresia dát

Jednou z najsilnejších vlastností TimescaleDB je natívna stĺpcová (columnar) kompresia. Staršie chunky (napríklad staršie ako 1 mesiac) sa dajú automaticky prekonvertovať zo štandardného riadkového formátu na komprimovaný stĺpcový formát. Pri time-series dátach, kde sa hodnoty medzi susednými meraniami často menia len málo, to bežne znamená 10- až 20-násobné zmenšenie objemu dát oproti nekomprimovanej tabuľke v čistom PostgreSQL.

Pre archív SCADA dát to má priamy dopad na náklady – rovnaký disk unesie oveľa dlhšiu históriu, zálohy sú rýchlejšie a lacnejšie, a keďže sa číta menej dát z disku, aj dotazy nad komprimovanými dátami môžu byť paradoxne rýchlejšie ako nad nekomprimovanými.

A čo časové rezy?

Časové rezy boli v procese D2000 Archív implementované už v roku 2010. Jedná sa o „užívateľský partitioning“ dátových tabuliek, ktorý je na rozdiel od TimescaleDB funkčný na všetkých podporených platformách (PostgreSQL, Oracle, Sybase SQL Anywhere, Microsoft SQL Server, SQLite). Na druhej strane, časové rezy iba „nasekajú“ dáta do viacerých tabuliek s fixnou časovou veľkosťou (30 dní). Nevykonáva sa žiadna konverzia na stĺpcový formát ani kompresia. Mimochodom, agregácia dát a kompresiu (natívny PostgreSQL TOAST) sa vytvára pri kompresii dát trezorov, ale do výslednej komprimovanej dátovej tabuľky v trezore už D2000 Archív nedokáže zapisovať. TimescaleDB dokáže zapisovať aj do skomprimovaných chunkov.

Prvá verzia tohto blogu obsahovala nasledovný text: Keďže časové rezy a TimescaleDB riešia ten podobnú sadu problémov, nedajú sa v D2000 použiť súčasne. Ak archívna databáza už používa časové rezy, nie je možné TimescaleDB aktivovať. A naopak, ak bola archívna databáza skonvertovaná na TimescaleDB hypertabuľky a chunky, nie je možné aktivovať časové rezy.

Lenže ... časové rezy sú dobrá vec. Riešia fragmentáciu indexov pri mazaní a optimalizujú mazanie. To znamená, že dáta sa nemažú priebežne, ale čistí sa celý časový rez, keď je starší ako nakonfigurovaná hĺbka archivácie. Pri tom sa používa príkaz TRUNCATE TABLE, ktorý negeneruje REDO logy, je rýchly a databázu zaťažuje oveľa menej ako séria DELETE príkazov. Na druhej strane, časové rezy neriešia kompresiu dát – tu by pomohla TimescaleDB. A preto sme povolili aj kombinovaný režim. Časové rezy, pričom každý časový rez može byť konvertovaný na hypertabuľku s jedným chunkom a tento chunk následne skomprimovaný. Takto zostanú zachované všetky výhody časových rezov a pridá sa výhoda kompresie.

Inštalácia TimescaleDB

Najskôr musí byť do PostgreSQL nainštalované rozšírenie TimescaleDB. Toto je možné stiahnúť z webu TimescaleDB, pričom je nutné sťahovať pre špecifickú platformu (Linux, Windows) ako aj pre konkrétnu verziu PostgreSQL (aktuálne sú podporené verzie 16, 17 a 18).

Pozor – odporúčame pred inštaláciou rozšírenia opatchovať PostgresSQL na najnovší dostupný patch. Stalo sa nám to, že najnovšia TimescaleDB (2.29.0) sa na starší PostgreSQL 17.9 síce nainštalovala, ale nebola funkčná (pomohlo nainštalovať staršiu 2.28.3). Po opatchovaní na 17.10 fungovala už aj najnovšia 2.29.0.

Aktivácia TimescaleDB v D2000 archíve

Pred aktiváciou je ešte nutné zabezpečiť, aby databázový užívateľ, ktorý je používaný na pripojenie sa k databáze (štandardne dba), mal práva SUPERUSER. Toto je možné nastaviť v D2000 Application Manageri, alebo priamo v Postgres-e (alter role dba superuser).

Rozšírenie sa v D2000 aktivuje nastavením parametrov TimescaleDBType, TimescaleDBInterval a voliteľne TimescaleDBIntervalCps.

Parameter TimescaleDBType nastavuje, pre ktoré typy archívnych objektov sa ich dátové tabuľky skonvertujú na hypertabuľky (podobne ako pre časové rezy):

• 0 - Žiaden (podpora TimescaleDB je vypnutá).

• 1 - Všetky (jednoduché aj štruktúrované archívne objekty).

• 2 - Štruktúrované archívne objekty (archivujúce stĺpec štruktúry aj celú štruktúru).

Podobne ako pri časových rezoch, v konfiguráciách s veľkým množstvom jednoduchých archívov môže zapnutie hypertabuliek na všetkých objektoch byť problematické kvôli veľkému množstvu chunkov, preto odporúčame pre takéto konfigurácie hodnotu 2.

Parameter TimescaleDBInterval udáva veľkosť časového intervalu pre jeden chunk (odporúčaná hodnota je „1 month“).

Voliteľný parameter TimescaleDBIntervalCps udáva čas komprimácie pre jednotlivé chunky hypertabuľky. Chunky, ktoré obsahujú staršie dáta, budú skomprimované. Ak tento parameter nie je zadaný, použije sa hodnota TimescaleDBInterval. Parameter teda umožňuje mať napríklad chunky s veľkosťou 1 mesiac, ale čakať 2 mesiace, kým sa budú staré dáta komprimovať.

Konverzia v D2000 archíve

Po nastavení parametrov a reštarte D2000 Archívu sa vykoná konverzia archívnych tabuliek. Ich dáta sú presunuté do chunkov a staršie chunky sú skomprimované. Konverzia môže trvať podľa veľkosti archívnej databázy a výkonu servera aj niekoľko hodín či dní.

Na mojom počítači trvala konverzia staršej kópie produkčnej databázy (iba štruktúrovaných archívnych objektov) cca 55 minút. Pôvodná veľkosť archívnej databázy bola 184 GB:

Po konverzii sa archívna databáza zmenšila na 133 GB, takže sa ušetrilo 50 GB (viac ako 25% diskového miesta).

‍

Následne som chcel vyskúšať, konverziu všetkých archívnych objektov (aj neštruktúrovaných). Keďže štruktúrované už boli skonvertované v predchádzajúcom kroku, konvertovali sa teraz iba tabuľky jednoduchých archívnych objektov. Toto trvalo 2 hodiny a 10 minút a výsledná databáza mala veľkosť 24 GB, čiže iba 13% pôvodnej veľkosti.

‍

Pozor – keďže som použil staršiu zálohu archívnej databázy, tak sa komprimovali prakticky všetky dáta. Pokiaľ by som mal aktuálnu produkčnú databázu, chunky s najnovšími dáta by zostali neskomprimované a komprimovali by sa až po dosiahnutí nakonfigurovaného veku (napr. 1 mesiac).

Informácie o objektoch

Do príkazu SHOW_INFO v D2000 System Console boli doplnené informácie o jednotlivých chunkoch hypertabuľky a o veľkosti dát komprimovaných chunkov pred a po komprimácii. Na nasledujúcom obrázku je príklad výpisu, na ktorom vidieť mesačné chunky (všetky komprimované), ktoré zaberajú 220 MB, pričom pôvodná veľkosť bola 1578 MB.

Licencovanie

Aké sú dodatočné náklady na licenciu TimescaleDB? Teraz dúfam poteším všetkých administrátorov, ktorí chcú zmenšiť svoje archívne databázy. Licencia TimescaleDB povoľuje bezplatné použitie tohto rozšírenia na vlastných serveroch aj v cloude, modifikovanie TimescaleDB pre vlastné použitie, embedovanie do vlastných aplikácií alebo servisov a použitie v komerčnom softvéri (t.j. aj na účely ako archivácia v D2000). Zakazuje iba použitie database-as-a-service v cloude, čím zabraňuje tomu, aby na TimescaleDB parazitovali poskytovatelia cloudu (viac informácii tu).

Dokumentácia

Podpora TimescaleDB v procese D2000 Archív je detailne zdokumentovaná v našej online dokumentácii.

Záver

Podpora rozšírenia TimescaleDB umožní znížiť nároky archívnej databázy na diskové miesto podobne, ako to dávnejšie implementovaná kompresia dát spravila pre trezorové databázy.

Predpokladám, že v nových aplikáciách bude táto vlastnosť využitá najskôr – a v existujúcich aplikáciách s časovými rezmi bude nasadzovaná počas migrácie na nový hardvér a novú verziu D2000, keďže si bude vyžadovať vytvorenie novej archívnej databázy a naplnenie cez utilitu arcsynchro – a následné aktivovanie TimescaleDB.

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

‍

Archivácia - podpora TimescaleDB

Peter Humaj

Archivácia - podpora TimescaleDB

Iné blogy

Dátová pumpa do DB

Príklady architektúry D2000

Komunikácia - S7-200