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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Wird frei gehalten für die gesammelten Optimierungsideen.
Um den eigentlichen Entwicklungsthread der aktuellen Version weder übersichtlicher zu bekommen, wurde sich auf diesen neuen Thread zur Zusammenfassung
von Optimierungsideen geeinigt.
Die meisten dieser Ideen bisher stammen aus dem Entwicklungsthread, weitere bitte einfach wie gewohnt im Thread anhängen oder besprechen.


Hinweis: Die Liste ist (bisher) unbewertet. (Fett markierte sind in neueren Versionen des Moduls gelöst.).

#01 Lokales Zwischenspeichern von Einträgen bei nicht-erreichbarkeit der DB (@Heiko)
#02 Ausgeben auch der Memcache-Datensätze bei Plotanfragen
#03 "insert into history" ersetzen durch "insert ignore into history" zur Unterstützung eines PK-Indexes erledigt in #50, #119 für alle DB's
#04 "insert into current" ersetzen durch "insert ignore into current" um die zwei (insert und update)-Befehle zu einem zusammenzufassen  erledigt in #50
#05 den Index der Datenbank zu einem  PK ändern, und doppelte Einträge verhindern wird am #50 unterstützt
#06 den Index von DbLog und DbRep zusammelgen
#07   "set .... deleteOldDays <n> EXCLUDE=..." ergänzen
#08 Direktes "addLog" in die Datenbank statt über Trigger fixed
#09 ist ASCI ausreichend oder wird Unicode benötigt? -> RPI Optimierung Zwischen ASCI und UTF8 kann der Anwender wechseln, ohne Änderung in DbLog. Die Performance bei ASCI ist ca. doppelt so schnell unter MySQL.
#10 noTransaction-Modus: Verzicht auf Transaktionen zur Reduzierung von Overhead; sollte bei LOGS keinen Vorteil ergeben, ein Rollback macht keinen Sinn.
#11 NonBlocking der DB für Bereinigungen (nonBlocking (Version im Kommentar 119)
#12 Prüfung der wichtigsten DB-Parameter
#13 Blockieren von Plots während die DB gelockt ist (zB durch Backup, ...)
#14 verhindern von commitCache während die DB gelockt ist
#15 Updateoption für die DB für alle, die noch nach "altem Schema" angelegt wurden.
#16 einene SplitRoutinen analog zu userReadings für Devices, deren Module die Splitfunktion von DbLog noch nicht unterstützen. über attr valueFn gelöst.
#17 "markieren" von zu löschenden Datensätzen als "Dry run" vor dem tatsächlichen löschen.
#18 Integrieren einer Importfunktion für die Übernahme von FileLog-Logs, um den Umstieg auf DbLog zu vereinfachen (@DeeSPe, ...) wird in externem Modul realisiert
#19 Integrieren eines non-blocking Backups für die DB (@friesenjung, ...), ggf. per Parameter eingebunden in das Systembackup. wird in DbRep integriert.
#20 Anpassen der benutzten Spalten in der DB(verzicht auf events, ggf. auch auf units). (@Garry Hayne)
#21 Funktion zum korrigieren von Werten vor dem Einfügen in die Datenbank (duplikat von #26)
#22 clearReadings -> V2.12.3.pm
#23 ReduceLog: Möglichkeit zum Löschen des Inhalts der Spalte "Event" ergänzen.
#24 Möglichkeit schaffen zum Verhindern des Loggings von "state". (über valueFn möglich) NEU: ab 2.22 zusätzlich über "addStateEvent = 0"
#25 Unterstützung MongoDB (betateilchen)
#26 valueFn ähnlich wie bei readingsProxy oder valueFormat bei readingsGroup, indem Werte vor der Aufnahme in die DB verändert werden können (korrigiere Units, verhindere bestimmte Werte (bsp kleiner 0), map true/false auf 0/1; ...) (erledigt in c2.15.0 aus Kommentar #225)
#27 Eine Funktion ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag... (werner)
#28 exportCache / importCache (erledigt in v2.14 in #205)
#29 excludeDevs auch als <devspec> plus Newline als Trenner für excludeDevs (erledigt in v2.14.4 )
#30 verhindern eines Logeintrags, der bestimmte kriterien (nicht) erfüllt (erledigt in v2.15.0_test1 über valueFn mit ignore=1; )
#31 timestamp soll beim Update nicht auf die aktuelle Uhrzeit geändert werden (entfernen von default timestamp für das Feld timestamp)
#32 "$UPDATE=1" für valueFN um bestimmte Werte in der Datenbank aktualisieren zu können!
#33  <Reading> von addLog sollte als Regex angegeben werden können in 2.16.3 enthalten.
#34 set <name> deleteOldDaysFilter<n> <Device> <Reading> (Muschelpuster)
#35 UTF8-Modus für Datenbankverbindungen
#36 "set sql checkConfig", prüfung auf alte Konfigurationen, zusammenpassende unicode-DB-verbindung mit unicode-Tabellenstruktur, DB-Typen (bei MySQL),... in 2.18 erledigt
#0 ... wird fortgesetzt


