python data bijhouden voor grafiek file based?

[bucovaina89]

Ik zou met Python ooit iets simpel en file-based willen maken wat bijvoorbeeld actuele opbrengst van zonnepanelen bij houdt, of actueel verbruik, of hoeveel water er in de regenwaterput zit, temperatuur buiten. De data die ik ooit terug zou willen is bijvoorbeeld een simpele web-pagina met grafiekjes. Het is een huis/tuin/keuken toepassing, dus geen Enterprise performance/stabiliteit nodig. Als een grafiek 15 seconden nodig heeft om te laden ben ik daar perfect gelukkig mee.

Wat ik expliciet niet zou willen is MySQL/andere DB dependency inbouwen. Specifiek om backup simpel te houden.

Maar dus, als "database-backend" zou je daar eenvoudig CSV voor kunnen gebruiken? Het zou trouwens ook perfect OK zijn om de .CSV files te splitsen per jaar/maand/... en desnoods files ouder dan x te gaan zippen als de grootte per bestand uit de hand loopt. Ik vermoed dat het relatief eenvoudig is om die achteraf terug te joinen if need be.

Wat zijn de mogelijke redenen om vooral niet CSV te gaan? En zijn er misschien nog alternatieven die ook file based zijn en "beter" dan CSV?

[Matis]

Lees https://www.valentina-db....why_excel_isnt_a_database eens door.

Als je toch een "file based" (lees lokale) database wilt, kun je kijken naar SQLite

Dit slaat een databasebestand op naast / in je project.

[JackBol]

bucovaina89 schreef op woensdag 30 december 2020 @ 08:31:
Ik zou met Python ooit iets simpel en file-based willen maken wat bijvoorbeeld actuele opbrengst van zonnepanelen bij houdt, of actueel verbruik, of hoeveel water er in de regenwaterput zit, temperatuur buiten. De data die ik ooit terug zou willen is bijvoorbeeld een simpele web-pagina met grafiekjes. Het is een huis/tuin/keuken toepassing, dus geen Enterprise performance/stabiliteit nodig. Als een grafiek 15 seconden nodig heeft om te laden ben ik daar perfect gelukkig mee.

Wat ik expliciet niet zou willen is MySQL/andere DB dependency inbouwen. Specifiek om backup simpel te houden.

Maar dus, als "database-backend" zou je daar eenvoudig CSV voor kunnen gebruiken? Het zou trouwens ook perfect OK zijn om de .CSV files te splitsen per jaar/maand/... en desnoods files ouder dan x te gaan zippen als de grootte per bestand uit de hand loopt. Ik vermoed dat het relatief eenvoudig is om die achteraf terug te joinen if need be.

Wat zijn de mogelijke redenen om vooral niet CSV te gaan? En zijn er misschien nog alternatieven die ook file based zijn en "beter" dan CSV?

Je bent minder tijd kwijt om te leren hoe je SQL goed kan gebruiken en backuppen dan alle file based data-consistency in je app te ontwikkelen. De 80% van je code zal lees-schrijf gerelateerd zijn en je bent feitelijk een database connector aan het nabouwen.

[JJ16v]

Uhm, misschien gewoon domoticz gaan gebruiken, die kan precies dit

[Kalentum]

Als je use case beperkt blijft tot 'toon huidig gebruik voor 1 maand' ofzo dan is CSV prima.

Maar met filebased data store verlies je flexibiliteit, bv als je gegevens wil combineren ('gemiddeld verbruik per dag') dan moet je al snel door files heen loopen en berekeninginen in code doen terwijl een DBMS dat veel sneller kan (joins, indexen)

En als je eenmaal al die data aan het verzamelen bent dan wil je al snel meer dan alleen maar weergeven in een tabel of grafiek. En dan denk je al snel 'had ik maar een database'

Ik sla allerlei data (waaronder zonnepanelen) op in een PostgreSQL database die draait op Ubuntu. Met behulp van autopostgresqlbackup (een pakketje uit de Ubuntu repos) maak ik een dagelijkse backup. En die backup loopt mee in de file-based backup die ook dagelijks loopt. Het is set-and-forget en niet moeilijk.

Dus ik vermoed dat je beter nu de stap naar een 'echte' database kan maken want die files voldoen wel voor nu maar waarschijnlijk ben je er over 2 weken al zat van...

[RobIII]

Los van wat hierboven allemaal al gezegd is mis je bij een CSV ook het gemak om allerlei 'views' op je data te maken waarbij je gebruik maakt van een sum, average, max, min, etc. Al die dingen zul je in code moeten implementeren - en ook dat is geen rocketscience maar het tikt wel allemaal aan bovenop wat eerder al gezegd is. Je zult heel wat abstracties moeten verzinnen/maken/bouwen die een RDBMS (of een TSDB) voor je doen.

