93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[JoeALLb]

Stelle mir die Frage, ob man diese "Erweiterung", die von Rudi sogar als Fehler bezeichnet wurde,
von Filelog in DbLog nachziehen sollte:

https://forum.fhem.de/index.php/topic,88084

sG Joe

[blofield]

Moin @all,

da ich auch so meine Probleme mit meinem RPi3 und MySQL auf dem NAS habe:
https://forum.fhem.de/index.php/topic,88361.0.html

Hatte ich mir überlegt, ob man bei der Durchführung eines reduceLog(Nbl) o.ä. auf schwacher HW wie dem RPi aber der DB auf dem NAS, den RPi nicht komplett aussen vor lassen kann, indem man die Bereinigung/Berechnung direkt server-seitig (also auf dem NAS selbst) durchführen kann.
MySQL kennt ab ca. 5.1.irgendwas den EventScheduler mit dem man ggf. eine stored Procedure anwerfen kann.

Da (zumindest mein NAS) deutlich kräftiger als der RPi ist, würde es aus meiner Sicht Sinn machen, da man dann auch nicht die Daten hin und her zu schicken muss.
Allerdings fehlt mir das Wissen, ob und wenn ja, wie das geht.
Was sagt ihr?

blofield

[kadettilac89]

Moin @all,

da ich auch so meine Probleme mit meinem RPi3 und MySQL auf dem NAS habe:
https://forum.fhem.de/index.php/topic,88361.0.html

Ich habe mir nur die Einleitung eines Posts durchgelesen. Ich hatte ähnliche Probleme aber seit ich auf Devices einschränke läuft  es ... kannst ma testen

Code Auswählen Erweitern


set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:humidity ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:pressu% ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=Heizung_%:measured-temp ; sleep 180 ;


Einziger Nachteil ... die in den Readings gespeicherten Statistiken sind vom letzen Teil. Für mich kein Showstopper

Allerdings fehlt mir das Wissen, ob und wenn ja, wie das geht.
Was sagt ihr?

Gehen tut das sicher. Frage des Aufwands. Ggf. kannst du auch Perl auf dem NAS installieren wenn das möglich ist, dann kannst die Logik aus fhem-Modul sicher übernehmen und muss nur Teile anpassen. Du liest zwar immer noch DAten aus, aber die bleiben lokal auf dem NAS und nutzt die Resourcen die du dort hast ohne Fhem lahmzulegen.

[blofield]

Ich habe mir nur die Einleitung eines Posts durchgelesen. Ich hatte ähnliche Probleme aber seit ich auf Devices einschränke läuft  es ... kannst ma testen

Code Auswählen Erweitern


set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:humidity ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:pressu% ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=Heizung_%:measured-temp ; sleep 180 ;


Einziger Nachteil ... die in den Readings gespeicherten Statistiken sind vom letzen Teil. Für mich kein Showstopper

Danke! Werde ich mal testen.
Alternativ hatte ich mir auch überlegt auf dem NAS fhem selbst zu installieren, nur mit DbLog und dann dort das reduceLog anzuschmeißen.
Schöner wäre aber direkt in SQL

blofield

[JoeALLb]

Sind das immer die selben Arten von Daten, die ihr löschen wollt? Es gibt noch die sehr schnelle Löschmethode über Datenbankpartitionen, jedoch muss man dafür vorabgenauer planen....

SG Joe

[DS_Starter]

Hallo Joe,

wäre es denn möglich die Einrichtung von Datenbankpartitionen als Template z.B. im DbRep dem User anzubieten ?
Damit meine ich die Möglichkeit dem User eine Scriptgestützte Einrichtung/Verwaltung zu ermöglichen.
Wollte jetzt nicht vom eigentlichen Thema ablenken, fiel mir gerade so ein. Wenn ja, können wir uns vllt. im DbRep-Thread dazu austauschen.

LG,
Heiko

[blofield]

Hallo Joe,

es geht halt um das normale reduceLogNbl, um die Datenbank auszudünnen.
Ich bin auch schon über die Partitionen gestolpert hatte aber verstanden, dass die leider nicht so einfach auf den Timestamp zu machen sind - was man in diesem Falle aber ja genau möchte.
Mein RPi steigt halt aus, wenn es zuviele Daten pro Tag sind.
Ich versuche jetzt mal mit Include/Exclude ... aber es wäre ja eleganter (zumindest in Konstellation mit DB auf dem NAS) das alles nicht vom RPi machen zu lassen. Ich kenne das aus der Firma von Hadoop, da bringst Du den Rechenprozess zu den Daten und nicht anders herum Daher der Ansatz, das irgendwie in (My)SQL mit dem EventScheduler zu koppeln.