Offene Fragen (bitte bringt euren Input direkt im Thread ein!)
# Soll das Datenbankschema angepasst werden oder genügt es, nicht benutzte Spalten wie "Events" und "Units" auf Wunsch einfach nicht zu schreiben?
# Gibt es Empfehlungen für die Optimalen DB_Servereinstellungen? Wie kann man zB den Speicherverbrauch auf dem RPI für MySQL möglichst gering halten?
# ...

Aktuelle Workarounds:
#20 durch setzen von "attr dbLog colEvent = 0" wird diese Spalte nict mehr gefüllt (DS_Starter in Kommentar #26)
# Korrektur von Fehlerhaften Loggings über attr valueFn am Beispiel von Whatsapp (yowsup): https://forum.fhem.de/index.php/topic,65860.msg618486.html#msg618486


Aktuelle Testversion:
=> Enthalten in Message #50. Mit dieser ist der Betrieb auf einem RPI1 schon sehr performant möglich.
« Letzte Änderung: 27 Juli 2017, 09:04:53 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (12 Watt),
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 JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #1 am: 27 Januar 2017, 22:17:16 »
Workaround für Tests:

Wie können große Änderungen an der Datenbank durchgeführt werden, ohne dass
FHEM dadurch blockiert wird?

Schritte:

1. Erzeuge eine leere History-Tabelle mit neuem Namen
2. Benenne die aktuelle history-tabelle um und platziere eine neue, leere Tabelle dort. Dies funktioniert ohne Unterbrechung.
3. Korrigiere/Bereinige die Einträge in der Umbenannten Tabelle: FHEM kann somit völlig ungestört weiterarbeiten.
4. Benenne die Tabellen zurück um:
5. Kopiere die neuen Werte aus der "Temporären leeren History-Tabelle" wieder zurück in die Haupttabelle
6. Lösche die Einträge der temporären History-Tabelle.

zu 1:
Nutzt ihr DbRep? Diese Tabellen haben auch den Index für DbRep, der ggf. entfernt werden kann... gebenchmarked habe ich diesen noch nie.
CREATE TABLE `historyNEW`  like history;
zu 2: Achtung! Beide Befehle in einer Zeile gemeinsam ausführen, damit es zu keiner Unterbrechung kommt.
rename table history to historyOLD; rename table historyNEW to history;
Jetzt hast Du eine neue leere History-Tabelle in die alles neue geloggt wird. Jetzt kannst Du die alte Tabelle so verändern, bereinigen, etc. bis sie ok ist und Du sie wieder
an Original-stelle zurück spielst.

zu 3: Jetzt kannst Du mit der Datenbank "historyOLD" arbeiten, ohne FHEM zu blockieren.
Hier kannst Du neue Indexe anlegen, große Datenmengen bereinigen, etc...

zu 4:
rename table history to historyTMP; rename table historyOLD to history;
zu 5: Dies sollte ohne großen Lock gehen, da in der zwischenzeit nur eine geringe Anzahl an Datensätzen angelaufen ist:
insert ignore into history select * from historyTMP;
zu 6:
drop table historyTMP;
« Letzte Änderung: 31 Januar 2017, 13:33:19 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (12 Watt),
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
Hilfreich Hilfreich x 2 Liste anzeigen

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #2 am: 27 Januar 2017, 22:21:02 »
kleiner Auszug aus gemachten Benchmarks:(wird noch weiter durchgeführt)

