Database keuze voor sensor data

[jeroenk13]

Poging 2 - Gelieve niet de topic weer platbombarderen en gelocked laten worden binnen 24uur voordat ik kan reageren Ik waardeer jullie inzet maar het werd wel iets te enthousiast

OT: Databasekeuze sensordata

Originele vraag (Updated versie eronder)

Ik ben een klein projectje begonnen waarbij ik iedere 15 seconde 2 temperatuur sensoren uitlees dmv. een Arduino.

Ik ben nu op het punt aangekomen om de data op te gaan slaan in een database zodat er een frontend gemaakt kan worden.

Welke database zou het beste bij dit type data passen?

Gewoon MySQL of is wellicht MongoDB beter? De database zal lopen op een Synology NAS.

Ik denk eraan om 2 tables te maken, 1tje voor sensor 1 en 1tje voor sensor 2.
Per table heb je alleen het tijdstip en de temperatuur waarde.

Per dag worden er ~11500 entries aan de database toegevoegd. (Iedere 15s 2sensoren => 8per min => 480 per uur => 11520 per dag)


Uiteindelijk word de data uitgelezen en een grafiek gemaakt dmv van Highcharts oid.

Updated:

De sensoren zijn niet aan elkaar gelinkt, en zijn voor bijv. de binnen en buitentemperatuur. Ze nemen allebei een waarde op, en geven dat iedere x seconden door.
Ik heb wel wat ervaring met MySQL, alleen niet met grote datasets, maar vandaar dat in eerste instantie mijn voorkeur daar naar uit ging. Ik sta zeker open voor andere (betere) opties.

Ik heb al wat aanbevelingen gezien voor verschillende DB's, o.a:

Compizfox schreef op dinsdag 25 juli 2017 @ 23:21:
[...]

Geen van beide. Neem een DBMS die bedoeld is voor time series data, zoals InfluxDB of Graphite.

Daarna werd gereageerd met: "Maar de eis was toch dat het draaien moet op een Synology"

Klopt deels. Ik had dat in gedachten omdat ik hem heb staan, en niet bijv. een server/pc 24/7 erbij wilde zetten. Een optie voor een Rb. PI is eventueel ook een optie, alleen heb ik daar weinig ervaring mee, vandaar dat ik voor de vertrouwde weg koos.


Hetzelfde voor dit:

Creepy schreef op woensdag 26 juli 2017 @ 11:39:
Dus voor elke nieuwe sensor een nieuwe tabel aanmaken? Sorry, maar dan heb je het echt niet begrepen. Dat kan de TS wel willen in eerste instantie, maar dat klopt gewoon niet. Ik denk dat jeroenk13 dat nu wel inziet.

Mijn gedachte hierbij ging uit naar overzichtelijkheid met de eventuele optie voor het bijprikken van een 3de sensor. Maar dit kan dus anders.


En ook werd er bijvoorbeeld CSV voorgesteld:

Merethil schreef op woensdag 26 juli 2017 @ 12:12:
[...]


Lees even goed wat ik voorstel. Ik stelde dit voor:

code:

sensors

id    name
1    sensor_1
2    sensor_2

code:

sensor_data_type

id    name
1    temperature
2    height
3    air_density
4    door_open

code:

measurements

id    sensor_id    timestamp    value    data_type
1    1              12570127     "12.3"   1
2    1              12575126     "312"    2
3    2              12575127     "12.8"   1
4    2              12575127     "true"    4

Dit is nagenoeg letterlijk EAV zoals beschreven hier: Wikipedia: Entity–attribute–value model


[...]


Dan is een binair bestand prima imo, geef ik je groot gelijk in!

Hierbij zit ik dus met de vraag hoe het op de lange termijn gaat. Volgensmij is een CSV bestand totaal niet geschikt voor de hoeveelheid data over de jaren heen.


Als laatste vraag heb ik nog: Hoe gaat InfluxDB om met grote datasets tov. bijvoorbeeld MySQL?
En wat is de performance als je de data van 2 sensoren in 1 table gooit, of in 2 aparte tables ?

[gekkie]

Nog een vraag, heb je al nagedacht over eventuele aggregatie van je data:
Wil je tot in de lengte van dagen nog de exacte metingen kunnen blijven inzien ?
Of is het afdoende als het zeg na een week of een maand met een resolutie van bijvb een gemiddelde (en/of min en max) waarden per 5 minuten of een kwartier of andere interval beschikbaar is ?

Voordeel is dat het dus nogal in storage scheelt (en de size er van vast ligt), nadeel kan dus zijn dat je na verloop van tijd alleen nog maar geaggregeerde waarden hebt wat je niet wilt.

Als je dat vooraf in kunt schatten en kunt leven met geaggregeerde data dan het door iemand anders geopperde RRD ook nog een aardige kandidaat zijn. Tevens moet je er dan niets anders mee willen dan grafiekjes er van plotten.

Vroeger, toen storage nog echt schaars was werd het veel gebruikt voor bijvb server monitoring (cacti).

[ Voor 13% gewijzigd door gekkie op 26-07-2017 22:58 ]

[jeroenk13]

gekkie schreef op woensdag 26 juli 2017 @ 22:55:
Nog een vraag, heb je al nagedacht over eventuele aggregatie van je data:
Wil je tot in de lengte van dagen nog de exacte metingen kunnen blijven inzien ?
Of is het afdoende als het zeg na een week of een maand met een resolutie van bijvb een gemiddelde (en/of min en max) waarden per 5 minuten of een kwartier of andere interval beschikbaar is ?

Voordeel is dat het dus nogal in storage scheelt (en de size er van vast ligt), nadeel kan dus zijn dat je na verloop van tijd alleen nog maar geaggregeerde waarden hebt wat je niet wilt.

Als je dat vooraf in kunt schatten en kunt leven met geaggregeerde data dan het door iemand anders geopperde RRD ook nog een aardige kandidaat zijn. Tevens moet je er dan niets anders mee willen dan grafiekjes er van plotten.

Vroeger, toen storage nog echt schaars was werd het veel gebruikt voor bijvb server monitoring (cacti).

Goede vraag!

In principe is het alleen 'nodig' om voor bijvoorbeeld de recentste 7 dagen alle meting te bewaren, en alles daarna bijvoorbeeld iedere 20ste meting (4 metingen per min - 20 per 5min) te bewaren en de metingen ertussen te verwijderen.


edit:
Is het bijvoorbeeld ook een optie om per maand een nieuwe table aan te maken ? Of is dat onhandig / niet prestatiebevorderend ivm meerdere queries naar de tables als je wat globalere data wilt weergeven ?

[ Voor 8% gewijzigd door jeroenk13 op 26-07-2017 23:20 ]

[Compizfox]

Over InfluxDB: draait dat niet op een Synology NAS dan? Ik dacht dat dat gewoon Linux was? Of is de processing power het probleem hier?

Als laatste vraag heb ik nog: Hoe gaat InfluxDB om met grote datasets tov. bijvoorbeeld MySQL?
En wat is de performance als je de data van 2 sensoren in 1 table gooit, of in 2 aparte tables ?

Dat valt hier allemaal te lezen: https://www.influxdata.com/time-series-database/

Voor relatief kleinschalige datasets zullen de performanceverschillen niet heel wonderbaarlijk zijn, maar software als InfluxDB heeft wel handige features die afgestemd zijn voor time series databases. Dan moet je vooral denken aan mogelijkheden om gemakkelijk en snel je data te kunnen filteren/groupen/averagen/integreren.

jeroenk13 schreef op woensdag 26 juli 2017 @ 23:05:
[...]
Goede vraag!

In principe is het alleen 'nodig' om voor bijvoorbeeld de recentste 7 dagen alle meting te bewaren, en alles daarna bijvoorbeeld iedere 20ste meting (4 metingen per min - 20 per 5min) te bewaren en de metingen ertussen te verwijderen.

Voor dit soort dingen heeft InfluxDB dus hele mooie ingebouwde functies (namelijk "continuous queries" en "retention policies"). Daarmee kun je automatisch je data downsamplen/aggregaten en aangeven voor hoe lang de raw en aggregated data moet worden bewaard.

In jouw geval kun je dus instellen dat de 'raw' data 7 dagen wordt bewaard (dat is de retention policy). Je stelt dan ook een continuous query in die elke 20 metingen middelt (middelen is beter dan weggooien) en dat voor altijd bewaart.

Hoe dat moet wordt ook duidelijk beschreven in een tutorial: https://docs.influxdata.c...wnsampling_and_retention/

jeroenk13 schreef op woensdag 26 juli 2017 @ 23:05:
edit:
Is het bijvoorbeeld ook een optie om per maand een nieuwe table aan te maken ? Of is dat onhandig / niet prestatiebevorderend ivm meerdere queries naar de tables als je wat globalere data wilt weergeven ?

Hoe het zit met performance weet ik zo niet maar ik kan je wel vertellen dat dat tegen alle principes van database design ingaat.

[ Voor 36% gewijzigd door Compizfox op 26-07-2017 23:34 ]

[pedorus]

jeroenk13 schreef op woensdag 26 juli 2017 @ 22:44:
Ik heb wel wat ervaring met MySQL, alleen niet met grote datasets, maar vandaar dat in eerste instantie mijn voorkeur daar naar uit ging. Ik sta zeker open voor andere (betere) opties.

Wat let je om het uit te proberen?

mysql> create table measurements (time datetime, sensorId int, value double, primary key(time, sensorId));

done

Of wacht, het kan nog simpeler:

mysql> create table measurements (time datetime primary key, insideTemperature double, outsideTemperature double);

We kunnen altijd nog over naar dat andere design als we n sensors krijgen.

Hierbij zit ik dus met de vraag hoe het op de lange termijn gaat. Volgensmij is een CSV bestand totaal niet geschikt voor de hoeveelheid data over de jaren heen.

Waarom niet? Een bedrijf als Google gebruikt gzip csv voor het uitwisselen van miljarden aan impressies per dag, maar het is niet geschikt voor 2 sensortjes? Als je een gzip csv zou maken (per dag) kan dat heeeel lang aan.

En wat is de performance als je de data van 2 sensoren in 1 table gooit, of in 2 aparte tables ?

Weinig verschil, maar het is een stukje makkelijker om een group by te doen dan een union. Desnoods zou je partitions kunnen gebruiken die effectief meerdere tabellen maken van 1 tabel. Maar zou eerst eens kijken of je daar ooit op komt. Gok dat dat minstens een jaar duurt, tegen die tijd kun je een partitie per jaar maken of erachter komen dat je het project niet meer interessant vindt. Of gewoon de data aggregeren en weggooien, enz.

Je bent trouwens het belangrijkste vergeten denk ik: Wat wil je met de data gaan doen en wat is het doel van het project? Meestal is het handig om een beetje naar dat doel toe te werken. Wil je iets streaming gaan doen, dan is mysql niet zo handig bijvoorbeeld. Zoek je wat Graphite al biedt, dan is het, heel gek, vast handig om Graphite te gebruiken.. InfluxDB of Prometheus is speciaal voor dit soort data gemaakt, maar het is de vraag of je daarin verdiepen perse nodig is.

[Merethil]

jeroenk13 schreef op woensdag 26 juli 2017 @ 22:44:
Poging 2 - Gelieve niet de topic weer platbombarderen en gelocked laten worden binnen 24uur voordat ik kan reageren Ik waardeer jullie inzet maar het werd wel iets te enthousiast

OT: Databasekeuze sensordata

Originele vraag (Updated versie eronder)


[...]


Updated:

De sensoren zijn niet aan elkaar gelinkt, en zijn voor bijv. de binnen en buitentemperatuur. Ze nemen allebei een waarde op, en geven dat iedere x seconden door.
Ik heb wel wat ervaring met MySQL, alleen niet met grote datasets, maar vandaar dat in eerste instantie mijn voorkeur daar naar uit ging. Ik sta zeker open voor andere (betere) opties.

Ik heb al wat aanbevelingen gezien voor verschillende DB's, o.a:


[...]


Daarna werd gereageerd met: "Maar de eis was toch dat het draaien moet op een Synology"

Klopt deels. Ik had dat in gedachten omdat ik hem heb staan, en niet bijv. een server/pc 24/7 erbij wilde zetten. Een optie voor een Rb. PI is eventueel ook een optie, alleen heb ik daar weinig ervaring mee, vandaar dat ik voor de vertrouwde weg koos.


Hetzelfde voor dit:

[...]


Mijn gedachte hierbij ging uit naar overzichtelijkheid met de eventuele optie voor het bijprikken van een 3de sensor. Maar dit kan dus anders.


En ook werd er bijvoorbeeld CSV voorgesteld:


[...]


Hierbij zit ik dus met de vraag hoe het op de lange termijn gaat. Volgensmij is een CSV bestand totaal niet geschikt voor de hoeveelheid data over de jaren heen.


Als laatste vraag heb ik nog: Hoe gaat InfluxDB om met grote datasets tov. bijvoorbeeld MySQL?
En wat is de performance als je de data van 2 sensoren in 1 table gooit, of in 2 aparte tables ?

Mijn voorstel was een databasedesign, niet een CSV

Maar ik zou het vooral simpel houden, mijn oplossing ontstond uit een verzande discussie over "wat als een sensor meerdere metingen kan doen en we een infinite amount of sensors willen toevoegen zonder de DB/code hoeven aan te passen"

Hoe dan ook: succes! Een CSV kan ook prima trouwens, is alleen minder snel met zoeken ivm optimalisaties die je zelf zou moeten doen ipv de DB engine het laten afhandelen.

[farlane]

Nogmaals, SQLite is wmb ruimschoots te prefereren boven een csv bestand, alles wat je aan structuur wilt bovenop een flat-file achtig iets als csv gaat SQLite je helpen.

[Cloud]

Aangezien je de data er vast ook weer eenvoudig uit wilt halen en ongetwijfeld zult willen filteren/groeperen, zou ik geen CSV aanraden tenzij je heel wat wielen zelf uit wil vinden (of een library wil vinden die het kan).