blofield

[DS_Starter]

Noch eine Idee. Je nachdem wie die Daten aussehen und  wie das Ziel ist, kannst du evtl. auch die delSeqDoublets Funktion im DbRep verwenden.

[JoeALLb]

Hallo Heiko,
hallo blofield:

wäre es denn möglich die Einrichtung von Datenbankpartitionen als Template z.B. im DbRep dem User anzubieten ?

Ja, das wäre in MySQL einfach möglich, auch ein zurückswitchen ist problemlos.
Dies funktioniert alles über ein "alter table".

Ich bin auch schon über die Partitionen gestolpert hatte aber verstanden, dass die leider nicht so einfach auf den Timestamp zu machen sind - was man in diesem Falle aber ja genau möchte.

Das ist prinzipiell korrekt, wenn man aber zB die Daten vorab schon sortiert und die Partitionierung in Wochentage unterteilt,
kann man zB alle nur zur Berechnung von Stundenwerten benötigten Daten von gestern ohne jegliche Wartezeit und fast ohne Systembelastung
innerhalb von 0.1s löschen.

Ich versuche jetzt mal mit Include/Exclude ... aber es wäre ja eleganter (zumindest in Konstellation mit DB auf dem NAS) das alles nicht vom RPi machen zu lassen. Ich kenne das aus der Firma von Hadoop, da bringst Du den Rechenprozess zu den Daten und nicht anders herum Daher der Ansatz, das irgendwie in (My)SQL mit dem EventScheduler zu koppeln.

Davon würde ich mir nicht zuviel Verbesserung versprechen, denn das aufwändige ist nicht, den "delete" prozess vom rpi an den mysql zu senden, sondern
die Daten am mySQL tatsächlich zu löschen. Da wir hier eine flache DB strucktur haben gehe ich davon aus, dass dies eher sogar länger dauert als zeitersparnis bringt.


sG
Joe

[DS_Starter]

Morgen Joe,

danke für deinen Hinweis. Dann schaue ich mir das mal bei Gelegenheit an. Dauert aber etwas weil ich mich momentan um ein paar Themen meines SSCam bzw. DbRep kümmere.
Aber die Technik wäre sicherlich etwas für den einen oder anderen MySQL-User.
Die technische Löung im Modul (wahrscheinlich DbRep) können wir uns dann im entsprechenden Thread anschauen/diskutieren.

LG,
Heiko

[blofield]

Moin Joe,

Hast Recht. Hat statt ~700s diesmal 4200s gedauert. Und reboot gab es dann auch noch. :-/

Das mit den Partitionen hört sich gut an.
Ich habe gestern noch ein bisschen mit dem Event Scheduler experiment. Für DeleteOld wäre das z.B. sehr einfach umsetzbar.
Ich werde das die Woche Mal ausgiebig testen und dann Feedback geben.

blofield

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

[JoeALLb]

Hallo Heiko, @All.

