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

[davidgross]

Hallöchen und ein frohes Neues Jahr!

Was mich damals vor ein paar Jahren gestört hatte das die DB-logs ein vielfaches (2fach, 3-fach, ich weiß es nicht mehr) der logfiles waren. Ich fand das alles ziemlich unhandlich. Im Moment habe ich 2 Raspi's mit jeweils 1GB log files.
Ich werde da die nächsten Tage nochmal etwas mit rumspielen.

Allerdings gebe ich kadettilac89 recht was die Normalisierung betrifft und würde auch nur
- Device
- Reading
- Unit
in separate Tabellen auslagern

Alles auslagern war in diesem Fall erstmal einfacher,.... weil alles das Gleiche
Klar das man sich die Speicherreduzierung mit CPU-Last erkauft.

Bis jetzt habe ich für mich noch keinen Projektstart gesetzt. Das Modul werde ich mit dem Projektnamen  DbLogNG (NG= new Generation) starten.
Das bisherige 93_DbLog wird im Grunde so bleiben wie es ist, nur Bug Fixes, Code Restrukturierung wo nötig usw habe vor umzusetzen.

Ja, so hätte ich es auch gedacht. Warum das anfassen was gut läuft...
Ich denke das man das meiste aus den originalen DBLog Codes weiterverwenden kann, und nur die direkten SQL-Routinen anfassen muss. Auch wenn ich mir den Code noch nicht angeschaut habe. Ich als Hobby-Programmierer tue mich immer etwas schwer in Code von anderen rumzuwühlen.

Ich experimentiere mal noch etwas weiter. Tabellen erstellen, Daten schreiben, Exportieren, Sichern, alte logfiles importieren funktioniert auf meinem alten RPI 1 testweise schon mal recht gut. Mal schauen ob ich auch Trends anzeigen kann.
Ich hätte auch nicht gedacht das ich innerhallb weniger Tagen nebenbei soweit komme.

VG

[DS_Starter]

Ich denke das man das meiste aus den originalen DBLog Codes weiterverwenden kann, und nur die direkten SQL-Routinen anfassen muss.

Leider nein. Es hat sich viel Ballast angesammelt über viele Jahre der in einem Log-Device eigentlich nichts zu suchen hat und ausgebaut werden soll. Der Code ist auf Packages umzustellen und zu testen,testen,testen ... (für alle unterstützen Datenbanken und nicht nur MariaDB, also auch SQLite und PostgreSQL ! )
Dann ist die Verbindungsinformation über das cfg-File ungünstig (fehleranfällig und Paßwort zu lesen) und soll geändert werden.
Nicht zuletzt sind Pflegeroutinen zu erstellen um Daten auszudünnen bzw. allgemein zu pflegen, d.h. entsprechend in DbRep zu integrieren. Außerdem war der Wunsch noch InfluxDb zu integrieren.
Da kommt bestimmt noch mehr zusammen.

LG

[Ellert]

@DS_Starter:
Mir ist folgender Eintrag im Log aufgefallen:

DbLog logdb - WARNING - "deleteOldDaysNbl" is outdated. Please consider use of DbRep "set <Name> delEntries" instead.

Ich beschränke die vorgehaltenen Daten auf 14 Tage und benutze die Funktion "deleteOldDaysNbl" von DBLog. DBRep benötige ich nicht.

Wenn diese Funktion in DBLog entfällt, dann müsste ich das mit 1 MB grösste in FHEM  vorhandene Modul installieren, nur um die Datenbank zu reduzieren. Das ist aus meiner Sicht keine Optimierung.

Daher meine dringliche Bitte, lass deleteOldDaysNbl in DBLog, bitte!

[DS_Starter]

Moin Ellert,

Wenn diese Funktion in DBLog entfällt, dann müsste ich das mit 1 MB grösste in FHEM  vorhandene Modul installieren, nur um die Datenbank zu reduzieren. Das ist aus meiner Sicht keine Optimierung.

Daher meine dringliche Bitte, lass deleteOldDaysNbl in DBLog, bitte!

Keine Sorge, es ist nicht geplant die Funktion zu entfernen. Aber bestimmte Funktionen, die im DbLog nicht zum eigentlichen Logging gehören werden von mir nicht weiterentwickelt, sondern stehen mit erweiterten Möglichkeiten im DbRep zur Verfügung. Deswegen der Hinweis für die User, dass die Funktion veraltet ist.

Grüße,
Heiko

[Guybrush]

Hallöchen,

ich habe mich die letzten Tage dem erstellen einer neuen DB ein wenig angenommen und mal ein kleines Grundgerüst erstellt, welches auf Basis von MariaDB eine DB anlegt, Tabellen erstellt und Daten in die Tabellen speichern kann.
Hier in den einzelnen Tabellen soll es nix doppeltes geben. Im Idealfall werden pro Logeintrag nur noch 5 Zahlen abgespeichert:
MariaDB [fhemlog]> select * from Log01;
+----------+--------------+-----------+------------+--------------+
| Log01_ID | Timestamp_ID | Device_ID | Reading_ID | ReadValue_ID |
+----------+--------------+-----------+------------+--------------+
|        1 |            1 |         1 |          1 |            1 |
|        2 |            1 |         1 |          1 |            1 |
|        3 |            4 |         1 |          4 |            4 |
|        4 |            5 |         5 |          5 |            5 |
|        5 |            6 |         5 |          5 |            6 |
|        6 |            7 |         5 |          5 |            7 |
|        7 |            8 |         5 |          5 |            8 |
|        8 |            9 |         5 |          5 |            9 |
+----------+--------------+-----------+------------+--------------+

Ich habe die Scripte angehängt.
Eine Abfrage der Daten, also das wieder einlesen habe ich noch nicht angefangen.
Auch wünschenswert ein Import aus alten log files und der alten db habe ich noch nix gemacht.

Guten Rutsch!

Es ist immer eine Abwegung zwischen Speicher HDD, Speicher RAM und CPU Usage. Je mehr joins erforderlich sind um Datensätze auszulesen, umso mehr I/O sind nötig. Insbesondere werden die Indexe (HDD Speicher) dadurch um ein vielfaches größer, da du dann indizierte Werte redundant vorhalten musst. Alles in separate Tabellen auszulagern halte ich nicht für glücklich, da die meisten FHEM eher auf Einplatinen PCs wie raspberry pi laufen haben. Ich nutze z.b. einen mit einer SSD. Logging auf einer SD Karte zu machen ist nicht so schlau - egal ob man logfiles oder logdb nutzt. Daraus folgt dann aber auch, dass HDD Speicher nicht das entscheidende sein kann, sondern nur Ram + CPU Auslastung.

Die Datenstruktur der history table ist sicherlich optimierbar. Die Felder Device, Type, Reading und Unit auszulagern wäre ggf. zu überlegen. In der history Tabelle bräuchte man dann nur noch ids als smallint (default) speichern, was dann jeder individuell auch noch auf tinyints reduzieren könnte, was insbesondere bei type/reading möglich sein dürfte. Die Kardinalität ist hier eher sehr gering. Jedenfalls bezweifle ich, dass es eine Notwendigkeit gibt, dass man dort tausende verschiedene Werte benötigt. Ob man diese Werte dann in jeweils eigene Tabellen auslagert oder eine einzelne Attribut Tabelle macht hängt davon ab, wie man die Daten verarbeiten/selektieren will. Auch hier muss man dann Aufwand/Nutzen abwiegen.

Ob die Spalte Event wirklich gebraucht wird, weiß ich nicht. Ich meine DS_Starter meinte mal, dass die nur aus historischen Gründen drin ist, weil das an einzelnen Stellen noch im Code wäre. Am wichtigsten sind jedenfalls timestamp, device, value. value nur noch als id zu speichern und dann über einen left join auszulesen halte ich aber für unperformant. Hinzu kommt, dass man hier 3x soviel datenvolumen hat wegen der dann notwendigen valueid (2x felder + index). Der einzige Vorteil wäre, dass die Tabelle dann statisch und nicht mehr flexible wäre, was die Datenselektion etwas beschleunigen könnte. Das kommt aber nur dann zum tragen, wenn der Index der History Tabelle nicht Hot Cached ist, also nicht mehr in den RAM passt. Durch die Änderung von Device und Reading von varchar zu int hin würde das aber bei den meisten 10+ jahre dauern, bis das der Fall ist und bis dahin dürfte wieder viel bessere Hardware zur Verfügung stehen?

Am Ende stellt sich die Frage, was man möchte. Einfach nur einen Ersatz für DBLog zu schreiben halte ich für vertane Zeit. Sicherlich könnte man dblog anders strukturieren, wenn man es heute nochmal von neuem entwickeln müsste. Aber es funktioniert und für mutmaßlich 95% der Nutzer reicht es doch vollkommen aus und der verbleibende Teil mit größeren Installationen hat im Zweifel auch genug Geld sich einfach bessere Hardware hinzustellen . Alternative DBs zu unterstützen halte ich auch für verschwendete Zeit. Die meisten nutzen ohnehin nur mysql und nur weil einzelne Nerds (nicht böse gemeint) meinen, eine andere DB wäre toller... Nunja, mysql ist nicht umsonst im Bereich der relationalen Datenbanken der Standard. Aus meiner Sicht gibt es jedenfalls keinen sachlichen Grund nicht mysql/mariadb zu nutzen. Bleibt also die Frage wer ein neu entwickeltes dblog wirklich braucht.

Ich fänds jedenfalls auch schöner, wenn man den speicherbedarf reduzieren könnte. Meiner Meinung nach würde es aber erstmal genügen spalten wie Event zu entfernen. Als weiteren Schritt wäre zu überlegen, ob man dblog fürs debugging (auch) nutzen will oder es "nur" für Plots verwenden möchte. Im letzteren Fall könnten Type, Reading und Unit auch entfernt werden.

Das bringt mich zumindest zum überlegen, ob es nicht vielleicht sinnvoller wäre neben der history table einfach noch eine weitere tabelle nur mit den spalten timestamp, device und value zu pflegen und hier über ein attribut je device zu bestimmen, ob ein Event nur in dieser, in beiden oder nur in history gespeichert werden soll. Soweit ich den Code überblicke, wäre sowas jedenfalls relativ einfach umzusetzen und würde für die meisten Fälle eine erhebliche Optimierung mit sich bringen. In der history table könnte man dann z.b. viel einfacher alte Werte löschen, weil man diese dann ja eigentlich nur noch fürs debugging bräuchte. So bliebe alles bisherige kompatibel und man könnte gezielt für plots eine optimierung vornehmen ohne viel Aufwand betreiben zu müssen. Der Aufwand für einen DBLog Nachfolger mit den hier angedachten Ideen ist ja sicher der Grund dafür, warum es immer noch nicht in Angriff genommen wurde - was absolut nachvollziehbar ist