Hallo zusammen,
ich migriere bei uns gerade alles von dem Gira-M*** weg... Das dateibasierte Loging in FHEM ist allenfalls für kleinere Installationen angezeigt. Dementsprechend gibt es kaum eine Alternative zur datenbankbasierten Protokollierung. Das läuft insoweit auch alles wunderbar. Mir ist allerdings aufgefallen, dass die Datenbankstruktur der history Tabelle schräg erscheint. Vielleicht erkenne ich auch einfach nur den Sinn dahinter nicht. Im Nachfolgenden geht es nur um MySQL.
Die vorgegebene Struktur sieht ja wie folgt aus:
CREATE TABLE `history` (
`TIMESTAMP` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`DEVICE` varchar(64) DEFAULT NULL,
`TYPE` varchar(64) DEFAULT NULL,
`EVENT` varchar(512) DEFAULT NULL,
`READING` varchar(64) DEFAULT NULL,
`VALUE` varchar(255) DEFAULT NULL,
`UNIT` varchar(32) DEFAULT NULL,
KEY `IDX_HISTORY` (`DEVICE`,`READING`,`TIMESTAMP`,`VALUE`),
KEY `DEVICE` (`DEVICE`,`READING`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Daten werden abgelegt wie folgt:
select * from history limit 1;
+---------------------+-----------------------------------+------+---------------------+---------+-------+--------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
+---------------------+-----------------------------------+------+---------------------+---------+-------+--------+
| 2020-05-21 00:05:42 | ***.Temperatur.IST | KNX | state: 24.08 °C | state | 24.08 | °C |
+---------------------+-----------------------------------+------+---------------------+---------+-------+--------+
Wenn man nun viel protokolliert, können da ganz schnell hunderttausende Einträge/Tag zukommen. Ich habe das bei mir insoweit schon weitestgehend auf die wirklich nötigsten Daten beschränkt, was aber immer noch sehr viel ist. Es scheint hier ja nicht wenige zu geben, die in ihrer Datenbank 10 Mio und mehr Einträge haben. Meiner (ersten) Analyse nach gibt es einige Punkte, die unnötigerweise eine dramatische Auswirkungen auf die Performance größerer Datenbanken haben dürften. Da es ja möglich ist, dass dahinter ein Sinn steht, den ich vielleicht noch nicht entdeckt hab, nachfolgende Fragen:
1. Wieso gibt es einen Index DEVICE? Device, Reading sind bereits im Index IDX_HISTORY enthalten, der entsprechend genauso greift. Der Index DEVICE ist dementsprechend überflüssig.
2. Wozu gibt es die Spalte EVENT? Das ist doch nichts anderes als ein CONCAT(READING, ': ', VALUE, ' ', UNIT) ? Das ist ein Varchar(512) und macht z.m. bei mir ca. 15% der Größe aus, obwohl da nur redundantes Zeug drin steht.
3. Warum wird eine dynamische Datenstruktur genutzt? Grundsätzlich wäre es doch erheblich schneller, wenn die Datenstruktur für die Selektion Fix wäre. Das bedingt natürlich joins.
4. Die Indexe scheinen nicht gut zu passen. Z.b. selektieren Plots u.a. so:
SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1 AND DEVICE = 'Wetterstation.Helligkeitsensor1' AND TIMESTAMP >= STR_TO_DATE('2020-05-26 08:55:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2020-05-27 08:54:59', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP;
Hier greift der Index IDX_HISTORY nicht vollständig. Der ist nach DEVICE, READING, TIMESTAMP, VALUE sortiert. Genutzt würde aber nur DEVICE. Eine weitere Einschränkung anhand des Indexes erfolgt dann nicht. Für dieses Query wäre z.b. ein Index (nur) auf DEVICE, TIMESTAMP deutlich performanter.
5. Wäre eine eine Datenstruktur (Indexe nicht berücksichtigt) nicht sinnvoller, die so ähnlich aufgebaut wäre:
CREATE TABLE `history` (
`TIMESTAMP` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`DEVICE_ID` smallint(16) UNSIGNED,
`TYPE_ID` smallint(16) UNSIGNED,
`READING_ID` smallint(16) UNSIGNED,
`VALUE_ID` int(32) UNSIGNED,
`UNIT_ID` smallint(16) UNSIGNED
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `device` (
`DEVICE_ID` smallint(16) UNSIGNED AUTO_INCREMENT,
`DEVICE` varchar(64),
PRIMARY KEY (DEVICE_ID, DEVICE)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `type` (
`TYPE_ID` smallint(16) UNSIGNED AUTO_INCREMENT,
`TYPE` varchar(64),
PRIMARY KEY (TYPE_ID, TYPE)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `reading` (
`READING_ID` smallint(16) UNSIGNED AUTO_INCREMENT,
`READING` varchar(64),
PRIMARY KEY (READING_ID, READING)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `value` (
`VALUE_ID` int(32) UNSIGNED AUTO_INCREMENT,
`VALUE` varchar(255),
PRIMARY KEY (VALUE_ID)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `unit` (
`UNIT_ID` smallint(16) UNSIGNED AUTO_INCREMENT,
`UNIT` varchar(32),
PRIMARY KEY (UNIT_ID, UNIT)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Das mag vielleicht als Overkill aussehen und sicherlich für kleine Installationen auch nicht notwendig, aber gerade bei größeren Datenmengen wäre eine Selektion auf die History Tabelle so um Faktoren schneller - die dann notwendigen Joins fallen da kaum ins Gewicht - zumal das alles mit Ausnahme von Value gecached werden könnte. Ein anderer Vorteil wäre auch, dass die Datenmenge nicht mehr linear skaliert, sondern deutlich reduziert würde.
Hat sich damit schon mal jemand beschäftigt bzw. unterliege ich irgendeinem Fehlverständnis? Ich habe FHEM ja noch nicht lange im Einsatz und mag daher sicher vieles noch nicht kennen...
LG
Andreas
ZitatDas dateibasierte Loging in FHEM ist allenfalls für kleinere Installationen angezeigt.
Ab wann redet man so von grossen Installationen?
Zitat von: rudolfkoenig am 27 Mai 2020, 10:55:12
Ab wann redet man so von grossen Installationen?
Das ist ja eine relative Frage... Ich hab bei mir alleine ca. 200 KNX Geräte, 80 1-Wire Sensoren,10 Modbus und ansonsten noch wie Zigbee/HUE etc. Ich hab ehrlich gesagt keine Ahnung von was für Größenordnungen ihr sonst ausgeht und ob ich mit meiner Installation hier etwas übers Ziel hinausgeschossen bin.. :-)
Ich hab insoweit laut FHEM auch 1013 Devices angelegt (Großteil kommt durch KNX Adressen)
Eine Installation mit ueber 1000 Geraeten ist selten, ich habe aber auch mit doppelt so grossen Konfigurationen zu tun gehabt.
Falls irgendwo wg. dem Framework Engpaesse sichtbar werden, bitte melden.
Exportiere doch ganz einfach das db-log und baue dir extern deine Struktur neu auf. Auf dem T-SQL-Server klappt das wunderbar
Gesendet von meinem Pixel 4 mit Tapatalk
Hallo Andreas,
erstmal vielen Dank dass du dir Gedanken um Verbesserungen machst.
Ganz allgemein ist zu DbLog zu sagen, dass dieses Modul bereits mindestens 10 Jahre im Einsatz ist und bereits einiges "durchlebt" hat. Die Tabellenstruktur wie sie momentan ist, würde ich nur in einem kompletten Neuansatz mit einem weiteren Modul (sagen wir DbLogNG) umbauen. Jetzt in die vorhandene Tabellen-Architektur einzugreifen würde die momentan erreichte Stabilität beeintächtigen zumal die wenigsten FHEM-User DB-Administratoren sind.
Ich kann mir den zu erwartenden Supportaufwand lebhaft vorstellen. :o
Und es gibt auch nicht nur DbLog welches mit der DB arbeitet.
Eigentlich hatte ich mir vorgenommen, eine Weiterentwicklung des Loggings in einem weiteren Modul zu bauen welches neben den von dir angesprochenen Verbesserungen dann z.B. auch NoSQL-DB berücksichtigen würde.
Aber ob ich jemals dazu komme steht in den Sternen.
Das vorab, auf einige deiner Fragen möchte ich noch antworten bei denen mir etwas aufgefallen ist.
Zitat
Wieso gibt es einen Index DEVICE? Device, Reading sind bereits im Index IDX_HISTORY enthalten, der entsprechend genauso greift. Der Index DEVICE ist dementsprechend überflüssig.
Weder den Index DEVICE noch den Index IDX_HISTORY gibt es per default, sondern nur den
Search_Idx. Wo hast du die her ?
Zitat
2. Wozu gibt es die Spalte EVENT? Das ist doch nichts anderes als ein CONCAT(READING, ': ', VALUE, ' ', UNIT) ? Das ist ein Varchar(512) und macht z.m. bei mir ca. 15% der Größe aus, obwohl da nur redundantes Zeug drin steht.
Die Spalte EVENT existiert wiederum aus historischen Gründen. Aber genau aus dem angesprochenen Grund kann man als User auf das Füllen der Spalte verzichten indem man das Attribut
colEvent = 0 setzt. Das ist in der commandRef beschrieben !
EDIT: Auch User verwenden die Spalte für alternative, eigene Einträge. So kann man über das Attr valueFn darauf Einfluß nehmen und der addLog Befehl setzt in dieser Spalte auch ein individuelles Kennzeichen.
Zitat
Die Indexe scheinen nicht gut zu passen. Z.b. selektieren Plots u.a. so:
SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1 AND DEVICE = 'Wetterstation.Helligkeitsensor1' AND TIMESTAMP >= STR_TO_DATE('2020-05-26 08:55:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2020-05-27 08:54:59', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP;
Also bei mir selektieren Plots so:
2020.05.27 12:43:41.466 4: LogDB1 - Processing Statement:
SELECT
DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
DEVICE,
READING,
VALUE
FROM fhemtest1.history WHERE 1=1 AND DEVICE = 'MyWetter' AND READING = 'temperature' AND TIMESTAMP >= STR_TO_DATE('2020-05-27 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2020-05-28 00:00:00', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP
Das heißt das Feld READING ist mit enthalten, bzw. alle -> DEVICE, READING, TIMESTAMP.
Übrigens wird der Index der default ohne VALUE gebildet (weiß wieder nicht wo du VALUE hergenommen hast):
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP) USING BTREE;
Soweit vllt. dazu. Jedenfalls nehme ich deine vorgeschlagene Tabellenstrutur zu meinen Unterlagen und werde sie mit verwenden falls ich mal die Energie aufbringen sollte ein weiterentwickeltes DbLogNG zu erstellen.
Wenn du Vorschläge zu Verbesserunegn hast, die sich relativ komplikationslos in die vorhandene Lösung einfügen lassen würden, könne wir das gerne tun.
LG,
Heiko
Zitat von: greenBelt am 27 Mai 2020, 11:24:52
Exportiere doch ganz einfach das db-log und baue dir extern deine Struktur neu auf. Auf dem T-SQL-Server klappt das wunderbar
Das kann man auch alles mit MySQL machen. Grundsätzlich ist MySQL - für allgemeine Anwendungen - meiner Meinung nach die geeignetste Datenbank. Es geht mir ja nicht darum, dass ich extern irgendwas mit den Daten was machen will. Ich finde ja gerade den Reiz an FHEM, dass es als universelle Schnittstelle dienen kann. Ich stellte mir nur die Frage, wie man mit geringst möglichen Aufwand sicherstellen kann, dass die Datenselektion bei größeren Datenmengen noch flott ist. Ich hab hier nur einen Raspberry Pi 3 im Einsatz. Derzeit sind nur ein paar hundert tausend Einträge drin und es geht noch alles halbwegs. Das Problem an relationalen Datenbanken ist nur, dass mit zunehmender Datenmenge die Querytimes länger werden. Insbesondere dann, wenn der Index nicht mehr heiß vorgehalten werden kann, was in Anbetracht des geringen RAMs der Pis sehr schnell passieren wird.
ZitatGrundsätzlich ist MySQL - für allgemeine Anwendungen - meiner Meinung nach die geeignetste Datenbank.
Ich mag diese DB auch sehr und benutze sie in meinem Prod. FHEM.
Allerdings muss ich als Maintainer ebenfalls sicherstellen, dass die Lösung auch von SQLite und Postgre funktioniert.
Das nur als Anmerkung damit man nicht zu sehr auf MySQL/MariaDB fixiert ist.
Ich bin mehr in der T-SQL Welt unterwegs. Meine Erfahrungen mit großen Datenmengen auf dem Raspberry brachten mich auf den Gedanken die Datenauswertung auf einem externen System laufen zu lassen.
In gewisser Weise lässt sich der Export der RAW Daten automatisieren. Alles andere erledige ich auf dem SQL-Server
Gesendet von meinem Pixel 4 mit Tapatalk
Ich nehme gerne Postgresql. Finde die DB sehr schön in der Verwendung. Kommt näher an Oracle ran wo ich früher mal mit tätig war.
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
Ganz allgemein ist zu DbLog zu sagen, dass dieses Modul bereits mindestens 10 Jahre im Einsatz ist und bereits einiges "durchlebt" hat. Die Tabellenstruktur wie sie momentan ist, würde ich nur in einem kompletten Neuansatz mit einem weiteren Modul (sagen wir DbLogNG) umbauen. Jetzt in die vorhandene Tabellen-Architektur einzugreifen würde die momentan erreichte Stabilität beeintächtigen zumal die wenigsten FHEM-User DB-Administratoren sind.
Ich wollte jetzt nicht nur meckern. Ich kenn die Problematik ja, dass man Sachen die man vor Jahren machte, man ggf. heute anders machen würde etc... Mir ist auch klar, dass DB Architektur auch für Softwareentwickler oftmals nur Randthemen sind. Daher dachte ich mir ja, ich stoße mal eine Diskussion an, wie man ohne eine komplette Neuentwicklung ggf. z.m. etwas Feintuning betreiben kann ;-)
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
Eigentlich hatte ich mir vorgenommen, eine Weiterentwicklung des Loggings in einem weiteren Modul zu bauen welches neben den von dir angesprochenen Verbesserungen dann z.B. auch NoSQL-DB berücksichtigen würde.
MySQL ist schon ok als Datenbank. Die ist bereits sehr performant - z.m. wenn die Datenstruktur passt.
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
Das vorab, auf einige deiner Fragen möchte ich noch antworten bei denen mir etwas aufgefallen ist.
Weder den Index DEVICE noch den Index IDX_HISTORY gibt es per default, sondern nur den Search_Idx. Wo hast du die her ?
Ich hatte es mir ehrlich gesagt sehr einfach gemacht beim Aufsetzen und es nach dem Howto hier gemacht, da ich im FHEM Wiki nicht direkt fündig wurde
https://haus-automatisierung.com/hardware/fhem/2016/05/20/fhem-tutorial-reihe-part-7-mysql-server-fuer-logging-nutzen.html
Wenn die Datenstrukturen offiziell anders sind, dann schau ich mir das selbst nochmal an. Ich wollte mir ohnehin die nötigen Indexe noch selbst erstellen, aber hier erstmal nachfragen... Danke aber für den Hinweis!
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
Die Spalte EVENT existiert wiederum aus historischen Gründen. Aber genau aus dem angesprochenen Grund kann man als User auf das Füllen der Spalte verzichten indem man das Attribut colEvent = 0 setzt. Das ist in der commandRef beschrieben !
kannte ich nicht, danke für den Hinweis!
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
2020.05.27 12:43:41.466 4: LogDB1 - Processing Statement:
SELECT
DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
DEVICE,
READING,
VALUE
FROM fhemtest1.history WHERE 1=1 AND DEVICE = 'MyWetter' AND READING = 'temperature' AND TIMESTAMP >= STR_TO_DATE('2020-05-27 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2020-05-28 00:00:00', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP
Das heißt das Feld READING ist mit enthalten, bzw. alle -> DEVICE, READING, TIMESTAMP.
Übrigens wird der Index der default ohne VALUE gebildet (weiß wieder nicht wo du VALUE hergenommen hast):
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP) USING BTREE;
Der Indexteil VALUE macht keinen Sinn... aber das war auch aus dem Howto wie vor. Bei deinem Beispiel passt DEVICE, READING, TIMESTAMP als Index. Ich wundere mich nur, wieso der bei mir nach Reading nicht selektiert. Könnte damit zusammen hängen, dass ich die in den Plots nicht angab, sondern nur die devices.
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
Wenn du Vorschläge zu Verbesserunegn hast, die sich relativ komplikationslos in die vorhandene Lösung einfügen lassen würden, könne wir das gerne tun.
Ich schau mir jetzt erstmal an, was bei mir noch anders ist im Vergleich zur offiziellen Version.
Zitat
Ich hatte es mir ehrlich gesagt sehr einfach gemacht beim Aufsetzen und es nach dem Howto hier gemacht, da ich im FHEM Wiki nicht direkt fündig wurde
https://haus-automatisierung.com/hardware/fhem/2016/05/20/fhem-tutorial-reihe-part-7-mysql-server-fuer-logging-nutzen.html
Wenn die Datenstrukturen offiziell anders sind, dann schau ich mir das selbst nochmal an. Ich wollte mir ohnehin die nötigen Indexe noch selbst erstellen, aber hier erstmal nachfragen... Danke aber für den Hinweis!
Immer zuerst in der commandRef der Module nachlesen. Die wird von den Entwicklern aktiv gepflegt. Auch das Wiki ist u.U. mit Vorsicht zu genießen je nachdem wer es wann geschrieben hat.
Manches ist schlicht falsch und manches veraltet mit der Zeit wenn nicht aktiv gepflegt.
EDIT: Die Standard Skripte zur Einrichtung findest du hier: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog
Steht auch in der commandRef drin.
Zitat von: DS_Starter am 27 Mai 2020, 15:19:42
Immer zuerst in der commandRef der Module nachlesen. Die wird von den Entwicklern aktiv gepflegt. Auch das Wiki ist u.U. mit Vorsicht zu genießen je nachdem wer es wann geschrieben hat.
Manches ist schlicht falsch und manches veraltet mit der Zeit wenn nicht aktiv gepflegt.
als quasi Anfänger und noch kein Brett vorm Kopf habender wäre ein entsprechender Hinweis auf der Startseite nach der Ersteinrichtung ggf. ganz gut. Ich ging z.m. davon aus, dass das Wiki passt. Dass nur die CommandRef maßgeblich ist, wusste ich nicht. Das erspart aber tatsächlich Kummer... :-)
Schau mal auf den Screenshot. Der Hinweis findet überall wo ein FHEM-Modul beschrieben wird, zumindest aber bei DbLog, DbRep ... ;)
Aber damit kein falscher Einruck entsteht, das Wiki ist wirklich sehr hilfreich um Zusammenhänge zu erklären und ich verfasse auch viel zu meinen Modulen (siehe Footer), aber im Zweifel _immer_ erst die commandRef konsultieren.
Wahrscheinlich meintest du aber die FHEMWEB Startseite mit deiner Anregung.
Das wäre ein Vorschlag für Rudolf König der FHEMWEB entwickelt.
Den Vorschlag kannst du im Forum
FHEM » Frontends » FHEMWEB
platzieren wenn du magst.
Zitat von: DS_Starter am 27 Mai 2020, 13:22:04
Wenn du Vorschläge zu Verbesserunegn hast, die sich relativ komplikationslos in die vorhandene Lösung einfügen lassen würden, könne wir das gerne tun.
Hattest du oder irgendwer anders das einmal in Erwägung gezogen, die Spalte DEVICE beim schreiben/lesen jeweils mit gzip zu behandeln? Soweit ich das in der dblog.pm sah, dürfte das mit nicht allzuviel Aufwand möglich sein. Das Problem wäre dann nur, dass damit ein Reset der Daten oder wenigstens ein nachträgliches Update auf alle früheren Einträge nötig wäre. Bei READING, VALUE, UNIT dürfte das wenig Sinn machen, da die auch bei mir meist nur aus 5 Zeichen bestehen.
Bei mir sind allerdings meine Devicenames relativ lang, da ich alle Devices bei mir hierarchisch halte (z.b. Zimmer.Gerät.Wert // Kinderzimmer.Temperatur.IST). Das finde ich im Zusammenspiel mit der Regex Möglichkeit sehr angenehm global z.b. das Licht auszuschalten (set .*\.Licht off) - ka obs da eleganteres gibt - für alle Sachen extra Strukturen einrichten war mir etwas viel Aufwand :-) Ich gehe aber mal davon aus, dass vermutlich die meisten eher kürzere Devicenames nutzen?
Wenn das Befüllen der EVENT Spalte jedenfalls bereits abschaltbar ist und demnach nur DEVICE, READING,VALUE,UNIT übrig blieben, dann würde davon bei mir Device > 50% der row length ausmachen. Ich weiß noch nicht, wie sich row format Compressed bei der Tabelle verhält. Dafür hab ich noch nicht genug Daten bei mir drin. Soweit da alles über den Index gecovered wird, dürfte compressed aber kaum was ausmachen. Dann wäre das ggf. bereits ausreichend und eine Codeanpassung sinnlos. Das ist am Ende wie immer die Frage, ob der gzip Overhead nicht die gesparten IO kompensiert. Ich denke gerade bei raspberry Pi & Co sollte eine kleinere Größe weit wichtiger sein, als ein paar gesparte CPU Cycles.
Zitat von: DS_Starter am 28 Mai 2020, 13:59:48
Wahrscheinlich meintest du aber die FHEMWEB Startseite mit deiner Anregung.
Das wäre ein Vorschlag für Rudolf König der FHEMWEB entwickelt.
Den Vorschlag kannst du im Forum
FHEM » Frontends » FHEMWEB
platzieren wenn du magst.
Ja, genau das meinte ich. Ganz offen, dein Screenshot ist eindeutig, aber den markierten Bereich hab ich nicht gesehen... ich bin immer direkt runter zum content. Ich mach da mal wie vorgeschlagen einen Post.
Hallo Andreas,
Zitat
Hattest du oder irgendwer anders das einmal in Erwägung gezogen, die Spalte DEVICE beim schreiben/lesen jeweils mit gzip zu behandeln? Soweit ich das in der dblog.pm sah, dürfte das mit nicht allzuviel Aufwand möglich sein.
Nein, habe zumindest ich noch nicht in Erwägung gezogen.
Zitat
Das Problem wäre dann nur, dass damit ein Reset der Daten oder wenigstens ein nachträgliches Update auf alle früheren Einträge nötig wäre.
Genau, das ist ein Migrations- / Support-problem. Und wie ich schon Eingangs erwähnte sind meisten FHEM User keine Admins. Und ich müßte eine Migrationsroutine schreiben und Fehlersituationen abfangen sowie den Ansturm an Supportanfragen abfangen etc.pp. ;)
Deswegen wäre so etwas m.M. nach auch etwas was in einem Modul DbLogNG einfließen könnte.
Nehme ich mit zu den Ideen !
Edit: Frage ... Hättest du Interesse mitzuwirken sobald ich dazu komme etwas Neues in Fragen Datenbank-Logging anzufangen ?
LG,
Heiko
Zitat von: DS_Starter am 28 Mai 2020, 14:40:33
Edit: Frage ... Hättest du Interesse mitzuwirken sobald ich dazu komme etwas Neues in Fragen Datenbank-Logging anzufangen ?
Würde ich. Ich brauche mittelfristig für mich ohnehin eine Lösung. Ich seh schon jetzt, dass das mit MySQL auf ner kleinen Möhre Probleme geben wird. Und unnötig auf historische Daten verzichten ist auch blöd... :P
Hallo Andreas,
es klingt so, als hättest Du nicht nur einen Pi für fhem im Einsatz. Falls ich mich da nicht täusche, warum installierst Du die MySQL Datenbank nicht auf einem anderen Rechner?
Mein Pi sendet die Daten an einen virtualisierten DB Server, von den ich dann die Daten für die Visualisierung auf einer weiteren VM lese.
Beste Grüße
Torsten
Zitat von: ToKa am 29 Mai 2020, 20:56:08
es klingt so, als hättest Du nicht nur einen Pi für fhem im Einsatz. Falls ich mich da nicht täusche, warum installierst Du die MySQL Datenbank nicht auf einem anderen Rechner?
Ich habe nur den Pi und daneben noch einen Gira FacilityServer. Das Ganze Zeug von Gira (FacilityServer, Controlpanel etc) will ich aber bei mir aber raushauen. Mein neuer Pi hat aber eine X825 Extension, woran ich eine SSD dran hab. Das Problem beim Pi ist vor allem der Ram von nur 4 GB Ram... Bei den alten Pis mit 512MB/1GB mal ganz abgesehen ;)
Zitat von: ToKa am 29 Mai 2020, 20:56:08
Mein Pi sendet die Daten an einen virtualisierten DB Server, von den ich dann die Daten für die Visualisierung auf einer weiteren VM lese.
Das wäre sicher eine Idee, aber wenn wir ehrlich sind, ist das meiste wofür man mehr als ein Pi bräuchte nur Spielerei - wie das meiste an der Hausautomation, auch wenns Spaß macht.. :-) Ich könnte hier sicherlich auch einen leistungsfähigeren server hinstellen, aber der Pi verbraucht im Vergleich unschlagbar wenig Strom und es ist ja möglich, dass auch nur mit dem Pi zu betreiben. Bessere Hardware ist nicht immer die beste Lösung
Zitat von: Guybrush am 30 Mai 2020, 11:56:20
Das Problem beim Pi ist vor allem der Ram von nur 4 GB Ram... Bei den alten Pis mit 512MB/1GB mal ganz abgesehen ;)
Der 4er PI wurde gerade mit 8GB RAM angekündigt.
Das könnte ne Variante sein.
Gesendet von meinem S68Pro mit Tapatalk
Zitat von: Frank_Huber am 30 Mai 2020, 14:50:12
Der 4er PI wurde gerade mit 8GB RAM angekündigt.
Das könnte ne Variante sein.
bring nichts, solang rasbpian nur als 32bit verfügbar ist. Ob 4 oder 8 GB ist egal. MySQL kann unter raspbian maximal 3 GB allokieren. Man kann zwar auch Debian etc drauf installieren, aber damit geht auch etwas mehr händische Arbeit einher. Insofern (noch) nicht wirklich eine Option (für mich)
Zitat von: Guybrush am 30 Mai 2020, 15:50:51
bring nichts, solang rasbpian nur als 32bit verfügbar ist. Ob 4 oder 8 GB ist egal. MySQL kann unter raspbian maximal 3 GB allokieren. Man kann zwar auch Debian etc drauf installieren, aber damit geht auch etwas mehr händische Arbeit einher. Insofern (noch) nicht wirklich eine Option (für mich)
Die 8GB Variante des Raspberry ist für mich aber auch ein Zeichen dass ein 64bit OS "auf dem Weg" ist.
Denke ein 64bit Raspbian wird nicht lange auf sich warten lassen.
Gesendet von meinem S68Pro mit Tapatalk
https://www.heise.de/newsticker/meldung/Raspberry-Pi-Erste-Fassung-des-64-Bit-Kernels-verfuegbar-4524121.html (https://www.heise.de/newsticker/meldung/Raspberry-Pi-Erste-Fassung-des-64-Bit-Kernels-verfuegbar-4524121.html)
Ich betreibe mal Leichenfledderei und hole den Thread aus der Versenkung hoch. Ich muss Guybrush recht geben, dass die Datenstruktur aktuell nicht perfekt gelöst ist. Bei einigen hunderttausend bis Millionen Zeilen (was bei einem Klimalogger oder vielleicht HM-Thermosten recht schnell erreicht ist) dürfte ein Query (auf einem Raspi) inperformant werden.
Ich bin gerade dabei für meine Zwecke etwas Optimierung zu betreiben, wobei ich aber die Besonderheit habe Plots per Grafana zu erstellen und nicht per FHEM. Das erspart mir Anpassungen in Perl. ;-)
Vielleicht möchte ja der eine oder andere mal schauen oder hat gute Anregungen für mich was man verbessern könnte. Aktuell ist der Ansatz Daten aus der History thematisch in verschiedene Tabellen zu splitten und history durch einen Trigger regelmäßig zu leeren (noch nicht implementiert). Das ermöglicht thematische Anpassungen und so Speichereinsparungen. Demnächst soll eine (partielle) Normalisierung wie auch von Guybrush vorgeschlagen, folgen.
https://github.com/StephanMuenzberg/fhem_docker/tree/main/scripts/sql
P.s.: Leider kann die logDb anscheinend aktuell keine Strings als Value verarbeiten. Das ist etwas schade, da ausgeschaltete Homematic-Thermostate "off" statt einer Zieltemperatur senden. Daher musste ich meine Thermostate vorerst auf die niedrigste Nicht-Aus-Temperatur (5 °C) stellen. Gleiches gilt für einige IoT-Geräte mit Batterieanzeige, die gerne eine Akkuwarnung, statt einem integer Wert, schreiben möchten.
Moin,
Wenn Du auf dem RPI4 ein 64 Bit Image mit Docker verwendest, dann kannst Du den original Oracle MySQL Container laden. Da sollte MySQL Partitioning möglich sein, was ich aber noch nicht getestet habe.
VG
Christian
Zitat von: ch.eick am 05 Juni 2022, 09:35:44
Moin,
Wenn Du auf dem RPI4 ein 64 Bit Image mit Docker verwendest, dann kannst Du den original Oracle MySQL Container laden. Da sollte MySQL Partitioning möglich sein, was ich aber noch nicht getestet habe.
VG
Christian
Hi Christian,
besten Dank für den Tipp. Du hast Recht, aber Partitionierung unterstützt MariaDB auch. Partitionierung in MySQL/MariaDB wird aber häufig eher kritisch gesehen, denn oft bringt ein guter Index ebenso viel (Ausnahme, beim Löschen einer ganzen Partition). Das ist anders als beispielweise bei Databricks' Delta Tables, die aber auch keine richtige Datenbank sind.
Der Grund, dass ich die Tabellen hier splitte ist mehr, dass ich dadurch mein Tabellenschema anpassen kann. Beispielweise sollten Klimalogger (diverse T, p, Humidity) nur DOUBLE Werte enthalten. Batteriedaten können hingegen sowohl Gleitkommazahlen sein als auch eine Einschätzung ob der Status "gut", "okay" oder "schlecht" ist. Oder ich speichere Verspätungen (und Gründe dafür) des örtlichen ÖPNVs, da können sogar Arrays notwendig werden.
Das kann ich zwar alles in die History packen, aber dann muss halt alles als String abgelegt werden, was aus Speichersicht suboptimal wäre.
Die zusätzliche Normalisierung findet außerdem noch zur Perfomance- und Maintenanceoptimierung statt. Zum Beispiel ist ein Index auf Basis von Integer-Werten meines Wissens in MySQL performanter (wobei ich das gelernt und nie getestet habe) als über Strings, zum anderen reduziert das den Speicherbedarf noch einmal enorm.
Was meinst du, ergibt das soweit Sinn oder habe ich etwas übersehen?
Viele Grüße
Stephan
Zitat von: Muenzi am 06 Juni 2022, 02:00:41
Hi Christian,
besten Dank für den Tipp. Du hast Recht, aber Partitionierung unterstützt MariaDB auch. Partitionierung in MySQL/MariaDB wird aber häufig eher kritisch gesehen, denn oft bringt ein guter Index ebenso viel (Ausnahme, beim Löschen einer ganzen Partition). Das ist anders als beispielweise bei Databricks' Delta Tables, die aber auch keine richtige Datenbank sind.
Der Grund, dass ich die Tabellen hier splitte ist mehr, dass ich dadurch mein Tabellenschema anpassen kann. Beispielweise sollten Klimalogger (diverse T, p, Humidity) nur DOUBLE Werte enthalten. Batteriedaten können hingegen sowohl Gleitkommazahlen sein als auch eine Einschätzung ob der Status "gut", "okay" oder "schlecht" ist. Oder ich speichere Verspätungen (und Gründe dafür) des örtlichen ÖPNVs, da können sogar Arrays notwendig werden.
Das kann ich zwar alles in die History packen, aber dann muss halt alles als String abgelegt werden, was aus Speichersicht suboptimal wäre.
Die zusätzliche Normalisierung findet außerdem noch zur Perfomance- und Maintenanceoptimierung statt. Zum Beispiel ist ein Index auf Basis von Integer-Werten meines Wissens in MySQL performanter (wobei ich das gelernt und nie getestet habe) als über Strings, zum anderen reduziert das den Speicherbedarf noch einmal enorm.
Was meinst du, ergibt das soweit Sinn oder habe ich etwas übersehen?
Viele Grüße
Stephan
Hallo Stephan,
so tief bin ich da nicht drin. Bei mir wird nur irgend wann man die Datenbank mit den Files zu groß, weshalb ich immer schon fleißig aufräume :-) Das mit den Partitionen hatte ich in dem zusammenhang mal nachgelesen. Ich habe bisher nur minütliche Stromverbräuche vom ganzen Haushalt wegen des Wechselrichters, was aber noch nicht weh tut.
VG
Christian
Zitat von: ch.eick am 06 Juni 2022, 09:19:55
Hallo Stephan,
so tief bin ich da nicht drin. Bei mir wird nur irgend wann man die Datenbank mit den Files zu groß, weshalb ich immer schon fleißig aufräume :-) Das mit den Partitionen hatte ich in dem zusammenhang mal nachgelesen. Ich habe bisher nur minütliche Stromverbräuche vom ganzen Haushalt wegen des Wechselrichters, was aber noch nicht weh tut.
VG
Christian
Hallo Christian,
hier hat mal jemand eine schöne Zusammenfassung zu Pros/Cons/Use Cases für Partitioning in Mysql geschrieben.
http://mysql.rjweb.org/doc.php/partitionmaint
Beruflich nutze ich bisher Partitioning eigentlich nur für Zeitreihen-Partitionierung weil die meisten User ohnehin nur die letzten paar Tage Daten sehen wollen und nicht x Jahre. Zugegeben, da ergibt Partition Pruning dann auch Sinn. Allerdings muss der Query das dann auch unterstützen.
Aber ich gebe dir vollkommen recht. Eine Cleanup-Strategie ist meist VIEL besser als Datenbank-Tweaking.