Database keuze voor sensor data

[incaz]

_Erikje_ schreef op dinsdag 1 augustus 2017 @ 11:04:
Waarom zo'n hoge meetfrequentie? Elke 15s lijkt mij nogal onnodig vaak, 1 keer per minuut (of elke 5 minuten) lijkt mij voldoende

Wat je hebt kun je altijd nog weggooien. Wat je niet opslaat kun je nooit meer terughalen.

[CurlyMo]

incaz schreef op dinsdag 1 augustus 2017 @ 14:19:
[...]
Wat je hebt kun je altijd nog weggooien. Wat je niet opslaat kun je nooit meer terughalen.

incaz schreef op maandag 31 juli 2017 @ 20:25:
[...]
Ik zou dit niet doen bij het wegschrijven, maar bij het aggregeren. Eerst de data zo simpel mogelijk wegschrijven (geeft ook zo min mogelijk kans op fouten), en dan pas daarna naar de aggregatie kijken.

Dit is een beetje dezelfde discussie als je vaak ziet bij GPIO implementaties. Je kan 100x per minuut kijken wat de status van een GPIO is of dit via interrupts uitlezen.

Pollen:

code:

1 | 0:00:00.001
1 | 0:00:00.002
1 | 0:00:00.003
1 | 0:00:00.004
...
1 | 0:00:00.099
0 | 0:00:00.100

Interrupts:

code:

1 | 0:00:00.001
0 | 0:00:00.100

Je verliest op de tweede manier 0 informatie, maar slaat het geheel wel efficienter op.

[incaz]

CurlyMo schreef op dinsdag 1 augustus 2017 @ 14:43:
[...]

Dit is een beetje dezelfde discussie als je vaak ziet bij GPIO implementaties. Je kan 100x per minuut kijken wat de status van een GPIO is of dit via interrupts uitlezen.

Dat kan, maar ten eerste is dit een hobbyproject, waarin ik eenvoud en kleine kans op fouten zo laag mogelijk zou houden, keep it simple, en dat is dus gewoon wegschrijven. Het bedenken en uitwerken van code die vergelijkt met de vorige meting is toch net wat ingewikkelder, niet moeilijk maar wel net een paar dingen meer die mis kunnen gaan, en foutdetectie is ook lastiger. Als je een timeseries hebt die iedere 15 seconden registreert dan zie je heel snel als er geen data geregistreerd is, en dan weet je dat er iets mis is. Als je alleen kijkt naar verandering kun je achteraf niet zien of een groot gat in je data een gevolg is van een storing of dat de temperatuur niet veranderde.
Ja, dat kun je testen, en het is best leuk denk ik, maar je moet er meer aandacht aan besteden.

En ten tweede reageerde ik (zeker bij mijn laatste reactie) rechtstreeks op iemand die de meetfrequentie op zich omlaag wilde halen. En dat zou ik dus niet doen als je nog niet echt een gevoel hebt voor wat je wilt meten.

[Hydra]

incaz schreef op dinsdag 1 augustus 2017 @ 14:19:
Wat je hebt kun je altijd nog weggooien. Wat je niet opslaat kun je nooit meer terughalen.

Precies. Na aggregatie kan 'ie prima de brondata in ZIP files aggregeren. Een CSV export van dit soort data comprimeert extreem goed. Moeilijk doen over de hoeveelheid data in dit stadium is complete energieverspilling.

[Morrar]

CurlyMo schreef op dinsdag 1 augustus 2017 @ 14:43:
Interrupts:

code:

1 | 0:00:00.001
0 | 0:00:00.100

Je verliest op de tweede manier 0 informatie, maar slaat het geheel wel efficienter op.

Qua opslag inderdaad veel efficiënter, maar ook veel lastiger om de tijdreeks te reconstrueren. Dus je code voor bijvoorbeeld plots, periodieke aggregaten of statistieken wordt een stuk complexer en minder efficiënt.

In dit geval - met deze geringe hoeveelheid metingen - zou ik dan liever voor inefficiënte opslag kiezen en efficiënte code.

Mijn advies aan TS zou zijn om het met MariaDB te doen, omdat het prima draait op Synology en dit voorlopig makkelijk moet voldoen. Tenzij TS het natuurlijk leuk lijkt om een ander systeem (zoals InfluxDB) te leren kennen. Maar dan kan TS zelf het beste bepalen welk systeem hem het meest interessant lijkt.

[ Voor 20% gewijzigd door Morrar op 01-08-2017 23:26 ]