V rokoch 2022 – 2023 sme cez partnerskú spoločnosť dodávali analytickú časť projektu optimalizácie štátnych informačných systémov. Jedna z otázok znela: ukladať časové rady (merania, udalosti, logy) do čistého PostgreSQL, alebo do rozšírenia TimescaleDB? Obe strany mali argumenty, ani jedna merania. Pripravili sme test, ktorý sa dal zopakovať, a dali rozhodnutiu podklad. Článok je pre architektov a technických vedúcich pred podobnou voľbou: čo je TimescaleDB v roku 2026, čo zvládne samotný PostgreSQL, ako navrhnúť test, ktorému uverí aj druhá strana, a ako výsledok zhrnúť pre vedenie.

Čo je TimescaleDB a čo sa odvtedy zmenilo

TimescaleDB je rozšírenie PostgreSQL, nie samostatná databáza. Aplikácia ďalej používa štandardné SQL a rozšírenie pridáva hypertabuľky: navonok jedna tabuľka, ktorá sa interne automaticky delí na časové úseky (chunky). Nad nimi stoja priebežné agregáty (continuous aggregates), teda materializované súhrny, ktoré sa obnovujú inkrementálne, teda prepočítajú sa len tie časové úseky, v ktorých sa dáta zmenili, nie celý pohľad. Od verzie 2.13 do nich predvolene nevstupujú najnovšie, ešte nezmaterializované riadky. Ak ich výsledok má obsahovať, treba to zapnúť (real-time agregácia).

Kompresia, s ktorou sme pracovali v rokoch 2022 – 2023, sa dnes v dokumentácii opisuje ako hypercore: nové dáta sa zapisujú do riadkového úložiska (rowstore) a s pribúdajúcim vekom sa presúvajú do stĺpcového (columnstore), ktoré je stavané na skenovanie a agregácie. Od verzie 2.18 majú príslušné funkcie nové názvy a pôvodné sú označené ako zastarané. Zmenil sa aj výrobca: spoločnosť Timescale sa v júni 2025 premenovala na Tiger Data a jej cloudová služba sa volá Tiger Cloud. Rozšírenie si názov TimescaleDB ponechalo. V starších podkladoch, zmluvách a dokumentácii sa preto stretnete s oboma názvami firmy aj funkcií.

Licencia: ktorá časť je open source

Kód TimescaleDB je pod dvoma licenciami. Vydanie Apache 2 (licencia Apache 2.0) obsahuje hypertabuľky, základnú prácu s chunkami a funkciu time_bucket. Vydanie Community pod licenciou TSL (v texte zmluvy Timescale License, v dokumentácii vydaní už Tiger Data License) pridáva práve to, čo býva dôvodom nasadenia: priebežné agregáty, stĺpcové úložisko a kompresiu, politiky uchovávania dát a plánovač úloh. Podľa dokumentácie výrobcu sa vydanie Community dá bezplatne prevádzkovať na vlastnej infraštruktúre pre vlastné potreby. Licencia zakazuje ponúkať ho ako databázovú službu (Database-as-a-Service) alebo ho inou formou služby sprístupňovať tretím stranám. Výnimkou sú produkty s pridanou hodnotou, ktoré nie sú primárne databázovou službou, pridávajú hodnotu inej povahy a neumožňujú používateľom meniť schému databázy. Interná aplikácia nad databázou teda problém nie je, pri softvéri ponúkanom ako služba treba podmienky licencie posúdiť.

Spravovaný PostgreSQL od iného poskytovateľa než Tiger Data preto môže obsahovať len vydanie Apache 2, teda bez funkcií, ktoré v našom teste rozhodovali. Aktívne vydanie ukáže príkaz SHOW timescaledb.license. Pri obstarávaní alebo pri prevádzke cez externého dodávateľa patrí licencia do posúdenia skôr než výkon, lebo výsledok testu na vlastnom serveri nemusí platiť na hostingu, ktorý napokon dostanete.

Viazanosť na verzie PostgreSQL

Každá verzia TimescaleDB podporuje len určité hlavné verzie PostgreSQL. Podľa aktuálnej tabuľky kompatibility verzie 2.20 až 2.22 podporovali PostgreSQL 15 až 17, PostgreSQL 18 pribudol vo verzii 2.23 a od verzie 2.29 už PostgreSQL 15 podporovaný nie je. Rozšírenie sa musí načítať pri štarte servera (shared_preload_libraries) a aktualizuje sa v každej databáze zvlášť cez ALTER EXTENSION. Upgrade PostgreSQL tak znamená dva zladené kroky: najprv verzia rozšírenia, ktorá podporuje starý aj nový PostgreSQL, potom samotný PostgreSQL.

