Autor Thema: 93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)  (Gelesen 65444 mal)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3146
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #765 am: 08 Oktober 2018, 19:04:16 »
Hi Joe,

die Aufteilung in mehrere Tabellen hatte ich auch schon mal kurz auf dem Schirm.
Aber ich habe das ganz schnell wieder verworfen als ich an die Arbeit gedacht habe, die mir das im DbRep bescheren würde wenn ich sowohl die Tabellenstruktur des bisherigen DbLog UND die Struktur über mehrere Tabellen in einem neuen Modul unterstützen müsste, und das noch für verschiedene Datenbanksysteme.
Das wäre mir momentan echt zuviel  ;)

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline Bond246

  • Jr. Member
  • **
  • Beiträge: 70
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #766 am: 12 Oktober 2018, 00:14:40 »
Hallo zusammen,

ich würde in meiner bestehenden Datenbank (Synology mit mariadb10) gerne einen Primary Key hinzufügen.
Leider werden dabei die ein oder anderen doppelten Einträge gefunden, was das Vorhaben verhindert.

Im anderen Thread ist es schon kurz angesprochen. https://forum.fhem.de/index.php/topic,68646.30.html
Mit dem Hinweis von DS_Starter hab ichs auch probiert, ohne Erfolg:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
delSeqDoublets hab ich in einem kurzen Zeitraum ausprobiert, mit dem Ergebnis das nahezu alle Daten aus dem Zeitraum gelöscht wurden, vermutlich weil delSeqDoublets nur auf Device,Reading and Value prüft, nicht aber auf den Timestamp. Und gerade bei Value-States eines Thermostats gibt es ja über längere Zeiträume auch gleiche Zustände. Solange pro Zeitstempler ein Wert ist, ist das ja auch OK.

Meine gelöschten Daten muss ich jetzt aus einem Backup wiederherstellen. Aber anderes Thema.

Wäre es ein Lösungsweg, die Datenbank zu sichern, dann komplett zu löschen, mit Primary Key neu anzulegen und dann die alten Daten wieder rückwärts zu importieren?

Wie könnte ich in der Zwischenzeit dafür sorgen, dass die anfallenden Daten irgendwo zwischengespeichert werden um währen des Prozederes keine Daten zu verlieren?

Besten Dank,
Bond

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3146
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #767 am: 12 Oktober 2018, 10:50:49 »
Hallo Bond,

Zitat
delSeqDoublets hab ich in einem kurzen Zeitraum ausprobiert, mit dem Ergebnis das nahezu alle Daten aus dem Zeitraum gelöscht wurden, vermutlich weil delSeqDoublets nur auf Device,Reading and Value prüft, nicht aber auf den Timestamp. Und gerade bei Value-States eines Thermostats gibt es ja über längere Zeiträume auch gleiche Zustände. Solange pro Zeitstempler ein Wert ist, ist das ja auch OK.
Die Funktion delSeqDoublets macht etwas mehr als "nur" doppelte Datensätze löschen. Wie genau es wirkt, ist in der commandref detailliert beschrieben. Es gibt auch einen Testlauf vorher mit "delSeqDoublets adviceDelete".  Ich hätte dich vermutlich explizit nochmal darauf hinweisen sollen vorher die commandref zu lesen und das dort beschriebene Beipiel anzuschauen. Sorry ... mein Fehler.

Werde wohl noch eine Funktion ins DbRep einbauen, die ausschließlich doppelte (mehrfache) Datensätze bereinigt.

Zu deinem eigentlichen Thema.

Ich würde mit einer Standby-Datenbank arbeiten.

1. Neue DB (z.B. fhempk) anlegen und dort den PK wie beschrieben mit anlegen für die history.
2. ein DbLog-Device Log.fhempk für diese DB anlegen was einsatzbereit ist, aber so einstellen das nichts geloggt wird (Regex im DEF z.B. aaaaaa:bbbbbbb).
3. ein Dbrep-Device anlegen was mit produktiven Datenbank verbunden ist.
4. mit dem Befehl "syncStandby Log.fhempk" alle Datensätze in die Standby-DB übertragen. Doppelte Datensätze werden durch den PK
   automatisch ignoriert. Der produktive Betrieb wird nicht behindert und kann weiter laufen.
   Je nach Größe der DB kann das einige Zeit in Anspruch nehmen. Vorher Commandref lesen !