Ik zou een database aanraden zoals MySQL/PostgreSQL of een time series database. Maar qua schaalgrootte is dit echt geen probleem hoor. Ik heb een MySQL database draaien die alle output van mijn slimme meter opvangt en dat is één meting per seconde 24/7. Staan inmiddels al 11 miljoen metingen in en geen centje pijn hoor Zeker als je gaat kijken naar het indikken van je data naarmate het ouder wordt, zullen met zo weinig sensoren/input, eigenlijk alle databases wel voldoen.

SQLite kan ook maar is afhankelijk van de omstandigheden iets lastiger in gebruik; bijvoorbeeld als je metingen niet daadwerkelijk op de Synology zelf gedaan worden maar op een ander apparaat, of juist als je de data in wilt zien vanuit de DB maar niet op de Synology zelf. En je zit een beetje met concurrency wellicht, maar goed het kán wel

[farlane]

Cloud schreef op donderdag 27 juli 2017 @ 09:26:
SQLite kan ook maar is afhankelijk van de omstandigheden iets lastiger in gebruik; bijvoorbeeld als je metingen niet daadwerkelijk op de Synology zelf gedaan worden maar op een ander apparaat, of juist als je de data in wilt zien vanuit de DB maar niet op de Synology zelf. En je zit een beetje met concurrency wellicht, maar goed het kán wel

Die problemen heb je bij CSV ook allemaal, maar dan nog meer. Vandaar dat het wmb verreweg te prefereren is boven CSV, maar niet perse boven een database server.

[gekkie]

jeroenk13 schreef op woensdag 26 juli 2017 @ 23:05:
[...]
Goede vraag!

In principe is het alleen 'nodig' om voor bijvoorbeeld de recentste 7 dagen alle meting te bewaren, en alles daarna bijvoorbeeld iedere 20ste meting (4 metingen per min - 20 per 5min) te bewaren en de metingen ertussen te verwijderen.

Uiteraard kan aggregatie met een timeseries of sql database ook, maar dan moet je het zelf verzorgen.
Bij RRD is het een vereiste om het te definieren bij het aanmaken van de database en gaat dat vervolgens dus automagisch. Let wel dat je tevens een limiet moet opgeven waarna data definitief weggegooid gaat worden.

Het is overigens een vorm van wat in het vorige topic werd genoemd als "binair bestand", alleen is de uitvoering in deze wel slim (voor zijn niche functie).

Het zit dus wel heel anders in elkaar als een RDBMS, dus als je subdoel is om ook een beetje met een relationele database te spelen dan mis je dat doel wel weer.
Voor wat meer info over RRD: http://oss.oetiker.ch/rrdtool

edit:
Is het bijvoorbeeld ook een optie om per maand een nieuwe table aan te maken ? Of is dat onhandig / niet prestatiebevorderend ivm meerdere queries naar de tables als je wat globalere data wilt weergeven ?

Is met SQL databases wel mogelijk middels "partitioning" geen idee of mysql het kan, postgres wel middels een extension en in de komende versie (postgres 10) komen er de nodige verbeteringen voor.

[ Voor 25% gewijzigd door gekkie op 27-07-2017 10:41 ]

[Cloud]

farlane schreef op donderdag 27 juli 2017 @ 10:14:
[...]


Die problemen heb je bij CSV ook allemaal, maar dan nog meer. Vandaar dat het wmb verreweg te prefereren is boven CSV, maar niet perse boven een database server.

Absoluut Ik wilde slechts aangeven dat SQLite nadelen zal hebben t.o.v. een database als MySQL/PostgreSQL, afhankelijk van de situatie. CSV zou ik gewoon afraden eigenlijk, niet alleen vanwege de eventuele problemen met de hoeveelheid data zoals TS zegt.

[hellfighter87]

Ik heb een tijdje een uptime monitor gehad die 10 sites bijhield en elke minuut een schop tegen die site deed vanaf 3 locaties, dus 60 / (10 * 3) is om de 2 seconden een record in de database.
Dit heb ik met mysql gedaan op een synology (ds412+) en dat ging prima.

Dat beetje sensor data daar moet elke database mee om kunnen gaan anders is het de naam database niet waardig. die 11520 records per dag is peanuts we praten wel weer als we het over miljoenen/miljarden rows hebben

Ik zou persoonlijk niet gaan aanklooien met CSV omdat je daar minder handig queries over heen kan halen en SQLite ben ik zelf een beetje huiverig voor (database corruptie....)

Ik heb 1 simpele regel, performance problemen (tenzij je zeker weet dat je ze tegen komt in een vrij korte tijdsduur) los je op tegen de tijd dat je er tegen aan loopt, dus of je nou 1 of 2 tabellen gebruikt => doe lekker wat handig is en als dat problemen oplevert refactor je het op dat moment.

Niet teveel bezig houden met overengineering

[Merethil]

hellfighter87 schreef op donderdag 27 juli 2017 @ 13:41:
Ik heb een tijdje een uptime monitor gehad die 10 sites bijhield en elke minuut een schop tegen die site deed vanaf 3 locaties, dus 60 / (10 * 3) is om de 2 seconden een record in de database.
Dit heb ik met mysql gedaan op een synology (ds412+) en dat ging prima.

Dat beetje sensor data daar moet elke database mee om kunnen gaan anders is het de naam database niet waardig. die 11520 records per dag is peanuts we praten wel weer als we het over miljoenen/miljarden rows hebben

Ik zou persoonlijk niet gaan aanklooien met CSV omdat je daar minder handig queries over heen kan halen en SQLite ben ik zelf een beetje huiverig voor (database corruptie....)

Ik heb 1 simpele regel, performance problemen (tenzij je zeker weet dat je ze tegen komt in een vrij korte tijdsduur) los je op tegen de tijd dat je er tegen aan loopt, dus of je nou 1 of 2 tabellen gebruikt => doe lekker wat handig is en als dat problemen oplevert refactor je het op dat moment.

Niet teveel bezig houden met overengineering

Rekening houden met schaalbaarheid en gemak in het uibreiden van je sensorgrid e.d. betekent niet automatisch overengineering he. Het is niet veel lastiger om 2 tabellen (1 stamtabel, 1 tabel met metingen met FK naar stamtabel) te gebruiken ipv 1, dus om dan over overengineering te spreken..

[termination]

Is het niet wat overkill om een RDBMS te gebruiken voor het loggen van wat simpele sensordata?
Ik zou dit soort data eerder in een NoSQL database (MongoDB/Redis) proppen.
Voordeel is dat je per dag/maand/jaar een key kan updaten, heb je ook meteen je aggregatie versimpeld en je groepering ingericht.

[farlane]

Careful ......

[hellfighter87]

Merethil schreef op donderdag 27 juli 2017 @ 13:45:
[...]


Rekening houden met schaalbaarheid en gemak in het uibreiden van je sensorgrid e.d. betekent niet automatisch overengineering he. Het is niet veel lastiger om 2 tabellen (1 stamtabel, 1 tabel met metingen met FK naar stamtabel) te gebruiken ipv 1, dus om dan over overengineering te spreken..

heel het idee van overengineering is dat je rekening houdt met usecases die op dit moment er nog niet zijn.

Op dit moment is er een usecase voor 2 sensoren, en mogelijk een 3de
In het ergste geval heb je dus 3 losse tabellen, wat weinig uitmaakt.

Verder kan je ze altijd nog samenvoegen mocht het wel uit de hand lopen met delfde schaalbaarheid en gemak van jou idee .

Ik zou voor dezelfde oplossing kiezen als die jij voordraagt, maar mijn punt was:
als de gebruiker het simpeler vind om 2 of 3 losse tabellen te hebben is dat op dit moment ook prima

termination schreef op donderdag 27 juli 2017 @ 14:38:
Is het niet wat overkill om een RDBMS te gebruiken voor het loggen van wat simpele sensordata?
Ik zou dit soort data eerder in een NoSQL database (MongoDB/Redis) proppen.
Voordeel is dat je per dag/maand/jaar een key kan updaten, heb je ook meteen je aggregatie versimpeld en je groepering ingericht.

wat maakt MySQL precies ingewikkelder dan MongoDB, want volgens mij is het instaleren en connecten bij beide even moeilijk en de rest stelt niks voor

[ Voor 22% gewijzigd door hellfighter87 op 27-07-2017 14:52 ]

[incaz]

jeroenk13 schreef op woensdag 26 juli 2017 @ 23:05:
edit:
Is het bijvoorbeeld ook een optie om per maand een nieuwe table aan te maken ? Of is dat onhandig / niet prestatiebevorderend ivm meerdere queries naar de tables als je wat globalere data wilt weergeven ?

Nee, dat zou ik niet doen. Zodra je tabelnamen als variabele gaat proberen te gebruiken wordt het onhandig. Dan gewoon een veld toevoegen met de maand. (Maar als je een datetime-veld hebt is dat waarschijnlijk niet nodig, omdat mysql gewoon ingebouwde functies daarvoor heeft, en voor zover ik weet kun je daar zelfs op indexeren.)

Wat wel kan is een table met live-data van elke minuut / elke seconde of hoe vaak je maar wilt, die je (deels) leeggooit zodra het teveel ruimte inneemt, en een tabel met aggregated data, waarin je bewaart wat je wilt houden. Daar vind ik meerdere tabellen wel zinnig, omdat ze een heel verschillende rol vervullen.

