Vlákno názorů k článku Home Assistant: ovládáme interní data a vizualizujeme od Martin Vancl - Ma nejake vyhody pouzivat InfluxDB oproti TimescaleDB? Co koukam,...

Ma nejake vyhody pouzivat InfluxDB oproti TimescaleDB?

Co koukam, tak vsechny navody pouzivaji InfluxDB. Pritom TimescaleDB je take db pro time series data a osobne se mi s ni lepe pracuje.

Klasicke relacni db, jako MySQL ted neresim. Jde mi ciste o InfluxDB vs TimescaleDB.

TimescaleDB je nadstavba nad PostgreSQL se všemi klady i zápory z tohoto faktu plynoucími... (a rozpadlých (rozuměj neopravitelných) velkých databází využivající TimescaleDB je na Internetu docela požehnaných story, děkuji radši buď čisté PgSQL (zde bych se nasazení vůbec nebál pro odpovídající data) nebo nativní timeseries DB)

Osobně jsem velice zvědavý na InfluxDB v3.0 Edge přepsanou do Rustu...:-) (jen mne nakrkli s odložením k ledu Flux-u, takové derivate přes celou timeserie s ohledem na window step je lahůdka - ne že by to v SQL nešlo, ale ten zápis je čistě pro masochisty, asi stárnu...)

Osobně razím tezi, že nástroj by se měl používat na to k čemu byl určen - a tedy v čem by měl excelovat a nedělat otvírák na ohýbák... a proto mám-li jednoznačná timeseries data, proč je cpát do relačního modelu?

Jen poznámka k tomu vámi několikrát použitému " otvírák na ohýbák "
To nedává smysl - používá se " rovnák na ohybák " ( nebo lidověji " vohejbák " )...
A ano, celé to ZigBee to mqtt je přesně tohle.

"A ano, celé to ZigBee to mqtt je přesně tohle." - v tom případě ovšem rozporujete základní paradigmata IoT a IIoT, což spolu tady nepochybně nevyřešíme...:-)

no, influxdb je menej narocna jak na spravu, tak na pouzitie. Proste vhodna na male nizkorozpoctove projekty, ktore nedokazu riadne zaplatit cloveka. Niekde kde nevadi, ze pre vecsie mnozstvo zariadeni a vecsie mnozstvo metrik, je influx niekde na tretine az desatine vykonu oproti timescale...

Diky. Neco potrebneho jsem potreboval vedet.
Ja si prave stavim ovladani celeho domu (takze ne jen par zigbee zarovek) a rad bych vybral dobrou databazi, na kterou pak roky nebudu muset sahnout. Pokud je opravdu vykon InfluxDB o tolik mensi, zni to jako velky problem.

Rad bych uchovaval data idealne na porad :-)
Bylo by zajimave po 20 letech moct delat ruzne statistiky.
Co se tyka velikosti ulozenych dat, tak ta me tolik netrapi. 1TB SSD dnes stoji par drobnych...

Opravdu by me zajimalo, proc by se mela (a jaka je sance) TimescaleDB rozbit. Pouzivam jich vetsi mnozstvi na produkcnich serverech (ty nesouvisi s domaci automatizaci) a zatim jsem nikdy nemel problem. Mozna mam jen stesti?

Byl by k tomuto tvrzení o třetinové rychosti InfluxDB nějaký regulérní benchmark? Moje vlastní zkušenosti totiž hovoří pro zcela jinou aproximaci - jak co se týče spotřebovaného místa na disku, tak při vizualizaci (= queries)... (a opravdu se nebavím zrovna o home projektíku na Malině a podobně koncipovaném HW)

oni někde asi nějaká čísla budou. Z velkého nasazení má influxdb značné problémy při hodně zapisujících streamech s vysokou kardinalitou metrik najednou, tam výkon padá i o řád proti timescaledb, řešit se to dá předagregátorem a bulkováním zápisu. Influx má prostě drahé inserty a kompakce.

Influxdb je pak o hodně (nemám v ruce čísla) pomalejší při agregování na více než jednu dimenzi (klasicky něco group by time, room, device), jde to vidět o na spotřebě paměti a iops. To vlastně platí pro jakékoliv komplexnější dotazy než prostý select s jednou dimenzí, tam timescaledb vládne.

Hlídání thresholdů (pro alerty) má zase influx výrazně rychlejší a poskytuje stabilnější latency.

Jen doplním, že mluvím o nasazení pro metriky na infrastrukturu (sítě, servery, aplikace) v počtem atributů v desítkách tisíc.