Omgaan met veel data

[Justinfailber]

Beste mede-Tweakers,

Omdat wij sinds een paar weken zonnepanelen hebben leek het mij leuk om de data in te lezen, dit kan bijvoorbeeld mooi met enelogics.
Toch heb ik daar echter mijn twijfels over omdat iemand anders toch precies kan zien hoeveel ik verbruik etc.

Daarom kwam ik op het idee om zelf iets kleins te ontwikkelen.

Het idee wordt dat ik via een cronjob elke 1-15 minuten de data ophaal via een raspberry pi vanuit mijn slimme meter, om het zo op te slaan in een MySQL database.

Het probleem waar ik een beetje mee zit is dat als je elke 15 minuten data opslaat in een database deze erg snel vol zou raken.

Weten jullie misschien een mooie oplossing voor dit probleem? En weten jullie misschien hoe bedrijven zoals enelogics dit doen?

Bijvoorbeeld:
1 dag = 1440 minuten / 15 minuten = 96 x per dag moet er data worden opgeslagen.

[Damic]

Veel data is normaal geen probleem, het is hoe je het opslaat (tabel grote e.d.) en hoe je het opvraagt.

[NMe]

Waarom is dit volgens jou veel data? MySQL kan prima overweg met miljoenen records en als je indexen goed staan kun je er nog snel op queryen ook. Als je daarna tegen problemen aanloopt wat betreft snelheid (of echt in de vele miljarden records per tabel terechtkomt) dan kun je altijd nog na X tijd alle data per dag/week/maand gaan aggregeren zodat je in plaats van 96 records per dag er nog maar 1 per dag/week/maand overhoudt.

Met 96 records per dag zit je over ruim 27 jaar pas aan de miljoen records, en dat is nog steeds peanuts voor MySQL...

[Voor 12% gewijzigd door NMe op 28-08-2015 13:11]

[Room42]

Je zou eens kunnen kijken naar de Logstash met Elasticsearch en Kibana. Dat is gericht op dit soort hoeveelheden.

[Voor 4% gewijzigd door Room42 op 28-08-2015 13:15]

[HMS]

Ik ben het met NMe eens, 1x per 15 minuten een row inserten is geen probleem. Experimenteren met een ELK stack is ook erg leuk, maar voor jouw use case lijkt mij je huidige setup voldoende.

[RobIII]

HMS schreef op vrijdag 28 augustus 2015 @ 13:14:
maar voor jouw use case lijkt mij je huidige setup voldoende.

Hoewel ik 't met bovenstaande reacties eens ben (96 records per dag is *peanuts*): ik lees nergens iets over de setup en 't maakt nogal wat verschil of we 't over een RaspberryPi hebben of over een fat-ass 32-core 386GB RAM "monster" van een server

[NMe]

RobIII schreef op vrijdag 28 augustus 2015 @ 13:19:
[...]

Hoewel ik 't met bovenstaande reacties eens ben (96 records per dag is *peanuts*): ik lees nergens iets over de setup en 't maakt nogal wat verschil of we 't over een RaspberryPi hebben of over een fat-ass 32-core 386Gb "monster" van een server

Er staat wel iets van een Raspberry Pi in de TS? Maar ook die zou voldoende moeten zijn voor dit lage aantal records per dag.

[RobIII]

NMe schreef op vrijdag 28 augustus 2015 @ 13:21:
Er staat wel iets van een Raspberry Pi in de TS?

* RobIII is scheel

NMe schreef op vrijdag 28 augustus 2015 @ 13:21:
Maar ook die zou voldoende moeten zijn voor dit lage aantal records per dag.

Jep.

[Wom]

Alles is relatief natuurlijk, maar 96 records per dag kan prima in een MySQL database. Geen idee hoeveel data er elke keer wordt opgehaald, maar zolang er genoeg schijfruimte is zou ik me niet druk maken

* Wom werkt in productieomgeving waar elke dag vele miljoenen records naar Oracle worden gepompt.

[Voor 21% gewijzigd door Wom op 28-08-2015 13:25]

[Damic]

Ik vermoed: index - tijd - opbrengst

[mclegodude]

ik heb een forum waar ruwweg 500 posts per dag bij kwamen op een pi2 gehost. dat wou prima. dus die schamele 96 records op een dag moet best kunnen

[Justinfailber]

@alle mensen

Ja ik ga een Raspberry Pi gebruiken.

Hoe snel is zo'n query dan als ik alle rows wil ophalen van 1 dag?
Dus 96 rows ophalen in een hele grote table.

[RobIII]

