Mysql Replikation

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

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

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.

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... :)

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

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! ;-)

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.

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.