Als het je puur om de backup te doen is is het onzin om daar een compleet "filesystem based database in CSV" voor te gaan bouwen; je hoeft maar 1 commando te leren om een, zeg, MySQL backup te maken.

[ Voor 32% gewijzigd door RobIII op 30-12-2020 09:54 ]

[bucovaina89]

OK thanks voor de duidelijke antwoorden. Misschien moet ik toch maar MySQL een kans geven.

[Morrar]

bucovaina89 schreef op woensdag 30 december 2020 @ 12:59:
OK thanks voor de duidelijke antwoorden. Misschien moet ik toch maar MySQL een kans geven.

Zoals eerder geopperd zou ik ook eerst naar Sqlite kijken. Dat zit ingebouwd in Python, is file based en daarmee extreem makkelijk te implementeren. Je hebt dan geen gedoe met apart database server installeren, connectie opzetten, authenticatie, et cetera.

Verder is SQLite redelijk feature complete, alleen niet enterprise ready. Maar zolang je maar 1 connectie maakt zou het prima moeten gaan. Lijkt me afdoende voor jouw project.

Als je later wilt opschalen, kun je altijd nog naar PostgreSQL / MariaDB / MySQL kijken (in die volgorde zou ik zeggen). Aangezien je met SQLite toch al in SQL werkt, is de aanpassing qua code minimaal.

Tot slot zou een timeseries DB ook nog een optie kunnen zijn. Verder zou ik pandas gebruiken om je data te verwerken in Python. Qua plotten zijn plotly / plotnine / streamlit of dash wel goede packages.

Succes!

[mkleinman]

En voor je zonnepanelen bijhouden kijk eens naar jSunnyreports. Die leest logfiles in en creeert een hele vracht aan charts voor je.

Voorbeeldje: http://trinity.familie-kleinman.nl/v2

[Verwijderd]

Je zou als file een Json kunnen gebruiken. De meeste chartplotters werken al met Json. Maar je moet dan wel zoals hierboven gemiddeldes en sommen e.d. coderen

[Rukapul]

Verwijderd schreef op donderdag 31 december 2020 @ 18:36:
Je zou als file een Json kunnen gebruiken. De meeste chartplotters werken al met Json. Maar je moet dan wel zoals hierboven gemiddeldes en sommen e.d. coderen

Voor data als dit is er nul voordeel van json boven CSV.

Voor deze toepassing werkt CSV waarschijnlijk prima. Met 1-2 regels lees je de hele zooi in een Pandas dataframe. Vervolgens selecteer je met een oneliner de data en plot je die met nog een paar regels mbv matplotlib.

Op het moment dat de data te groot wordt voor puur in memory kun je denken aan een optimalisatie of andere aanpak. Maar met een datapunt per minuut ofzo kom je daar niet aan.

[Ben(V)]

Je zou met python gewoon een excel spreadsheet kunnen vullen.
Je kunt daar openpyxl voor gebruiken.

En data in excel kun je erg makkelijk in allerlei formaten tonen en bewerken inclusief grafieken maken.

[Janoz]

Ik denk dat @Ben(V) nog even de reactie van @Matis moet lezen . Daarnaast bied wegschrijven in een excel file geen enkel voordeel boven een CSV file. Die laatste kun je imers ook gewoon in excel inlezen waarna je alsnog al die grafiekjes kunt maken. CSV heeft vervolgens wel weer als voordeel dat hij makkelijk te updaten is. Nieuwe records kunnen gewoon ge-append worden ipv dat het hele bestand bij elke update opnieuw geschreven moet worden.


Maar op terug te komen op het originele issue. Ik weet dat de TS liever geen afhankelijkheden heeft, maar voor deze specifieke usecase is het ook een idee om naar een Time-Series oplossing te kijken zoals influxdb. Die zijn speciaal bedoeld voor dit soort tijdreeksen (tijdstip -> meetwaarde).

[ Voor 34% gewijzigd door Janoz op 04-01-2021 13:55 ]

[Ben(V)]

Geen idee waarom jij denkt dat een csv file voordeel heeft boven native excel file, maar beiden kun je gebruiken.
En als je openpyxl gebruikt is updaten net zo eenvoudig, inclusief appenden.

En uiteraard kun je ook sqlite gebruiken, maar hij wilde geen database en sqlite heeft geen presentatie mogelijkheden en andere functionaliteiten die in dit kader erg handig kunnen zijn.

[Janoz]

Ben(V) schreef op maandag 4 januari 2021 @ 13:26:
Geen idee waarom jij denkt dat een csv file voordeel heeft boven native excel file, maar beiden kun je gebruiken.
En als je openpyxl gebruikt is updaten net zo eenvoudig, inclusief appenden.

Dat is het niet en dat heeft alles te maken met het formaat.

Als je een record toevoegd aan een CSV bestand hoef je je bytes alleen maar aan het einde van het bestand toe te voegen. Je opent het bestand in append mode en schrijft je gegevens weg. Zolang je vaak genoeg flushed of telkens je handle closed zal het bestand altijd bruikbaar zijn.

Wil je een record toevoegen aan je excelfile dan zul je in het meest gunstigste geval een deel van het bestand opnieuw moeten schrijven omdat je sluittag opgeschoven moet worden. Gebruik je echter openpyxl dan ben je of constant je bestand opnieuw aan het wegschrijven op het moment dat er een meetwaarde toegevoegd wordt, of je hebt constant een niet afgesloten bestand in een corrupte state todat je script afgesloten wordt. Beiden lijken me een onwenselijke situatie


Als je vervolgens ook nog meeneemt dat een CSV file relatief simpel te importeren is in Excel dan valle vervolgens alle voordelen voor het gebruik van een excelfile weg.

[ Voor 7% gewijzigd door Janoz op 04-01-2021 13:54 ]

[Ben(V)]

En jij denk dat bij het appenden van een csv bestand onder water niet eerst het hele bestand gelezen wordt?

Normale tekst bestanden (wat een csv file ook is) zijn niet record georiënteerd en als je iets wilt appenden dan zal het OS eerst het hele bestand inlezen, data eraan toevoegen en weer wegschrijven.

En als het een applicatie is die continue update, zoals meestal het geval is in beschreven gebruik, dan open je in de python applicatie het excel bestand en kun je continue velden wegschrijven, dus ook velden die geupdate moeten worden zonder hele csv regels toe te voegen.

Csv bestanden zijn iets uit de oude doos en als je perse data wilt opslaan vanuit python gebruik je pickle of als je portable wilt zijn json of een simple database als sqlite, maar geen antiek formaat als csv.

Het voordeel van excel in dit geval is de bewerkings en presentatie mogelijkheden die excel bied.

[ Voor 21% gewijzigd door Ben(V) op 04-01-2021 14:11 ]

[Rukapul]

Ben(V) schreef op maandag 4 januari 2021 @ 14:06:
En jij denk dat bij het appenden van een csv bestand onder water niet eerst het hele bestand gelezen wordt?

Normale tekst bestanden (wat een csv file ook is) zijn niet record georiënteerd en als je iets wilt appenden dan zal het OS eerst het hele bestand inlezen, data eraan toevoegen en weer wegschrijven.

Nee.

Elk OS (en Python) heeft een append flag bij het openen van een file. Dat is een open + seek operatie die het OS efficient voor je afhandelt op basis van de beschikbare metadata in het filesystem.

[Ben(V)]

Tja er is wel een append flag maar onder water werkt het gewoon zoals ik beschreef.
Bestanden zijn voor een OS gewoon een sequentiële data en metadata die records bijhouden bestaan gewoon niet, daar heb je databases voor.

[CCJJVV]

Het ligt er aan wat je doel precies is.

Wil je snel en makkelijk deze data opslaan en grafieken genereren, dan is iets als InfluxDB met grafana the way to go.

Wil je gewoon hobbyen en ervaring opdoen dan kan je het prima opslaan in bijvoorbeeld een CSV file die je per dag bij kan houden.

[Compizfox]

Volgens mij is rrdtool precies wat je zoekt. Combinatie van een database en plotting library, bedoeld voor time series data, alles zit in een enkele file, en er bestaat zeker een Python-library voor.

[ Voor 59% gewijzigd door Compizfox op 04-01-2021 15:06 . Reden: Waarom gebruikt GoT nog steeds UBB ipv Markdown.... ]

[Janoz]

Ben(V) schreef op maandag 4 januari 2021 @ 14:15:
Tja er is wel een append flag maar onder water werkt het gewoon zoals ik beschreef.
Bestanden zijn voor een OS gewoon een sequentiële data en metadata die records bijhouden bestaan gewoon niet, daar heb je databases voor.

CSV is ook sequentiele data. Er is niet een tag die het einde van het bestand aan geeft. Een nieuw record kan gewoon achter alle bestaande records geschreven worden.

Ga je straks ook beweren dat alle logfiles elke keer opnieuw geschreven worden zodra er een regel bij komt?

[JackBol]

De consistentie mbt open files is in mijn ogen niet eens het grootste struikelblok. Ook al ga je een Python module gebruiken, je zal veel Logic mbt de interactie moeten beschrijven.

Een database kan je gewoon als object openen en ermee doen en laten wat je wilt.

[Ben(V)]

Janoz schreef op maandag 4 januari 2021 @ 14:30:
[...]


Ga je straks ook beweren dat alle logfiles elke keer opnieuw geschreven worden zodra er een regel bij komt?

Dat zie je correct.
Misschien moet je eens wat verdieping zoeken hoe filesystemen en de interactie met het OS in elkaar zit.

[Janoz]

Ben(V) schreef op maandag 4 januari 2021 @ 14:42:
[...]


Dat zie je correct.
Misschien moet je eens wat verdieping zoeken hoe filesystemen en de interactie met het OS in elkaar zit.

Ik heb Minix ooit eens uitgebreid met ondersteuning voor symbolic links. Ik denk dat ik wel een beetje een idee heb hoe op OS niveau omgegaan wordt met bestanden....

[RobIII]

Ben(V) schreef op maandag 4 januari 2021 @ 14:42:
Misschien moet je eens wat verdieping zoeken hoe filesystemen en de interactie met het OS in elkaar zit.

Of jij

Je kunt 't super simpel testen: Schrijf 10GB aan data weg. Close de file. Open de file for append, voeg 1 byte toe en close weer en time dat. Duurt dat:

a) een fractie van een seconde of^*
b) de tijd die je schijf (SDD, HDD, whatever) nodig heeft om 10GB te schrijven?

Ik zal het verklappen: het antwoord is a. Jij denkt serieus dat er dan eerst 10GB aan data doorgespit wordt? For what? Een append is niets anders dan een open (filepointer staat aan 't begin), zet filepointer naar sizeof(file) (oftewel: een seek naar EOF) en voila. Daar gaat je OS écht niet eerst door 10GB heen kauwen. Precies wat Rukapul in "python data bijhouden voor grafiek file based?" zegt dus.

Het is een héél ander verhaal als je een byte toevoegt in notepad en dan opslaat. Notepad (en de meeste 'tekstverwerkers') zijn vrij dom en zullen de complete file (her)schrijven maar dat is, zoals ik zei, een totaal ander verhaal.

^{* En dan niet lopen flauwekullen over dat je op een tape aan 't schrijven bent of één of andere exotische hardware gebruikt}

[ Voor 33% gewijzigd door RobIII op 04-01-2021 15:02 ]

[.oisyn]

Ben(V) schreef op maandag 4 januari 2021 @ 14:15:
Bestanden zijn voor een OS gewoon een sequentiële data en metadata die records bijhouden bestaan gewoon niet,

Dat is gewoon onzin . Een bestand bevat ook metadata. Deel van die data is zichtbaar (bestandsnaam, grootte, attributen, creation&modified time, etc), maar een deel is onzichtbaar (zoals waar de daadwerkelijke data op het volume te vinden is). Veel moderne filesystems ondersteunen ook gewoon sparse files, waarbij blokken die je nooit aanraakt ook niet worden weggeschreven.

Hoe dan ook, de data staat vrijwel nooit sequentieel achter elkaar op disk (ken je defrag nog?). Een file openenen voor append is niets meer dan de schrijfpointer bij het openen aan het eind van de file plaatsen. Als op die plek nog geen blok is gealloceerd, wordt dat bij het schrijven gedaan. Liefst achter de vorige blokken, als daar ruimte is, maar dat kan ook op een andere plek op disk.

RobIII schreef op maandag 4 januari 2021 @ 14:49:
^{* En dan niet lopen flauwekullen over dat je op een tape aan 't schrijven bent of één of andere exotische hardware gebruikt}

Een tape is nog steeds een block device waaraan data kan worden gewijzigd en toegevoegd. Seeks duren alleen wat langer

[ Voor 15% gewijzigd door .oisyn op 04-01-2021 15:12 ]

[Merethil]

Ben(V) schreef op maandag 4 januari 2021 @ 14:06:
En als het een applicatie is die continue update, zoals meestal het geval is in beschreven gebruik, dan open je in de python applicatie het excel bestand en kun je continue velden wegschrijven, dus ook velden die geupdate moeten worden zonder hele csv regels toe te voegen.

Csv bestanden zijn iets uit de oude doos en als je perse data wilt opslaan vanuit python gebruik je pickle of als je portable wilt zijn json of een simple database als sqlite, maar geen antiek formaat als csv.

Het voordeel van excel in dit geval is de bewerkings en presentatie mogelijkheden die excel bied.

Even naast alle tekst omtrent hoe je OS data wegschrijft - Waarom zou je de file handle naar de CSV dan niet ook gewoon open kunnen laten staan? Het lijkt me heel gek velden te gaan updaten in het bestand dat TS wil maken, want het is gewoon een log van opbrengst van zijn panelen. Er hoeven dus geen updates plaats te vinden op oudere records.

Dus... Je voegt extra gedoe toe door er een .xlsx van te willen maken terwijl een CSV die je continu openhoudt sneller append en uiteindelijk óók in Excel geopend kan worden en exact dezelfde opties voor bewerking- en presentatiemogelijkheden biedt.

Dat het "antiek" is beteken niet dat het geen nut heeft. Zat systemen die een CSV genereren voor exports, gebruiken voor imports of gewoon om data op te slaan in een relatief makkelijk readable format.

[RobIII]

.oisyn schreef op maandag 4 januari 2021 @ 15:08:
Een tape is nog steeds een block device waaraan data kan worden gewijzigd en toegevoegd. Seeks duren alleen wat langer

offtopic:
...en waarschijnlijk is "langer" dan méér dan een fractie van een seconde, waar 't over ging

[Ben(V)]

@.oisyn Een bestand op disk is een linked list van records en er wordt wel metadata opgeslagen maar echt geen record indexering.
Dus om iets toe te voegen moet het OS echt door die linked list een lezen om het einde van het bestand te vinden.

Maar de discussie gaat helemaal nergens meer over.
Waar het om ging is dat excel toegevoegde waarde kan hebben vanwege zijn krachtige functies voor o.a. tonen van grafieken maar ook mooie totalisering en trend kun je er mee maken.

En de omweg via het importeren van csv lijkt mij enkel maar overbodig, maar als TS het via csv wil doen prima, ik geef enkel een optie weer en denk dat hij zelf prima in staat is zelf een keuze te maken.

[.oisyn]

Ben(V) schreef op maandag 4 januari 2021 @ 15:19:
@.oisyn Een bestand op disk is een linked list van records en er wordt wel metadata opgeslagen maar echt geen record indexering.
Dus om iets toe te voegen moet het OS echt door die linked list een lezen om het einde van het bestand te vinden.

Of dat waar is hangt nogal af van het filesystem. Ik weet dat FAT zo werkt, maar NTFS bijvoorbeeld niet, waar een file een of meerdere entries in de MFT beslaat, waar mogelijk ook data in staat, of een tabel die aangeeft waar de data staat, of slechts een verwijzing naar een tabel als de tabel zelf weer te groot is voor een MFT entry.

Hoe dan ook, het is een moot point. Het opzoeken van het einde bij een linked list betekent niet dat alle data hoeft te worden ingelezen, maar alleen de lijst met verwijzingen naar clusters/blocks. Appenden aan een file is hoe dan ook veel efficienter dan de hele file inlezen en opnieuw wegschrijven.

[Morrar]

Voor grafieken tonen i.c.m. met Python zou ik echt naar streamlit kijken voor dit soort use cases: https://www.streamlit.io/. Makkelijker en interactiever dan Excel en in ongeveer dezelfde tijd in elkaar te flansen.

Voor dataopslag zou ik ook niet naar Excel kijken vanwege proprietary format, (gerelateerd) halfslachtige implementaties in Python, traagheid van verwerking, et cetera. CSV zou mijn voorkeur hebben, al zijn daar ook wel nadelen aan. Bijvoorbeeld dat de data niet self-describing zijn en (mede daardoor) floating point precision in uitzonderlijke gevallen kan opspelen, encoding issues tussen verschillende bronsystemen, et cetera. In de praktijk zul je hier echter zelden last van hebben. En anders zou je nog een format als parquet kunnen overwegen al moet je dan weer met een engine als fastparquet of pyarrow aan de slag.

Een voordeel van SQLite is in ieder geval dat je het schema hebt en dat de data dus wel self-describing zijn. Daarnaast kun je ook meteen relaties en views inbouwen in de DB, wat me ideaal lijkt voor bijvoorbeeld aggregaties. Overzetten naar een meer volwassen RDBMS is ook relatief simpel, dus daar scoort SQLite ook punten.

Time-series databases zoals influxdb zijn ook een optie, maar dan moet TS zich daar wel weer ff in gaan verdiepen.

Sowieso ben ik eigenlijk wel benieuwd wat er van dit project geworden is!