Test#1: Import von 22.794.730 Datensätzen in die jeweilige Datenbank. Einheit in Sekunden
Test#2: Größe der unterschiedlichen DBs.
Test#3: Plot-ähnliche Suche aller Daten der 200 häufsten Devices aus meiner Tsest-DB für jeweils einen Monatszeitraum:
Test#9: Gruppierung über sämtliche Devices und Count um zu häufig loggende und zu selten loggende Devices erkennen zu können (optionaler Zusatztest. kommt direkt in FHEM nicht vor)

Datenbanken:
#1:  Original MySQL InnoDB-Datenbank mit original Index.
#1a: Original ohne Unicode
#2: Original mit Engine MyISAM
#2a: Original mit Engine Aria
#3a: Aria mit zweitem Index aus DbRep
#6a: Aria zweitem Hash-Index
#6b: Aria mit "vertauschtem" index
#7: Aria als "CrashSafe".
#7a: Aria als "CrashSafe" mit einfachem index
#8: Aria mit unicode sonst wie 7a.


Test1: MySQL
Datenbank  Test#1        GrößeMB       Test#2     test #3   Test#9
--------------------------------------------------
#1        96,56s      3500      861s     91s  48,56s     
#1a 36s
#2
#2a
#3a 39s
#6a 814s
#6b         68,58s       2200     112s 36s        2,32s
#7 38s
#7a 548s
#8


Tabellen:
original: ist die Original MySQL-innoDB -Tabelle, wie sie im create-Script von DbLog erzeugt wird.
MyISAM:
Aria: Ist ähnlich wie MyISAM, funktioniert jedoch nur in MariaDB. Dieser Datenbanktyp ist "crashsave".
« Letzte Änderung: 08 Februar 2017, 13:58:49 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (12 Watt),
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 DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1529
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #3 am: 27 Januar 2017, 22:29:53 »
Ok .. bin dabei ...
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology 415+,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #4 am: 27 Januar 2017, 22:35:14 »
Ok .. bin dabei ...
Sehr schön :D
Bitte Ideen und Vorschläge einfachhier einbringen, im ersten Thread möchte ich diese halbwegs "zusammenhalten" soweit möglich!

Für heute bin ich raus... CU

FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Online friesenjung

  • Full Member
  • ***
  • Beiträge: 132
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #5 am: 27 Januar 2017, 22:55:20 »
Hallo Daniel,

Die Fehlermeldung wäre schön ;-)
...

Hallo Joe,
leider habe ich keine Fehlermeldung (wo würde sowas geloggt?). :o
Ich nutze ja PHPmyAdmin i.V.m. MariaDB auf einer Synology.

Ich merke es an versch. Dingen an der historyNEW-Tabelle:
-nach dem "insert ignore..." klicke ich auf Anzeigen der neuen Tabelle, aber er bleibt hängen
-den Prozess (unter PHPmyAdmin) sieht man zwar unter Status, nur bleibt der immer bei 0
-auch der Prozess von MariaDB auf der Synology ist ungewöhnlich konstant bei 50%
-unter "Tabellenkommentar > Speicherplatzverbrauch steht immer nur "Daten 0 B"
-einzig der Index wächst minimal (so 0,1MB pro Minute)
-die Spalten Timestamp, Device, Reading haben auf einmal einen Primärschlüssel (im Gegensatz zu auch neuen history-Tabelle)

Oder bin ich zu ungeduldig und die Datensätze kommen erst nach 10h? Glaub ich aber irgendwie nicht.
Kann ich den Prozess abbrechen?

Das mit dem
   limit 0,10000;
bzw.
   limit 10000,20000

hab ich noch nicht ganz gerafft. Muß ich das jedesmal nach 10000Stück wieder machen? Bei 5Mio. Datensätzen keine schöne Vorstellung   :-[

VG
Daniel
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #6 am: 27 Januar 2017, 23:05:58 »
Hallo Joe,
leider habe ich keine Fehlermeldung (wo würde sowas geloggt?). :o
Ich nutze ja PHPmyAdmin i.V.m. MariaDB auf einer Synology.
vermutlich ist das dann ein anderes Problem ...
Ich tippe auf Timeouts.
Kannst Du ein anderes Tool laden, zB Heidisql? das ist ein Sql-Browser.
Alternativ geht natürlich aich die Console.

5Mio datensätze sollte eigentlich funktionieren , die primary keys hatte ich in meiner Vorlage, wollte diese aber eigentlich entfernen, bis diese ordentlich von DbLog supported werden. das schau ich mir noch an.
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Online friesenjung

  • Full Member
  • ***
  • Beiträge: 132
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #7 am: 27 Januar 2017, 23:54:05 »
Hallo Joe,
der Groschen viel bei "...die primary keys hatte ich in meiner Vorlage, wollte diese aber eigentlich entfernen,"!!!

Das war das Problem. Hab die DB nochmal ohne die  Primarykeys übernommen und siehe da, es lief :)

