Probleme mit Logdb

[DS_Starter]

Hallo Christian,

sehr schön, dass du alles geschafft hast. 

Die Geschwindigkeit der SQL-Abfrage ist nicht besonders gut. Das liegt aber nicht an deiner DB, sondern daran, dass ein select mit einer Like-Statement und wildcard  deutlich langsamer ist als "=".
Also wenn es geht, besser auf Like mit "%" verzichten und das Statement so wählen, dass die DB den Index nutzen kann.
Manchmal gehts aber auch nicht anders.

Setz dir im DbLog das Attr showproctime=1. Dann siehst du Readings sql_processing_time. Die geben dir ein Gefühl wie schnell deine Db schreibt. Sollte im 0,x Sekundenbereich liegen.
Damit du die DB von FHEM entkoppelst, kannst du auf asynchron umschalten (asyncMode=1) und das Attr bulkInsert=1 kann dir nochmal einen Schub geben wenn du ohne current-Tabelle arbeitest.

Gibt es eine Sammlung der Besten mysql Skripte? z.B.
- Alle Werte eines Devices am Montag um 8:00 Uhr oder den naechsten, der nahe 8:00 Uhr liegt?
- Bildung von Tages, Wochen und Monatswerten
- Liste aller Devices (habe ich schon)
- ...

Eine Sammlung als solche gibt es m.W. nicht, aber vieles davon kannst du mit DbRep erledigen.
Z.B. ist die Bildung von Tages, Wochen und Monatswerten als Funktionalität eingebaut.

Ebenso kannst du Werte eines Device/Readings zu einem bestimmten Zeipunkt oder dem nächstgelegenen zu diesem Zeitpunkt liegenden Datenwert liefern lassen. -> Stichwort dbReadingsVal

Sobald du ein DbRep-Device definiert hast, gibt es dbReadingsVal. Einfach mal help eingeben oder in die commandref von DbRep reinschauen. Ist gleich zu Beginn beschrieben.

Daneben gibt es im DbRep ein paar vorgefertigte SQL unter set ... sqlSpecial, z.B.:

50mostFreqLogsLast2days  : ermittelt die 50 am häufigsten vorkommenden Loggingeinträge der letzten 2 Tage
allDevCount                      : alle in der Datenbank vorkommenden Devices und deren Anzahl
allDevReadCount               : alle in der Datenbank vorkommenden Device/Reading-Kombinationen und deren Anzahl

Dort stelle ich allgemein interssierende Auswertungen zur Verfügung. Diese Sammlung kann ich gerne erweitern wenn etwas konkretes benötigt wird.

Ansonsten gibt es DbRep im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten

Das wäre auch ein guter Platz um SQL's gesammelt zusammenzutragen.

Grüße,
Heiko

[ch.eick]

Hallo Heiko,

vielen Dank für die vielen Tipps, ich arbeite mich da natürlich noch durch. Die Wünsche sind schneller als die Umsetzung DbRep stand schon auf der Liste.

Die Geschwindigkeit der SQL-Abfrage ist nicht besonders gut. Das liegt aber nicht an deiner DB, sondern daran, dass ein select mit einer Like-Statement und wildcard  deutlich langsamer ist als "=".
Also wenn es geht, besser auf Like mit "%" verzichten und das Statement so wählen, dass die DB den Index nutzen kann.
Manchmal gehts aber auch nicht anders.

Okay, optimiert wäre es dann so, es sieht jedoch etwas unbeholfen aus

Code Auswählen Erweitern


select * from history where DEVICE = 'PV_Anlage_1' and TIMESTAMP like "2020-02-25%";
9590 rows in set (51.956 sec)

MySQL [fhem]> select * from history where DEVICE = 'PV_Anlage_1' and TIMESTAMP > "2020-02-25_00:00:00" and  TIMESTAMP < "2020-02-26_00:00:00";
9590 rows in set (0.184 sec)

Aber das Ergebnis spricht für sich

[DS_Starter]

0.184 sec. ... Das sieht freundlich aus 

Besser unbeholfen und schnell als schick und schneckenlangsam 

[ch.eick]

0.184 sec. ... Das sieht freundlich aus 

Besser unbeholfen und schnell als schick und schneckenlangsam 

Mein O...le Kollege hat es mir nochmal erklärt:
- die Spalte TIMESTAMP ist vom Type timestamp
- bei der Suche mit LIKE und % wird der Type string verwendet und kann intern nicht auf den Type timestamp gewandelt werden.
- somit wird TIMESTAMP auf Type string gewandelt und dann mit dem Wildecard verglichen