Pribúdajú aj zmeny, ktoré vyžadujú zásah. Priebežné agregáty vytvorené pred verziou 2.7 používajú starý formát, ktorý verzia 2.25 odstránila, takže ich treba zmigrovať ešte na staršej verzii. Výrobca tiež odporúča nepoužívať rozšírenie s PostgreSQL 17.1, 16.5 a 15.9 pre zmenu binárneho rozhrania, ktorú PostgreSQL v nasledujúcich opravných verziách vrátil. Nič z toho nie je dôvod rozšírenie odmietnuť. Je to však práca, ktorá patrí do odhadu prevádzky.

Čo zvládne samotný PostgreSQL

Férové porovnanie stavia TimescaleDB proti dobre navrhnutému PostgreSQL, nie proti jednej obrovskej tabuľke s jedným indexom. Čistý PostgreSQL má na časové rady niekoľko nástrojov:

  • Deklaratívne particionovanie podľa času: plánovač vynechá partície, ktoré dotaz nepotrebuje, a staré dáta sa odstránia odpojením alebo zmazaním partície, bez hromadného DELETE a následnej záťaže pre VACUUM.
  • pg_partman: rozšírenie, ktoré vopred zakladá nové partície a podľa nastavenej politiky odstraňuje staré. Od verzie 5 pracuje len s natívnym deklaratívnym particionovaním a vyžaduje PostgreSQL 14 alebo novší.
  • BRIN indexy: pre veľmi veľké tabuľky, v ktorých poradie riadkov na disku zodpovedá času zápisu. Index je malý a umožní preskočiť veľké časti tabuľky. Pri dátach bez takejto súvislosti stráca zmysel.
  • Materializované pohľady: REFRESH prepočíta celý dotaz, inkrementálne obnovovanie PostgreSQL nemá. Variant CONCURRENTLY neblokuje čítanie, ale vyžaduje jedinečný index. Alternatívou sú súhrnné tabuľky, ktoré dopĺňa vlastná plánovaná úloha.

Ani particionovanie nie je zadarmo: dokumentácia PostgreSQL upozorňuje, že príliš veľa partícií predlžuje plánovanie dotazov a zvyšuje spotrebu pamäte. Veľkosť časového úseku sa preto oplatí overiť meraním rovnako ako veľkosť chunku v TimescaleDB.

Ako navrhnúť férový a zopakovateľný test

Náš test stál na štyroch pilieroch. Server a verzia PostgreSQL boli na oboch stranách rovnaké a TimescaleDB bežal ako rozšírenie nad nimi. Dáta zodpovedali objemu a tvaru produkcie (stovky miliónov riadkov, skutočné rozloženie časov a kľúčov). Dotazy pochádzali z aplikácie a neboli syntetické (posledné hodnoty, agregácie po dňoch a mesiacoch, vyhľadávanie v okne, hromadné zápisy). Každý dotaz sme spustili viackrát a merali medián aj najhorší čas. Pri ďalších rozhodnutiach tohto typu postupujeme podľa tohto zoznamu:

  • Otázka a kritérium pred meraním. Zapíšte, aké rozhodnutie má test podporiť a aký rozdiel je pre vás podstatný. Inak sa kritérium dodatočne prispôsobí výsledku.
  • Reprezentatívne dáta. Objem, rozloženie v čase, nerovnomernosť kľúčov a vek dát ako v produkcii. Ak ide o osobné údaje, anonymizujte ich tak, aby sa rozloženie nezmenilo.
  • Reálne dotazy s váhami. Zoznam dotazov a ich frekvenciu vezmite z prevádzky, napríklad z pg_stat_statements, nie z predstavy o tom, čo aplikácia robí.
  • Rovnaké a izolované prostredie. Rovnaký hardvér, verzie, konfigurácia a indexy. Na stroji počas merania nebeží nič iné a klient, ktorý generuje záťaž, nesmie byť sám úzkym hrdlom.
  • Rovnaký stav dát. Po načítaní VACUUM ANALYZE na oboch stranách. Pri TimescaleDB zaznamenajte, ktoré chunky sú v stĺpcovom úložisku. Merania pred kompresiou a po nej sú dva rôzne výsledky.
  • Studená a teplá cache oddelene. Prvý dotaz sám osebe nezaručuje čítanie z disku: dáta už môžu byť v cache databázy alebo operačného systému. Stav oboch vrstiev preto pri meraní kontrolujte a zaznamenajte. Cache sa dá cielene zahriať napríklad modulom pg_prewarm.
  • Dosť opakovaní a správne štatistiky. Dlhšie behy, viac opakovaní, medián a p95 alebo p99 namiesto priemeru, ktorý skreslí niekoľko extrémnych hodnôt. Najhorší čas uveďte zvlášť.
  • Súbežnosť. Okrem samostatných dotazov aj zmiešaná záťaž: zápisy počas čítania. Nástroj pgbench vie spúšťať vlastné skripty a zapisovať čas každej transakcie, z ktorého sa percentily dopočítajú.
  • Vysvetlenie, nielen čas. EXPLAIN ANALYZE pri kľúčových dotazoch ukáže, či rozdiel spôsobil plán, vynechanie časových úsekov alebo počet prečítaných blokov. Dotaz sa pritom naozaj vykoná, zápisy preto spúšťajte v transakcii s ROLLBACK.
  • Zaznamenaná konfigurácia. Verzie, nastavenia servera (EXPLAIN s voľbou SETTINGS vypíše odchýlky od predvolených hodnôt), skripty na generovanie dát aj na meranie uložené v repozitári, aby test mohla zopakovať druhá strana.

