TimescaleDB vs. InfluxDB vs. ClickHouse: výběr databáze pro time-series data

Pro Netigo jsme stavěli NetFlow Manager, který v reálném čase přijímá a analyzuje síťový provoz z IPFIX/NetFlow senzorů —peaky v řádech GB/s. Výběr databáze byl kritický. Špatná volba = systém padá pod zátěží nebo stojí 5× víc.

Srovnávali jsme tři kandidáty: TimescaleDB, InfluxDB, ClickHouse. Tady je, co jsme zvážili, a proč jsme vybrali TimescaleDB.

Workload, pro který jsme vybírali

• Write-heavy: 500 000 — 2 000 000 rows/s ingestion
• Rows typicky 100-200 bytes (kompaktní event)
• Retention 90 dní hot, 2 roky cold
• Query patterny: aggregace nad časovými okny (sum bytes per src_ip per hour last 24h), top-N dotazy (top 100 flows by volume)
• Dotazuje API backend, dashboardy, alerting systém

TimescaleDB — Postgres extension

Výhody:

• Je to Postgres. Všichni ho znají, tooling existuje, integrace s backendem je triviální.
• SQL — bez nového dotazovacího jazyka.
• Hyperpartitioning (hypertable) a native compression — tabulka se dělí podle času automaticky, starší chunky se komprimují 10-20× méně místa.
• Continuous aggregates — pre-spočítané hodinové/denní roll-up tabulky aktualizované automaticky.
• JOINs s běžnými tabulkami (user, config, device metadata) bez tanců — to je u TSDB výjimka.

Nevýhody:

• Write throughput nižší než ClickHouse. My jsme na našem hardware (32 core, NVMe SSD) naměřili ~400k inserts/s v single-node. Pro 2M/s bychom potřebovali cluster.
• Licenční model — open-source Apache 2.0 core, některé enterprise features (multi-node, advanced compression) jsou placené.
• Disk usage před compression větší než ClickHouse o ~30-50 %.

InfluxDB — time-series purist

Výhody:

• Designované čistě pro time-series. Benchmarks na syntetických workloadech dobré.
• Retention policies a downsampling out-of-the-box.
• Menší disk footprint než Postgres/TimescaleDB.

Nevýhody:

• Flux query language (v InfluxDB 2.x) — další jazyk, další křivka učení, méně lidí to umí. V 3.x se vracejí k SQL přes IOx backend, ale ekosystém je turbulentní.
• Žádný JOIN s relačními daty. Pokud chceš aggregovat flows podle device metadata (které jsou v Postgresu), musíš to dělat v aplikaci.
• V naší interní zátěžové zkoušce jsme narazili na problém s cardinality explosion — unikátních `src_ip × dst_ip` párů je při GB/s provozu miliony, InfluxDB začal zpomalovat.
• Historicky turbulentní: major verze 1 → 2 → 3 měnily storage engine i dotazovací jazyk. Bet na dlouhodobou stabilitu neposkytoval nikdo.

ClickHouse — čisté throughput monstrum

Výhody:

• Nejvyšší write throughput. Na stejném hardware jsme naměřili 1,8M inserts/s — skoro 5× TimescaleDB.
• Kolumnární storage, agresivní komprese, nejmenší disk footprint (30-40 % TimescaleDB).
• SQL-ish jazyk (CH má vlastní dialekt, ale velmi podobný standardnímu SQL).
• Vynikající pro OLAP — top-N, aggregations, rollups.

Nevýhody:

• Slabé update/delete operace. ClickHouse je čistě append-optimized. Mazání a update jsou nákladné a asynchronní. Pro GDPR deletes nevhodné.
• Eventual consistency při replikaci. Pro některé use cases (audit trail) to nevyhovuje.
• Operations complexity — ZooKeeper/Keeper coordination, sharding strategy, merge tree tuning. Vyžaduje dedikovaného devops.
• Ekosystém menší než Postgres. Některé nástroje (např. Liquibase schema migrations) ho neznají.

Rozhodovací matice

Pro Netigo jsme scorovali na 5 dimenzích:

• Write throughput: CH > TS > Influx. CH vyhrává o ~5×.
• Query expressivness: TS > CH > Influx. TS SQL s JOINs proti metadata tabulkám vyhrál.
• Operations: TS > Influx > CH. TS je „jen Postgres“.
• Team expertise: TS vysoko. Celý tým zná Postgres.
• Long-term risk: TS > CH > Influx. Postgres ekosystém je nejstabilnější.

Pro naše konkrétní čísla (500k-2M rows/s write, potřeba JOINs, tým bez dedicated DBA) vyšla TimescaleDB jako optimum. CH by šetřil hardware, ale ops overhead by to zrušil.

Kdy byste vybrali jinak

ClickHouse vyber, pokud:

• Write throughput > 3M/s na single node je požadavek
• Máš dedicated platform team nebo zkušené DBA
• Nepotřebuješ JOINs s transakčními daty (analytics-only workload)
• GDPR-style deletes nebo frequent updates nejsou use case

InfluxDB vyber, pokud:

• Čistě IoT/observability use case s nízkou cardinality
• Tým tolerujue Flux nebo čeká na stabilitu 3.x
• Potřebuješ out-of-the-box downsampling bez custom kódu

Výsledek pro Netigo po 10 měsících

• TimescaleDB, single-node (zatím), 64 core, 1TB NVMe
• Průměrný write throughput 650k rows/s
• P99 query latency na top-100 dotazy: 180 ms
• Compression ratio na 7-denních chunks: 12×
• Disk storage: 2,3 TB pro 90 dní hot data
• Scaling plán: přechod na TimescaleDB multi-node až při > 1,5M/s (aktuálně máme rezervu 2,3×)

Co si z toho vzít

Volba TSDB není o „nejrychlejší wins“. Je to o tom, jak dobře zapadá do tvého celkového stacku, týmového know-how a operačních možností. Pro 80 % projektů, které řeší time-series data, je TimescaleDB pragmatic default — pokud nemáš explicitní důvod jít jinam. ClickHouse je silnější pro OLAP warehouse; InfluxDB pro IoT s nízkou cardinality.

Nejdůležitější rada: měř svůj reálný workload. Benchmarks na syntetických datech neřeknou nic. Nasetupuj prototyp, vystrč mu 10 % očekávaného provozu a pozoruj, co se děje.