Hallo Experten, ich möchte auf verschiedenen kleinen Linux Geräten eine Mysqldatenbank anlegen. Auf jeder dieser Datenbank möchte ich Tabellen beschreiben. Da diese Geräte nicht immer mit dem Internet verbunden sind möchte ich wenn Internet da ist diese Tabellen in eine große Msql Datenbank abgleichen. Hat jemand damit bereits Erfahrung? Kann mir jemand die Grundsätzliche Vorgehensweise erklären? Bin für jedes Stichwort dankbar. Also schon mal ein großes Dankeschön an alle. Lg
toscana schrieb: > diese Tabellen in eine große Msql Datenbank > abgleichen. Abgleichen ist ein einfaches Wort für ein komplexes Problem. Du müsstest als erstes mal feststellen, welche Fälle vorkommen können, z.B. Daten online nicht vorhanden, online älter, online jünger... Und dann entscheiden was jeweils passieren soll, neuanlegen, hochladen, runterladen usw. Das programmierst du dann einfach. Und was ist mit Daten, die lokal nirgends mehr vorhanden sind? Georg
Nachtrag: es gibt massenweise Software für den Datenabgleich, ich mache z.B. meine Backups mit rsync. Aber das erzeugt identische Kopien, das wird nicht funktionieren wenn du eine gemeinsame Datenbank als Backup für viele verschiedene lokale verwendest. Das könntest du dir ja auch anders überlegen. Georg
georg schrieb: > toscana schrieb: >> diese Tabellen in eine große Msql Datenbank >> abgleichen. > > Abgleichen ist ein einfaches Wort für ein komplexes Problem. Du müsstest > als erstes mal feststellen, welche Fälle vorkommen können, z.B. Daten > online nicht vorhanden, online älter, online jünger... Und dann > entscheiden was jeweils passieren soll, neuanlegen, hochladen, > runterladen usw. Das programmierst du dann einfach. > > Und was ist mit Daten, die lokal nirgends mehr vorhanden sind? > > Georg das Thema ist in der Überschrift "Replikation"!!! @toscana: Ich habe gleiches Problem, bin zwar noch nicht weitergekommen aber hier schon mal ein paar Hinweise: https://www.thomas-krenn.com/de/wiki/MySQL_Replikation https://gridscale.io/community/tutorials/mysql-master-master-replikation/ --> google hilft weiter Mein Ansatz: jeder Client bearbeitet sein lokales Schema welches auf einen zentralen Server repliziert wird. Daher sollte der Schemaname eindeutig sein, sodass später auf dem Server eine Anzahl Schemas entsteht, die der Anzahl der Clients entspricht. Die Replikation sollte unabhängig vom Verbindungsstatus funktionieren. evtl kommst du damit weiter
Verrat mal mehr über die Anwendung bzw. die Daten. Hört sich für mich bislang so an, als hättest du dich da in was verrannt, und du suchst eigentlich eine Lösung wie: Client, wenn Internet da ist: mysql dump table -> data_%CLIENTNAME%.csv rsync auf server Server: cat *.csv | sort | uniq | mysql-import
toscana schrieb: > kleinen Linux Geräten eine Mysqldatenbank Das Solltest Du auch nochmal überdenken. Klassischerweise braucht eine MySQL einige Ressourcen, vielleicht reicht es ja auf dem "kleinen Linux Geräten" eine sqlite zu verwenden.
georg schrieb: > Und was ist mit Daten, die lokal nirgends mehr vorhanden sind? Was meinst du damit? Εrnst B. schrieb: > Verrat mal mehr über die Anwendung bzw. die Daten. > > Hört sich für mich bislang so an, als hättest du dich da in was > verrannt, und du suchst eigentlich eine Lösung wie: Also meine Geräte sammeln Daten in einer lokalen Datenbank. Leider ist nicht immer Internet da.....sonst könnte ich ja immer direkt in die Master Datenbank rein schreiben. Wenn nun sagen wir mal einmal am Tag doch Internet da ist möchte ich die gesammelten Daten in die große Datenbank schieben. Lokal brauche ich die Daten nicht mehr. Imonbln schrieb: > Das Solltest Du auch nochmal überdenken. Klassischerweise braucht eine > MySQL einige Ressourcen, vielleicht reicht es ja auf dem "kleinen Linux > Geräten" eine sqlite zu verwenden. Ok wenn ein sqlite ausreicht nehme ich auch gerne die. Danke für die Hilfe
Dazu brauch man keine Literatur sondern Regeln. Und die macht man sich selbst. Ich würde z.b. beim Anlegen des Datensatzes ein ID2-Feld anlegen. Dies besteht aus der Geräte-ID (Vergebe ich selbst) und der Satz-ID. Vergibt die SQL-DB. Dann noch ein Anlege/Änderungdatum. Aus Sicherheitsgründen falschherum und als Text" z.b. 2020-08-27_14:10 für Heute. Ist einfacher zu handhaben und umgeht die Lokalisation-Probleme. (Schreibweise von Datum/Zeit Angaben nach Ländern) Nun muss man min. 2. Regeln aufstellen. 1.) Wer hat die höhere Priorität zum ändern der Daten. 2.) Nach welchen Schlüsselworten soll abgeglichen werden. Und die Frage auflegen, soll jede Änderung Protokolliert werden. Wenn man nur ein Backup-System will geht es einfacher. Letztes Abgabe-Datum anlegen nach den Backup. Sql-Abfrage nach > letzte Änderungsdatum und alle mit Update / Neu_anlage Befehl hoch schicken zum Server. Durch das ID2-Feld kann ich den Datensatz immer identifizieren und sogar später sehen wer in der Server-DB den mir untergejubelt hat.
Kleiner Tipp am Rande. Lagere Alte Daten in andere Tabellen in der DB aus. Das beschleunigt den Zugriff ungemein. Idealerweise wäre z.b. 1 Tabelle pro Jahr. Muss halt nur in der Abfrage geregelt werden. Kleiner Tipp zum Speed. Auf mein PC unter VB braucht eine Abfrage von 4.5 Mio Datensätze in einer Tabelle mit LIKE Befehl ca. 50-60 Sekunden von einer SSD-Platte. Unter SQL-Lite.
Schlaumaier schrieb: > Dann noch ein Anlege/Änderungdatum. Aus Sicherheitsgründen > falschherum und als Text" z.b. 2020-08-27_14:10 für Heute. Gute Idee ... NICHT! Stringvergleiche sind deutlich langsamer als Vergleiche auf einem Datumswert, wenn mal große Datenmengen durchsucht werden sollen. merciless
Dirk K. schrieb: > Gute Idee ... NICHT! Stringvergleiche sind deutlich > langsamer als Vergleiche auf einem Datumswert, wenn > mal große Datenmengen durchsucht werden sollen. Sind ja keine Großen Datenmengen. Das er das Datum auch "richtig herum" speichern kann / Soll streitet ja keiner ab. Aber ich mag Backup-Systeme und so was hat mir schon oft den POPO gerettet. Und auf der Server-Datenbank ist das nur ein Feld mehr. Macht nicht wirklich was aus. Aber falls sich noch einer an die y2k Theater erinnern kann. Da war das Gold wert ;)
toscana schrieb: > Hat jemand damit bereits Erfahrung? Kann mir jemand die Grundsätzliche > Vorgehensweise erklären? Bin für jedes Stichwort dankbar. Viele Hinweise findest Du hier: http://infocenter.sybase.com/help/topic/com.sybase.dbsren_1001/pdf/dbsren10.pdf?noframes=true Wenn Du Dir das durchliest, wirst Du auch erkennen, dass das Thema sehr komplex werden kann (jedenfalls wenn es um mehr als eine einfache flache Tabelle geht). Die SAP (früher Sybase) Datenbank hat Mechanismen zur Replikation eingebaut und kann verschiedene Transportprotokolle einsetzen. Die Master-Master Replikation von MySQL habe ich noch nicht benutzt, aber so etwas schon mit Triggern realisiert. In SQLite gibt es weder eingebaute Replikation noch Trigger, da muss die Anwendung alles übernehmen. Generell kann man sagen, dass einfache flache Tabellen auch einfach zu replizieren sind (nach dem Prinzip "der letzte gewinnt"). Und wenn es nur um neue Datensätze geht (also nichts verändert oder gelöscht wird), ist es grundsätzlich auch ziemlich einfach. Zweckmäßigerweise benutzt man Guids (UUIDs) als Primärschlüssel. Bei Tabellen mit Foreign Keys muss man sicherstellen, dass ein Master keinen Datensatz löscht, der von einem anderen noch benutzt wird. Oder eine Konfliktlösungsstrategie bereitstellen. Wenn man Daten auf den einzelnen Geräten vor der Übertragung konsolidiert (also z.B. Summen erstellt, Filter anwendet etc.), darf ein anderes Gerät die Ursprungs-Datensätze nicht verändern - oder man muss sicherstellen, dass die Summen nach dem Abgleich komplett neu berechnet werden.
Bernd S. schrieb: > das Thema ist in der Überschrift "Replikation"!!! Aha - und wie repliziert man eine Menge lokaler Datenbanken in eine gemeinsame Online-Datenbank? Mit naiver Replikation wären immer nur die Daten vom letzten System verfügbar das Kontakt hatte. Es ist ja noch nicht mal bekannt, ob sich gleiche Datensätze auf mehreren lokalen Systemen befinden. toscana schrieb: > georg schrieb: >> Und was ist mit Daten, die lokal nirgends mehr vorhanden sind? > > Was meinst du damit? Na genau so wie es da steht - wenn es Daten auf einem lokalen System jetzt gibt und später nicht mehr, was ist dann mit den Daten auf dem Server? Bleiben die auf ewige Zeiten als Karteileichen erhalten? Konsequent durchdacht ist das noch lange nicht. Georg
Also, ich fass die Anforderung mal zusammen: Es gibt mehrere Geräte, die Daten Loggen z.B Gerät1:
1 | "2020-08-27 14:00",22.5°C |
2 | "2020-08-27 14:10",22.0°C |
Gerät2:
1 | "2020-08-27 14:00",20.0°C |
2 | "2020-08-27 14:15",19.5°C |
usw. und dazu eine Master-Datenbank. Sobald alle Geräte einmal Internet-Kontakt hatten, soll in der Master-Datenbank stehen:
1 | "2020-08-27 14:00",Gerät1,22.5°C |
2 | "2020-08-27 14:00",Gerät2,20.0°C |
3 | "2020-08-27 14:10",Gerät1,22.0°C |
4 | "2020-08-27 14:15",Gerät2,19.5°C |
± weitere/andere Messwerte usw. Soweit korrekt? LösungsIdee: Geräte-Datenbank um ein Flag "Synchronized" erweitern, sobald Internet da ist: Alle Datensätze "where Synchronized is null" lokal auslesen, in die Master-DB inserten, danach Synchronized auf "true" oder timestamp oder primary-key/last-insert-id der Master-DB aktualisieren. insert in die Master-DB mit "on conflict update", "update into" o.Ä., um zu verhindern dass nicht uploadbare Datensätze bei einem Verbindungsabbruch während dem Sync-Lauf entstehen.
Ich bin immer versucht, solche Dinge mit Transaktionen zu machen, so daß unvollständig übertragene Anfragen gar nicht ausgeführt werden. Beim Synchronisieren müssen die Geräte sowieso bei der Haupt-Datenbank anfragen hey wie ist denn dein letzter Stand für mein Gerät, dann können sie alles was nachher neu dazukam übertragen und alles was davor liegt löschen. MySQL bietet inzwischen gute Datumsfunktionen wenn man nicht mehr mit Zeitstempeln arbeiten möchte - wobei letztere ein sehr performanter Ansatz sind, da das Datum kein menschenlesbarer String sein muß, sondern für die Datenbank nur ein 32/64bit Integer, der sich extrem schnell verarbeiten lässt. PHP mit seinem 32bit Integer-Zeitstempel hat da aber in 18 Jahren ein Problem, wahrscheinlich kommt da noch ein Update auf 64 Bit, das hält dann länger als Computer leben. Man könnte die Datenbank auch noch etwas entschlacken, indem man redundante Werte gar nicht speichert. Also angenommen ein Sensor meldet über eine Stunde hinweg die exakt gleiche Temperatur, wird aber alle 5 Minuten ausgelesen. Dann reicht es, den ersten Wert zu speichern und den nächsten erst wieder bei einer Änderung des Messwertes. Nachteil: Das überlagerte Programm muß die fehlenden Einträge anschließend selbst hinzufügen können, ein reines Auslesen der Datenbank führt zu unvollständigen Ergebnissen. > Auf mein PC unter VB braucht eine Abfrage von > 4.5 Mio Datensätze in einer Tabelle mit LIKE Befehl > ca. 50-60 Sekunden von einer SSD-Platte. Das wundert mich nicht, sowas macht man ja auch nicht. Volltextsuche in so vielen Datensätzen killt jede Datenbank.
Εrnst B. schrieb: > "2020-08-27 14:00",Gerät1,22.5°C > "2020-08-27 14:00",Gerät2,20.0°C > "2020-08-27 14:10",Gerät1,22.0°C > "2020-08-27 14:15",Gerät2,19.5°C > > ± weitere/andere Messwerte usw. > > Soweit korrekt? Fast Korrekt;) eigentlich möchte ich für jedes Gerät eine Eigene Tabelle. Entschuldigt mich wenn ich mich etwas ungeschickt ausgedrückt habe. Εrnst B. schrieb: > LösungsIdee: > > Geräte-Datenbank um ein Flag "Synchronized" erweitern, sobald Internet > da ist: > > Alle Datensätze "where Synchronized is null" lokal auslesen, in die > Master-DB inserten, danach Synchronized auf "true" oder timestamp oder > primary-key/last-insert-id der Master-DB aktualisieren. > > insert in die Master-DB mit "on conflict update", "update into" o.Ä., um > zu verhindern dass nicht uploadbare Datensätze bei einem > Verbindungsabbruch während dem Sync-Lauf entstehen. Klingt für mich als Laie gut. Sind das alles MySql Befehle?
toscana schrieb: > Klingt für mich als Laie gut. Sind das alles MySql Befehle? Nein, das sind SQL-Fragmente/Konzepte/Ideen, die sich auch mit MySQL umsetzen ließen, keine Fix-Und-Fertig Lösung. Für einen Laien also leider eher nutzlos, sorry. Ich würde empfehlen, erstmal den "Laien"-Status zu verbessern, bevor du dich an komplexe Synchronisations-Algorithmen machst.
toscana schrieb: > Εrnst B. schrieb: >> Geräte-Datenbank um ein Flag "Synchronized" erweitern, sobald Internet >> da ist: >> >> Alle Datensätze "where Synchronized is null" lokal auslesen, in die >> Master-DB inserten, danach Synchronized auf "true" oder timestamp oder >> primary-key/last-insert-id der Master-DB aktualisieren. >> >> insert in die Master-DB mit "on conflict update", "update into" o.Ä., um >> zu verhindern dass nicht uploadbare Datensätze bei einem >> Verbindungsabbruch während dem Sync-Lauf entstehen. > > Klingt für mich als Laie gut. Sind das alles MySql Befehle? Aus meiner Perspektive sind die Ansätze von Dir und Ernst durchaus brauchbar, aber... naja, vielleicht trotzdem nicht der Weisheit letzter Schluß. Also, im Prinzip reden wir hier von verschiedenen Datenquellen und einer Master-DB, die nur hin und wieder, also über eine unsichere Verbindung verfügbar ist. Zudem reden wir von Datenaufzeichnungen von mehreren Computern, die in diese Master-DB geschrieben werden sollen. Nun, Euer Gedanke ist jetzt: speichere die Daten lokal, und wenn die Internet-Verbindung und die Master-DB vorhanden sind, dann übertrage die Daten in die Master-DB. Ist das so korrekt? Wenn das so korrekt ist, ergeben sich aus meiner Perspektive noch ein paar weitere Fragen. Zunächst zur Natur der Daten: wenn das Meßwerte von Sensoren sind, dürften das meines Erachtens keine relationalen Daten für ein klassisches SQL-RDBMS sein. Daten, die keine (oder nur sehr oberflächliche) Beziehungen zueinander haben, sind leider sehr schlecht in Systemen aufgehoben, die Daten- und Transaktionssicherheit garantieren wollen. Außerdem würde eine lokale Zwischenspeicherung auf den Geräten entweder ein Housekeeping brauchen, das alle schon in die Master-DB geschriebenen Datensätze (bestätigter Write) lokal löscht. Außerdem halte ich von einer höheren Perspektive aus die ganzen Ideen für etwas.. schwierig. Wenn wir ohnehin wissen, daß die Verbindung zur Master-DB nicht stabil ist, dann sollten wir einfach davon ausgehen, daß sie es nicht ist. Hinzu kommt, daß mir nicht ganz klar ist, welche Folgen es haben würde, wenn Daten verloren gingen. Bei üblichen Wettersensoren ist es meist keine Katastrophe, wenn hin und wieder ein paar Einzeldatensätze verloren gehen. Wenn ich die Aussagen des TO richtig interpretiere, geht es um Logdaten. Das sind aber Daten, die nicht in eine transaktionssichere RDBMS gehören, sondern in einen Append-Only-Log. Außerdem braucht es wegen der unsicheren Connection einen Puffer der nichtgeschriebene Daten speichert, bis sie geschrieben wurden. Und wenn diese Daten am Ende visualisiert oder gar analysiert werden sollen, dann dürften sie in einem indexierten Columnarstore viel besser aufgehoben sein als in einem Rowstore wie es ein klassisches RDMBS ist... Ich persönlich würde daher etwas anderes benutzen. Für den Transport der Daten gibt es bereits fertige Protokolle, ebenso fertige Software zur Speicherung, Analyse und Visualisierung. Als Übertragungsprotokoll könnten sich etwa MQTT oder Apache Kafka, zur zentralen Speicherung Elasticsearch und zur Visualisierungs und Analyse Kibana anbieten, womöglich Redis als internen Cache. Wie auch immer, basiert das alles nur auf Vermutungen. Wenn der TO etwas genauer hinsichtlich des Anwendungsfalls und seiner Anforderungen und referieren könnte, wäre das sicherlich nützlich, um bessere Lösung vorschlagen zu können. ;-)
Sheeva P. schrieb: > Ich persönlich würde daher etwas anderes benutzen. Für den Transport der > Daten gibt es bereits fertige Protokolle, ebenso fertige Software zur > Speicherung, Analyse und Visualisierung. Als Übertragungsprotokoll > könnten sich etwa MQTT oder Apache Kafka, zur zentralen Speicherung > Elasticsearch und zur Visualisierungs und Analyse Kibana anbieten, > womöglich Redis als internen Cache. gerade für Messwerte bietet sich InfluxDB an; per Telegraf (plus TEMP plugin) lassen sich die Messwerte reinschieben, und Grafana gibt's dann einfach on top... :)
Sheeva P. schrieb: > Also, im Prinzip reden wir hier von verschiedenen Datenquellen und einer > Master-DB, die nur hin und wieder, also über eine unsichere Verbindung > verfügbar ist. Zudem reden wir von Datenaufzeichnungen von mehreren > Computern, die in diese Master-DB geschrieben werden sollen. Nun, Euer > Gedanke ist jetzt: speichere die Daten lokal, und wenn die > Internet-Verbindung und die Master-DB vorhanden sind, dann übertrage die > Daten in die Master-DB. > > Ist das so korrekt? Ja so stelle ich es mir vor. Sheeva P. schrieb: > dürften das meines Erachtens keine relationalen Daten für > ein klassisches SQL-RDBMS sein. Was meinst du damit? Sorry ich kann mit der Aussage nichts anfangen:/ Sheeva P. schrieb: > Hinzu kommt, daß mir nicht ganz klar ist, welche Folgen es haben würde, > wenn Daten verloren gingen. Bei üblichen Wettersensoren ist es meist > keine Katastrophe, wenn hin und wieder ein paar Einzeldatensätze > verloren gehen. Also ich sage mal so, es hängt kein Leben dran. Ich möchte mit diesen Daten einfach die Maschinen wo ich die Daten aufzeichne verstehen und im Fehlerfall die Ursache besser verstehen. Sheeva P. schrieb: > Wenn ich die Aussagen des TO richtig interpretiere, geht es um Logdaten. > Das sind aber Daten, die nicht in eine transaktionssichere RDBMS > gehören, sondern in einen Append-Only-Log. Außerdem braucht es wegen der > unsicheren Connection einen Puffer der nichtgeschriebene Daten > speichert, bis sie geschrieben wurden. Und wenn diese Daten am Ende > visualisiert oder gar analysiert werden sollen, dann dürften sie in > einem indexierten Columnarstore viel besser aufgehoben sein als in einem > Rowstore wie es ein klassisches RDMBS ist... Leider kann ich Dir auch bei dieser Aussage nicht folgen:/ Sheeva P. schrieb: > Wie auch immer, basiert das alles nur auf Vermutungen. Wenn der TO etwas > genauer hinsichtlich des Anwendungsfalls und seiner Anforderungen und > referieren könnte, wäre das sicherlich nützlich, um bessere Lösung > vorschlagen zu können. ;-) Also ich möchte auf den einzelnen Maschinen bei auftreten gewisser Events alle Sensordaten (ca. 30 Stück)in eine Lokale Datenbank schreiben. Wenn eine Verbindung zum Internet besteht möchte ich diese Lokale Datenbank in eine Große Datenbank auf einem Server speichern. Lokal werden dieDaten nicht gebraucht. Also im Prinzip denke ich das eine ganz Einfache Anwendung wenn man mit den richtigen Werkzeugen und Hintergrundwissen ran geht.
Schlaumaier schrieb: > Dirk K. schrieb: >> Gute Idee ... NICHT! Stringvergleiche sind deutlich >> langsamer als Vergleiche auf einem Datumswert, wenn >> mal große Datenmengen durchsucht werden sollen. > > Sind ja keine Großen Datenmengen. Das er das Datum auch "richtig herum" > speichern kann / Soll streitet ja keiner ab. Aber ich mag Backup-Systeme > und so was hat mir schon oft den POPO gerettet. Es wurde keine Aussagen über die zu erwartenden Datenmengen getroffen und es geht auch nicht darum, wie Datum und Zeit miteinander verkettet werden: Wenn mal in der Datenbank Messwerte über mehrere Jahre gesammelt wurden und dann abgefragt werden soll, wie war die Temperatur in der 3. Woche im März 2020 muss für JEDEN Eintrag ein Stringvergleich gemacht werden. Da warte ich schon auf den Thread: MySQL-Datenbank ist viel zu lahm, mit einer Textdatei geht das viel schneller! merciless
:
Bearbeitet durch User
Erstens e Dirk K. schrieb: > Es wurde keine Aussagen über die zu erwartenden > Datenmengen getroffen und es geht auch nicht > darum, wie Datum und Zeit miteinander verkettet > werden: Gar nicht. Man legt ein Timestamp an. Wer sich schon öfters mit UNIX-Datenbanken herum geschlagen hat, weiß das die genau DAS machen. Und zwar nicht als Text sondern als "Ganz lange Zahl". Wenn er genau DAS macht, dann brauch er nur das Datum der letzten Übertragung speichern als ZAHL / Timestamp auf den Lokalen Gerät und die letzte ID. Bei der nächsten Übertragung macht er folgendes. letzter_timestamp = Lese_letzte_timestamp_aus_inidatei() letzte_id = Lese_letzte_ID_aus_inidatei(). select * form Datenbank where timestamp > letzter_timestamp Do while lese_daten_Satz if ID < letzte_id then update Datensatz_auf_server else lege_datensatz_an_auf_server end if loop Lese_letzte_id_in_meiner_db_und_schreibe_sie_in_ini_datei. schreibe_timestamp_in_ini_datei Eine einfacher Programmstruktur in "Fake-Basic" die das komplette Sycn macht. Zum Thema Timestamp https://de.wikipedia.org/wiki/Unixzeit Der Nachteil dieser Methode ist, das man das Datum nicht in der Datenbank mit den Auge lesen kann. Deshalb benutzte ich (siehe andern Beitrag von mir) das zusätzliche abspeichern als Text. Was wenn mein Prg. kein Mist baut, das Unixdatum als richtig lesbares Datum anzeigt.
Nachtrag : Timestamp gehört ins Feld "letzte_änderungen". Wenn du das ganze mit 2 aktivierten Transaktionen" machst (Auf Server und lokal) dann geht das super schnell.
Jan L. schrieb: > Sheeva P. schrieb: >> Als Übertragungsprotokoll >> könnten sich etwa MQTT oder Apache Kafka, zur zentralen Speicherung >> Elasticsearch und zur Visualisierungs und Analyse Kibana anbieten, >> womöglich Redis als internen Cache. > > gerade für Messwerte bietet sich InfluxDB an; per Telegraf (plus TEMP > plugin) lassen sich die Messwerte reinschieben, und Grafana gibt's dann > einfach on top... :) Stimmt, InfluxDB und zur Visualisierung Grafana oder Chronograf würden auch gehen. Aber Tests in der Firma haben gezeigt, daß InfluxDB ein bisschen schneller ist und etwas weniger Ressourcen benötigt als Elasticsearch. Trotzdem haben wir uns für Elasticsearch entschieden, weil es viel mehr Anwendungsfälle abbilden kann.
toscana schrieb: > Sheeva P. schrieb: >> Ist das so korrekt? > > Ja so stelle ich es mir vor. Okay, prima. ;-) > Sheeva P. schrieb: >> dürften das meines Erachtens keine relationalen Daten für >> ein klassisches SQL-RDBMS sein. > > Was meinst du damit? Sorry ich kann mit der Aussage nichts anfangen:/ > [...] > Sheeva P. schrieb: >> Wenn ich die Aussagen des TO richtig interpretiere, geht es um Logdaten. >> Das sind aber Daten, die nicht in eine transaktionssichere RDBMS >> gehören, sondern in einen Append-Only-Log. Außerdem braucht es wegen der >> unsicheren Connection einen Puffer der nichtgeschriebene Daten >> speichert, bis sie geschrieben wurden. Und wenn diese Daten am Ende >> visualisiert oder gar analysiert werden sollen, dann dürften sie in >> einem indexierten Columnarstore viel besser aufgehoben sein als in einem >> Rowstore wie es ein klassisches RDMBS ist... > > Leider kann ich Dir auch bei dieser Aussage nicht folgen:/ Bitte entschuldige, daß ich mir die Freiheit genommen habe, die Reihenfolge ein bisschen zu ändern, weil es hier um denselben Punkt geht: nämlich um die Natur der Daten und die für solche Daten geeigneten Speicherungsmöglichkeiten. Leider kennen immer noch sehr viele Entwickler für so etwas ausschließlich klassische Relationale Datenbank Management Systeme (RDBMS), also SQL-Datenbanken wie beispielsweise MySQL oder PostgreSQL. RDBMS sind im Wesentlichen dazu da, bestimmte Garantien zu erfüllen, zum Beispiel die Transaktionssicherheit. Wenn zum Beispiel ein Betrag X von einem Konto A auf Konto B gebucht werden soll, müssen zwei Schritte erfolgen: vom Kontostand von A muß der Betrag X abgezogen und zum Kontostand des Kontos B addiert werden. Wenn zwischen dem Abzug des Betrags auf dem einen Konto und der Gutschrift auf dem anderen Konto etwas schlimmes passiert -- etwa, die Datenbanksoftware oder gar die ganze Maschine stürzt ab -- ist das ein großes Problem, denn entweder hat der Ausfall gerade unsere Bank ärmer gemacht, wenn zuerst die Gutschrift stattgefunden hat und der Ausfall vor dem Abzug erfolgt ist, oder, bei umgekehrter Reihenfolge, einen der Kunden. Das muß verhindert werden, und deswegen können RDBMS die Garantie geben, daß entweder beide Transaktionen (Abzug und Gutschrift) erfolgt sind oder keine von beiden. Eine weitere Garantie von RDBMS ist die Relationssicherheit. Wenn ich nun eine Person mit mehreren Konten habe, dann haben diese Konten jeweils einen Bezug -- eine Relation -- zu der Person. Das RDBMS kann nun sicherstellen, daß kein Konto angelegt kann, das nicht mit einer Person verknüpft ist. Und sogar, daß die Konten der Person automatisch gelöscht werden, sobald die Person gelöscht wird. Für solche Daten sind relationale Datenbanken richtig gut, aber diese Garantien sind andererseits leider auch ziemlich teuer und machen die ganze Sache ziemlich langsam. In PostgreSQL zum Beispiel würde die oben genannte Übertragung des Betrages X viele Festplattenzugriffe erfordern: erst werden die beiden Aktionen ins Write-Ahead-Log (WAL) geschrieben, um sie im Falle eines Ausfalls überhaupt erstmal gespeichert zu haben. Dann werden sie von einem anderen Prozeß aus dem WAL gelesen, in die jeweiligen Tabellen geschrieben, und dann im WAL als abgearbeitet markiert... Außerdem speichern RDBMS ihre Datensätze zeilenweise, was beim Lesezugriff langsam ist, wenn nur wenige Spalten einer großen Tabelle gelesen werden müssen. Genau das ist bei bei der Datenanalyse aber der wichtigste und häufigste Anwendungsfall. Solange Daten also keine Relationen (Bezüge) untereinander haben und auch keine Transaktionssicherheit benötigt wird, wie das bei Deinen Daten der Fall ist, und obendrein zu erwarten ist, daß die Daten nur einmal geschrieben (write once) und ansonsten nur zur Analyse und Visualisierung benötigt und gelesen werden, gibt es bessere Möglichkeiten zur Speicherung Deiner Daten als ein RDBMS. Ein Beispiel wäre eine auf Zeitserien und Metrikdaten (also Zahlenreihen mit einem zeitbasierten Index) spezialisierte Datenbank wie das von Jan L. genannte InfluxDB oder alternativ das ebenfalls beliebte Prometheus besser geeignet. Oder eben das von mir erwähnte Elasticsearch, das zwar einstmals vor allem als Volltext-Suchmaschine entwickelt wurde, aber auch stark in der Speicherung, Analyse und Visualisierung von Zeitserien und Metrikdaten (wie Deinen) ist. Soviel zur Speicherung, kommen wir zur Visualisierung. Warum ist die so wichtig? Weil kein Mensch eine Tabelle mit dutzenden Spalten und hundert oder gar tausend Zeilen vernünftig überblicken kann. Deswegen ist eine Software nützlich, die aus Deinen Daten einen hübschen Grafen zeichnen kann. Für Elasticsearch gibt es dazu eine auf Elasticsearch spezialisierte Websoftware namens Kibana, die direkt vom Entwicklerteam von Elasticsearch stammt, für InfluxDB und Prometheus wird dagegen gerne eine Webapplikation namens Kibana benutzt. Du kannst Dir natürlich auch selbst etwas entwickeln, zum Beispiel Deine Daten in eine CSV-Datei exportieren und mit gnuplot hübsche Grafen daraus erzeugen, oder die Python-Library Pandas nutzen, die viele analytische und statistische und auch die Möglichkeit bietet, die Daten zu plotten. Aber das ist vermutlich aufwändiger als die Benutzung einer fertigen Software, und lohnt sich deswegen wahrscheinlich nur dann, wenn Du wirklich sehr spezielle Anforderungen hast. > Sheeva P. schrieb: >> Hinzu kommt, daß mir nicht ganz klar ist, welche Folgen es haben würde, >> wenn Daten verloren gingen. > > Also ich sage mal so, es hängt kein Leben dran. > Ich möchte mit diesen Daten einfach die Maschinen wo ich die Daten > aufzeichne verstehen und im Fehlerfall die Ursache besser verstehen. Prima. > Sheeva P. schrieb: > Also ich möchte auf den einzelnen Maschinen bei auftreten gewisser > Events alle Sensordaten (ca. 30 Stück)in eine Lokale Datenbank > schreiben. > Wenn eine Verbindung zum Internet besteht möchte ich diese Lokale > Datenbank in eine Große Datenbank auf einem Server speichern. > Lokal werden dieDaten nicht gebraucht. > Also im Prinzip denke ich das eine ganz Einfache Anwendung wenn man mit > den richtigen Werkzeugen und Hintergrundwissen ran geht. Entschuldige bitte, aber ich glaube, Du solltest vielleicht umdenken. Die "lokale" Datenspeicherung muß also gar nicht in einer Datenbank erfolgen, sondern ist nur eine Art Schreibpuffer, bis eine Internetverbindung steht die Daten dann in Deine zentrale Datenbank geschrieben und lokal gelöscht werden können. Für derartige Aufgaben wie Deinen Schreibpuffer gibt es aber spezialisierte Software, die die Daten zwischenpuffern kann, zum Beispiel diverse Server (dort Broker genannt) für das MQTT-Protokoll, aber auch so genannte Message Queues wie Apache Kafka oder RabbitMQ, das (unter anderem) auch MQTT sprechen kann. Ich glaube daher, Du solltest dahingehend umdenken, daß Deine "Datenbank" kein RDBMS wie MySQL oder PostgreSQL sein muß und diese auch nicht sehr gut für Deine Aufgabe geeignet wären, und daß lokal ohnehin keine Datenbank, sondern nur ein Schreibpuffer benötigt wird. Und dann, ach ja: dieser Schreibpuffer kann natürlich auch eine ganz einfache Textdatei sein, wenn die Daten nicht von mehreren konkurrierenden Prozessen geschrieben werden sollen, und womöglich kannst Du die Daten auch einfach in Deine lokalen Systemlogs schreiben und sie dort wieder herauslesen, sobald die Verbindung zum zentralen Datenspeicher besteht. Die lokalen Systemlogs haben obendrein einen riesigen Vorteil: sie werden rotiert und nach einer bestimmten Haltezeit dann auch automatisch wieder gelöscht, so daß Dir die Platten nicht volllaufen! ;-)
Sheeva P. schrieb: > Die "lokale" Datenspeicherung muß also gar nicht in einer Datenbank > erfolgen, sondern ist nur eine Art Schreibpuffer, bis eine > Internetverbindung steht die Daten dann in Deine zentrale Datenbank > geschrieben und lokal gelöscht werden können. Für derartige Aufgaben wie > Deinen Schreibpuffer gibt es aber spezialisierte Software, die die Daten > zwischenpuffern kann, zum Beispiel diverse Server (dort Broker genannt) > für das MQTT-Protokoll, aber auch so genannte Message Queues wie Apache > Kafka oder RabbitMQ, das (unter anderem) auch MQTT sprechen kann. > > Ich glaube daher, Du solltest dahingehend umdenken, daß Deine > "Datenbank" kein RDBMS wie MySQL oder PostgreSQL sein muß und diese auch > nicht sehr gut für Deine Aufgabe geeignet wären, und daß lokal ohnehin > keine Datenbank, sondern nur ein Schreibpuffer benötigt wird. Und dann, > ach ja: dieser Schreibpuffer kann natürlich auch eine ganz einfache > Textdatei sein, wenn die Daten nicht von mehreren konkurrierenden > Prozessen geschrieben werden sollen, und womöglich kannst Du die Daten > auch einfach in Deine lokalen Systemlogs schreiben und sie dort wieder > herauslesen, sobald die Verbindung zum zentralen Datenspeicher besteht. > Die lokalen Systemlogs haben obendrein einen riesigen Vorteil: sie > werden rotiert und nach einer bestimmten Haltezeit dann auch automatisch > wieder gelöscht, so daß Dir die Platten nicht volllaufen! ;-) Vielen Herzlichen Dank das du mir das alles so ausführlich erklärt hast! Angenommen ich würde RabbitMQ verwenden, könnte ich damit mit einem einfachen Skript meine Daten von meine Client auf die Server Datenbank bringen? Mysql empfand ich bis jetzt als eine sehr einfache Datenbank, aus der man auch schnell die Daten in eine Webseite bringt. Aber ich komme eigendlich aus einer ganz anderen Ecke...ich programmiere ehere Mikrocontroller und SPSen.... Und ich muss zu meinen bedauern auch sagen das ich mit der ganzen Linuxwelt bzw Server und Datenbanken erst in den Kinderschuhen bin.
Ich würde die Daten lokal in CSV-Dateien mit eindeutigen Namen speichern (z.B. Gerätename + Timestamp) und dann per rsync auf den Master replizieren. Evtl. ist es auch sinnvoll jeder Zeile eine eigene UUID zu verpassen um Duplikate zu vermeiden. Auf dem Master kannst du die Daten dann entweder direkt aus CSV auslesen und in-memory analysieren (Pandas, PySpark) oder auch wenn gewünscht in eine Datenbank wie MySQL oder Elasticsearch importieren.
toscana schrieb: > Sheeva P. schrieb: >> Die "lokale" Datenspeicherung muß also gar nicht in einer Datenbank >> erfolgen, sondern ist nur eine Art Schreibpuffer [...] > > Vielen Herzlichen Dank das du mir das alles so ausführlich erklärt > hast! Sehr gerne, dazu ist so ein Forum ja da. > Angenommen ich würde RabbitMQ verwenden, könnte ich damit mit einem > einfachen Skript meine Daten von meine Client auf die Server Datenbank > bringen? Ja, kannst Du. Aber dabei kommst Du natürlich früher oder später auf die Frage, wie Du das aufbauen möchtest. Ich ganz persönlich würde damit anfangen, mir Gedanken darüber zu machen, wie mein Skript überhaupt mitbekommt, daß jetzt gerade eine Internetverbindung besteht und es bitteschön seine Arbeit tun möge. Dann muß Du Dir bei so ziemlich jeder MessageQueue-Software -- egal ob RabbitMQ, Kafka oder eine MQTT-Implementierung -- überlegen, wie das mit der Persistierung läuft. Denn eigentlich ist solche Software zunächst nicht für die Pufferung, sondern für die Verteilung der Daten gemacht, auch wenn mittlerweile alle mir bekannten Lösungen eine Möglichkeit zur Pufferung bieten. Bei MQTT nennt sich das "retained messages" und benötigt zusätzlich eine Client-Id sowie das Quality Of Service-Flag. Übrigens ist mir noch eine hübsche Lösung eingefallen, die besonders einfach und leichtgewichtig ist, nämlich ein Redis. Redis verwaltet seine Datenstrukturen im Arbeitsspeicher und ist deswegen extrem schnell; es gibt zwar auch eine Message Queue, aber würde stattdessen eine Liste oder noch besser ein Set benutzen. Darin werden neue Daten einfach eingefügt, und das Set kümmert sich um die Eliminierung eventueller Duplikate. Wenn Dein Skript dann das Signal bekommt, daß die Verbindung besteht, benennt es das Set einfach um (um zu verhindern, daß ein "Datensammler" während der Übertragung in das Set hineinschreibt), liest dann die gespeicherten Datensätze aus dem Set und überträgt sie in Deinen Internet-Datastore, und wenn dieser den Empfang aller Datensätze bestätigt hat, wird das umbenannte Set ganz einfach wieder gelöscht. Das hat auch noch einen weiteren Vorteil, neben der Atomizität: die Anzahl der Zugriffe auf die Festplatte wird minimiert. Ich weiß nicht, wie das bei Dir ist, aber wenn Deine "kleinen Linux-Geräte" so etwas wie Raspberry Pis sind, laufen sie von einer (Micro-)SD-Karte, und die vertragen bedauerlicherweise nicht unbegrenzt viele Schreibzugriffe. Trotzdem kann Redis regelmäßig Backups auf Deiner "Platte" anlegen, als Dumps zu bestimmten Zeitpunkten oder wenn eine bestimmte Anzahl von Datensätzen geschrieben wurde, oder als "Append-Only-Log". Und Redis macht das in der Standardkonfiguration ohnehin, wenn es regulär gestoppt wird... Die Sache mit den Schreibzugriffen ist übrigens auch der Grund, weshalb ich den Vorschlag von Andreas zwar grundsätzlich gut und sinnvoll finde, aber hier für diesen besonderen Anwendungsfall vermutlich eher nicht wählen würde. Und wenn, dann nur wenn die Textdateien nicht auf dem Root-Medium des RasPi gespeichert werden, sondern auf einem langlebigeren Medium -- das kann eine externe Festplatte sein, oder auch zwei USB-Sticks in einer (gespiegelten) RAID1-Konfiguration -- die USB-Sticks haben zwar dasselbe Problem der begrenzten Schreibzugriffe, aber dann ist wenigstens ein RAID1 da, das den Ausfall eines der beiden Medien erstmal überlebt und so einem Datenverlust vorbeugen sollte. Man müßte den Ausfall dann natürlich mitbekommen, nicht wahr -- und hier käme wieder Elasticsearch ins Spiel: das kann nämlich auch die Log- und Performancedaten Deiner kleinen Linux-Geräte in einer zentralen Stelle speichern, so daß Du Dir mit Kibana sehr schnell einen Überblick nicht nur über Deine Applikationsdaten, sondern auch über den Zustand der Systeme verschaffen kannst... ;-) > Mysql empfand ich bis jetzt als eine sehr einfache Datenbank, aus der > man auch schnell die Daten in eine Webseite bringt. Naja, MySQL ist ein RDBMS, wie oben beschrieben... mit allen daran hängenden Vor- und Nachteilen. Und ja, für einfache Anwendungsfälle und überschaubare Datenmengen ist das auch noch relativ performant, aber das gilt auch für alle anderen RDBMS; komplexe Anwendungsfälle und große Datenmengen können allerdings dazu führen, daß die ganze Angelegenheit in eine enorme Komplexität ausarten kann. Ich persönlich habe allerdings ohnehin so meine Schwierigkeiten mit MySQL und verwende daher seit vielen Jahren viel lieber PostgreSQL. > Und ich muss zu meinen bedauern auch sagen das ich mit der ganzen > Linuxwelt bzw Server und Datenbanken erst in den Kinderschuhen bin. Alles gut, wir alle haben mal klein angefangen, aber bei manchen ist es eben schon ein bisschen länger her... Naja, wie gesagt, für sowas ist ein Forum ja da. ;-)
Schlaumaier schrieb: > Wenn er genau DAS macht, dann brauch er nur das Datum der letzten > Übertragung speichern als ZAHL / Timestamp auf den Lokalen Gerät und die > letzte ID. Bei der nächsten Übertragung macht er folgendes. Wenn ohnehin auf beiden Seiten eine Datenbank arbeitet, muß man sich den letzten Timestamp nicht extern speichern -- und wenn man eine Datenbank hat, schon gleich gar nicht in einer INI-Datei... Begründung: man kann sich den letzten Timestamp einfach mit einer Aggregatfunktion aus der Zieldatenbank holen und dann aus der Quelldatenbank alle Datensätze selektieren, die neuer sind als dieser Timestamp. Funktioniert auch mit "last_changed"-Einträgen, die bei jeder Aktualisierung des Datensatzes auf der Quelldatenbank gesetzt werden; die Aktualisierung derartiger Felder kann mit den Datenbank-Triggern "ON INSERT" und "ON UPDATE" natürlich auch automatisch erfolgen, so daß ein Entwickler es nicht vergessen kann... ;-) Und wenn sowas trotzdem noch irgendwie speichern will, macht man sich dazu besser eine kleine Hilfstabelle in der Datenbank... ich meine, wozu habe ich eine DB und ein existierendes Connection-Handle, wenn ich meine Daten dann doch in irgendeine Textdatei schreibe? > letzter_timestamp = Lese_letzte_timestamp_aus_inidatei() > letzte_id = Lese_letzte_ID_aus_inidatei(). > > select * form Datenbank where timestamp > letzter_timestamp > > Do while > lese_daten_Satz > if ID < letzte_id then > update Datensatz_auf_server > else > lege_datensatz_an_auf_server > end if > loop In Elasticsearch würde man die Daten ohnehin nicht einzeln schreiben -- das Öffnen, Beschreiben und Schließen der Spaltenindizes ist ziemlich teuer -- sondern das als Bulk-Operation machen. Wenn man dann die _id des Datensatzes entsprechend eindeutig wählt, beispielsweise als "<hostname>:<zeitstempel>[:<sensor>]", und als Operation für den Bulk die Option "_index" (statt "_create" oder "_update"), dann macht ES genau das richtige: wenn der Datensatz noch nicht existiert, wird er angelegt, wenn er schon vorhanden ist und sich von dem neuen unterscheidet, wird er aktualisiert, und wenn er vorhanden ist und sich nicht unterscheidet, passiert gar nichts. > Zum Thema Timestamp > https://de.wikipedia.org/wiki/Unixzeit > > Der Nachteil dieser Methode ist, das man das Datum nicht in der > Datenbank mit den Auge lesen kann. Deshalb benutzte ich (siehe andern > Beitrag von mir) das zusätzliche abspeichern als Text. Was wenn mein > Prg. kein Mist baut, das Unixdatum als richtig lesbares Datum anzeigt. Äh, PostgreSQL gibt den Datentyp TIMESTAMP als menschenlesbares Datum mit Zeit und den Datentyp TIMESTAMPTZ ebenso plus Zeitzone aus:
1 | sheeva=# CREATE TABLE fart (id SERIAL, eins TIMESTAMP); |
2 | CREATE TABLE |
3 | sheeva=# INSERT INTO fart (eins) VALUES (NOW()); |
4 | INSERT 0 1 |
5 | sheeva=# SELECT * FROM fart; |
6 | id | eins |
7 | ----+---------------------------- |
8 | 1 | 2020-08-29 21:57:01.470088 |
9 | (1 row) |
Sheeva P. schrieb: > Für Elasticsearch gibt es dazu eine auf Elasticsearch > spezialisierte Websoftware namens Kibana, die direkt vom Entwicklerteam > von Elasticsearch stammt, für InfluxDB und Prometheus wird dagegen gerne > eine Webapplikation namens Kibana benutzt. Huch, ich bitte um Entschuldigung, mein Fehler: für die Visualisierung von Daten aus InfluxDB und Prometheus wird natürlich gerne die Webapplikation Grafana verwendet, nicht das auf Elasticsearch spezialisierte Kibana.
Sheeva P. schrieb: > Ja, kannst Du. Aber dabei kommst Du natürlich früher oder später auf die > Frage, wie Du das aufbauen möchtest. Ich ganz persönlich würde damit > anfangen, mir Gedanken darüber zu machen, wie mein Skript überhaupt > mitbekommt, daß jetzt gerade eine Internetverbindung besteht und es > bitteschön seine Arbeit tun möge. Guten Morgen, Ich wollte die Verbindung zum Internet prüfen indem ich in Abständen von 5 Minuten versuche einen Ping auf meinen Server mache. Aber um ehrlich zu sein weiß ich auch nicht ob das klappt? Außerdem muss ich erst lernen wie ich so ein Skript realisiere.... Sheeva P. schrieb: > Dann muß Du Dir bei so ziemlich jeder MessageQueue-Software -- egal ob > RabbitMQ, Kafka oder eine MQTT-Implementierung -- überlegen, wie das mit > der Persistierung läuft. Denn eigentlich ist solche Software zunächst > nicht für die Pufferung, sondern für die Verteilung der Daten gemacht, > auch wenn mittlerweile alle mir bekannten Lösungen eine Möglichkeit zur > Pufferung bieten. Bei MQTT nennt sich das "retained messages" und > benötigt zusätzlich eine Client-Id sowie das Quality Of Service-Flag. Also Theoretisch könnte ich eine der genannten Software installieren und dann versuchen per Shell Skript damit spielen?! Sheeva P. schrieb: > Übrigens ist mir noch eine hübsche Lösung eingefallen, die besonders > einfach und leichtgewichtig ist, nämlich ein Redis. Redis verwaltet > seine Datenstrukturen im Arbeitsspeicher und ist deswegen extrem > schnell; es gibt zwar auch eine Message Queue, aber würde stattdessen > eine Liste oder noch besser ein Set benutzen. Darin werden neue Daten > einfach eingefügt, und das Set kümmert sich um die Eliminierung > eventueller Duplikate. Wenn Dein Skript dann das Signal bekommt, daß die > Verbindung besteht, benennt es das Set einfach um (um zu verhindern, daß > ein "Datensammler" während der Übertragung in das Set hineinschreibt), > liest dann die gespeicherten Datensätze aus dem Set und überträgt sie in > Deinen Internet-Datastore, und wenn dieser den Empfang aller Datensätze > bestätigt hat, wird das umbenannte Set ganz einfach wieder gelöscht. Ich staune wie viele potenzielle Lösungen möglich sind. Für mich als Anfänger ist es aber noch schwieriger den Richtigen Einstieg zu wählen. Für mich klingt jede der genannten Lösungen gut, aber ich glaube es geht jetzt für mich hauptsächlich darum mit irgend was anzufangen...? Das Thema ist komplex und es sollte ja auch irgendwann ein kleiner Erfolg zu verbuchen sein. Danke für die Hilfe!
Beitrag #6388544 wurde von einem Moderator gelöscht.
Beitrag #6388635 wurde von einem Moderator gelöscht.
toscana schrieb: > Ich wollte die Verbindung zum Internet prüfen indem ich in Abständen von > 5 Minuten versuche einen Ping auf meinen Server mache. Aber um ehrlich > zu sein weiß ich auch nicht ob das klappt? Außerdem muss ich erst lernen > wie ich so ein Skript realisiere.... Wenn Deine Internetverbindung automatisch aufgebaut wird, ist das vielleicht keine so gute Idee. Dann würde die Verbindung nämlich durch den Ping beziehungsweise durch die vorher stattfindende DNS-Abfrage aufgebaut. > Sheeva P. schrieb: > Also Theoretisch könnte ich eine der genannten Software installieren und > dann versuchen per Shell Skript damit spielen?! Ja, genau. Mittelfristig würde ich Dir aber empfehlen, eine leistungsfähigere, moderne Skriptsprache wie Python (mein Favorit) oder auch Ruby oder Perl zu benutzen. Damit hast Du einfach viel mehr und viel elegantere Möglichkeiten. > Ich staune wie viele potenzielle Lösungen möglich sind. Für mich als > Anfänger ist es aber noch schwieriger den Richtigen Einstieg zu wählen. > Für mich klingt jede der genannten Lösungen gut, aber ich glaube es geht > jetzt für mich hauptsächlich darum mit irgend was anzufangen...? Dann würde ich empfehlen, erstmal Redis auszuprobieren. Das bringt auch direkt einen schicken Kommandozeilenclient mit, der auch einen interaktiven Modus hat. Einfach "redis_cli" aufrufen, schon bist Du im interaktiven Modus und kannst alle Befehle ausprobieren, die Redis auf seiner Website [1] unter "Commands" aufführt. Fang mit den einfachen Befehlen wie GET, SET und DEL an, um Dich ein bisschen daran zu gewöhnen, und spiel' danach mal mit den Befehlen für Sets herum. Das ist auch beim Umstieg auf eine Skriptsprache wie Python keine verlorene Investition, denn in den Client-Libraries für die verschiedenen Programmiersprachen heißen die Befehle genauso und tun natürlich auch dasselbe. Der nächste Schritt wäre dann, ein Skript für eines Deiner Linuxgeräte zu schreiben, um die Daten Deiner Sensoren in ein lokales Redis zu schreiben. Wenn Du soweit bist (und das möchtest, natürlich), kann ich gerne mal über Dein Skript schauen und Dir vielleicht ein paar Tipps und Tricks zeigen... ;-) [1] https://redis.io/ Edit: Vergessenen URL zur Redis-Website hinzugefügt.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.