Justinfailber schreef op vrijdag 28 augustus 2015 @ 18:24:
Hoe snel is zo'n query dan als ik alle rows wil ophalen van 1 dag?

Doe eens gek en probeer het eens Insert gewoon voor een stuk of 10 jaar aan dummy data... ~350k records ofzo.

Justinfailber schreef op vrijdag 28 augustus 2015 @ 18:24:
Dus 96 rows ophalen in een hele grote table.

Sowieso is 't nogal afhankelijk van of je de juiste indexen maakt en gebruikt en hoe 'complex' je query verder is. Er is, op basis van de gegevens die we nu hebben, he-le-maal niets zinnigs te zeggen. En daarbij: definieer 'snel". Wil je 't binnen 0.05ms of is 100ms ook voldoende om "snel" te zijn?

[Justinfailber]

RobIII schreef op vrijdag 28 augustus 2015 @ 18:31:
[...]

Doe eens gek en probeer het eens Insert gewoon voor een stuk of 10 jaar aan dummy data... ~350k records ofzo.


[...]

Sowieso is 't nogal afhankelijk van of je de juiste indexen maakt en gebruikt en hoe 'complex' je query verder is. Er is, op basis van de gegevens die we nu hebben, he-le-maal niets zinnigs te zeggen. En daarbij: definieer 'snel". Wil je 't binnen 0.05ms of is 100ms ook voldoende om "snel" te zijn?

Ben het met je eens, ik ga het maar gewoon een keer testen

En snel is voor mij 0,5-1,5 seconden.

[NMe]

Dan moet je je al helemaal geen zorgen maken.

Je bent veel te vroeg met je optimalisatieslag. Soms is het niet erg om éérst tegen een probleem aan te lopen voordat je probeert het op te lossen.

[LennardF1989]

Daarnaast kan je altijd gaan voor een NoSQL database gaan als grote onbeheersbare data een probleem wordt. Maar vergeet niet dat je wel héél veel in SQL moet stoppen wil je een database van een paar gigabyte krijgen. Ik heb gigantische applicaties gezien met 20 jaar data erin, werkelijk miljoenen records met allemaal niet-genormaliseerde data, misschien wel rond de miljard, en de database was net-aan 6GB.

[Fish]

of ze verzamelen in 3 jaar 400GB oid

De case van de ts is echter peanuts, en dan alleen dat losse onderkantje wat uitsteekt

[The Eagle]

Wat bedrijven als Enelogics zelf doen is een Big Data infrastructuur neerzetten. Er is overigens niks op tegen om dat zelf ook op kleine schaal in een VM te doen. Of het op een Pi draait weet ik niet maar volgens mij moet het kunnen.
Wat je even kunt doen is naar Apache Flume kijken. Dat trap je 1x aan en dan heb je geen cronjob nodig ook. Kun je meteen op HDFS opslaan maar ook op disk als je wilt.
De hamvraag is denk ik meer hoeveel variatie er gaat zitten in de datastream die je van je sensor gaat krijgen. Als daarvan blijkt dat iedere regel verschillend is heb je wel een klein probleempje met je MySQL DB. Dan kun je beter Pig en Hive gebruiken.
Tip: check even bij Cloudera. Die leveren kant en klare VM's met hun big data stack. Kun je zo mee aan het prutsen

[Nibble]

1 Woord: Cassandra
Bloedsnel, precies hiervoor bedoeld en enorm schaalbaar.

[The Eagle]

Cassandra is vziw een NoSQL database die met name van toepassing is als je in verhouding meer dan 50% writes hebt. Nou schrijft ie veel, maar om daar nou meteen cassandra voor neer te zetten...
Bovendien heeft ie dan nog steeds geen manier om zinn data binnen te krijgen.
True, je zou bijvoorbeeld Flume naar cassandra kunnen laten schrijven. Maar met dit soort beperkte hoeveelheden data kun je willekeurig welke andere NoSQL pakken - of gewone RDBMS als de sensordata idd structured en structureel gelijk is.

[CubicQ]

Aangezien iedereen hierboven al heeft aangegeven dat 96x per dag geen probleem is, zal ik dat niet nog een keer doen

Als je perse toch ergens anders naar wilt kijken, kan je ook kijken naar een round-robin database (rrdtool etc). Dat is een databasetype bedoeld om logdata op te slaan, waarbij automatisch de granulariteit van oude data lager wordt. Dat zorgt ervoor dat je datahoeveelheid binnen de perken blijft en je toch lang kunt terugkijken.

[pedorus]

Nibble schreef op woensdag 02 september 2015 @ 11:15:
1 Woord: Cassandra
Bloedsnel, precies hiervoor bedoeld en enorm schaalbaar.

Wut, Cassandra precies hiervoor bedoelt? Lijkt me heel erg veel overhead geven in dit geval, die rijen zien er steeds hetzelfde uit, en de tijdstippen zijn bekend. Typisch een gevalletje waarbij een normale sql database het beter gaat doen. (Mits de tabelstructuur goed is.)

Een raspberry pi + mysql gaat prima <1 kb/min kunnen opslaan. Dat is helemaal niets. Echter, Cassandra die uiteindelijk in een keer iets weg gaat schrijven alsof je een echte server hebt, of rustig aan alle data doorneemt bij het opstarten na een crash (want verwacht redundancy van serverpark) zie ik de boel zomaar alsnog fors traag maken...

The Eagle schreef op woensdag 02 september 2015 @ 18:28:Maar met dit soort beperkte hoeveelheden data kun je willekeurig welke andere NoSQL pakken - of gewone RDBMS als de sensordata idd structured en structureel gelijk is.

Waarom NoSQL? Dat betekend vooral dat je geen SQL kan gebruiken op je data, terwijl dat juist zo handig is... Daarnaast gaat bijna iedere nosql database hier veel meer overhead geven op deze dataset.

Als een sql database zoals mysql niet goed genoeg is, maak dan gewoon een plat komma-gescheiden tekstbestand per maand en voeg iedere minuut een regel toe. Simpeler kan niet, en het is zelfs de default van Hive en je kunt het ook zo in mysql importeren..

[Richh]

MySQL kan, ook op een Raspberry Pi, verder prima iedere minuut data opslaan/query'en - over deze workload zou ik me zéker niet druk maken! In plaats van 15 minuten kan je het imo prima naar 1 minuut draaien. Qua schijfruimte gaat het toch om weinig data en je bent ten slotte de enige die aan de gegevens zit.

Ik heb voor een schoolprojectje eens wat moeten klooien met veel binnenkomende data (~700 gegevens per minuut) opslaan en exporteren naar leesbare grafieken. NoSQL was overigens ook niet toegestaan
Toen ben ik gaan wegschrijven naar platte text en daar om de paar minuten averages van gaan berekenen, om die vervolgens op te slaan in een MySQL database. In die case bleek die aanpak wel nuttig.

[Martinusz]

Ah leuk meetdata oftewel kwartierwaarden, ik werk bij een bedrijf die software levert om deze data te verwerken bij de energieleveranciers. Hier gaat het dus om duizenden aansluitingen die dagelijks elk kwartier data leveren.

Gezien je alleen je eigen data elk kwartier ophaalt, kun je wel even vooruit voordat je database erg groot wordt

[Gomez12]

Richh schreef op woensdag 02 september 2015 @ 21:04:
Ik heb voor een schoolprojectje eens wat moeten klooien met veel binnenkomende data (~700 gegevens per minuut) opslaan en exporteren naar leesbare grafieken. NoSQL was overigens ook niet toegestaan
Toen ben ik gaan wegschrijven naar platte text en daar om de paar minuten averages van gaan berekenen, om die vervolgens op te slaan in een MySQL database. In die case bleek die aanpak wel nuttig.

Wat is het toch tegenwoordig dat mensen geen idee meer hebben wat nou veel data is en wat een standaard RDBMS kan?

Waarom dit soort ingewikkelde constructies verzinnen of de veelgenoemde NoSQL constructies hierboven?

Bij een veelgebruikt programma als excel zou iedereen extreem raar staan te kijken en het zo ongeveer per direct afschrijven als het opslaan van 1 excel bestand met 700 regels per minuut zou gaan (als ik even de oude excel aanhou met 65.535 regels zou dus een "vol" bestand 1 1/2 uur duren om op te slaan) en dan hebben we het dus over een programma wat data moet tonen, kunnen bewerken en allerlei opmaak meuk naast de data zelf moet beheren terwijl het in de xlsx versie dat ook nog eens in een xml-formaat binnen een zip moet doen en dat allemaal op consumentenhardware.

Maar gaan we een gespecialiseerd programma gebruiken wat niet al die opsmuk erbovenop heeft van een excel dan moeten we opeens de hele trukendoos open gaan trekken, want oh jee, we gaan 700 rows per minuut erbij krijgen.
Terwijl een commodore 64 dat zo ongeveer al met 4 vingers in de neus aankon.

[Richh]

Gomez12 schreef op donderdag 03 september 2015 @ 00:26:
Verhaal

Ik heb de boel nog even nagezocht en het ging om 700 rows per seconde, zie ik nu

Anyhow, een gedeelte van de opdracht was om de bottleneck van het systeem te testen, en het hele idee van de opdracht was dat MySQL niet toereikend was voor de inkomende data, zodat je op zoek moest gaan naar alternatieven en te maken kreeg met file locks. Uit tests (op een VM uiteraard) bleek MySQL ook echt ontoereikend, er is echt niet voor niks voor die oplossing gekozen

[McKaamos]

Het enige waar ik me zorgen over zou maken is de levensduur van het SD kaartje in een Raspberry Pi.
Dat is misschien wel wat overdreven, maar ik zou zelf kijken voor een BananaPi, want die heeft een SATA aansluiting.
Daar hang je dan een 2,5inch (laptop) HDD of een goedkope SSD aan. Dat is allicht een langer leven beschoren dan een SD kaartje.

Verder lijkt me een Pi snel zát voor deze toepassing.
Een paar miljoen records is peanuts, en als het je écht dwars zit kan je nog records gaan verplaatsen naar andere tabellen. Historische data oid.
Als je de My.cnf goed instelt maakt MySQL per tabel een nieuw bestand, dus dan zitten je oude records je niet in de weg.
En die historische data kan je dan ook wegschrijven naar een MySQL DB op een NAS oid.

Edit: En je kan ook nog performance tweaken trouwens.
My.cnf kan je vol stouwen met allerlei tweaks voor optimale snelheid.
En je tables kan je sowieso in MyISAM en INNODB format doen. MyISAM leest sneller, INNODB schrijft sneller, naast nog wat andere verschillende features zoals diverse soorten locking, logging/rollbacks, etc. Maar die extra feats maken niet zoveel uit in dit geval.

[Voor 20% gewijzigd door McKaamos op 03-09-2015 07:39]

[celshof]

Justinfailber schreef op vrijdag 28 augustus 2015 @ 13:02:
Beste mede-Tweakers,

Omdat wij sinds een paar weken zonnepanelen hebben leek het mij leuk om de data in te lezen, dit kan bijvoorbeeld mooi met enelogics.
Toch heb ik daar echter mijn twijfels over omdat iemand anders toch precies kan zien hoeveel ik verbruik etc.

Daarom kwam ik op het idee om zelf iets kleins te ontwikkelen.

Het idee wordt dat ik via een cronjob elke 1-15 minuten de data ophaal via een raspberry pi vanuit mijn slimme meter, om het zo op te slaan in een MySQL database.

Het probleem waar ik een beetje mee zit is dat als je elke 15 minuten data opslaat in een database deze erg snel vol zou raken.

Weten jullie misschien een mooie oplossing voor dit probleem? En weten jullie misschien hoe bedrijven zoals enelogics dit doen?

Bijvoorbeeld:
1 dag = 1440 minuten / 15 minuten = 96 x per dag moet er data worden opgeslagen.

Buiten dat zelf doen heel leuk is natuurlijk, met https://energiemanageronline.nl/ kun je ook je slimme meter laten uitlezen en de gegevens zijn alleen voor jou toegankelijk.
En als je je omvormer kan (laten) uitlezen, dan moet je ook zeker eens naar http://pvoutput.org/ kijken.

[Croga]

celshof schreef op donderdag 03 september 2015 @ 07:43:
Buiten dat zelf doen heel leuk is natuurlijk, met https://energiemanageronline.nl/ kun je ook je slimme meter laten uitlezen en de gegevens zijn alleen voor jou toegankelijk.

Het staat online. Het is dus per definitie niet alleen voor jou toegankelijk.
Uiteraard is niets "alleen voor jou toegankelijk" maar zodra het de modem-barriere voorbij is maak je het meteen veel toegankelijker voor de rest van de wereld.

[Sissors]

McKaamos schreef op donderdag 03 september 2015 @ 07:35:
Het enige waar ik me zorgen over zou maken is de levensduur van het SD kaartje in een Raspberry Pi.

Wat is daar het probleem dan van? Je logt data, oftewel je bestand wordt enkel groter, dus het is niet dat je steeds hetzelfde stuk flash overschrijft. En we hebben het dan dus over een bestand dat echt 3x niks is qua grootte de eerste 10 jaar.

Croga schreef op donderdag 03 september 2015 @ 07:48:
[...]

Het staat online. Het is dus per definitie niet alleen voor jou toegankelijk.
Uiteraard is niets "alleen voor jou toegankelijk" maar zodra het de modem-barriere voorbij is maak je het meteen veel toegankelijker voor de rest van de wereld.

Ik vind persoonlijk dat de gevaren dan wel heel erg vergezocht zijn (een inbreker gaat die servers hacken zodat hij kan kijken wanneer je niet thuis bent? Daar zijn makkelijkere methodes voor).

[Voor 37% gewijzigd door Sissors op 03-09-2015 08:44]

[pedorus]

Richh schreef op donderdag 03 september 2015 @ 01:21:
Ik heb de boel nog even nagezocht en het ging om 700 rows per seconde, zie ik nu

Anyhow, een gedeelte van de opdracht was om de bottleneck van het systeem te testen, en het hele idee van de opdracht was dat MySQL niet toereikend was voor de inkomende data, zodat je op zoek moest gaan naar alternatieven en te maken kreeg met file locks. Uit tests (op een VM uiteraard) bleek MySQL ook echt ontoereikend, er is echt niet voor niks voor die oplossing gekozen

700 rows per seconde kan makkelijk, maar je moet ze dan niet per stuk achter elkaar willen wegschrijven en steeds bevestiging willen hebben dat een row naar een fysieke harde schijf is geschreven voordat de call terugkomt. Of je hebt extreem grote regels/indexes, wat ook fout gebruik is. Dit doet me vooral denken dat de manier van wegschrijven + instellingen van mysql/OS niet goed waren.

[celshof]

Sissors schreef op donderdag 03 september 2015 @ 08:43:
[...]

Ik vind persoonlijk dat de gevaren dan wel heel erg vergezocht zijn (een inbreker gaat die servers hacken zodat hij kan kijken wanneer je niet thuis bent? Daar zijn makkelijkere methodes voor).

En dan moet hij ook nog het weerbericht in de gaten houden, want zonnepanelen verstoren flink de bruikbaarheid van de gegevens die uit de slimme meter rollen.

[Croga]

Sissors schreef op donderdag 03 september 2015 @ 08:43:Ik vind persoonlijk dat de gevaren dan wel heel erg vergezocht zijn (een inbreker gaat die servers hacken zodat hij kan kijken wanneer je niet thuis bent? Daar zijn makkelijkere methodes voor).

TS geeft aan dat hij geen cloud service wil gebruiken omdat hij het in eigen beheer wil houden. Een andere cloud service voorstellen helpt TS dan ook niet.

[Creepy]

Richh schreef op donderdag 03 september 2015 @ 01:21:
[...]

Anyhow, een gedeelte van de opdracht was om de bottleneck van het systeem te testen, en het hele idee van de opdracht was dat MySQL niet toereikend was voor de inkomende data, zodat je op zoek moest gaan naar alternatieven en te maken kreeg met file locks. Uit tests (op een VM uiteraard) bleek MySQL ook echt ontoereikend, er is echt niet voor niks voor die oplossing gekozen

Toch gek. Op een server van 3 jaar oud met een HDD erin schrijf ik hier makkelijk 700 rows/s weg. Je zou niet de eerste zijn die domweg losse queries doet en commit per query (row) dus vergeet niet dat er ook zoiets bestaat als batched queries. Zie https://dev.mysql.com/doc...db-bulk-data-loading.html. MySQL kan makkelijk 700 rows per seconde aan op gewone hardware. Op een beetje nieuwe server met een SSD erin nog veel meer.

[Justinfailber]

Ondertussen een testje gedaan,

105120 rows aan fake data in een table gegooit en daarna wat query's er op los gelaten om de betreffende data van 1 dag weer op te vragen.

Ging allemaal lekker vlot en altijd onder 1 seconde dus dat moet wel goed komen.

Ik kan eventueel altijd nog de boel elk jaar overzetten.


@mensen die zeiden dat ik het bij pvoutput.org moet doen enzo,

De bedoeling is juist dat ik het in eigen beheer hou zonder dat een derde partij alles kan zien.

[armageddon_2k1]

Leuke verhalen hier en bizar hoe snel men denkt dat iets veel data is

Ik log zelf met mijn RPI mijn gas, water en licht en tijdens de debugperiode sample'de ik met 10Hz (de timing van de RPI is niet zo accuraat, maar het kwam er in de buurt), voor 1 week 3 IR sensoren die een vlakje moesten meten van de 3 meters. Dit waren dus 30 metingen per seconde van een byte op een RPI en die sloeg ik op in SQLite via Python. De RPI had daar ab-so-luut geen moeite mee! Ik verzamelde 1 minuut aan data en dat sloeg ik bulk op, wat weer scheelde met het aantal queries.

Even voor de duidelijkheid, dat zijn dus: 10 * 3 * 60 * 60 * 24 * 7 = 18144000 = 18 miljoen metingen. Dat is dus maar een fractie van de 2^64 rijen die SQLite aankan (http://www.sqlite.org/limits.html).

Ik had een 16GB usb stick erin geplugd en mijn DB was uiteindelijk iets van 300MB geworden en aardig snel te querien (<1 sec).
Heck, hier op het werk hebben we een RPI die een meting doet op 1000Hz (wel via een extern bordje die via USB is aangesloten) en daar meten we 1 uur, wat ook echt geen probleem is.

[Voor 15% gewijzigd door armageddon_2k1 op 03-09-2015 13:12]

[Hydra]

Creepy schreef op donderdag 03 september 2015 @ 09:45:
Toch gek. Op een server van 3 jaar oud met een HDD erin schrijf ik hier makkelijk 700 rows/s weg. Je zou niet de eerste zijn die domweg losse queries doet en commit per query (row) dus vergeet niet dat er ook zoiets bestaat als batched queries. Zie https://dev.mysql.com/doc...db-bulk-data-loading.html. MySQL kan makkelijk 700 rows per seconde aan op gewone hardware. Op een beetje nieuwe server met een SSD erin nog veel meer.

Dat kun je niet zo eenvoudig stellen. In de basis is het wegschrijven van data in een SQL database gewoon IO bound met een heel klein beetje overhead. Wat 'duur' is is het bijwerken van indices: het continue herbalanceren van die b-trees is relatief duur, zelfs als je het in batches doet. Of het voor een machine 'moeilijk' is een bepaalde performance te verkrijgen is dus vooral afhankelijk van het aantal indices. Boven een bepaald aantal is het efficienter de indices gewoon te droppen en deze na het batch-inserten weer aan te maken.

[Creepy]

Eens, maar om domweg te zeggen dat MySQL niet geschikt is om 700 rows / seconde te verwerken kan je ook niet zo eenvoudig stellen

[Black Eagle]

Wij hebben een scada systeem ontwikkeld dat o.a. alle informatie van de gemalen bij gemeenten verzameld en opslaat in een MySQL database. Je moet er vanuit gaan dat elk gemaal bijhoud hoeveel stroom de pompen verbruiken, waterstand, overstort, debiet, etc. Afhankelijk van de PLC wordt dit elke 1/5min gelogd (sommige gevallen elke xx seconden). Uitgaande van ~21 tags per PLC zijn dit zo'n 30.000 records p/gemaal p/dag. Afhankelijk van de grote van de gemeente heeft deze zo'n 30-500 gemalen staan. Sommige database's zijn nu enkele 10 tallen GB's, de rapportage's over deze trend data is nog steeds snel, ondanks dat alles in 1 tabel wordt gezet (wel met de juiste indexen).

[pedorus]

Hydra schreef op donderdag 03 september 2015 @ 13:16:
[...]


Dat kun je niet zo eenvoudig stellen. In de basis is het wegschrijven van data in een SQL database gewoon IO bound met een heel klein beetje overhead. Wat 'duur' is is het bijwerken van indices: het continue herbalanceren van die b-trees is relatief duur, zelfs als je het in batches doet. Of het voor een machine 'moeilijk' is een bepaalde performance te verkrijgen is dus vooral afhankelijk van het aantal indices. Boven een bepaald aantal is het efficienter de indices gewoon te droppen en deze na het batch-inserten weer aan te maken.

Klopt, maar als je zodanig veel records hebt dat de indices een probleem worden om aan te passen, dan kun je in mysql nog altijd de tabel partitioneren om de indices op te splitsen. Je hebt gewoon zeer waarschijnlijk ergens iets fout gedaan als 700 rows/sec niet lukt, dat durf ik wel zo te stellen.

[The Eagle]

Die 700 rows/sec was voor een schoolprojectje. Dikke kans dat de docent in kwestie wel wat van MySQL wist, maar echt geen guru was. Oftewel: het was hem zelf niet gelukt en dus mochten zijn studenten naar een betere oplossing zoeken

En uiteraard kun je zaken als partitioning op je tables en indexes gaan toepassen, maar dat is helemaal afhankelijk van hoe je dataset er uit ziet. Dus daar valt van hier af weinig over te zeggen.
Saillant detail trouwens: als je bij Oracle met partitioning aan de gang wilt heb je de Enterprise Edition nodig. Wordt standaard niet eens ondersteund

[RobIII]

Sissors schreef op donderdag 03 september 2015 @ 08:43:
[...]

Wat is daar het probleem dan van? Je logt data, oftewel je bestand wordt enkel groter, dus het is niet dat je steeds hetzelfde stuk flash overschrijft.

Even wat mierenneuken / offtopic maar toch: besef wel dat 't ook zeer waarschijnlijk geen simpele 'append' is op de file bij elk record dat je weg schrijft. Het mooie van een RDBMS is dat je kunt zeggen: "hier heb je een kwak data, sla maar op, veel plezier ermee, don't care how". Een beetje RDBMS schrijft data niet "simpelweg achteraan" weg maar werkt vaak met pages van x KB. Een enkel record inserten kan dus resulteren in 't ophalen van een complete page aan data (zeg 64 KB) en 't daarna wegschrijven van de complete page. Zolang de data allemaal op dezelfde page terecht komt (her)schrijf je dus telkens dezelfde complete 64Kb. En dan heb je 't nog niet gehad over "onderliggende" filesystem implementaties die mogelijk weer blokken van 4kb hanteren of write-caching en whatnot. Of indices die (ook) bijgewerkt moeten worden (en dus weer andere pages (her/be)schreven moeten worden (zie ook deze post). Enz. enz. En dat verhaal wordt dan weer (deels) teniet gedaan door al-dan-niet aanwezige wear leveling bijv. Al-met-al komt er dus iets meer bij kijken en is het dus lastig te stellen hoeveel een kaart er uiteindelijk onder 'lijdt'

Je punt is verder IMHO wel valide; ik zou me ook niet druk maken over 't 'stuk schrijven' van het flashgeheugen (en wat kost 't nou helemaal... zorg gewoon voor een goede backup...), ik wou alleen maar even aangeven dat 't allemaal nét wat ingewikkelder in elkaar steekt dan een simpele "nieuwe data => achteraan wegschrijven".

[Voor 15% gewijzigd door RobIII op 03-09-2015 14:54]

[Sissors]

Om mee te beginnen, mijn kennis van DB systemen is nul, dus mogelijk zit ik ernaast .

Maar het lijkt mij toch dat zo'n systeem juist gemaakt is om niet elke keer dat je een row toevoegt dat hij een hele zooi data ophaalt, één regeltje aanpast, en dan weer een hele zooi terugschrijft. Dat lijkt me niet bepaald efficient. Dan zou ik het gewoon in een csv file wegschrijven .

Want dit lijkt me ook het makkelijkst mogelijke database systeem: Je voegt enkel sequentieel rijen toe. Wear leveling zal het enkel beter maken, en ik ging ervan uit dat een write cache wel ingeschakeld is. Maar ook zonder dat, en wat je ook schreef: Hierbij hoef je je echt geen zorgen te maken over levensduur van je flash kaartje.

[Jegorex]

Sissors schreef op donderdag 03 september 2015 @ 15:02:
Om mee te beginnen, mijn kennis van DB systemen is nul, dus mogelijk zit ik ernaast .

Maar het lijkt mij toch dat zo'n systeem juist gemaakt is om niet elke keer dat je een row toevoegt dat hij een hele zooi data ophaalt, één regeltje aanpast, en dan weer een hele zooi terugschrijft. Dat lijkt me niet bepaald efficient. Dan zou ik het gewoon in een csv file wegschrijven .

Want dit lijkt me ook het makkelijkst mogelijke database systeem: Je voegt enkel sequentieel rijen toe. Wear leveling zal het enkel beter maken, en ik ging ervan uit dat een write cache wel ingeschakeld is. Maar ook zonder dat, en wat je ook schreef: Hierbij hoef je je echt geen zorgen te maken over levensduur van je flash kaartje.

Als je een lijst hebt met gebruikers en je wilt iedereen die Piet heet eruit halen, dan zul je op jouw manier de hele lijst moeten doorzoeken.
Het zal veel efficiënter zijn als de lijst alfabetisch is. Daarvoor zul je dus nieuwe gebruikers ergens midden in de lijst moeten toevoegen.

[RobIII]

Jegorex schreef op donderdag 03 september 2015 @ 15:05:
[...]

Als je een lijst hebt met gebruikers en je wilt iedereen die Piet heet eruit halen, dan zul je op jouw manier de hele lijst moeten doorzoeken.
Het zal veel efficiënter zijn als de lijst alfabetisch is. Daarvoor zul je dus nieuwe gebruikers ergens midden in de lijst moeten toevoegen.

Euh; nu heb je 't meer over iets dat neigt naar indices (die ook in pages worden opgeslagen overigens) en niet zo zeer ("append-only" of niet) tabellen; bij die laatste zal niet gauw iets "tussengevoegd" worden (tenzij je een "clustered" index gebruikt, in jouw voorbeeld dan op naam). Je zult je wat meer moeten verdiepen in RDBMS'es om het fijne ervan te snappen (en 't waarom), maar als je googled op pages (en/of "extents") in combinatie met RDBMS dan is er wel e.e.a. over te vinden. Maar goed, het is verder ook niet héél relevant in dit topic. Lang leve abstractie. Gewoon inserten en boeie hoe je RDBMS / FileSystem / OS / Controller / Flashkaart en whatnot 't oplost

[Voor 12% gewijzigd door RobIII op 03-09-2015 15:17]

[Jegorex]

RobIII schreef op donderdag 03 september 2015 @ 15:13:
[...]

Euh; nu heb je 't meer over iets dat neigt naar indices (die ook in pages worden opgeslagen overigens) en niet zo zeer ("append-only" of niet) tabellen; bij die laatste zal niet gauw iets "tussengevoegd" worden (tenzij je een "clustered" index gebruikt, in jouw voorbeeld dan op naam). Je zult je wat meer moeten verdiepen in RDBMS'es om het fijne ervan te snappen (en 't waarom), maar als je googled op pages (en/of "extents") in combinatie met RDBMS dan is er wel e.e.a. over te vinden. Maar goed, het is verder ook niet héél relevant in dit topic. Lang leve abstractie. Gewoon inserten en boeie hoe je RDBMS / FileSystem / OS / Controller / Flashkaart en whatnot 't oplost

Sorry, ik zal inderdaad aan indices te denken.

[Sissors]

Jegorex schreef op donderdag 03 september 2015 @ 15:05:
[...]

Als je een lijst hebt met gebruikers en je wilt iedereen die Piet heet eruit halen, dan zul je op jouw manier de hele lijst moeten doorzoeken.
Het zal veel efficiënter zijn als de lijst alfabetisch is. Daarvoor zul je dus nieuwe gebruikers ergens midden in de lijst moeten toevoegen.

Dat is een algemene situatie, ik bedoelde specifiek hier waar enkel elke X tijd een nieuwe rij aan de onderkant wordt toegevoegd.

[McKaamos]

Sissors schreef op donderdag 03 september 2015 @ 08:43:
[...]

Wat is daar het probleem dan van? Je logt data, oftewel je bestand wordt enkel groter, dus het is niet dat je steeds hetzelfde stuk flash overschrijft. En we hebben het dan dus over een bestand dat echt 3x niks is qua grootte de eerste 10 jaar.


[...]

Ik vind persoonlijk dat de gevaren dan wel heel erg vergezocht zijn (een inbreker gaat die servers hacken zodat hij kan kijken wanneer je niet thuis bent? Daar zijn makkelijkere methodes voor).

Ja, dan denk je alleen aan de data die je wegschrijft voor het doel waar je de Pi voor inzet.
Maar er draait ook een OS op het ding. Die kan ook nog van alles loggen, logrotations (dus steeds ruimte vrijmaken en weer overschrijven), temporary files, temptables, noem t maar... SD kaartjes hebben geen slimme wear leveling zoals een SSD dat heeft.

Dus sja, ik zou er over in zitten als ik het niet eerst zou meten.
Met een HDD of SSD is het sowieso geen issue iig.
SD kaartje is voor mijn gevoel in ieder geval niet zo stabiel/bedrijfszeker.

[Sissors]

Maar dat is algemeen aan een Raspberry, en niet specifiek voor deze toepassing.

Sowieso heeft een gedeelte van de SD kaarten wel wear levelling ingebouwd. (Waarschijnlijk wat dommer dan een SSD, maar de basis is er). Algemeen gesproken zijn er sowieso zat mensen die een Raspberry heel lang laten lopen zonder enig probleem, en dan is die ook aan het loggen, temp files, etc.

Als laatste: Het is hier wat loggen van zijn energieverbruik. Oftewel als dat ding na een paar jaar zijn SD kaart kapot heeft gemaakt, dan is dat jammer, maar niet meer dan dat.

[CurlyMo]

Net zoals velen denken dat ze al snel veel data in een database zetten geldt hetzelfde voor het gebruik van SD kaarten. Als oud XBian ontwikkelaar heb ik in 2 jaar echt veel data geschreven naar mijn SD kaart. Na twee jaar werkte dat ding nog prima. Alleen het plastic van de SD kaart ging kapot door het vele in en uithalen van de kaart. Een RPi in een meterkast die je niet meer aanraakt gaat het echt prima 10 jaar doen met de load die je voor ogen hebt.