Als je indices toe wilt voegen om bv maandoverzichten te maken, dan bij voorkeur op de tweede tabel. (Indices zijn een vorm van denormalisatie die is gericht op veel lezen en weinig schrijven. Veel indices op een tabel kunnen het wegschrijven traag maken en nemen extra ruimte in, da's dus meer geschikt voor de geaggregeerde data en niet voor de live-data.)

Maar, voer vooral ook een Agile werkwijze in: begin met bouwen maar als je het idee hebt dat je dingen gaat kopieren of handige hacks aan het bedenken bent om bv je tabelnamen te kunnen genereren, omdat je dat zo vaak doet dat met de hand aanmaken omslachtig is, ben je beland op een punt dat je even uit moet zoomen en een betere oplossing moet bedenken. En met een paar backups van je database is een kolom later prima toe te voegen aan een tabel, dus als je dat nu nog niet nodig hebt, dan komt dat zodra het wel nodig is.

[Paul]

Een andere invalshoek: Wil je het per se allemaal zelf programmeren? Want voor dit soort dingen is iets als Cacti uitermate geschikt Als het je meer om de grafiekjes gaat dan om de programmeerervaring dan is dat misschien nog een leuke optie.

[CurlyMo]

incaz schreef op donderdag 27 juli 2017 @ 16:59:
[...]
Wat wel kan is een table met live-data van elke minuut / elke seconde of hoe vaak je maar wilt, die je (deels) leeggooit zodra het teveel ruimte inneemt, en een tabel met aggregated data, waarin je bewaart wat je wilt houden. Daar vind ik meerdere tabellen wel zinnig, omdat ze een heel verschillende rol vervullen.

Als ruimte een probleem wordt dan moet je gewoon een Full HD Film weggooien of die 100MB HDD vervangen voor een van 1TB. Simpele sensor data binair opgeslagen gaat echt het eerste jaar geen pijn doen, en het tweede en derde ook niet. Desnoods verlaag je de temporele resolutie waarin je opslaat.

Het is overigens wel een goede tip om meerdere tabellen te gebruiken, Bijv. 1 voor ruwe data en een andere incrementeel bijwerken met geaggregreerde data. Dat is wat ik zelf ook doe voor mijn slimme meter log. De aggregratie die ik wekelijks gebruikt voor rapportage staat dan gewoon klaar, wil ik een hogere temporele resolutie, dan duik ik in de ruwe data.

[incaz]

CurlyMo schreef op donderdag 27 juli 2017 @ 18:05:
[...]

Als ruimte een probleem wordt dan moet je gewoon een Full HD Film weggooien of die 100MB HDD vervangen voor een van 1TB. Simpele sensor data binair opgeslagen gaat echt het eerste jaar geen pijn doen, en het tweede en derde ook niet. Desnoods verlaag je de temporele resolutie waarin je opslaat.

Kan maar waarom zou je? Waarom zou je je resolutie op voorhand beperken? Dan kun je ook op korte termijn niet gedetailleerd terugkijken (wat leuk kan zijn voor bepaalde doeleinden.) Want het is, zeker bij temperatuur, best aannemelijk dat je over de afgelopen dagen graag zeer fijnmazig de veranderingen kunt zien, maar dat het over een jaar meer dan nauwkeurig genoeg is om 1 meting per uur of nog minder te behouden.
En HD-ruimte bijkopen kan ook, en als je dit zou loggen voor profesionele/wetenschappelijke doeleinden zou ik niet zo snel zijn om aan te raden om meetgegevens weg te gooien, maar voor een priveproject ruimt het soms wel lekker op.
(En het gaat best snel. Reductie van een regel per 15s naar een per uur is toch een reductie van zo'n 99%. Dat schiet wel op.)

(Geheel terzijde, ik zou het best interessant vinden wat eigenlijk een goede manier is om temperatuurverloop op te slaan. Want je zou ipv intervalgebaseerd ook kunnen kijken naar min/max-punten en enkele punten daartussen, of nog leuker, fourier-analyse, zodat je kunt interpoleren. Wellicht kun je dan met nog minder datapunten een goed beeld krijgen. Maar... da's meer voor de hobbyist die het leuk vindt om daar op te puzzelen dan als nuttige bezuiniging op ruimte lijkt me )

[CurlyMo]

Even teruggezocht, 500.000 rijen energiemeter data kost me 55MB in MySQL. In TS zijn geval is dat per jaar zo'n 8 keer zoveel, oftewel 440MB per jaar. Dan zie je dat je er met 1TB wel even tegenaan kan

[Yucon]

Het is niet je vraag, maar ik ben wel een beetje nieuwsgierig. Welke toepassing heb je in gedachten die het zinvol maakt om elke 15 seconden een temperatuur op te slaan? Voor de meeste toepassingen is elke 5 minuten meer dan genoeg.

[Sissors]

incaz schreef op donderdag 27 juli 2017 @ 19:23:
[...]


(Geheel terzijde, ik zou het best interessant vinden wat eigenlijk een goede manier is om temperatuurverloop op te slaan. Want je zou ipv intervalgebaseerd ook kunnen kijken naar min/max-punten en enkele punten daartussen, of nog leuker, fourier-analyse, zodat je kunt interpoleren. Wellicht kun je dan met nog minder datapunten een goed beeld krijgen. Maar... da's meer voor de hobbyist die het leuk vindt om daar op te puzzelen dan als nuttige bezuiniging op ruimte lijkt me )

Ik denk niet dat frequentie domein (fourier) erg interessant is voor temperatuursdata. Enkel om het een keertje op oude data te draaien, als methode om te zien hoeveel je mist als je minder samples hebt.

Overigens eens met bovenstaande, ja je wil een plotselinge temperatuursval mooi meenemen, of je CV die aanslaat binnen, maar elke 15 seconde is misschien niet heel zinvol meer.

[armageddon_2k1]

Is deze ook niet superhip voor Timeseries data?
https://www.influxdata.com/

[Verwijderd]

Ik weet niet wat de granulariteit van e.e.a. is , temp op de honderste? of tienden? of zijn hele graden ook goed? of halve?

Als je bv. tevreden zou zijn met halve graden, temperatuur verandert niet heel snel. Ipv. statisch om de x tijd de temperatuur op te slaan, zou je ook temperatuurswisselingen op kunnen slaan. Als het dan 3 uur lang 24 graden is, heb je maar 1 record in je database. En ook een volledige dekking ipv momentopnames.

Ik kan mij voorstellen dat als je een wat gevoelige sensor hebt die op tienden of zelfs hondersten werkt, dat er dan teveel wisselingen zijn om dit gunstig te maken.

Voor wat betreft indices, als je indexeert op maand, is het voor performance niet nodig om per maand aparte tabellen te maken. Kwestie van je queries 'goedkom' schrijven en ze ook laten explainen om te kijken in welke volgorde er geselecteerd wordt. Voor het formaat van de gegevens hoef je het ook niet te doen. Om kort te gaan, ik zie geen enkel voordeel van het per maand een aparte tabel maken, afgezien van dat het ook gewoon onjuist database-gebruik is.

[ajakkes]

Je kan er lang en kort over discussiëren. Maar uiteindelijk is de beste tip, stop die eerste maand in een database die je op je Synology al hebt. Kijk welke mooie dingen je met de data kan doen. En kom over een maand terug om te kijken waar je het echt voor gebruikt en wat je daar voor nodig hebt.

Want het komende half jaar ga je geen problemen hebben. En al je toekomst problemen kan je beter in de toekomst oplossen.

Tenzij je je werk ervan gaat maken.

[jeroenk13]

Paul schreef op donderdag 27 juli 2017 @ 17:36:
Een andere invalshoek: Wil je het per se allemaal zelf programmeren? Want voor dit soort dingen is iets als Cacti uitermate geschikt Als het je meer om de grafiekjes gaat dan om de programmeerervaring dan is dat misschien nog een leuke optie.

Het programmeren is het probleem niet. Ik wist gewoon niet zeker wat de beste aanpak was. Vandaar dat ik het hier even navraag.
Mijn plan was om het gewoon in 1x goed neer te zetten, en niet dat ik iedere maand bezig ben met het fixen van problemen.

armageddon_2k1 schreef op donderdag 27 juli 2017 @ 20:55:
Is deze ook niet superhip voor Timeseries data?
https://www.influxdata.com/

Deze is inderdaad ook al genoemd in het andere topic; InfluxDB.
Dit is misschien wel de beste oplossing voor mijn toepassing.

Yucon schreef op donderdag 27 juli 2017 @ 20:39:
Het is niet je vraag, maar ik ben wel een beetje nieuwsgierig. Welke toepassing heb je in gedachten die het zinvol maakt om elke 15 seconden een temperatuur op te slaan? Voor de meeste toepassingen is elke 5 minuten meer dan genoeg.

Het doel is om bepaalde temperatuur fluctuaties in kaart te brengen. Die 15s is maar een richtlijn, maar als je iedere 5min een meting doet dan mis ik hoogstwaarschijnlijk eventuele pieken die ik graag wel zou willen zien.

Verwijderd schreef op donderdag 27 juli 2017 @ 20:59:
Ik weet niet wat de granulariteit van e.e.a. is , temp op de honderste? of tienden? of zijn hele graden ook goed? of halve?

Als je bv. tevreden zou zijn met halve graden, temperatuur verandert niet heel snel. Ipv. statisch om de x tijd de temperatuur op te slaan, zou je ook temperatuurswisselingen op kunnen slaan. Als het dan 3 uur lang 24 graden is, heb je maar 1 record in je database. En ook een volledige dekking ipv momentopnames.

Ik kan mij voorstellen dat als je een wat gevoelige sensor hebt die op tienden of zelfs hondersten werkt, dat er dan teveel wisselingen zijn om dit gunstig te maken.

Voor wat betreft indices, als je indexeert op maand, is het voor performance niet nodig om per maand aparte tabellen te maken. Kwestie van je queries 'goedkom' schrijven en ze ook laten explainen om te kijken in welke volgorde er geselecteerd wordt. Voor het formaat van de gegevens hoef je het ook niet te doen. Om kort te gaan, ik zie geen enkel voordeel van het per maand een aparte tabel maken, afgezien van dat het ook gewoon onjuist database-gebruik is.

Ik ga ze gebruiken op 1 of 2 tienden.

Als je bv. tevreden zou zijn met halve graden, temperatuur verandert niet heel snel. Ipv. statisch om de x tijd de temperatuur op te slaan, zou je ook temperatuurswisselingen op kunnen slaan.

Zeker een goed punt om rekening mee te houden!


Ik zit dit moment nog te twijfelen over MySQL en InfluxDB. Ik ga me nog even verder verdiepen in InfluxDB vanwege de ingebouwde downsample feature.
In de toekomst komt er waarschijnlijk nog een 3de of 4de sensor bij.

[ Voor 3% gewijzigd door jeroenk13 op 27-07-2017 21:07 ]

[Rob]

Ik denk dat het simpel is: gooi er MySQL op met 1 tabel met de volgende velden
ID (int)
sensor (enum)
tijd (timestamp)
temp (float)

en draai daar een tijdje mee. Wordt het traag, kans is klein, dan kun je altijd nog simpel een export maken en een andere methode gebruuiken

[Verwijderd]

Een hybride oplossing kan ook. Wél elke 15s pollen, maar alleen opslaan als er een verschil is. Met twee tiendes, zou je dat al enorm veel data moeten gaan schelen in opslag.

Dit maakt je rapportages wel iets complexer, maar niets wat niet op te lossen is.

[Yucon]

jeroenk13 schreef op donderdag 27 juli 2017 @ 21:04:
[...]

Het doel is om bepaalde temperatuur fluctuaties in kaart te brengen. Die 15s is maar een richtlijn, maar als je iedere 5min een meting doet dan mis ik hoogstwaarschijnlijk eventuele pieken die ik graag wel zou willen zien.

Heb je overwogen om de sensor permanent te laten meten en de piek over de periode over te laten sturen? Dan bereik je waarschijnlijk hetzelfde terwijl een en ander veel hanteerbaarder wordt.

[Gomez12]

jeroenk13 schreef op donderdag 27 juli 2017 @ 21:04:
[...]
Ik zit dit moment nog te twijfelen over MySQL en InfluxDB. Ik ga me nog even verder verdiepen in InfluxDB vanwege de ingebouwde downsample feature.
In de toekomst komt er waarschijnlijk nog een 3de of 4de sensor bij.

Ja, ik zou zelf influxDB pakken, maar dat is meer omdat ik het al voor andere dingen inzet.

Maar lees je erg goed in over influxDB, het is geen RDMS, je kunt bijv per definitie geen oude data eruitmieteren (zonder extreem moeilijk te moeten doen), SQL kent het niet.
En eigenlijk is het meer bedoeld voor 1000'en datapunten per seconde ipv 1 per 15 seconde.

Als ik niks op influxDB had draaien dan zou ik denk ik toch voor simpelweg MySQL gaan, omdat het gewoon veel en veel en veel makkelijker te beheren en duidelijk is en omdat het het gewoon met 2 vingers in de neus aankan... Waarom moeilijk doen met InfluxDB als het niet nodig is.

Ingebouwde downsample feature klinkt leuk, maar het is wel iets wat je moet instellen en 100% goedzetten voordat je 1e datapunt binnenkomt, want later kan je het niet meer wijzigen.
En tja, wil je downsampling in mysql, waar praat je dan over? Dat je 1x per jaar een query moet draaien?

[Paul]

jeroenk13 schreef op donderdag 27 juli 2017 @ 21:04:
Het programmeren is het probleem niet. Ik wist gewoon niet zeker wat de beste aanpak was. Vandaar dat ik het hier even navraag.
Mijn plan was om het gewoon in 1x goed neer te zetten, en niet dat ik iedere maand bezig ben met het fixen van problemen.

Ik had het het niet over problemen, ik had het over doelen

Het doel is om bepaalde temperatuur fluctuaties in kaart te brengen. Die 15s is maar een richtlijn, maar als je iedere 5min een meting doet dan mis ik hoogstwaarschijnlijk eventuele pieken die ik graag wel zou willen zien.

Je hebt het over binnen- en buitentemperatuur. Die schommelen mijns inziens ook weer niet zoveel dat je met 5 minuten significant data verliest?

[pedorus]

hellfighter87 schreef op donderdag 27 juli 2017 @ 13:41:
Ik zou persoonlijk niet gaan aanklooien met CSV omdat je daar minder handig queries over heen kan halen en SQLite ben ik zelf een beetje huiverig voor (database corruptie....)

Scala:

val res = spark.sql("SELECT * FROM csv.`put/hdfs/csv/file/name/here`")

(met gebruik van "org.apache.spark" %% "spark-sql" % 2.2.0 )

Maar goed, mysql heeft wel als voordeel dat je indexes enzo kan gebruiken... Dit is meer om direct wat te kunnen doen met data die je op deze manier hebt opgeslagen omdat het teveel is voor mysql bijvoorbeeld. Of als je toch tijd genoeg hebt om de volledige data door te gaan.

jeroenk13 schreef op donderdag 27 juli 2017 @ 21:04:
Als je bv. tevreden zou zijn met halve graden, temperatuur verandert niet heel snel. Ipv. statisch om de x tijd de temperatuur op te slaan, zou je ook temperatuurswisselingen op kunnen slaan.

Zeker een goed punt om rekening mee te houden!


Ik zit dit moment nog te twijfelen over MySQL en InfluxDB. Ik ga me nog even verder verdiepen in InfluxDB vanwege de ingebouwde downsample feature.
In de toekomst komt er waarschijnlijk nog een 3de of 4de sensor bij.

Ik voel al een stukje overengineering aankomen. YAGNI.

[termination]

hellfighter87 schreef op donderdag 27 juli 2017 @ 14:50:
[...]

wat maakt MySQL precies ingewikkelder dan MongoDB, want volgens mij is het instaleren en connecten bij beide even moeilijk en de rest stelt niks voor

Waar exact zie je mij zeggen dat MySQL ingewikkelder is dan MongoDB? Ik heb het over overkill.
Timeseries data zoals sensorgegevens hebben m.i. geen plaats in een relationele database als dat het enige is dat word opgeslagen (er is immers niets relationeels aan). Hiervoor zijn o.a. NoSQL oplossingen, InfluxDB of Elasticsearch veel geschikter.

[hellfighter87]

termination schreef op vrijdag 28 juli 2017 @ 08:33:
[...]


Waar exact zie je mij zeggen dat MySQL ingewikkelder is dan MongoDB? Ik heb het over overkill.
Timeseries data zoals sensorgegevens hebben m.i. geen plaats in een relationele database als dat het enige is dat word opgeslagen (er is immers niets relationeels aan). Hiervoor zijn o.a. NoSQL oplossingen, InfluxDB of Elasticsearch veel geschikter.

Agreed, al denk ik dat alles overkill is voor die paar miljoen records die je haalt in een jaar als je alles laat staan. ik zou zeggen gebruik lekker wat je al hebt dat is de simpelste oplossing. Mocht dat ooit tekort komen dan kan je altijd nog kijken naar iets wat beter werkt .

[Cloud]

termination schreef op vrijdag 28 juli 2017 @ 08:33:
[...]


Waar exact zie je mij zeggen dat MySQL ingewikkelder is dan MongoDB? Ik heb het over overkill.
Timeseries data zoals sensorgegevens hebben m.i. geen plaats in een relationele database als dat het enige is dat word opgeslagen (er is immers niets relationeels aan). Hiervoor zijn o.a. NoSQL oplossingen, InfluxDB of Elasticsearch veel geschikter.

Ik zou even terugkijken in het vorige topic, voordat díe discussie weer opnieuw helemaal los gaat (zie de inleiding van de TS in dit topic). Want dat zijn nogal boude uitspraken die je daar doet (met name het 'er is niets relationeels aan'-stukje). Zou zonde zijn als dit topic ook die kant weer op gaat; daar heeft de TS niets aan.

@jeroenk13
De huidige richting van MySQL of InfluxDB lijkt me een prima richting en beide heel geschikt.

hellfighter87 schreef op vrijdag 28 juli 2017 @ 08:55:
[...]


Agreed, al denk ik dat alles overkill is voor die paar miljoen records die je haalt in een jaar als je alles laat staan. ik zou zeggen gebruik lekker wat je al hebt dat is de simpelste oplossing. Mocht dat ooit tekort komen dan kan je altijd nog kijken naar iets wat beter werkt .

TS heeft nog niet echt iets hé, dus gebruiken wat hij al heeft is geen oplossing Of bedoel je daarmee de verborgen PostgreSQL server op de Synology?

[ Voor 23% gewijzigd door Cloud op 28-07-2017 09:56 ]

[termination]

offtopic:
Mij ontgaat even wat er mis is met mijn uitspraken. Het gaat over het loggen van sensordata, daar is in principe geen relationeel systeem voor nodig en zijn er wellicht betere technieken te onderzoeken.

Anywho, het heeft inderdaad geen zin om de discussie aan te gaan.

On-topic: Als je al bekend bent met MySQL zou ik daar gebruik van maken, zo simpel mogelijk houden.

ajakkes schreef op donderdag 27 juli 2017 @ 20:59:
Je kan er lang en kort over discussiëren. Maar uiteindelijk is de beste tip, stop die eerste maand in een database die je op je Synology al hebt. Kijk welke mooie dingen je met de data kan doen. En kom over een maand terug om te kijken waar je het echt voor gebruikt en wat je daar voor nodig hebt.

Hier sluit ik me bij aan, bouw eerst een simpele basis, dan iteraties met verbeteringen doorlopen.

[jeroenk13]

Wat zou de handigste manier zijn om de data in de database te krijgen ?

Gewoon een php pagina hosten op de Synology web server zoals dit: https://forum.arduino.cc/index.php?topic=320990.0

Of voor een arduino optie gaan?: https://github.com/ChuckB...c_insert/basic_insert.ino

[Verwijderd]

Qua handigheid denk ik lood om oud ijzer, maar ik zou toch voor de eerste optie gaan.

Zo hou je zaken bij elkaar. Zou je bv. in de toekomst je arduino door een raspberry pi willen vervangen, kan dat, zonder aan databasekant of de benadering van de database iets te hoeven aanpassen.

Of stel je besluit straks toch voor een andere database te gaan dan waar je mee begonnen bent, dan beperken de aanpassingen zich tot de 'server' waar de database op draait.

[whoami]

Ik gebruik voor een gelijkaardig project waarbij ik om de 20seconden 26 temperatuur sensoren uitlees influxdb. Dit draait allemaal op een pi.

Waarom die keuze: goede samenwerking met grafana en de retention policies. Het heeft in mijn geval geen zin om de data ouder dan 2 of 3 jaar bij te houden.

Daarnaast is het gewoon ook eens een nieuwe/onbekende omgeving en dat is ook altijd eens leuk.

Sensoren uitlezen doe ik trouwens met python.

[ Voor 5% gewijzigd door whoami op 29-07-2017 00:05 ]

[Compizfox]

gekkie schreef op donderdag 27 juli 2017 @ 10:36:
[...]

Uiteraard kan aggregatie met een timeseries of sql database ook, maar dan moet je het zelf verzorgen.
Bij RRD is het een vereiste om het te definieren bij het aanmaken van de database en gaat dat vervolgens dus automagisch. Let wel dat je tevens een limiet moet opgeven waarna data definitief weggegooid gaat worden.

Bij InfluxDB kan dat dus ook helemaal automagisch In dat opzicht heeft InfluxDB veel met RRDTool gemeen. Het is allebei software bedoeld voor time series data, dus je zult dezelfde approaches tegenkomen. Het grootste verschil is dat InfluxDB alleen een database is, terwijl RRDTool ook grafieken uitkakt.

---

Gomez12 schreef op donderdag 27 juli 2017 @ 21:42:
[...]
Maar lees je erg goed in over influxDB, het is geen RDMS, je kunt bijv per definitie geen oude data eruitmieteren (zonder extreem moeilijk te moeten doen), SQL kent het niet.
En eigenlijk is het meer bedoeld voor 1000'en datapunten per seconde ipv 1 per 15 seconde.

Ik zou niet weten waarom je er geen oude data uit kunt mieteren. Je kunt bijvoorbeeld gewoon het volgende doen:

code:

DELETE WHERE time < '2016-01-01'

Dit voorbeeld komt overigens rechtstreeks uit de documentatie, waar dit duidelijk beschreven staat, dus ik snap niet waar je het idee vandaan haalt dat je met InfluxDB geen data eruit zou kunnen mieteren.

De query-taal die InfluxDB gebruikt is inderdaad strict gezien geen SQL, maar het lijkt er wel heel erg op. (zie Comparison to SQL uit de documentatie).

---

jeroenk13 schreef op vrijdag 28 juli 2017 @ 20:15:
Wat zou de handigste manier zijn om de data in de database te krijgen ?

Gewoon een php pagina hosten op de Synology web server zoals dit: https://forum.arduino.cc/index.php?topic=320990.0

Of voor een arduino optie gaan?: https://github.com/ChuckB...c_insert/basic_insert.ino

In het geval van InfluxDB, daar kun je in principe gewoon over HTTP tegenaan POSTen. Geen PHP nodig dus, zolang je vanuit je temperatuursensoren daarmee kunt interfacen.

[ Voor 62% gewijzigd door Compizfox op 29-07-2017 00:34 ]

[Thralas]

termination schreef op vrijdag 28 juli 2017 @ 10:21:
[offtopic]Mij ontgaat even wat er mis is met mijn uitspraken. Het gaat over het loggen van sensordata, daar is in principe geen relationeel systeem voor nodig en zijn er wellicht betere technieken te onderzoeken.

Ik zie in het vorige topic ook vooral in discussie over hoe de data zo geforceerd mogelijk in een RDBMS te duwen. Volgens mij enkel gedragen door het feit dat iedere IT'er weet wat een relationele database is, maar dat is het dan ook wel.

Voor time series data (zoals sensoren) hadden we in 2000 RRDtool, welke nog steeds prima volstaat als je een paar simpele grafiekjes wilt tekenen. Het hippe/moderne alternatief is InfluxDB.

Als ik niks op influxDB had draaien dan zou ik denk ik toch voor simpelweg MySQL gaan, omdat het gewoon veel en veel en veel makkelijker te beheren en duidelijk is en omdat het het gewoon met 2 vingers in de neus aankan... Waarom moeilijk doen met InfluxDB als het niet nodig is.

De tijd die je nodig hebt om InfluxDB eigen te maken win je terug op het punt dat je de data wilt gaan visualiseren. Grafana maakt dat heel erg gemakkelijk, makkelijker dan een relationele database.

On-topic: Als je al bekend bent met MySQL zou ik daar gebruik van maken, zo simpel mogelijk houden.

Dat is een prima argument voor een RDBMS.

In plaats van 'dat draait op Synology'. Tegenwoordig weet een Tweaker niet meer hoe een compiler werkt?

En dan zijn er nog pitfalls van time series databases (of in ieder geval Influx). Bijvoorbeeld het feit dat je niet kunt groeperen op kalendereenheden. Met een RDBMS kun je dat makkelijker realiseren, en je komt ermee weg omdat je dataset helemaal niets voorstelt qua grootte.

Misschien nog wel het beste idee: gooi het in zowel MySQL als InfluxDB/Grafana, dan leer je er nog wat van en ontdek je vanzelf de voor- en nadelen van beide oplossingen.

[Kettrick]

De data die je op wilt slaan is timeseries data, die discussie lijkt me redelijk zinloos, vraag is dan of je de moeite wil nemen om je je er in te verdiepen of dat je in het in een relationele database wil proppen.

Elke eenvoudige database kan met een dergelijke dataset omgaan, geen probleem, maar mijn voorkeur zou hier zeker uitgaan naar influx met de voornaamste reden dat het er voor gemaakt is en het veel meer query mogelijkheden biedt die gericht zijn op timeseries.

Timeseries is bovendien een goede skillset om te hebben, elke mafkees snapt sql maar influx op je CV op wat voor niveau dan ook is een stuk unieker

[Verwijderd]

Wat cool!

Toevallig ben ik met exact hetzelfde bezig, met een Arduino allerlei sensor data verzamelen. Wil die data in een webservice gaan drukken (metrix.io).

Mijn projectje ben ik aan het bouwen met Cassandra.

Het is wat archaisch maar ideaal om data slechts tijdelijk op te slaan; rijen/columns hebben hun eigen TTL.

Je mist echter een hoop eromheen; waarschijnlijk is InfluxDB veel sneller om een time-series use-case op te lossen.

Naast de ingebouwde TTL voor data was een andere reden voor Cassandra te kiezen dat het een #10 veelgebruikte database is volgens https://db-engines.com/en/ranking , leek me goede op CV. Het is ook de hoogste genoteerde NoSQL database na MongoDB (die ik vrij goed ken, en inmiddels wel "klaar" mee ben). Daarnaast wil ik er een publieke webservice van gaan maken; cassandra is redelijk eenvoudig op te schalen naar extreme omvang mits data keys goed zijn gekozen; MongoDB en relationele database sharding/clustering is relatief complex is mijn ervaring. Daar heb ik geen zin meer in.

Ik heb het projectje eerder gemaakt in MongoDB (wat gek genoeg best efficient kan, als je van in-field replacement gebruikmaakt), en daarna omgebouwd naar een relationele database. Maar die TTL bleef ik tegenaan lopen; telkens zelf opruimen zag ik niet zitten.

Ik zou Cassandra afraden als je redelijk nieuw bent met databases in het algemeen; dan is een relationele of Influx-oplossing waarschijnlijk veel eenvoudiger/sneller/flexibeler. Zo zit ik alle aggregaties nu handmatig op te lossen in mijn eigen applicatie zodat ik zowel van de afgelopen week alle brondata heb en long-term geaggregeerde data. Heb niet gezocht/gekeken of zoiets bestaat in het Cassandra ecosysteem eigenlijk, vooral te leuk om zelf in elkaar te knutselen Apache heeft een half dozijn tools op dit vlak geloof ik.

Voor kleine data omvang kun je de meeste databases wel pakken eigenlijk; ik lees uit je inleiding dat je tegen de 10-30 miljoen records krijgt in 3 jaar, dat is goed te doen. Indien weinig ervaren zou ik voor relationeel gaan (toch wel een basis vaardigheid voor programmeurs) puur voor de leerervaring. Het is juist interessant om mee te maken hoe een relationele database slecht begint te performen naarmate je dataset groeit. Vergeet een indexje, verkeerde config params, verkeerde engine gekozen, slechte data normalisatie (of juist gebrek aan denormalisatie! Laat je niet gekmaken, er zijn genoeg use cases met name in de BI-wereld waarin je data juist niet wilt normaliseren), zie hoe het beestje klapt. Veel van geleerd. Je kan altijd data migreren naar een ander schema als je er niet tevreden over bent; is een goede oefening in SQL. In de praktijk zijn data migraties aan de orde van de dag.

Als je al redelijk thuis bent in de SQL-wereld zou Influx (of Cassandra ;-) ) waarschijnlijk een betere/more mature oplossing vormen.

Mocht je MongoDB een kans willen geven, zie bijv; https://www.mongodb.com/b...me-series-data-in-mongodb
In feite druk je alle metingen van bijv. 1 uur in 1 document; vantevoren maak je placeholders en vervolgens update je dat document continu. Dat was een efficiente oplossing, ik weet alleen niet of dat nog opgaat met de nieuwe wiredtiger engine... Het is ook een stuk complexer dan een simpele table met wat time/value-pairs en een metric identifier.

Het snelst is altijd natuurlijk een webservice ergens gebruiken; hosted database of tool. Maar where's the fun in that?

Maar altijd leuk om te horen dat anderen met hetzelfde gehobbybob bezig zijn

[ Voor 36% gewijzigd door Verwijderd op 30-07-2017 10:09 ]

[Hydra]

Als iemand die professioneel met Cassandra werkt: het is zeker leuk om mee te hobbyen. Maar hou er rekening mee dat Cassandra eigenlijk maar een erg nauwe use-case heeft (append-only inserts en selects op keys). Je kunt het an sich voor time-series data gebruiken maar daar is het niet voor ontwikkeld (i.t.t. Influx). Pas wel op dat je geen wide rows gebruikt: hoewel dit redelijk vaak terug komt in blog-posts over Cassandra is de performance hiervan erg slecht kan zin.

Je kunt ook eens naar https://prometheus.io/ (een metrics database) kijken. Samen met Grafana kun je daar erg makkelijk mooie dashboards op maken. Wij gebruiken het in ons Kubernetes cluster voor de metrics van al onze microservices.

termination schreef op donderdag 27 juli 2017 @ 14:38:
Is het niet wat overkill om een RDBMS te gebruiken voor het loggen van wat simpele sensordata?
Ik zou dit soort data eerder in een NoSQL database (MongoDB/Redis) proppen.

Als je met een gespecialiseerde tool komt (wat NoSQL databases vrijwel allemaal zijn) moet je wel uit kunnen leggen waarom dat je voorkeur heeft boven een generieke relationele database. Vooral als je er twee noemt de hele andere specialisaties hebben dan een voor timeseries data gespecialiseerde NoSQL database als Influx of Prometheus.

Mongo (een B-tree met een marketing sausje) is de enige uitzondering; die is nergens goed voor.

[ Voor 34% gewijzigd door Hydra op 30-07-2017 15:00 ]

[Verwijderd]

Hydra schreef op zondag 30 juli 2017 @ 14:49:
Mongo (een B-tree met een marketing sausje) is de enige uitzondering; die is nergens goed voor.

Dat is alsof je zegt dat PHP nergens goed voor is. Al sla je me dood, ik zou geen PHP meer willen gebruiken dezer tijd. Maar het is en blijft een veelzijdige tool die voor een groot aantal use cases kan werken. Van al mijn projecten in het verleden zou MongoDB rustig 80% van de gevallen kunnen oplossen; en als je Node.js en enkel JSON blobs processed zoals profile data van diverse third parties is het mogelijk zelfs een hele goede keus.

Akkoord; MongoDB zou ik zelf vrijwillig nooit gebruiken. Maar je lost er genoeg problemen snel en eenvoudig mee op. Als ik de JSON integratie van PostgreSQL vergelijk met die van MongoDB dan is PostgreSQL een lachertje (los van of je uberhaupt JSON in een database wil opslaan... maar leg dat de business eens uit).

Hydra schreef op zondag 30 juli 2017 @ 14:49:
Als iemand die professioneel met Cassandra werkt: het is zeker leuk om mee te hobbyen. Maar hou er rekening mee dat Cassandra eigenlijk maar een erg nauwe use-case heeft (append-only inserts en selects op keys). Je kunt het an sich voor time-series data gebruiken maar daar is het niet voor ontwikkeld (i.t.t. Influx). Pas wel op dat je geen wide rows gebruikt: hoewel dit redelijk vaak terug komt in blog-posts over Cassandra is de performance hiervan erg slecht kan zin.

Thanks voor de tip! Ik had het inderdaad op meerdere plekken zien staan. Ik ging uit van max 100.000 records per column (ik zie ze meer als "buckets" of "shards" omdat CQL niet echt de column-orientatie van Cassandra benadrukt). Maar rekening houdend met die omvang, is dan cassandra nog altijd een mindere keuze? Ik was aan het rekenen met tientallen miljarden records data opslag; en de vele queries en aggregaties die daarbij horen. Stuff als een aggregator had ik al geaccepteerd zelf te bouwen, in een query request wil ik binnen 10ms een response hebben voor 99,5% van de aggregate requests, dus leek mij dat alles vantevoren al berekend moet zijn. In andere woorden; ik zie Cassandra meer puur als opslag dan als query/search engine op data.

Als ik een BI tool zou willen bouwen kijk ik wel naar Redshift of iets dat Google tegenwoordig aan te bieden heeft denk ik. Maar misschien is dat idee ook wel achterhaald inmiddels.

[gekkie]

Verwijderd schreef op zondag 30 juli 2017 @ 18:55:
[...]
Akkoord; MongoDB zou ik zelf vrijwillig nooit gebruiken. Maar je lost er genoeg problemen snel en eenvoudig mee op. Als ik de JSON integratie van PostgreSQL vergelijk met die van MongoDB dan is PostgreSQL een lachertje (los van of je uberhaupt JSON in een database wil opslaan... maar leg dat de business eens uit).

Op welke punten is de JSON integratie in Postgres volgens jou dan een lachertje tov MongoDB ?

En "Los van of je uberhaupt JSON in een database wil opslaan", dat doe je in mongo toch ook, wat je kennelijk als een acceptabele, snelle en eenvoudige oplossing ziet ?

[Verwijderd]

gekkie schreef op zondag 30 juli 2017 @ 19:06:
[...]

Op welke punten is de JSON integratie in Postgres volgens jou dan een lachertje tov MongoDB ?

En "Los van of je uberhaupt JSON in een database wil opslaan", dat doe je in mongo toch ook, wat je kennelijk als een acceptabele, snelle en eenvoudige oplossing ziet ?

Ja, ik zie het ook als acceptabele, snelle en eenvoudige oplossing. Heb daarom ook bijna 3 jaar exclusief MongoDB gebruikt als database voor de meeste projecten, vooral toen ik met Nodejs werkte was het een "natural fit". Mijn eerste poging om time-series data op te slaan was ook in MongoDB; ik dacht "kijk eerst of dat werkt". Dat bleek uiteindelijk wat te complex voor mijn doen; hoewel de benchmarks die ik had ontwikkeld best goed bleken.

Wat betreft JSON in een database; in de praktijk kreeg ik vaak een BI request. Zoiets als "Geef mij alle users die de laatste maand niet zijn ingelogd, welke in totaal meer dan 1000 euro hebben uitgegeven over hun hele levenstijd". Omdat MongoDB zo veelzijdig is en diverse tools ingebouwd heeft kun je zo'n vraag prima beantwoorden... Maar de code die je daar voor nodig hebt is vaak erg complex; zeker als je daarbij de performance in de gaten wilt houden. Ik schaamde me regelmatig voor m'n scripts. Ik zat meer in de docs dan dat ik code aan het oplepelen was; en ik verwachtte ook niet dat iemand anders er ooit chocola van zou kunnen maken.

Maar toen ik een dergelijk scenario moest oplossen in PostgreSQL op JSON data met nested objects en arrays kwam ik er gewoon niet uit. Of het was te complex en ik begreep het niet, maar ik zat helemaal vast. Ik weet het niet meer precies maar ik herinner me dat wat ik wilde doen niet mogelijk was op dat moment in Postgres. Heb toen tijdelijke tabellen zitten bouwen en een simpel ETLetje ontwikkeld. Ik had erg veel spijt JSON op te slaan in PostgreSQL. Ik dacht toen nog: "Als 1 query een hele applicatie wordt doe je iets niet goed". Dat was zo'n 18-24 maanden geleden weliswaar. Heb het toen getransformeerd en gepusht naar Redshift in een gedenormaliseerd schema (ironisch genoeg is Redshift nota bene op Postgresql gebaseerd). Met wat eenvoudige SQL kwam ik er toen wel uit.

Misschien is de JSON support in PostgreSQL inmiddels krachtiger?

De puritein in mij zou zeggen: bouw dan een fatsoenlijke BI oplossing. Ja... als we daar eens tijd/geld voor hadden

Dus zowel in MongoDB als in PostgreSQL was ik niet tevreden over executie van ad-hoc complexe queries op JSON data. Dus ben wat cautious met JSON in databases momenteel. Er zijn zeker nog genoeg use cases waar het wel logisch kan zijn, bijv JSON responses opslaan van third-parties is MongoDB voor mij nog favoriet. Maar voor de meeste gevallen verkies ik nu een relationele database; mocht ik de data vervolgens willen transformeren naar een compleet ander dataschema dan is dat vrij eenvoudig met wat SQL. In MongoDB moet je je hersens echt goed op gang krijgen wil je grote schematransformaties voor mekaar krijgen; of complexe scripts schrijven die dat onderwater voor je doen. Dan verkies ik toch de elegantie van SQL en accepteer ik de gescheiden best practices van operationele vs BI use cases.

Overigens meer on-topic, hier nog een interessant artikel over time-series data in relationale databases en meer dedicated oplossingen:

https://db-engines.com/en/blog_post/71

[ Voor 24% gewijzigd door Verwijderd op 30-07-2017 19:58 ]

[Hydra]

Verwijderd schreef op zondag 30 juli 2017 @ 18:55:
Dat is alsof je zegt dat PHP nergens goed voor is.

PHP is 'gewoon' een programmeertaal. IMHO vrij bagger, maar het is wel gewoon een taal. Mongo is nooit een goeie keuze t.o.v. van meer generieke databases als Postgres. Het is niet makkelijker in het gebruik, het is trager, Mongo speelt vals in Benchmarks, Mongo raakt default data kwijt, mongo sharding werkt niet. Zo kan ik nog wel even doorgaan.

MongoDB is complete bagger. Het is een bedrijf dat puur drijft op marketing en een combinatie van ease of use en snelheid claimt. Die snelheid is vals spel (Postgres JSON storage is sneller) en het ease of use is compleet nul op het moment dat je erachter komt dat je data vrij snel relationeel is en dat er waarde in die relaties zit.

Dus als je met Mongo op de proppen komt als aanrader moet je van goeie huize komen wat betreft het waarom van het gebruik van deze tool. Vrijwel alle NoSQL oplossingen leveren genericiteit in om bepaalde dingen heel goed te doen. Cassandra is een distributed hashmap, erg snel op appens en key-retrievals. Redis is een betere memcached, graph databases als Neo4j zijn ideaal voor reporting, influxdb is specifiek voor time series. Etc. Mongo heeft geen enkel voordeel en ontelbare nadelen.

Thanks voor de tip! Ik had het inderdaad op meerdere plekken zien staan. Ik ging uit van max 100.000 records per column

Bedoel je nu columns per row?

(ik zie ze meer als "buckets" of "shards" omdat CQL niet echt de column-orientatie van Cassandra benadrukt). Maar rekening houdend met die omvang, is dan cassandra nog altijd een mindere keuze? Ik was aan het rekenen met tientallen miljarden records data opslag; en de vele queries en aggregaties die daarbij horen. Stuff als een aggregator had ik al geaccepteerd zelf te bouwen, in een query request wil ik binnen 10ms een response hebben voor 99,5% van de aggregate requests, dus leek mij dat alles vantevoren al berekend moet zijn. In andere woorden; ik zie Cassandra meer puur als opslag dan als query/search engine op data.

Dat kan. Maar als het puur opslag is en geen retrieval heeft het erg weinig nut om het in een database te stoppen met alle complexiteit van dien (want Cassandra is zeker complex). Dan kun je het net zo goed op HDFS opslaan en je aggregaties opslaan in een relationele DB.

Als ik een BI tool zou willen bouwen kijk ik wel naar Redshift of iets dat Google tegenwoordig aan te bieden heeft denk ik. Maar misschien is dat idee ook wel achterhaald inmiddels.

Waarom zou je een BI tool willen bouwen? Tableau ofzo werkt prima.

Verwijderd schreef op zondag 30 juli 2017 @ 19:22:
Dus zowel in MongoDB als in PostgreSQL was ik niet tevreden over executie van ad-hoc complexe queries op JSON data.

Daarom normaliseren we dus data. Dan heb je hier geen problemen mee. Je gebruik van Mongo heeft je manier van werken negatief beinvloed. Normaliseren die hap en in een fatsoenlijke DB stoppen.

[ Voor 6% gewijzigd door Hydra op 30-07-2017 20:21 ]

[gekkie]

Ah mjah je kunt natuurlijk niet verwachten dat je JSON dan ineens magisch eenvoudig querybaar wordt.
Al die relationele jongens en meiden zullen wel toch niet zo gek zijn dat ze steeds zoveel moeite doen om een model/schema te definieren ?
Doe je dat niet, dan ga je uiteindelijk alsnog een schema definieren, alleen dan pas bij elke query opnieuw. Echt efficient lijkt dat me niet nee.

[Hydra]

gekkie schreef op zondag 30 juli 2017 @ 20:21:
Ah mjah je kunt natuurlijk niet verwachten dat je JSON dan ineens magisch eenvoudig querybaar wordt.
Al die relationele jongens en meiden zullen wel toch niet zo gek zijn dat ze steeds zoveel moeite doen om een model/schema te definieren ?
Doe je dat niet, dan ga je uiteindelijk alsnog een schema definieren, alleen dan pas bij elke query opnieuw. Echt efficient lijkt dat me niet nee.

Je data heeft altijd een schema. In het geval van mongo zit het in je code. Een fout in je code leidt dan tot fouten in je data, zonder dat je het doorhebt.

De meeste talen hebben overigen prima frameworks om vanuit code een schema te generen als je dat wil voor rapid development. Dus ook hier heb je geen voordeel met Mongo. Voor al m'n Java 'pet projects' gebruik ik ook gewoon een relationele DB.

[gekkie]

Hydra schreef op zondag 30 juli 2017 @ 20:24:
[...]
Je data heeft altijd een schema. In het geval van mongo zit het in je code. Een fout in je code leidt dan tot fouten in je data, zonder dat je het doorhebt.

De meeste talen hebben overigen prima frameworks om vanuit code een schema te generen als je dat wil voor rapid development. Dus ook hier heb je geen voordeel met Mongo. Voor al m'n Java 'pet projects' gebruik ik ook gewoon een relationele DB.

Dat bedoel ik, dus je krijgt ingewikkelde code en of queries.
Achja ze hebben nu ook een sort of joins in mongo, uiteindelijk wandelen ze toch weer richting een relationele database met een uitgebreide query language .. maar dan non-standaard en de kantjes er van af lopende.

[Verwijderd]

gekkie schreef op zondag 30 juli 2017 @ 20:21:
Ah mjah je kunt natuurlijk niet verwachten dat je JSON dan ineens magisch eenvoudig querybaar wordt.
Al die relationele jongens en meiden zullen wel toch niet zo gek zijn dat ze steeds zoveel moeite doen om een model/schema te definieren ?

Mijn enige voorkeur voor MongoDB voor JSON is dat MongoDB het inderdaad wel allemaal querybaar maakt; hoe gek je je use case ook maakt, "het lukt" (hoe lelijk en complex ook soms ). PostgreSQL lukt dat niet. PostgreSQL maakt daarin ook een goede keuze wat mij betreft; misschien zelfs beter om helemaal geen JSON toe te staan. Schoenmaker blijf bij je leest ;-)

[ Voor 3% gewijzigd door Verwijderd op 30-07-2017 20:36 ]

[gekkie]

Verwijderd schreef op zondag 30 juli 2017 @ 20:35:
[...]
Mijn enige voorkeur voor MongoDB voor JSON is dat MongoDB het inderdaad wel allemaal querybaar maakt; hoe gek je je use case ook maakt, "het lukt" (hoe lelijk en complex ook soms ). PostgreSQL lukt dat niet. PostgreSQL maakt daarin ook een goede keuze wat mij betreft; misschien zelfs beter om helemaal geen JSON toe te staan. Schoenmaker blijf bij je leest ;-)

Tsja use it with care. Met postgresql is het ook querybaar, desnoods zet je je JSON weer om in een temp tabel. Maarja goed voor performance gaat het niet zijn. Dus voor data die je regelmatig queried is het niet verstandig, maak daar vooral gebruik van de kennis die je hebt over de data.

[Verwijderd]

gekkie schreef op zondag 30 juli 2017 @ 20:47:
[...]

Tsja use it with care. Met postgresql is het ook querybaar, desnoods zet je je JSON weer om in een temp tabel. Maarja goed voor performance gaat het niet zijn. Dus voor data die je regelmatig queried is het niet verstandig, maak daar vooral gebruik van de kennis die je hebt over de data.

eens

Sorry @jeroenk13; hoop dat het niet weer teveel verzand in persoonlijke meningen. Je legt een zeer fundamentele vraag neer voor veel database oplossingen; er is namelijk geen enkele database die ooit zou beweren "ik ben niet schikt voor grote volumes eenvoudige data". Je kan je oplossing in alle databases wel oplossen, elk op hun eigen manier (en binnen de SQL-familie op redelijk dezelfde manier).

De vraag is alleen welke het meest geschikt is. Als je extreem veel data hebt (10 miljard+ records) dan wordt het interessant. Dat is in jouw use case niet het geval. Dan zijn bestaande kennis, plezier en drang belangrijker.

Ik ken een half dozijn databases erg goed maar ik ken InfluxDB alleen van naam; desalniettemin lijkt mij dat een goede oplossing (hoewel ik dus zelf Cassandra voor een vergelijkbare use case gebruik).

Databases hebben allemaal hun quirks; je moet vooral kijken naar wat je wilt leren. Relationeel is dan altijd een goede keuze omdat het de lingua franca is; met die kennis begrijp je andere databases ook beter. De andere oplossingen zijn beter in sommige specifieke omstandigheden; maar met lage data volumes kun je er eigenlijk niet naast grijpen. Dan moet je je probleem binnen de tool zelf weten op te lossen.

[ Voor 60% gewijzigd door Verwijderd op 30-07-2017 21:22 ]

[Compizfox]

Hydra schreef op zondag 30 juli 2017 @ 20:20:
[...]
Mongo is nooit een goeie keuze t.o.v. van meer generieke databases als Postgres. Het is niet makkelijker in het gebruik, het is trager, Mongo speelt vals in Benchmarks, Mongo raakt default data kwijt, mongo sharding werkt niet. Zo kan ik nog wel even doorgaan.

Ja maar het is web scale

[Verwijderd]

Compizfox schreef op zondag 30 juli 2017 @ 21:19:
[...]

Ja maar het is web scale

Ik kan maar 1 keer rapporteren, maar sorry, wat is dat met die oude bronreferenties allemaal? Leven we nog in 2013? Ik begrijp de slechte MongoDB reputatie maar al te best, geloof me. Maar om nu te beweren dat met de huidige versie het een complete crapzooi is...

Damn, ik ben de allerlaatste die MongoDB zou verdedigen maar de trolls hier overtuigen me dat ik maar beter weer een ander forum op kan zoeken. The Gathering is achteruitgegaan over de jaren , niet zoals ik me herinner

[ Voor 6% gewijzigd door Verwijderd op 30-07-2017 21:28 ]

[Compizfox]

Verwijderd schreef op zondag 30 juli 2017 @ 21:28:
[...]

Ik kan maar 1 keer rapporteren, maar sorry, wat is dat met die oude bronreferenties allemaal? Leven we nog in 2013? Ik begrijp de slechte MongoDB reputatie maar al te best, geloof me. Maar om nu te beweren dat met de huidige versie het een complete crapzooi is...

Damn, ik ben de allerlaatste die MongoDB zou verdedigen maar de trolls hier overtuigen me dat ik maar beter weer een ander forum op kan zoeken. The Gathering is achteruitgegaan over de jaren , niet zoals ik me herinner

Rustig man, het is satire...

[Verwijderd]

Compizfox schreef op zondag 30 juli 2017 @ 21:29:
[...]

Rustig man, het is satire...

Dat had ik niet door, sorry. Ik had een wat kort lontje door een eerdere post.

Het is wat frustrerend als je maandenlang zit te testen en klooien; en erachter komt dat MongoDB inderdaad sneller blijkt dan veel andere databases voor je specifieke insert/query use case. Als er dan op basis van oude bronnen en een algemeen slechte reputatie Mongo puur als rotzooi wordt weggezet dan is dat erg vermoeiend. Het was maanden werk.

Ik heb de schurft aan MongoDB. Ik zal het nooit voor een hobbyproject gebruiken. Maar het is een goede database. Punt.

En ik zou het ook eenieder aanraden om eens serieus op de proef te nemen.

(disclosure; ik werkte voor Oracle Nederland toen ik MongoDB aanraadde voor de klant)

[gekkie]

Compizfox schreef op zondag 30 juli 2017 @ 21:29:
[...]
Rustig man, het is satire...

Maar in die satire geeft het wel de mindset aan van zowel de gebruikers als ontwikkelaars van Mongo.
Het nemen van shortcuts (by default) .. en daarmee afschuiven van alle problematiek rond databases op de gebruikers (implementeer het zelf maar keer op keer in je eigen code in een niet performante scripttaal).
Daar spreekt allemaal iets uit .. een manier van denken, waar ik m'n data niet aan toe zou willen vetrouwen.

Verwijderd schreef op zondag 30 juli 2017 @ 21:39:
Het is wat frustrerend als je maandenlang zit te testen en klooien; en erachter komt dat MongoDB inderdaad sneller blijkt dan veel andere databases voor je specifieke insert/query use case.

Dat is toch ook niet zo wonderlijk ? Mongo mikt je insert as-is in het geheugen en klaar is mongo.
Een ACID compliant RDBMS doet heel wat meer werk, maar dat betaald zich dubbel en dwars uit voor de overige queries en de code die je moet schrijven, maar daar ben je dus nu ook achter .

Ik heb de schurft aan MongoDB. Ik zal het nooit voor een hobbyproject gebruiken. Maar het is een goede database. Punt.

Hmmm misschien ben je er wel achter, maar is er toch nog enige mate van ontkenning .

Ik heb zelf ook eens een wat groter hobby ding geprobeerd met mongo, met ook als doel om eens te kijken of het inderdaad het walhalla was. En je wordt er inderdaad in gezogen want in het begin is het geweldig !
Je hoeft niet na te denken over je data, pleurt alles in mongo et voila magic. Wat simpele queries om individuele info op te halen .. mwah gaat vlot .. in no time staat dat ... maar dan gaat het komen .. dan komt de code waar je normaals gesproken joins in gaat doen .. en dan gaat het al knarsen. Je code wordt een zooi, progressie daalt naar het nulpunt. Je checkt je overal driedubbel suf omdat je overal en nergens in paniek je data probeert te valideren en constraints te handhaven. Ik was blij dat ik het gedaan had en dat het geen betaalde aangelegenheid was.

Overigens zou het ook nog wel kunnen dat er uiteindelijk nog wat timeseries optimalisatie terug vloeit naar postgres core vanuit https://www.timescale.com/how-it-works.html.

Ik doe momenteel zelf beperkt dingen met timeseries en dat queried best makelijk met zaken als "generate_series" functie, intervals en containment operator. Enige gotcha was dat je niet altijd indexen op functies op een timestamp with timezone kunt maken omdat ze mutable zijn door de timezone.

[ Voor 72% gewijzigd door gekkie op 30-07-2017 22:12 ]

[Verwijderd]

gekkie schreef op zondag 30 juli 2017 @ 21:44:
[...]

Maar in die satire geeft het wel de mindset aan van zowel de gebruikers als ontwikkelaars van Mongo.
Het nemen van shortcuts (by default) .. en daarmee afschuiven van alle problematiek rond databases op de gebruikers (implementeer het zelf maar keer op keer in je eigen code in een niet performante scripttaal).
Daar spreekt allemaal iets uit .. een manier van denken, waar ik m'n data niet aan toe zou willen vetrouwen.

Ik hoopte bloedserieus iets te kunnen leren van je ervaring met Cassandra maar door je reacties kan ik je kennis niet echt serieus meer nemen. Te gekleurd. Als we niet afstand kunnen nemen van voorkeuren/preferenties zijn we elkaar alleen maar aan het overtuigen van ons eigen gelijk.

Er zijn 1000+ database variaties? Meer? Wie weet welke database het beste is. Ik ken er slechts een half dozijn goed, waarvan 3 NoSQL.

Uit ervaring zeg ik: MongoDB is in sommige gevallen beter dan een half dozijn andere populaire databases. Ik kan de andere 995 niet testen, sorry.

Maar MongoDB is zeker niet geschikt. Punt. Omdat <bron uit 2010-2014> of <blogpost gisteren>. Voor je het weet gaan mensen beweren dat de CAP absoluut is en niet instelbaar in ongeveer elk van die 1000+ databases...

[ Voor 13% gewijzigd door Verwijderd op 30-07-2017 22:13 . Reden: Een PS ]

[BramV]

Ach de discussie is weer niet anders dan:
windows/linux
apple/windows
mysql/postgresql
lp/cd
links/rechts
etc etc etc

Jammer dat er niet wordt ingegrepen aangezien niemand gelijk heeft. Eigenlijk is het de schuld van de TS aangezien de vragen te algemeen zijn en te veel bevestiging vraagt, die niet te geven is. Wat mij opvalt is dat er steeds extreem overdreven oplossingen komen en dan verzeilen in allerlei theorie en levensverhalen.

Het gaat om 1 tabel (letje)... waarbij TS al aangaf Mysql ervaring te hebben. Om dan met Cassandra of weet ik veel aan te komen is echt een beetje triest. iedereen met een beetje kennis van databases weet dat Mysql prima is voor dit soort zaken (net als die andere 1001 oplossingen). Vooral omdat het maar 1 tabel is met data hoeveelheid waarom iedere database moet lachen...

TS had ook al zelf natuurlijk allang een proeftabel met een miljoen records kunnen maken en daar wat querie's overheen laten gaan...

[Verwijderd]

BramV schreef op zondag 30 juli 2017 @ 22:10:
Ach de discussie is weer niet anders dan:
windows/linux
apple/windows
mysql/postgresql
lp/cd
links/rechts
etc etc etc

Jammer dat er niet wordt ingegrepen aangezien niemand gelijk heeft. Eigenlijk is het de schuld van de TS aangezien de vragen te algemeen zijn en te veel bevestiging vraagt, die niet te geven is. Wat mij opvalt is dat er steeds extreem overdreven oplossingen komen en dan verzeilen in allerlei theorie en levensverhalen.

Het gaat om 1 tabel (letje)... waarbij TS al aangaf Mysql ervaring te hebben. Om dat met Cassandra of weet ik veel aan te komen is echt een beetje triest. iedereen met een beetje kennis van databases weet dat Mysql prima is voor dit soort zaken (net als die andere 1001 oplossingen). Vooral omdat het maar 1 tabel is met data hoeveelheid waarom iedere database moet lachen...

TS had ook al zelf natuurlijk allang een proeftabel met een miljoen records kunnen maken en daar wat querie's overheen laten gaan...

Sorry eens.

Ik dacht na over 10-30 miljoen records in 3 jaar, dan loop je toch wel tegen enige beperkingen en misconfiguraties aan meestal maar niets dat idd opgelost kan worden in een MySQL.

[BramV]

Verwijderd schreef op zondag 30 juli 2017 @ 22:12:
[...]

Sorry eens.

Ik dacht na over 10-30 miljoen records in 3 jaar, dan loop je toch wel tegen enige beperkingen en misconfiguraties aan meestal maar niets dat idd opgelost kan worden in een MySQL.

Ok, dan moet je je eigen teksten in dat licht maar eens teruglezen...

[Verwijderd]

BramV schreef op zondag 30 juli 2017 @ 22:13:
[...]


Ok, dan moet je je eigen teksten in dat licht maar eens teruglezen...

Ja eens. Ik werd meegezogen in de discussie, was wat kort van stof

Excuses.

[ Voor 9% gewijzigd door Verwijderd op 30-07-2017 22:15 ]

[pedorus]

Hydra schreef op zondag 30 juli 2017 @ 20:20:
Die snelheid is vals spel (Postgres JSON storage is sneller) en het ease of use is compleet nul op het moment dat je erachter komt dat je data vrij snel relationeel is en dat er waarde in die relaties zit.

Dus je zou postgres moeten gebruiken voor json ipv mongodb, want postgres is sneller en beter? Postgres kan bijvoorbeeld datetimes niet handig opslaan in json voor zover ik weet, en geloof niet dat het sneller is voor json naast dat allerlei operaties ontbreken.. Even voor de duidelijkheid, mongodb gebruik je als:

• Je een snelle (SSD) opslag hebt, dus geen trage EBS bijvoorbeeld
• De working set van je data in het geheugen past.
• Het daadwerkelijk om documenten gaat die ook steeds anders kunnen zijn (dus niet bijvoorbeeld een timeseries zoals hier). Dus bijvoorbeeld inkomende json requests.
• Je geen SQL wil gebruiken

Verwijderd schreef op zondag 30 juli 2017 @ 09:02:
een andere reden voor Cassandra te kiezen dat het een #10 veelgebruikte database is volgens https://db-engines.com/en/ranking , leek me goede op CV.

Een andere reden dan dat kan ik ook zo niet echt verzinnen.

	Mysql	Cassandra
start snel op	Ja	Nee
geheugen-efficiënt voor case	Ja	Nee
SQL tools bruikbaar	Ja	Nee
selecteer date range zonder full table scan	Ja	Clustered index only/expirmental SASI
veel hergebruik van kennis	Ja	Nee

Mooie tool verder dat Cassandra voor Key-Value stores met bloom filter.

[gekkie]

Verwijderd schreef op zondag 30 juli 2017 @ 22:02:
Allemaal fanboys. Laat ook allemaal maar dit.

Ps. en wederom, ik heb een persoonlijk ontzettend afschuwelijke hekel aan MongoDB. Maar het is een prima database. Zo context afhankelijk allemaal.

Waarom heb je dan een hekel aan een prima database ?
Of je hebt hem willens en wetens verkeerd ingezet maar dan moet je misschien een hekel aan je zelf hebben.
Of het was je niet vooraf duidelijk, kan het aan jezelf liggen of aan de docs van de DB.
Of het is misschien toch een iets minder prima database met bijzonder weinig usecases waarin het wel een prima database is.

Zoals Hydra al aangaf, er is eigenlijk niets waar mongo beter in is, het heeft eigenlijk geen niche (meer) die het bestaan rechtvaardigd. Al het bruikbare aan ideeën / richting, is al, of wordt al, overgenomen (of was vanuit zich zelf al ingezet) in de ontwikkeling van andere DB's.

En PS. ik heb zelf nog nooit met cassandra gewerkt, dat was hydra.

pedorus schreef op zondag 30 juli 2017 @ 22:18:
[...]
Dus je zou postgres moeten gebruiken voor json ipv mongodb, want postgres is sneller en beter? Postgres kan bijvoorbeeld datetimes niet handig opslaan in json voor zover ik weet, en geloof niet dat het sneller is voor json naast dat allerlei operaties ontbreken.. Even voor de duidelijkheid, mongodb gebruik je als:

Datetimes bestaan toch niet in JSON ?
Ben dan wel benieuwd wat mongo dan doet.
Bij mijn weten kan een int of een string hebben in je JSON waar je iets van epoch of ISO in plugt.maar daar houdt het wel op. Dus wat maakt mongo daar dan van, en hoe weet mongo dat het dat er van moet/mag maken ?

[ Voor 26% gewijzigd door gekkie op 30-07-2017 22:39 ]

[Verwijderd]

gekkie schreef op zondag 30 juli 2017 @ 22:25:
[...]

Waarom heb je dan een hekel aan een prima database ?
Of je hebt hem willens en wetens verkeerd ingezet maar dan moet je misschien een hekel aan je zelf hebben.
Of het was je niet vooraf duidelijk, kan het aan jezelf liggen of aan de docs van de DB.
Of het is misschien toch een iets minder prima database met bijzonder weinig usecases waarin het wel een prima database is.

Zoals Hydra al aangaf, er is eigenlijk niets waar mongo beter in is, het heeft eigenlijk geen niche (meer) die het bestaan rechtvaardigd. Al het bruikbare aan ideeën / richting, is al, of wordt al, overgenomen (of was vanuit zich zelf al ingezet) in de ontwikkeling van andere DB's.

En PS. ik heb zelf nog nooit met cassandra gewerkt, dat was hydra.

Sorry, het is allemaal wat confusing wie wat in de discussie inbracht.

Maandenlang testen en het was allemaal voor niets. Sorry, ik was dom.

[ Voor 3% gewijzigd door Verwijderd op 30-07-2017 22:41 ]

[pedorus]

gekkie schreef op zondag 30 juli 2017 @ 22:25:
Datetimes bestaan toch niet in JSON ?
Ben dan wel benieuwd wat mongo dan doet.
Bij mijn weten kan een int of een string hebben in je JSON waar je iets van epoch of ISO in plugt.maar daar houdt het wel op. Dus wat maakt mongo daar dan van, en hoe weet mongo dat het dat er van moet/mag maken ?

Zie http://bsonspec.org/spec.html type 9: "UTC datetime - The int64 is UTC milliseconds since the Unix epoch."
Dit bestaat dus vooral in bson en json staat daar alleen om het simpel te houden. Als je measurements over de tijd wil opslaan, dan is het toch wel handig om een echt datetime type te hebben.

In het kader van simpel houden: op dezelfde manier bedoel ik eigenlijk tegenwoordig vaak MariaDB waar ik Mysql zeg

[MorosMyrddin]

ik heb niet alle reacties gelezen, maar hier even mijn ervaring.
Wij hadden zeer veel sensor data (+1000 iedere 3sec) in een mysql db opgeslegen en dit ging zeer vlot, ook om terug te visualiseren.

Alleen om data opslag te sparen sloegen we enkel de data op wanneer deze was gewijzigd volgens een hysteresis, de tijd-datum van laatste meting werd wel telkens geupdate zodat bij eventuele sensor uitval dit toch op een of andere manier kon gelezen worden.

De meeste gegevens van sensoren blijven geruime tijd dezelfde. dus dit spaart toch een hoop data.
iedere maand werd er verder afgevlakt, met een grotere hysteresis of tijdsprongen.

EDIT: toch even verder gelezen en men voorstel was al langs gekomen.

[ Voor 5% gewijzigd door MorosMyrddin op 30-07-2017 22:55 ]

[gekkie]

pedorus schreef op zondag 30 juli 2017 @ 22:50:
[...]

Zie http://bsonspec.org/spec.html type 9: "UTC datetime - The int64 is UTC milliseconds since the Unix epoch."
Dit bestaat dus vooal in bson en json staat daar alleen om het simpel te houden. Als je measurements over de tijd wil opslaan, dan is het toch wel handig om een echt datetime type te hebben.

Ok, maar wie maakt er dan bson van de json en zet dan kennelijk toch een datatype?
Of wordt die timestamp alleen gebruikt voor de interne metadata van Mongo voor bijv een insert timestamp ?

In het kader van simpel houden: op dezelfde manier bedoel ik eigenlijk tegenwoordig vaak MariaDB waar ik Mysql zeg

Mjah mysql zou ik ook niet zo snel meer gebruiken, ben niet echt een Oracle enthousiast qua business ethiek.

[pedorus]

gekkie schreef op zondag 30 juli 2017 @ 22:58:
Ok, maar wie maakt er dan bson van de json en zet dan kennelijk toch een datatype?
Of wordt die timestamp alleen gebruikt voor de interne metadata van Mongo voor bijv een insert timestamp ?

Dit wordt door libraries vertaald met het Date type van de taal waar je in werkt. Dus bijvoorbeeld:

> db.measurements.insert({_id:new Date(), insideTemperature: 23.8, humidity: 59.0})
WriteResult({ "nInserted" : 1 })
> db.measurements.find()
{ "_id" : ISODate("2017-07-30T21:04:54.314Z"), "insideTemperature" : 23.8, "humidity" : 59 }

[Compizfox]

gekkie schreef op zondag 30 juli 2017 @ 22:58:
[...]
Mjah mysql zou ik ook niet zo snel meer gebruiken, ben niet echt een Oracle enthousiast qua business ethiek.

Dat is weer een heel verhaal apart natuurlijk, maar tegenwoordig is er MariaDB, wat een drop-in replacement is voor MySQL. Een hoop distro's gebruiken het al by default in plaats van MySQL.

[gekkie]

pedorus schreef op zondag 30 juli 2017 @ 23:07:
[...]

Dit wordt door libraries vertaald met het Date type van de taal waar je in werkt. Dus bijvoorbeeld:

> db.measurements.insert({_id:new Date(), insideTemperature: 23.8, humidity: 59.0})
WriteResult({ "nInserted" : 1 })
> db.measurements.find()
{ "_id" : ISODate("2017-07-30T21:04:54.314Z"), "insideTemperature" : 23.8, "humidity" : 59 }

Maar daar heb je dus weinig aan als je van ergens anders JSON vandaan krijgt en dat in je database moet gaan stoppen. Dan zou je dus eerst die JSON moeten ontleden en er waar nodig op een creatieve manier datatypes aan mee moeten geven. In dat geval moet je dus in je eigen code gaan parsen/casten, op basis van een semi los vast schema, alvorens te inserten. Op zich moet je dat toch als je netjes aan validatie doet, daar niet van. Maar ben je dan niet net zo ver van huis als met een RDBMS ?
(nou zit het probleem voornamelijk in JSON in dit geval omdat het een beperkt aantal datatypes kent)

[ Voor 3% gewijzigd door gekkie op 30-07-2017 23:34 ]

[jeroenk13]

Verwijderd schreef op zondag 30 juli 2017 @ 20:47:
[...]

eens

Sorry @jeroenk13; hoop dat het niet weer teveel verzand in persoonlijke meningen. Je legt een zeer fundamentele vraag neer voor veel database oplossingen; er is namelijk geen enkele database die ooit zou beweren "ik ben niet schikt voor grote volumes eenvoudige data". Je kan je oplossing in alle databases wel oplossen, elk op hun eigen manier (en binnen de SQL-familie op redelijk dezelfde manier).

De vraag is alleen welke het meest geschikt is. Als je extreem veel data hebt (10 miljard+ records) dan wordt het interessant. Dat is in jouw use case niet het geval. Dan zijn bestaande kennis, plezier en drang belangrijker.

Ik ken een half dozijn databases erg goed maar ik ken InfluxDB alleen van naam; desalniettemin lijkt mij dat een goede oplossing (hoewel ik dus zelf Cassandra voor een vergelijkbare use case gebruik).

Databases hebben allemaal hun quirks; je moet vooral kijken naar wat je wilt leren. Relationeel is dan altijd een goede keuze omdat het de lingua franca is; met die kennis begrijp je andere databases ook beter. De andere oplossingen zijn beter in sommige specifieke omstandigheden; maar met lage data volumes kun je er eigenlijk niet naast grijpen. Dan moet je je probleem binnen de tool zelf weten op te lossen.

Ik ga de discussie op m'n gemak even doorlezen en vergelijken.

Ik ben sowieso al van plan om alle DB's naast elkaar te gaan runnen en dan kijken welke mij het meeste bevalt qua gebruikservaring en opties.

[Creepy]

	Mysql	Cassandra
start snel op	Ja	Nee
data efficiënt weggeschreven	Ja	Nee
SQL tools bruikbaar	Ja	Nee
selecteer date range zonder full table scan	Ja	Nee
veel hergebruik van kennis	Ja	Nee

Mooie tool verder dat Cassandra voor Key-Value stores met bloom filter.

Misschien moet je je ff echt in Cassandra verdiepen voordat je een tabel dom vult met nee's

[Hydra]

Verwijderd schreef op zondag 30 juli 2017 @ 21:39:
Ik heb de schurft aan MongoDB. Ik zal het nooit voor een hobbyproject gebruiken. Maar het is een goede database. Punt.

Nee dat is het niet. Punt. Er is geen enkel ding waar Mongo goed in is, en het heeft een heleboel dingen waar het echt niet goed in is. Dit is de reden dat ze zich marketing als 'generieke' document store / database: ze hebben zoals anders NoSQL oplossingen geen sterke punten.

(disclosure; ik werkte voor Oracle Nederland toen ik MongoDB aanraadde voor de klant)

En? Ik heb tien jaar van m'n carriere voor een kleine Nederlandse database / search engine vendor gewerkt als integratie consultant. Naast dat ik daardoor vrij goed weet hoe databases werken heb ik ook met een hoop bedrijven samen mogen werken om hun zooi aan de onze te koppelen. In die hoedanigheid heb ik ook integraties gedaan met een paar klanten die Mongo gebruiken. Deze zijn hier later allemaal op teruggekomen toen ze erachter kwamen hoe erg je zaken als relaties, constraints, e.d. gaat missen.

Wel bijzonder dat je hier zo emotioneel onder wordt. Ik val Mongo aan (het bedrijf is ronduit onethisch), niet jou.

jeroenk13 schreef op zondag 30 juli 2017 @ 23:41:
Ik ben sowieso al van plan om alle DB's naast elkaar te gaan runnen en dan kijken welke mij het meeste bevalt qua gebruikservaring en opties.

Voor wat jij wil zijn er eigenlijk maar twee opties: een gespecialiseerde database (influx, prometheus) of gewoon een relationele database. Cassandra is leuk om mee te spelen maar voor wat jij wil niet bijzonder nuttig.

[ Voor 16% gewijzigd door Hydra op 31-07-2017 07:45 ]

[WhizzCat]

Heb je al eens gekeken naar b.v. http://www.blynk.cc/ ? Dit logt naar een CSV. I.c.m. b.v. een Wemos D1 kan je hier hele leuke dingen mee doen inc. een custom Interface via een App op je devices

(disclosure: heb lang niet alles gelezen, maar dit zou je misschien een hoop kopzorgen kunnen besparen).

[Dred]

TS wilt een makkelijke oplossing voor een hobby projectje, liefst iets waarvoor hij geen 24/7 server moet draaien, etc. Ik zie op zich 2 makkelijke oplossingen:
1) zoals de TS zelf aanhaalt een mysql op z'n synology. Niet moeilijker maken dan nodig...
2) AWS DynamoDB, volgens mij val je ruim binnen de free-tier met wat je wilt. (knal er een partition key in op date, dat zou je grootste performance problemen moeten weghelpen)