Čo vyšlo a čo rozhodlo

Pri agregáciách nad dlhými obdobiami bolo rozšírenie TimescaleDB výrazne rýchlejšie vďaka členeniu na časové úseky a priebežným agregátom. Pri bodových dotazoch a krátkych oknách bol rozdiel malý alebo žiadny. Pri hromadných zápisoch bol Timescale rýchlejší, ale s väčšou spotrebou miesta, kým sa nezapla kompresia. Po kompresii bol objem na disku menší než v čistom PostgreSQL.

Napokon rozhodla prevádzka. TimescaleDB pridáva ďalší komponent, ktorý treba aktualizovať, a viaže na konkrétne verzie PostgreSQL. Pre časť systému s dlhodobými agregáciami sa to oplatilo, pre zvyšok ostal čistý PostgreSQL. Pri podobnom rozhodnutí dnes do prevádzkových nákladov počítame najmä:

  • licenciu potrebného vydania a jeho dostupnosť na zvolenom hostingu,
  • plán upgradov PostgreSQL aj rozšírenia a čas na otestovanie každého z nich,
  • obnovu zo zálohy vyskúšanú na reálnom objeme, nielen existenciu zálohy,
  • monitorovanie úloh na pozadí (obnova agregátov, presun do stĺpcového úložiska, mazanie starých dát),
  • znalosti tímu, ktorý bude systém prevádzkovať o niekoľko rokov,
  • cestu späť: ako dostať dáta do obyčajných tabuliek, ak sa rozšírenie prestane hodiť.

Zhrnutie pre vedenie na jednu stranu

Vedenie nepotrebuje grafy zo všetkých behov. Potrebuje rozhodnutie a dôvod, prečo mu môže veriť. Osvedčila sa nám nasledujúca štruktúra a všetko ostatné patrí do prílohy:

  • Otázka: čo sa rozhoduje a do kedy.
  • Čo sme merali: dáta, dotazy, prostredie a počet opakovaní v niekoľkých vetách.
  • Čo vyšlo: výsledok po typoch záťaže (dlhé agregácie, bodové dotazy, zápisy, miesto na disku), s mediánom a p95, bez čísel vytrhnutých z kontextu.
  • Odporúčanie: čo, pre ktorú časť systému a prečo.
  • Náklady a riziká: licencia, upgrady, potrebné znalosti, závislosť od dodávateľa.
  • Čo sme nemerali a kde je príloha so skriptmi a nespracovanými výsledkami.

Test musí bežať na vašich dátach a vašich dotazoch, inak meriate niečo iné než svoj systém. Musí byť zopakovateľný, aby ho mohla overiť druhá strana. Jeho výsledkom navyše nemusí byť jeden víťaz. V našom prípade bolo najlepšou odpoveďou rozdeliť systém podľa typu záťaže. Rýchlosť je v takom rozhodnutí len jeden z argumentov, ďalšími sú licencia, upgrady a ľudia, ktorí budú systém prevádzkovať.