Alle Datensätze wurden in recht kurzer Zeit (ein paar Minute) kopiert.

Folgende Verbesserungen:
-Größe: Datenbank von 1300 auf 700 MB geschrumpft  :D
-Index von 500MB auf 50MB gesunken  :D :o
-Abfrage mit Count über alles: von 120 Sekunden auf 36 Sekunden gesunken :D
-die Plot-Abfrage sank von 0.04 auf 0.03 Sekunden. ok...

Wie soll ich nun vorgehen, um wieder nur eine history zu haben? hab ja neue Daten in der jetzigen history. So würde ichs machen:
1. history in historyTEMP und gleichzeitig historyWORK in history umbenennen
rename table history to historyTEMP; rename table historyWORK to history;2. aus historyTEMP die während der "Bauarbeiten an den anderen DBs" zuletzt geloggten Daten in die history kopieren
insert ignore into history select * from historyTEMP;
OK so?




« Letzte Änderung: 28 Januar 2017, 00:19:13 von friesenjung »
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM

Online friesenjung

  • Full Member
  • ***
  • Beiträge: 132
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #8 am: 28 Januar 2017, 00:17:57 »
und nochmal ich,
da sich meine SQL-Kenntnisse recht oberflächlich sind (für meine Anwendungsfälle wurschtel ich mich halt so durch), hier noch ein paar Verständnisfragen, die mir heute Abend noch so in den Sinn kamen:

  • was genau bewirken die Partitionen, ist das so ne art extra-Index? was bringen Sie in unserer FHEM-LOG-Anwendung?
  • die DB "Current" ist ja noch vom Typ InnoDB, ist das ein Problem? also die Kombi current=InnoDB und history=Aria?
  • warum benutzt Du gerade den schwedischen Zeichensatz "latin1_swedish_si" (Kollation)? und macht es Sinn diesen auch in der current-Tabelle einzustellen?
  • ich habe bei bestimmten Sensoren unter Unit "°C". Das war aber auch schon mit dem Zeichensatz UTF8 so. hast Du ne Idee, wie man das wegbekommt?

So, genug der Fragen.
VG...
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #9 am: 28 Januar 2017, 05:53:15 »

Wie soll ich nun vorgehen, um wieder nur eine history zu haben? hab ja neue Daten in der jetzigen history. So würde ichs machen:
1. history in historyTEMP und gleichzeitig historyWORK in history umbenennen
rename table history to historyTEMP; rename table historyWORK to history;2. aus historyTEMP die während der "Bauarbeiten an den anderen DBs" zuletzt geloggten Daten in die history kopieren
insert ignore into history select * from historyTEMP;

genau so, und da die  aktelle history recht klein ist, geht das auch sehr schnell! Ich mach grad Mittagpause und antworte danach auf die anderen fragen.
FHEM-Server auf IntelAtom+Debian (12 Watt),
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 JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #10 am: 28 Januar 2017, 08:44:45 »
  • was genau bewirken die Partitionen, ist das so ne art extra-Index? was bringen Sie in unserer FHEM-LOG-Anwendung?
Diese erzeugen praktisch eine völlig eigene tabelle.
Du hast jetzt eine Tabelle in der alle Logeinträge von Sonntagen, eine andere wo alle Montage drinnen sind, etc.
Auf dem RPI habe ich damit sehr gute Erfahrungen gemacht, ob man das tatsächlich braucht ist sicherlich disskussionswürdig.
Eventuell sollten wir noch eine zusätzliche Patrtition für "zu löschende" Datensätze ergänzen. Ein löschen von solch einer Partition geht in 0,2 sekunden mit allen
datensätzen, die darin enthalten sind, also ein Vorteil beim aufräumen.


  • die DB "Current" ist ja noch vom Typ InnoDB, ist das ein Problem? also die Kombi current=InnoDB und history=Aria?