PS: Beide zullen werken, bij beide wil je misschien na x-tijd (kan een paar jaar zijn zelfs) eens je oude data moet verwijderen of consolideren voor performance/cost reden, maar dat is een goeie oefening for real life projecten.

[Woy]

Modbreak:

Kunnen we weer ontopic gaan, en de persoonlijke aanvallen en meta-discussie achterwege laten? Thanks

[pedorus]

Creepy schreef op zondag 30 juli 2017 @ 23:54:
[...]

Misschien moet je je ff echt in Cassandra verdiepen voordat je een tabel dom vult met nee's

Beetje jammer dat je niet aangeeft wat je precies bedoel

We hebben het draaien, maar wel 4 jaar geleden opgezet en weinig meer aan gedaan, dus dit was even snel op basis van eigen ervaringen. Inmiddels zijn er wel veel dingen verbeterd als ik zo zie (van 1.2 naar nu 3.11), maar behalve range queries kan ik me slecht voorstellen dat de meeste nee's geheel niet meer waar zijn. Long-term version support kan trouwens ook in de tabel.

En waarom zijn we niet up to date dan of zetten we het meer in?

quote: http://www.techrepublic.c...-on-polyglot-programming/

Why U no love polyglot?

Make no mistake: the cost is enormous. For example, while the idea of using the exact right database for a precise type of data seems right, the reality is that this approach means that developers are forced to learn a seemingly infinite number of databases.

Maar probeer het anders eens, Cassandra single node op een server met 1GB geheugen en een database van enkele jaren dummy data. Herstart die single node, en probeer met je favoriete SQL tool die data te benaderen. Kijk hoe snel het gaat of misschien zijn de nee's toch waar..

[ Voor 19% gewijzigd door pedorus op 31-07-2017 10:35 ]

[Hydra]

@pedorus: Het is niet bepaald een eerlijke vergelijking natuurlijk. Als je alleen Cassandra als single node gebruikt, heb je per definitie geen Cassandra nodig. En daarnaast is het natuurlijk ook raar om het kunnen benaderen van een NoSQL database vanuit een SQL client als criterium te hanteren (hoewel ik zelf overigens DBeaver gebruik, die support Cassandra). Cassandra is veel beperkter in mogelijkheden dan een generieke relationele database die in principe 'alles' kan. Hoe lang iets aan het opstarten is vind ik ook weinig relevant voor een database.

Voor het werk waar Cassandra voor bedoeld is, schaalt het linair. Dit ga je met geen enkele relationele database voor elkaar krijgen. Dat is de kracht van Cassandra. Als je dit niet nodig hebt, heb je Cassandra niet nodig en ben je beter af met iets als Postgres.

Waarvoor gebruiken jullie het precies?