EDIT: diskussion hierrüber wird im Thread DbRep weitergeführt. (Siehe https://forum.fhem.de/index.php/topic,53584.msg808229.html#msg808229)


Anbei ein Tabellenlayout, das die Daten nach Wochentage und anschließend noch nach der neuen Spalte "Longterm" partitioniert. (Als Diskussionsgrundlage).

Code Auswählen Erweitern

CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(64) NOT NULL DEFAULT '',
`TYPE` VARCHAR(32) NULL DEFAULT NULL,
`EVENT` VARCHAR(512) NULL DEFAULT NULL,
`READING` VARCHAR(64) NOT NULL DEFAULT '',
`VALUE` VARCHAR(32) NULL DEFAULT NULL,
`UNIT` VARCHAR(32) NULL DEFAULT NULL,
`Longterm` TINYINT(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`, `Longterm`),
INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE
)
COLLATE='latin1_swedish_ci'
PARTITION BY RANGE (WEEKDAY(timestamp))
SUBPARTITION BY HASH (Longterm)
(PARTITION mon VALUES LESS THAN (1)
(SUBPARTITION monNolong ENGINE = Aria,
  SUBPARTITION monLong ENGINE = Aria),
PARTITION tue VALUES LESS THAN (2)
(SUBPARTITION tueNolong ENGINE = Aria,
  SUBPARTITION tueLong ENGINE = Aria),
PARTITION wed VALUES LESS THAN (3)
(SUBPARTITION wedNolong ENGINE = Aria,
  SUBPARTITION wedLong ENGINE = Aria),
PARTITION thu VALUES LESS THAN (4)
(SUBPARTITION thuNolong ENGINE = Aria,
  SUBPARTITION thuLong ENGINE = Aria),
PARTITION fri VALUES LESS THAN (5)
(SUBPARTITION friNolong ENGINE = Aria,
  SUBPARTITION friLong ENGINE = Aria),
PARTITION sat VALUES LESS THAN (6)
(SUBPARTITION satNolong ENGINE = Aria,
  SUBPARTITION satLong ENGINE = Aria),
PARTITION sun VALUES LESS THAN (7)
(SUBPARTITION sunNolong ENGINE = Aria,
  SUBPARTITION sunLong ENGINE = Aria)) ;


Diese Tabelle kann so jetzt schon in FHEM verwendet werden, ohne Codeänderung.
(Jedoch können die möglichen Vorteile noch nicht direkt genutzt werden.)
Somit könnte die Codeunterstützung jedoch schritt für schritt einfach ergänzt werden!

Eventuell sollte der default bei Longterm statt 0 auf 1 gesetzt werden.
(Man kann Longterm natürlich auch um die Werte 2,3,4,5, etc. ergänzen, wenn es sinn macht. Zb. analog zum Verbose level.

Beispielszenario:
Ein Insert eines Datenwertes HEUTE würde mit dieser Tabelle in der Partitionstabelle "monNoLong" landen.
Wenn ich Longterm auf 1 setzem landet er in der Partitionstabelle "monLong".

Ich packe also alle Werte, die ich nicht dauerhaft speichern möchte, in die Tabelle "*NoLong" und die anderen in "*Long".
Am Ende des Tages nehme ich die Werte aus der NoLong-Tabelle und berechne daraus meine Stundenmittel, etc.
Anschließend lösche ich sämtliche Daten (fast) verzögerungsfrei über

Code Auswählen Erweitern

ALTER TABLE history TRUNCATE PARTITION monNoLong;


Hilfreiche Codeunterstützung wäre dafür meines Erachtens nach (durchaus in dieser Reihenfolge als einzelne Punkte realisierbar):
1# Erlauben des direkten Setzens von Longterm auf definierte Werte über ein DbLogexclude/Include Attribut. 
      ((im Moment mache ich das in MySQL direkt über einen inserttrigger)))
2# Unterstützung der Tabellenkonfiguration (zB über set DbRep updateHistoryTable [no]partition)
3# Unterstutzung der neuen Löschmöglichkeiten in DbRep
4# Erlauben der Umkategorisierung von Daten von NoLong auf Long über das Modul nach gewissen Parametern.


@Heiko: Ich wollte die Antwort schon in DbRep posten, der Bezug zu DbLog ist aber fast stärker (durch die benötigte Unterstützung im DbLogInclude)....
Wo sollen wir die Diskussion aufteilen?


Edit: Fragen, die wir noch festlegen sopllten:
#1 Werden mehr als 2 Aufbewahrungszeiten (Longterm NoLongterm) benötigt? Ich bin mir hier nicht so sicher, denn die Komplexität steigt dadurch enorm.


sG
Joe

[DS_Starter]

Hi Joe,

alles was einen direkten Bezug zum Logging hat, also die Unterstützung durch "Logging nahe" Attribute wie DbLogExclude gehören ins DbLog.
Aber eigentlich ist das alles ein Datenbank Mangement Thema und gehört deswegen ins DbRep.
Auch ist das auch nur eine Thema was für die MySQL-Familie umgesetzt wird. Möglicherweise kann die Attributunterstützung auch im DbRep erfolgen und DbLog greift darauf zu sofern man die Technologie einsetzt.
Das überblicke ich momentan noch nicht, muss die Entwicklung bringen.

LG,
Heiko

[JoeALLb]

Passt, danke!
Habe den Post dorthin kopiert und hier einen Hinweis dazu hinterlassen.

[Loredo]

Zur Ermittlung der aktuellen Datenbankgröße habe ich folgende Helfer-Devices definiert:

Code Auswählen Erweitern



defmod at_DBLogging_Size at +*01:00:00 set DBLogging userCommand SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) FROM information_schema.tables;;
attr at_DBLogging_Size alias Database-Log Size
attr at_DBLogging_Size group Logging
attr at_DBLogging_Size icon edit_save
attr at_DBLogging_Size room System


defmod notify_DBLogging_Size notify DBLogging:userCommand:.SELECT.ROUND.* setreading DBLogging size [DBLogging:userCommandResult]
attr notify_DBLogging_Size alias Database-Log Size Notify
attr notify_DBLogging_Size group Logging
attr notify_DBLogging_Size icon edit_save
attr notify_DBLogging_Size room System



Man könnte das SELECT-Kommando sicherlich auch direkt ins Modul als Get-Befehl integrieren, um das Size Reading zu aktualisieren. Das würde zumindest das Notify Device ersparen






Gruß
Julian