kein Problem, aber für den Arbeitsspeicher nicht optimal. das gehen wir aber später an, wir können dann innodb in der my.cfg deaktivieren.[/list]

  • warum benutzt Du gerade den schwedischen Zeichensatz "latin1_swedish_si" (Kollation)? und macht es Sinn diesen auch in der current-Tabelle einzustellen?
Weil es immer der standard bei MysSQL für Single-Byte Zeichensätze war. Ist weit verbreitet und kein hindernis... Hast Du bessere Vorschläge?

  • ich habe bei bestimmten Sensoren unter Unit "°C". Das war aber auch schon mit dem Zeichensatz UTF8 so. hast Du ne Idee, wie man das wegbekommt?
Ich auch! Das Modul des Sensors übderstützt die splitFn von DbLog nicht, daher wird dies falsch eingetragen.
Ob man Units in der aktuellen Fassung überhaupt benöptigt, stelle ich mal zur Frage.
Ich habe dazu auch einen Workaround geschrieben als MySQL-Strored procedure geschrieben, wenn du willst kannst du ihn aktivieren:

Bitte passe ihn an deine Gegebenheiten an!!
CREATE DEFINER=`root`@`localhost` TRIGGER `history_before_insert` BEFORE INSERT ON `history_dup` FOR EACH ROW if
  (New.TYPE='CUL_EM'  and New.READING='total') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
  (New.value ='°C') then Set New.value = ' °C';
ELSEIF
  (New.TYPE='CUL_EM'  and New.READING='power') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
  (New.TYPE='OWTHERM'  and New.READING='data') then Set New.value =digits(New.value);
ELSEIF
  (New.event ='desiredTemperature auto') then Set New.value = 22.0;
ELSEIF
  (New.event ='desiredTemperature eco') then Set New.value = 18.0;
ELSEIF
  (New.event ='desiredTemperature comfort') then Set New.value = 22.0;
ELSEIF
  (New.event ='desiredTemperature off') then Set New.value = 5.0;
ELSEIF
  (New.event ='desiredTemperature boost') then Set New.value = 30.0;
ELSEIF
  (New.event ='desiredTemperature on') then Set New.value = 30.0;

END IF
FHEM-Server auf IntelAtom+Debian (12 Watt),
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 stromer-12

  • Hero Member
  • *****
  • Beiträge: 1332
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #11 am: 28 Januar 2017, 20:28:08 »
Ich habe mal bei mir auf dem Cubietruck MyISAM mit Aria verglichen.
Beide hatten ca. die gleichen Geschwindigkeitswerte.
Auch beim Speicherplatz ist die Aria nur um 2,2% kleiner als die MyISAM Tabelle.
FHEM 5.8(SVN) auf CT mit HMUSB | HMLAN | CUL
FHEM 5.8(SVN) RPi mit HMser | CUNO
loggt mit MariaSQL(ARIA) auf SSD
S300TH | FHT80TK-2 | FS20:AS4,HGS,ST,TK,UTS,WS1
HM: >50 Geräte, KFM100

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #12 am: 28 Januar 2017, 21:51:07 »
Ich habe mal bei mir auf dem Cubietruck MyISAM mit Aria verglichen.
Beide hatten ca. die gleichen Geschwindigkeitswerte.
Auch beim Speicherplatz ist die Aria nur um 2,2% kleiner als die MyISAM Tabelle.
Aria hat den Vorteil, dass sie crash-safe konfiguriert werden kann. Wenn also möglich, ist Aria die bessere Option.
FHEM-Server auf IntelAtom+Debian (12 Watt),
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 JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #13 am: 28 Januar 2017, 21:55:31 »
Hallo Daniel,

-nach dem "insert ignore..." klicke ich auf Anzeigen der neuen Tabelle, aber er bleibt hängen
-den Prozess (unter PHPmyAdmin) sieht man zwar unter Status, nur bleibt der immer bei 0
-auch der Prozess von MariaDB auf der Synology ist ungewöhnlich konstant bei 50%
-unter "Tabellenkommentar > Speicherplatzverbrauch steht immer nur "Daten 0 B"
-einzig der Index wächst minimal (so 0,1MB pro Minute)
-die Spalten Timestamp, Device, Reading haben auf einmal einen Primärschlüssel (im Gegensatz zu auch neuen history-Tabelle)

dem wäre es aber schon noch interessant, nachzugehen, denn im ALlgemeinen wäre es für diesen Einsatzzweck SEHR gut, einen Primary Key zu verwenden!
Ich sehe auch keinen Grund für schwierigkeiten, ich selbst hatte bei der ersten Konvertierung jedoch auch jede Menge doppelter Datensätze, die ich jedoch durch das "insert ignore"
einfach aussortieren konnte (ich habe auch andere Methoden versucht und die Daten auf deren Herkunft geprüft...).
zB erzeugen oft zu weit konfigurierte Userreadings doppelte Speichereinträge..
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Online friesenjung

  • Full Member
  • ***
  • Beiträge: 132
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #14 am: 29 Januar 2017, 15:02:44 »
Hallo Joe,


kein Problem, aber für den Arbeitsspeicher nicht optimal. das gehen wir aber später an, wir können dann innodb in der my.cfg deaktivieren.[/q]
Weil es immer der standard bei MysSQL für Single-Byte Zeichensätze war. Ist weit verbreitet und kein hindernis... Hast Du bessere Vorschläge?
> war nur Neugier. einen besseren Vorschlag hätte ich auch nicht...


kein Problem, aber für den Arbeitsspeicher nicht optimal. das gehen wir aber später an, wir können dann innodb in der my.cfg deaktivieren.[/q]
> rein theoretisch der gleiche Ablauf wie bei der history-Tabelle denk ich!?


Ich auch! Das Modul des Sensors übderstützt die splitFn von DbLog nicht, daher wird dies falsch eingetragen.
Ob man Units in der aktuellen Fassung überhaupt benöptigt, stelle ich mal zur Frage.
Ich habe dazu auch einen Workaround geschrieben als MySQL-Strored procedure geschrieben, wenn du willst kannst du ihn aktivieren:

Bitte passe ihn an deine Gegebenheiten an!!
...
> mh, ok. dann könnte man den Modul-Author danach fragen. Aber eigentlich hast Du Recht, das ist mein kleinstes Problem ;) . Ich nutze die Units auch nicht wirklich!
Deinen Workaround werde ich deshalb erstmal nicht aktivieren, aber gut zu wissen, dass es Ihn gibt!
Eine Verständnisfrage dazu: Der Code erfasst nur neue Einträge und wirkt nicht "rückwärts" oder?

dem wäre es aber schon noch interessant, nachzugehen, denn im ALlgemeinen wäre es für diesen Einsatzzweck SEHR gut, einen Primary Key zu verwenden!
Ich sehe auch keinen Grund für schwierigkeiten, ich selbst hatte bei der ersten Konvertierung jedoch auch jede Menge doppelter Datensätze, die ich jedoch durch das "insert ignore"
einfach aussortieren konnte (ich habe auch andere Methoden versucht und die Daten auf deren Herkunft geprüft...).
zB erzeugen oft zu weit konfigurierte Userreadings doppelte Speichereinträge..
> vermutlich lag es daran, dass die beiden Tabellen nicht beide einen PK hatten. Meine alte history (InnoDB) hatte keinen PK, jedoch die neue history (Aria). Nachdem ich dann beide ohne PK hatte funktionierte es. Werd das mal ausprobieren. Kann ich eine Tabelle kopieren, also ohne die Prozedur, die wir zum Ändern des Tabellentyps nutzten?

So und nun noch eine neue Frage:
Also ich habe nun alles wieder so wie es vorher war und alle Datensätze sind in der "history", nur ist die history-Tabelle "Aria" statt "InnoDB"! So weit so gut.
Nun lasse ich mir die (neue) history (ca. 5Mio. Datensätze) anzeigen, so dauert das ca. 15 Sekunden!!!??? Das komische ist, dass die gleiche Tabelle, als sie noch historyWORK hieß das gleiche in 0.003 Sekunden erledigt hatte. Irgendwas ist doch da noch faul!?
Selbst die alte historyOLD (InnoDB) liegt da bei 0.004Sek!
Was könnte das sein?

VG
Daniel
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM