Forum: PC-Programmierung Mysql Replikation


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von toscana (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von georg (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Bernd S. (soundgott)


Bewertung
1 lesenswert
nicht lesenswert
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

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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

von Imonbln (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von toscana (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von toscana (Gast)


Bewertung
0 lesenswert
nicht lesenswert
gibt es gute Literatur dazu?

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dirk K. (merciless)


Bewertung
1 lesenswert
nicht lesenswert
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

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Klaus P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
Also, ich fass die Anforderung mal zusammen:

Es gibt mehrere Geräte, die Daten Loggen

z.B
Gerät1:
"2020-08-27 14:00",22.5°C
"2020-08-27 14:10",22.0°C

Gerät2:
"2020-08-27 14:00",20.0°C
"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:
"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?


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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
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.

von toscana (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ε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?

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Jan L. (ranzcopter)


Bewertung
2 lesenswert
nicht lesenswert
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... :)

von toscana (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Dirk K. (merciless)


Bewertung
1 lesenswert
nicht lesenswert
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
von Schlaumaier (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Schlaumaier (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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! ;-)

von toscana (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (andreas) (Admin) Benutzerseite Flattr this


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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:
sheeva=# CREATE TABLE fart (id SERIAL, eins TIMESTAMP);
CREATE TABLE
sheeva=# INSERT INTO fart (eins) VALUES (NOW());
INSERT 0 1
sheeva=# SELECT * FROM fart; 
 id |            eins            
----+----------------------------
  1 | 2020-08-29 21:57:01.470088
(1 row)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von toscana (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.