- Bei der zweiten Suche wird der Vergleichsstring einmal in den Type timestamp gewandelt
- anschließend kann die Suche dann über den INDEX erfolgen, wo die Werte in der Spalte TIMESTAMP bereits sortiert vorliegen

Viele Grüße
     Christian

[DS_Starter]

Jepp, zum Thema Datenbanken , Performance und SQL Gestaltung gibt es endlos viel Material im Netz. Da kann man sich sehr damit beschäftigen. Manchmal streiten sich auch die Experten 

Vielleicht hat dein O...le Kollege noch ein paar schöne SQL auf Lager die man in DbRep als sqlSpecial einbauen könnte falls Bedarf besteht.

[ch.eick]

Vielleicht hat dein O...le Kollege noch ein paar schöne SQL auf Lager die man in DbRep als sqlSpecial einbauen könnte falls Bedarf besteht.

Ich schau mir erst mal an, was drin ist und scheue mich nicht optimieren zu lassen oder zu erweitern
Du hast ja jetzt noch einen Kontakt zum Riesen.

[DS_Starter]

OK ... Thema optimieren ... nicht vergessen alle SQL müssen auch unter SQLite und PostgreSQL laufen ! 

Riesen ??

[ch.eick]

Riesen ??

O...le , die mit der Datenbank

OK ... Thema optimieren ... nicht vergessen alle SQL müssen auch unter SQLite und PostgreSQL laufen ! 

Gut, dass schränkt dann wiederum ein.

[DS_Starter]

O...le , die mit der Datenbank

Man muss es nur richtig lesen. 

Ja, manchmal baue ich die SQL auch DB spezifisch ins Modul ein. Das mache ich aber davon abhängig wie viel Programmieraufwand es für mich bedeutet. Wenn es zu aufwändig wird oder der Aufwand nicht im Verhältnis zum Nutzen steht akzeptiere ich eher einen Kompromiss. Ein paar Millisekunden mehr oder weniger sind in unserem Umfeld dann doch nicht so ausschlaggebend.

[DS_Starter]

Vielleicht jetzt etwas OT ... kennst du den Thread zu DbRep ?

https://forum.fhem.de/index.php/topic,53584.msg452567.html#msg452567

Dort kannst du allgemeine Dinge zum Modul kommunizieren, z.B. bezüglich SQL. Möglicherweise ist dein Kollege auch mit FHEM aktiv ...

[ch.eick]

Vielleicht jetzt etwas OT ... kennst du den Thread zu DbRep ?

https://forum.fhem.de/index.php/topic,53584.msg452567.html#msg452567

Dort kannst du allgemeine Dinge zum Modul kommunizieren, z.B. bezüglich SQL. Möglicherweise ist dein Kollege auch mit FHEM aktiv ...

Ist er nicht, aber ich werde da sicher auch auftauchen.
DbRep läuft schon und ich arbeite mich durch die wiki Doku....

Vielen, vielen Dank, Du hast mir den Einstieg sehr vereinfacht.
    Christian

[Wzut]

Ich bin z.Z. dabei eine "etwas" ältere FHEM Instanz umzuziehen. DB_Log  hat die ID (15517 2017-11-28 20:22:56Z)  und läuft mit DbLogType Current/History. Mein Problem nun : die neue Version hat in Current und History die gleichen Daten, bei der alten stand in Current nur der zuletzt übertragene Wert eines Readings , wie der Name eigentlich schon sagt : Current.
Gibt es eine Chance das die neuere Version auch wieder so arbeitet oder muß ich die alte DBLog Version mit rüber nehmen ?   

[DS_Starter]

Hallo Wzut,

das Updateverhalten hat sich schon lange nicht geändert. Auch in der aktuellen Version stehen in der current Tabelle immer die letzten bzw. aktuellsten Werte einer spezifischen Device/Reading Kombination.
Ich habe es gerade bei mir nochmal kontrolliert und ist auch so.
Habe es auf meiner MariaDB gecheckt. Würde mich jetzt wundern wenn es auf einem anderen Typ nicht so wäre.
Gib mal noch ein paar Infos zu deiner.

[ch.eick]

Hi,
ich hatte zwar nur kurz current/history aktive, aber da waren nur wirklich die letzten readings zu sehen.
Soll ich das nochmal aktivieren, um es zu testen?

Gesendet von meinem SM-G930F mit Tapatalk

[DS_Starter]

   ... mach mal Christian. Bei mir ist es so wie du es auch bestätigt hast.