[ Voor 3% gewijzigd door Hydra op 31-07-2017 10:36 ]

[pedorus]

Hydra schreef op maandag 31 juli 2017 @ 10:35:
Waarvoor gebruiken jullie het precies?

Het belangrijkste is een soort web cache. Dus de keys zijn hier urls, en de columns bevatten informatie over die urls. Omdat de working set van de data niet echt in het geheugen past zijn dingen als memcached/redis/mongodb niet handig. En B-tree-achtige SQL oplossingen zijn ook niet echt handig.

Qua databases is de keuze in onze polyglot-collectie verder Mysql/MariaDB/Postgres/SQL server/Memcached/Redis/MongoDB/Neo4J/Solr/Elasticsearch/Spark SQL. En dan reken ik nog even buiten de cloud varianten bij Google/Azure/AWS, en heb ik er vast nog wel wat vergeten. Maar helaas, al die tools zijn hier niet zo geschikt voor. Dus weer eentje erbij.. En dan komt waarschijnlijk nog iets als Druid er straks ook bij..

Wellicht is het begrijpelijk dat ik niet om een InfluxDB erbij zou staan te springen als MariaDB goed genoeg is..

[Hydra]

pedorus schreef op maandag 31 juli 2017 @ 11:40:
Het belangrijkste is een soort web cache. Dus de keys zijn hier urls, en de columns bevatten informatie over die urls. Omdat de working set van de data niet echt in het geheugen past zijn dingen als memcached/redis/mongodb niet handig. En B-tree-achtige SQL oplossingen zijn ook niet echt handig.

Daar is Cassandra in ieder geval prima geschikt voor.

Qua databases is de keuze in onze polyglot-collectie verder Mysql/MariaDB/Postgres/SQL server/Memcached/Redis/MongoDB/Neo4J/Solr/Elasticsearch/Spark SQL. En dan reken ik nog even buiten de cloud varianten bij Google/Azure/AWS, en heb ik er vast nog wel wat vergeten. Maar helaas, al die tools zijn hier niet zo geschikt voor. Dus weer eentje erbij.. En dan komt waarschijnlijk nog iets als Druid er straks ook bij..

Wellicht is het begrijpelijk dat ik niet om een InfluxDB erbij zou staan te springen als MariaDB goed genoeg is..

Yikes

[Antrax]

Ik vraag me nu eigenlijk af wat @Femme voor database gebruikt voor zijn sensoren (en andere informatie) in zijn huis. Misschien kan hij advies geven m.b.t. het opslaan van de sensor data?

[jeroenk13]

Antrax schreef op maandag 31 juli 2017 @ 13:42:
Ik vraag me nu eigenlijk af wat @Femme voor database gebruikt voor zijn sensoren (en andere informatie) in zijn huis. Misschien kan hij advies geven m.b.t. het opslaan van de sensor data?

Verwijderd schreef op zondag 30 juli 2017 @ 22:12:
[...]

Sorry eens.

Ik dacht na over 10-30 miljoen records in 3 jaar, dan loop je toch wel tegen enige beperkingen en misconfiguraties aan meestal maar niets dat idd opgelost kan worden in een MySQL.

Die kant gaan we misschien wel op... Hier beneden een update


Even een update:

Het projectje is inmiddels al iets uitgebreider geworden.

Het netwerk bestaat uit:

1. Master
2. Slave_1
3. [list]
4. Sensor T1 (temp binnen)
5. Sensor T2 (temp buiten)
6. Sensor TI (temp intern - behuizing waar de arduino nano in zit)
7. Sensor HI (vochtigheids sensor)
8. [/list]
9. Slave_2
10. [list]
11. Sensor T1 (temp boven)
12. Sensor T2 (temp beneden)
13. [/list]

Er werd al een suggestie gedaan om dubbele entries -als de temperatuur 2 metingen achter elkaar hetzelfde is- weg te laten om zo data te besparen.

Echter: hoe zit dat als je het bij deze opzet doet?: (En er komt nog een rij bij met de huidige tijd)



http://sqlfiddle.com/#!9/efd350/1


Is het leeglaten van vakjes dan ook een optie ? Of is het dan beter om met aparte tables te gaan werken ?


Over de hoeveelheid data;

Stel dat er iedere 15s een meting word gedaan, met alle 6 sensoren:

24 entries per minuut
1.440 per uur
34.560 per dag
12.614.400 per jaar...

Natuurlijk blijft de 'vochtigheids sensor' redelijk gelijk, hoeft de temperatuur binnen in de behuizing ook niet nauwkeurig (hele / halve getallen zijn ook goed), dus dan zit je al aan redelijk wat waardes die wegblijven.

Alleen laat je die vakjes leeg?
Of werk je dan met aparte tables zodat je daadwerkelijk een groot aantal rows / entries weg kan laten?

[ Voor 9% gewijzigd door jeroenk13 op 31-07-2017 14:30 ]

[CurlyMo]

jeroenk13 schreef op maandag 31 juli 2017 @ 14:28:
[...]
Echter: hoe zit dat als je het bij deze opzet doet?: (En er komt nog een rij kolom bij met de huidige tijd)

Er werd al een suggestie gedaan om dubbele entries -als de temperatuur 2 metingen achter elkaar hetzelfde is- weg te laten om zo data te besparen

Dat dit dus niet werkt

Wat al gesuggereerd is:

code:

id | temp
1  | 23,75
2  | 25,7
3  | 23
4  | 55

Enz.

Ontdubbel nu per id (= FK naar sensor tabel)

Aanvulling:

Je tweede meetmoment is dus dit:

code:

1  | 24,81
2  | 25,78

Omdat sensor 3 en 4 hetzelfde zijn gebleven.

[ Voor 11% gewijzigd door CurlyMo op 31-07-2017 14:38 ]

[Gomez12]

jeroenk13 schreef op maandag 31 juli 2017 @ 14:28:
[...]
Er werd al een suggestie gedaan om dubbele entries -als de temperatuur 2 metingen achter elkaar hetzelfde is- weg te laten om zo data te besparen.

Disk space is cheap. Hier moet je niet aan willen beginnen, dit gaat tot allerlei problemen leiden als bijv in de vakantie de stroom er een uurtje uitgaat (is het dan dezelfde temperatuur geweest of was je installatie offline)

Als je dit al zou willen doen dan zou ik historische tabellen aanleggen die gewoon een gemiddelde van elke 30 sec pakt, daarmee halveer je het aantal historische meldingen terwijl je niet allemaal vage logica gaat krijgen van : ik mis meetwaardes, betekent dat nu dat ik ze daadwerkelijk mis of dat ze gelijk waren?

Ander heel simpel alternatief is gewoon je metingen ook loggen naar txt. Dat valt heel simpel te comprimeren met zip en dan kan je experimenteren wat je wilt met je sample groottes van je db. Je hebt altijd de originelen nog.

[CurlyMo]

Gomez12 schreef op maandag 31 juli 2017 @ 14:46:
[...]

Disk space is cheap. Hier moet je niet aan willen beginnen, dit gaat tot allerlei problemen leiden als bijv in de vakantie de stroom er een uurtje uitgaat (is het dan dezelfde temperatuur geweest of was je installatie offline)

Hoe wil je die conclusie überhaupt trekken a.d.v. alleen temp. sensor data? De uitkomst is hetzelfde. Het is X minuten een bepaalde temperatuur geweest.

[jeroenk13]

Gomez12 schreef op maandag 31 juli 2017 @ 14:46:
[...]

Disk space is cheap. Hier moet je niet aan willen beginnen, dit gaat tot allerlei problemen leiden als bijv in de vakantie de stroom er een uurtje uitgaat (is het dan dezelfde temperatuur geweest of was je installatie offline)

Als je dit al zou willen doen dan zou ik historische tabellen aanleggen die gewoon een gemiddelde van elke 30 sec pakt, daarmee halveer je het aantal historische meldingen terwijl je niet allemaal vage logica gaat krijgen van : ik mis meetwaardes, betekent dat nu dat ik ze daadwerkelijk mis of dat ze gelijk waren?

Ander heel simpel alternatief is gewoon je metingen ook loggen naar txt. Dat valt heel simpel te comprimeren met zip en dan kan je experimenteren wat je wilt met je sample groottes van je db. Je hebt altijd de originelen nog.

Disc space is niet zozeer het probleem, de mogelijke prestatieproblemen na een jaar misschien wel.

Daarom probeer ik de aantal entries zo laag mogelijk te houden. Niet meer dan nodig

[BramV]

Misschien zelf eens een testdb maken met random entries (dat had je al 20x kunnen doen?) dan weet je het ? Je vraagt steeds om bevestiging van allerlei aannames die je zelf ook kunt testen...

bijv ik heb er zo testdata in 786432 row(s) affected Records: 786432 Duplicates: 0 Warnings: 0 7.406 sec
voor mysql stelt dat allemaal natuurlijk niet zoveel voor...

[ Voor 62% gewijzigd door BramV op 31-07-2017 15:01 ]

[termination]

Zolang je geen idioot zware queries met veel joins gaat bouwen en je je MySQL configuratie een beetje op orde hebt kan het heel lang aan met records aan tabellen toevoegen.
Tables van enkele gigabytes(!) kunnen prima performant draaien op MySQL/InnoDB.

[MSalters]

Misschien is het nuttig om hier nog eens de vuistregel van RDBMS'en te herhalen: query performance is een O(og N) probleem, mits met een bruikbare index.

1 miljoen records? Dat is 6 cijfers. 10 miljoen? 7 cijfers.

Storage kan een O(N) probleem zijn, maar dat moet je afzetten tegen multi-terabyte harde schijven.

[Hydra]

jeroenk13 schreef op maandag 31 juli 2017 @ 14:52:
Disc space is niet zozeer het probleem, de mogelijke prestatieproblemen na een jaar misschien wel.

Insert gewoon eens een jaar aan data. Dan weet je het. Ik denk dat je onderschat wat een relationele DB aankan.

Daarnaast kun je prima je aggregaties per uur of whatever in een aparte tabel opslaan en daarop querien natuurlijk.

[Creepy]

pedorus schreef op maandag 31 juli 2017 @ 10:31:
[...]

Beetje jammer dat je niet aangeeft wat je precies bedoel

Naar mijn idee zijn writes juist wel efficiënt (snel en data wordt (later) compressed), gaan range queries prima met de juiste index ( of desnoods een sasi index) en gaat opstarten snel genoeg. Maar opstart snelheid boeit echt niet met een Cassandra cluster aangezien het cluster in principe altijd online is.

Ik zie dat je 1 nee al aangepast hebt. Maar serieus, testen met 1 machine van 1gb? Als je geen cluster nodig hebt (omdat je niet wil/moet schalen op commodity hardware) gebruik dan geen Cassandra. Maar time based series gaan echt prima in een cluster dat "altijd " online is. Ja, redelijk offtopic omdat de TS het op een nas wil draaien. Maar starten met 1 node en daarna opschalen gaat dan wel weer.

[incaz]

jeroenk13 schreef op maandag 31 juli 2017 @ 14:28:
Er werd al een suggestie gedaan om dubbele entries -als de temperatuur 2 metingen achter elkaar hetzelfde is- weg te laten om zo data te besparen.

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.

Met 6 sensoren zou ik gaan normaliseren, dus 1 rij per meetpunt en een rij bevat alleen maar een timestamp, sensor-id en waarde. (Dus geen aparte kolommen per sensor.)

Dat sla je allemaal op, en daarna kun je gaan kijken hoe fijnmazig je je data wilt behouden over langere tijd.

[_Erikje_]

jeroenk13 schreef op maandag 31 juli 2017 @ 14:28:
[...]


Stel dat er iedere 15s een meting word gedaan, met alle 6 sensoren:

24 entries per minuut
1.440 per uur
34.560 per dag
12.614.400 per jaar...

Waarom zo'n hoge meetfrequentie? Elke 15s lijkt mij nogal onnodig vaak, 1 keer per minuut (of elke 5 minuten) lijkt mij voldoende

Daarnaast zijn 12M regels in de tabel geen enkel probleem. Met dit soort simpele data kan je veeeeeeeeel meer data kwijt.

[pedorus]

jeroenk13 schreef op maandag 31 juli 2017 @ 14:28:
12.614.400 per jaar...

Met een record van datetime (8 bytes primary key) + sensorId (4 bytes primary key) + waarde (float not null, 4 bytes?) + header = ~20 bytes. Zit je toch aan wel ~250 MB/jaar (excl. overhead/indexes) op een NASje met 1 GB geheugen en 3+ TB opslag ofzo? Dat is natuurlijk niet schokkend, als querien traag gaat kun je bijvoorbeeld ook een aggregatie per uur ofzo opslaan, dat is 1 query om te maken.

Creepy schreef op maandag 31 juli 2017 @ 17:52:
Maar serieus, testen met 1 machine van 1gb?

Die 1GB komt van de specs af van een enkel NASje zoals in de TS. Het gaat om enkele honderden MBs aan data per jaar (zie boven). Als je dan een oplossing hebt die zelfs voor dev 4GB geheugen wil, dan zet ik "Nee" bij "data efficiënt weggeschreven". Het is wel efficiënt weggeschreven, maar voor totaal andere problemen. Voor het idee, wij gebruiken het voor meer dan 1000x zoveel data, waar het voor gemaakt is..

(Heb er nu "geheugen-efficiënt voor case" van gemaakt, misschien duidelijker)

[Creepy]

Cassandra op je nas is zeker niet de beste keuze inderdaad. En met de data die de ts verwacht ook echt niet nodig inderdaad.

offtopic:
Overigens draait het prima met 1-2 GB hoor, afhankelijk van je dataset. Datastax overdrijft daar wel wat. Hun commerciële versie met search geïntegreerd is wel wat meer memory hungry.

[ Voor 45% gewijzigd door Creepy op 01-08-2017 12:14 ]

[Cloud]

_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

Uit de TS:

jeroenk13 schreef op donderdag 27 juli 2017 @ 21:04:
[...]
Het doel is om bepaalde temperatuur fluctuaties in kaart te brengen. Die 15s is maar een richtlijn, maar als je iedere 5min een meting doet dan mis ik hoogstwaarschijnlijk eventuele pieken die ik graag wel zou willen zien.
[...]