Forum

Forum

Monitorovanie loxon...
 
Notifications
Clear all

Monitorovanie loxone pomocou grafana

228 Posts
31 Users
27 Reactions
42.3 K Views
msk
 msk
(@dusanmsk)
Member
Joined: 10 years ago
Posts: 1952
Topic starter  

Len si tu tak ublognem co som robil posledny tyzden, nech to nemusi skusat niekto dalsi. Ako mnohi mam loxone+influx+grafanu. Dlhodobo mi vadi, ze v influxe neviem niektore veci rozumne agregovat, vydolovat. Ucit sa Flux odmietam, to je nieco priserne a tak som chcel skusit nejake time db ktore maju sql jazyk, kde som viac doma.

TL;DR - zostal som na influxe

Najprv som skusil timescaledb pomocou vlastneho migracneho scriptu. Schemu som navrhol primitivnu - vsetko v jednej tabulke. Konkretne (timestamp, measurement_name, value_name, value). Napr. (XXXX, exterier_teplota, value, 4.12). Tu sa ukazal 'drobny' problem v tom, ze v influxe mam cca 900 measurementov, ktore sa narvali do jednej gigantickej tabule. Zralo to nasobky miesta na disku (influx 9GB, timescale som pri 50 zabil a nebol som ani v polovici migracie). Hm. Co s tym. Napadlo ma, ze sa tam dookola opakuju nazvy measurementov, ktore budu zbytocne zaberat miesto na disku. Tak som spravil slovnikovu foreign table a odkazoval sa do nej 2 bajtami (shortint). Nepomohlo. Furt vela. Skusim som komprimovat historicke data, pomohlo dost, ale furt som bol na nasobkoch.

Skusil som aj ofiko nastroj (outflux), ten mi zas vyrobil 900 tabuliek. Tadeto tiez cesta nevedie.

Ok, timescale teda nie, skusil som QuestDB. Vyhodu ma, ze vie byt schemaless, skusil som ju nakrmit, slo to rychlo, ale takisto - problem s miestom, kedy zaberala 10x tolko. Rychlost bola u nej ale bleskurychla. Naimportoval som X gigabajtove csv a hned na nom robil bleskurychle selecty.

Resume - po tyzdni laborovania hlasim fail a zostavam na influxe. Este sa mi v hlave rodi napad, ze by som do timescale migroval len measurementy u ktorych chcem sofistikovanejsi dotazovaci jazyk a zvysok nechal v influxe, ale asi na to hodim bobek.

Koniec hlasenia, influx je z pohladu storage zjavne velmi dobre navrhnuta databaza.



   
L reacted
ReplyQuote
skybor
(@skybor)
Trusted Member
Joined: 6 years ago
Posts: 77
 

Díky za info.

Je fakt, že influxdb má asi hodně úsporný způsob zápisu dat. To jsem poznal při nedávném přenosu dat z Rpi na slušnější HW. Taky trochu bojuju se zpracováním toho všeho co do influxdb zapisuju.

Ale naštěstí influxdb nepodporuje jen ten šílený Flux, ale i InfluxQL a tam už je ten zápis dotazů přece jen trochu lidštější 🙂 Tak možná ...

 

https://docs.influxdata.com/influxdb/v1/flux/flux-vs-influxql/

https://docs.influxdata.com/influxdb/v1/query_language/explore-data/

 


This post was modified 2 years ago by skybor

   
ReplyQuote
msk
 msk
(@dusanmsk)
Member
Joined: 10 years ago
Posts: 1952
Topic starter  

InfluxQL pouzivam 7 rokov, ale uz mi nestaci. Kazdopadne som sa trosku ponoril do tajov QuestDB a zacinam mat pocit, ze by stalo za to to skusit.

V influxe vsetci bojuju a nikto nevyhral nad zapasom "mam 2 measurementy, oba meriam zhruba v rovnaky cas, potrebujem spravit nad nimi join". V influxe podla mna nemozne. V QuestDB je to o 4 pismenkach - "ASOF".

select
v_dome.time as timestamp, v_dome.value as interier, vonku.value as exterier
from central_teplota_priemerna_teplota_v_dome v_dome
asof join central_teplota_vonkajsia_teplota vonku

Voala, 100 ms a mam join vonkajsej a vnutornej teploty (ktore sa meraju nezavislo na sebe v roznych intervaloch).

 

https://questdb.io/docs/reference/sql/asof-join/

Pokial by to niekto chcel skusit, tak QuestDB ma v sebe priamo listener na influx line protocol, takze ide zamenit jedno za druhe. A pokial by chcel niekto migrovat stare data, tak migracny script mam tiez. Ja budem teraz chvilu prevadzkovat paralelne vedla seba asi obe databazy a uvidim.



   
ReplyQuote
Page 16 / 16
Share: