Hi,
auf einem Raspberry bekomme ich externe Werte die ich über GPIO einlese. Etwa 1 bis 2 Mal pro Tag gibt es neue Daten.
Schritt1:
Diese würde ich in einer großen FIFO Ringpuffer Datenbank speichern (evtl ein Jahr lang). Was hier verwenden?
Schritt2:
Mit den Daten soll dann über ein Python skript ein Diagramm erstellt und als Bild-Datei (zB png) abgelegt werden. Welche Plot-Bibliotken bietet sich hier an?
Schritt3:
Da der Raspberry auch am Web hängt, hostet er eine kleine Homepage, die immer auf das Bild oben zugreift und es darstellt.
Klar, man kann es superduper mit JS oder so viel besser machen... aber ich bin noch nicht so weit. Will erstmal mit einfachen Mitteln anfangen.
Vor allem bei Schritt 1 und 2 bräuchte ich ein paar Vorschläge zur Herangehensweise.
vielen Dank!
Wetterdaten Logger: Daten als Plot-Bild auf Webseite ausgeben
Zur Ablage eignen sich spezialisierte Datenbanken wie InfluxDB. Und die können auch gleich mit Systemen wie Grafana oder Telegraf zur Darstellung gebracht werden. Das würde ich ohne Not nicht selbst programmieren. Wenn du darauf bestehst, eignet sich zb matplotlib.
-
- User
- Beiträge: 19
- Registriert: Dienstag 10. März 2020, 20:20
Was spricht gegen SQLite als Datenbank?
Nichts. Erst spricht auch nichts gegen MySQL, Postgres, CSV oder JSON. Du hast aber nicht danach gefragt. Sondern allgemein eine Zeitreihe beschrieben, und den Wunsch geäußert, die darzustellen. InfluxDB und Grafana oder Telegraf sind darauf hin entwickelt worden. Es ist also besonders einfach. Das heißt nicht, das man es anders nicht auch machen kann.
Was dagegen spricht, ist: es ist keine Datenbank. In Deinem Fall mit maximal < 1000 Einträgen und keinen parallelen Zugriffen ist das egal, aber... es ist halt, wie es ist.HeinzBacker hat geschrieben: ↑Sonntag 21. November 2021, 13:26 Was spricht gegen SQLite als Datenbank?
Wenn Du Spaß haben willst, probier' mal OpenSearch, Redis oder die PostgreSQL-Erweiterung Timescale. Nur so als Tipp.
![Wink ;-)](./images/smilies/icon_wink.gif)
@LukeNukem: Die Aussage ist so falsch. Nachtürlich ist SQLite eine Datenbank.
Deine "kleinen Tipps" hingegen sidn für den Anwendungsfall, für den es ja schon die oben genannten sehr passenden Lösungen gibt, eher nicht... naja... ungewöhnlich bis nicht wirklich zielführend.
Deine "kleinen Tipps" hingegen sidn für den Anwendungsfall, für den es ja schon die oben genannten sehr passenden Lösungen gibt, eher nicht... naja... ungewöhnlich bis nicht wirklich zielführend.
Wie man mit einer primaer in-Memory und Key-Value-basierten Loesung wie Redis kommt fuer einen solchen Anwendungsfall, bleibt auch des suesse Geheimnis eines Entwicklers, der zu ueberzeugt davon ist, dass seine Anforderungen auch die von allen anderen sein muessen ![🙄](//cdn.jsdelivr.net/gh/twitter/twemoji@latest/assets/svg/1f644.svg)
Redis unterstützt feingranuliert konfigurierbare Backup-Strategien, die sich auch ganz wunderbar mit der Anforderung "1 bis 2 Mal pro Tag gibt es neue Daten" vertragen. Zudem ist es sowohl beim Schreiben als auch beim Lesen extrem schnell, insbesondere auch auf einem RasPi mit seinen eher langsamen Persistierungsmedien.__deets__ hat geschrieben: ↑Mittwoch 24. November 2021, 12:10 Wie man mit einer primaer in-Memory und Key-Value-basierten Loesung wie Redis kommt fuer einen solchen Anwendungsfall, bleibt auch des suesse Geheimnis eines Entwicklers, der zu ueberzeugt davon ist, dass seine Anforderungen auch die von allen anderen sein muessen![]()
Obendrein kann die Schreiblast auf der SD-Karte deutlich reduziert werden, wodurch die Lebensdauer der SD-Karte geschont wird. Denn Du als Profi weißt doch sicher, wie klassische RDBMS das mit ihren Garantien machen, Stichwort Write-Ahead-Log, spricht: für jeden Write auf die DB gibt es mehrere Schreibzugriffe auf das Persistierungemedium, und das ist bei einem RasPi nun einmal empfindlich, wenn man nicht gerade viel Geld für eine "Industrial"-Karte ausgeben oder einen USB-Storage anklemmen kann oder will.
Das Dumme ist halt: unser Wissen über den tatsächlichen und konkreten Anwendungsfall des TO ist leider sehr begrenzt. Deswegen gefalle ich mir gerne in der Rolle, auch mal einen Blick auf einige Alternativen zu empfehlen, denn die mit Abstand meisten Entwickler, die ich kenne, denken bei "strukturierte Daten speichern" oft leider nur an ein RDBMS -- auch wenn das wie bei Zeitserien und anderen Daten, die viel besser zu einem Append-Only-Log passen, häufig keine sonderlich gute Idee ist.
Insofern, weißt Du... man kann in Anbetracht unseres allenfalls oberflächlichen Wissens hinsichtlich des Anwendungsfalls des TO und seiner konkreten Anforderungen sicherlich lange darüber diskutieren, ob Redis oder OpenSearch oder was-auch-immer nun wirklich eine gute Idee wäre. Aber es rundheraus auszuschließen, halte ich -- Pardon -- für nicht sonderlich professionell.
Deine feingranulierten Backupstrategie hat ja nun erstaunlich wenig mit der Eignung eines Key-Value-Store für Zeitserien zu tun.
Und wer Milliardenfach deployte Datenbanktechnologie abqualifiziert, ist so manches. Aber garantiert nicht „sonderlich professionell“…..
Das du dir aber selbst gefällst, das glaube ich unumschränkt.
Und wer Milliardenfach deployte Datenbanktechnologie abqualifiziert, ist so manches. Aber garantiert nicht „sonderlich professionell“…..
Das du dir aber selbst gefällst, das glaube ich unumschränkt.
Es gibt schon seit einigen Jahren ein Timeseries-Modul für Redis [1] und ich habe Redis sowohl mit als auch ohne dieses Modul bereits erfolgreich als Zeitseriendatenbank in verschiedenen Anwendungsfällen eingesetzt. Auch die Grafana-Entwickler scheinen das für eine durchaus sinnvolle Möglichkeit zu halten, siehe dazu unter [4], [5] und [6]. Daher wüßte ich nichts, was dagegen spräche, und bis auf Deinen korrekten, aber IMHO nicht unbedingt relevanten Hinweis, daß Redis grundsätzlich ein In-Memory-Key-Value-Store ist, kann ich bei Dir leider auch keine wirkliche oder gar sachliche Begründung für Deine Ablehnung finden. Kennst Du Redis und hast damit schon praktische Erfahrungen gesammelt? Das konnte ich aus Deinen Ausführungen leider nicht erkennen.
SQLite hingegen hat nun einmal leider das Problem, daß es eine Flatfile-Datenbank ist und wie die allermeisten solcher Systeme nunmal keine parallelen Writes erlaubt, siehe dazu auch [2] und [3]. In jenen Fällen, wo SQLite milliardenfach genutzt wird, kümmert sich die zugreifende Software um die notwendige Synchronisation der Schreibzugriffe. Aber kann sie das beim TO denn auch, oder hat er eine zuverlässige Lösung dafür? Ich weiß darüber leider ebensowenig wie Du (es sei denn, Du hättest mir unbekannte Informationen).
Grundsätzlich rate ich jedoch bei Datenbeständen, auf die mehrere Prozesse zugleich zugreifen sollen -- und diesen Eindruck leite ich hier aus den spärlichen Aussagen des TO ab --, von Flatfile-Datenbanken ab. Für derartige Anwendungsfälle sind sie einfach nicht gemacht und nicht gedacht. Das ist auch kein Problem von SQLite, sondern nun einmal seine Natur. SQLite ist prima als Storage für strukturierte Daten, wenn jetzt und für die Zukunft sichergestellt ist, daß immer nur maximal eine einzige lokale Prozeßinstanz schreibend darauf zugreift, denn sonst ist die Wahrscheinlichkeit recht groß, daß der Entwickler früher oder später an die Limitierungen von SQLite stößt. Wenn jedoch ohnehin mehrere Prozesse zugreifen, ist es in der Regel viel weniger Aufwand, von vorneherein eine Technologie zu verwenden, die diese inhärenten Limitierungen gar nicht erst hat.
Übrigens leidet SQLite3 wie andere RDBMS in diesem Fall unter dem bereits erwähnten Problem der vielen kleinen Schreibzugriffe in viele kleine und auch temporäre Dateien, die die SD-Karte schnell verschleißen. Darauf sollte man hinweisen, wenn man es für diese spezielle Plattform nahelegt. Aber auf der anderen Seite stellt sich die Frage, ob der TO überhaupt eine Transaktionssicherheit braucht? Soweit mir bislang bekannt, wären seine Daten ein klassischer Fall für ein Append-Only-Log. Da kann er sich den Performance-Impact und den übermäßigen Verschleiß seines Speichermediums aber doch auch gleich ersparen, findest Du nicht?
Ich habe übrigens noch einmal in meine Notizen und Benchmarks mit dem sehr beliebten, verbreiteten und ja auch von Dir empfohlenen InfluxDB geschaut. Dabei scheine ich wohl irgend etwas falsch gemacht zu haben, denn sogar PostgreSQL mit der TimescaleDB-Erweiterung war mit unterschiedlichen Größen verschiedener synthetischer und realer Daten wesentlich performanter. Obendrein schreibt auch InfluxDB meines Wissens ein Write-Ahead-Log und leidet somit unter ähnlichen Schwierigkeiten hinsichtlich der Lebensdauer des Persistierungsmediums wie oben für SQLite beschrieben. Insofern ist mir auch hier noch nicht ganz klar, welche Vorzüge InfluxDB für den vermuteten Anwendungsfall des TO haben sollte.
Die aus meiner Sicht gravierendsten Nachteile von SQLite (und anderen RDBMS) habe ich dargelegt. Nun sei doch bitte so freundlich und erkläre mir bitte der Einfachheit halber mal ganz sachlich, was Deiner Meinung nach die Vorteile von SQLite und InfluxDB wären und worin demgegenüber die Nachteile von Redis bestünden? Vielen Dank, ich bin sehr gespannt.
[1] https://oss.redis.com/redistimeseries/
[2] https://www.sqlite.org/faq.html
[3] https://www.sqlite.org/lockingv3.html
[4] https://grafana.com/go/observabilitycon ... d-grafana/
[5] https://grafana.com/grafana/plugins/redis-datasource/
[6] https://grafana.com/grafana/dashboards/12980