5. vermutlich wird es dann noch einen Datengap geben, der zwischen Start und Ende des syncStandby-Befehls liegt. Dann einfach diesen Zeitraum nochmal mit syncStandby und gesetzten Zeitattributen nachfahren
6. Sind alle Daten übertragen, das Device Log.fhempk disabled setzen und das bisherige produktive DbLog mit der neuen DB fhempk verbinden (db.cfg editieren).

Dann hättest du deine Daten relativ stressfrei umgezogen und fortan einen PK der doppelte Einträge in der DB verhindert.

Edit: Das Verfahren hat auch den Vorteil, dass man üben kann. Die Standby-DB aufbauen, schauen wie alles gelaufen ist, die Tabellen droppen und nochmal beginnen. Das kann man so oft wiederholen wie man es wünscht. Die produktive DB läuft in der Zeit munter weiter.

Grüße,
Heiko


« Letzte Änderung: 13 Oktober 2018, 19:54:58 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1473
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #768 am: 12 Oktober 2018, 11:36:10 »
So wie hier beschrieben würde es natürlich auch gehen, mit eventuell etwas weniger aufwand....

https://forum.fhem.de/index.php/topic,65860.msg571050/topicseen.html#msg571050

In Punkt 1 kannst Du dann die Tabelle vorab ja noch anpassen und den PK setzen.

sG Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline Bond246

  • Jr. Member
  • **
  • Beiträge: 70
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #769 am: 14 Oktober 2018, 15:35:09 »
So wie hier beschrieben würde es natürlich auch gehen, mit eventuell etwas weniger aufwand....

https://forum.fhem.de/index.php/topic,65860.msg571050/topicseen.html#msg571050

In Punkt 1 kannst Du dann die Tabelle vorab ja noch anpassen und den PK setzen.

sG Joe

Danke, so hab ich es jetzt gemacht.
Zuerst eine neue historyNEW angelegt, dann die aktuelle in historyOLD umgebannt und dann hab ich alle Daten von OLD zur neuen umgezogen mit dem aktiven privateKey.

Besten Dank.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3146
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #770 am: 09 November 2018, 21:32:24 »
Hallo zusammen,

zur Beseitigung von doppelten Datensätzen gibt es nun eine einfache Möglichkeit mit DbRep.

Im contrib Verzeichnis

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

gibt es eine neue DbRep-Version die den Befehl

set <name> delDoublets [adviceDelete | delete]


enthält. Mit der "delete" Option werden die doppelt oder mehrfach vorhandenen Datensätze gelöscht.
Wenn man noch keinen PK gesetzt hat und sich doppelte Records in der DB befinden, kann man folgendermaßen vorgehen um einen PK setzen zu können.

Erstmal die DB für das Logging (genügend lange) schließen:

set <DbLog> reopen 86000

Wie bekannt, gehen die Daten während dieser Zeit nicht verloren und werden nachgebucht, wenn DbLog im asynchronen Modus betrieben wird.
Dann die doppelten Datensätze entfernen:

set <DbRep> delDoublets

Das dauert nun je nach Größe und Performance eine gewissse Zeit.
Dann den PK setzen, für MySQL/MariaDB:

set <DbRep> sqlCmd ALTER TABLE 'history' ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

DbLog wieder zum Logging öffnen:

set <DbLog> reopen

Jetzt wird die DB von doppelten Datensätzen verschont.
Die delDoublets-Funktion kann man natürlich auch zum regelmäßigen Pflegen des Datenbestandes nutzen.
Wenn ich genügend getestet habe, checke ich die Version auch ein.
Siehe auch hier: https://forum.fhem.de/index.php/topic,53584.msg856008.html#msg856008

Grüße
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3146
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #771 am: 10 November 2018, 07:57:51 »
Guten Morgen,

Im contrib-Verzeichnis:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

liegt eine DbLog-Version die DbLogInclude mit berücksichtigt. Die Anforderung geht zurück auf diesen Thread:
https://forum.fhem.de/index.php/topic,92854.msg854173.html#new

set <name> addLog <devspec>:<Reading> [Value] [CN=<caller name>] [!useExcludes]

 Fügt einen zusätzlichen Logeintrag einer Device/Reading-Kombination in die Datenbank ein. Die eventuell in den Attributen "DbLogExclude" spezifizierten Readings (im Quelldevice) werden nicht nicht geloggt, es sei denn sie sind im Attribut "DbLogInclude" enthalten bzw. der addLog-Aufruf erfolgte mit der Option "!useExcludes".
....

Bitte testet die Erweiterung auch mal bei euch.

Grüße
Heiko

ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz