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

[DeeSPe]

Moin Heiko,

schön dass Du es geschafft hast meinen Code zu integrieren.
Aber wie ich Dir schon per PN geschrieben habe finde ich "clearReadings" nicht so gut. Es müsste wirklich die Readings leeren. Ich finde es nicht so schön wenn mir meine Readings weggelöscht werden, denn gerade bei den non-blocking Funktionen, die irgendwann zurückkehren und ihr Ergebnis in ein Reading schreiben, muss man immer mal wieder die Seite neu laden um das neu erstellte Reading (Ergebnis) zu sehen.
Wenn schon "clearReadings" dann könnte ich mir vorstellen alle Readings zu löschen, damit wieder Ordnung ist (und alle "alten", nicht wiederkehrenden Readings weg sind) und dann die wirklich wiederkehrenden Readings leer wieder erstellen.
Da ich im FileLogConvert Modul ein ähnliches Problem hatte, erstelle ich direkt beim Define alle Reading leer und fülle sie nach und nach. Das finde ich für den User angenehmer...

Gruß
Dan

P.S. Werd nachher mal mit der neuen Version testen...

[JoeALLb]

Hallo!

Leider bin ich kein Nutzer von reduceLog und bin daher für tests nicht sonderlich gut geeignet.
Ich werde mir heute mal die Doku dazu durchlesen und dann entscheiden, ob ich es mal testen kann/will.
Zu dem clearReadings habe ich nicht wirklich eine Meinung: Ich benötige es nicht, da ich mit

Code Auswählen Erweitern

deletereading <DbLogDevice> .*
oder eben

Code Auswählen Erweitern

deletereading <DbLogDevice> NextSync
das selbe Ergebnis bekomme und ich mir dort sicher bin, was genau passiert.

Anbei ein Überblick über den aktuellen Performancetest.
Um den Überblick nicht zu verlieren, zähle ich im Moment nur die wichtigsten Tests/Ergebnisse auf.
Wenn jemand an weiteren Ergebnissen interessiert ist oder auch einen Test hinzufügen möchte, bitte immer gerne melden.
Die Tests wurden automatisiert und somit auch mehrmals gemacht. Die Ergebnisse sind immer relativ konstant
und schwanken meist nur um 1-3 Sekunden. Ich denke somit dass das Ergebnis durchaus verwendet werden kann.
Besonders interessiert hat mich auch der Vergleich der unterschiedlichen Datenbanksysteme.

Original-Tabellen, gefüllt mit den jeweils exakt gleichen Daten (>24Mio) Datensätzen.

Code Auswählen Erweitern

Test 1 2 3 4
MySQL 5973,6 77 3014 3585MB
SqLite 2216 19 2441 3484MB
PostGres 8640 64 1756 4903MB

Beschreibung der Tests:
*1 Insert, also das Einfügen der Datensätze in die DB, Zeit in s
*2 Plot-Abfragen auf die 150 häufigsten Devices mit Zeitraum 1 Woche, Zeit in s
*3 Select-Abfrage mit Group und Order über alle Datensätze (zum Ermitteln, welches Device wie oft in der DB ist), Zeit in s
*4 Die Größe der Datenbank auf dem System, Gröe in MB


Mit verändertem Index:

Code Auswählen Erweitern

1 2 3 4
SqLite - 22 983 3555MB
PostGres - 59 1595 4401MB
MySQL#1c 6751 24 183 4203MB
MySQL#2 4050 668 149 2737MB
Maria#7b 7132 30 144 3018MB

Details zu den Veränderten Tabellen für den Versuch:
SqLite   Es wurde ein zweiter Key (`TIMESTAMP`, `DEVICE`) hinzugefügt
Postgr   (`TIMESTAMP`, `DEVICE`, `READING`)
#1c=     Wie Original-Tabelle jedoch ohne Unicode + zewiten Index;
          PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`), INDEX `key2` (`TIMESTAMP`, `DEVICE`)) COLLATE='latin1_bin' ENGINE=InnoDB
#2 =     MyISAM (Test als Alternative zu Aria, da Aria auf manchen Rechnern ohne MariaDB nicht verfügbar ist)
          COLLATE='latin1_swedish_ci' ENGINE=MyISAM;
#7b=   Engine Aria, ohne Unicode, jedoch Crashsafe(daher langsamer, jedoch sicherer bei möglichen Abstürzen/Stromausfall)
         PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`), UNIQUE INDEX `Schlüssel 2` (`TIMESTAMP`, `DEVICE`, `READING`) ) COLLATE='latin1_swedish_ci' TRANSACTIONAL= 1 ENGINE=Aria



Aktuelles Fazit:
Für mich(persönlich) scheint im Moment MariaDB mit der Konfiguration "7b" die interessanteste Variante zu sein.
Sie ist CrashSafe, im Schnitt sehr schnell, relativ klein, erlaubt mehrere Zugriffe gleichzeitig und benötigt wenig Arbeitsspeicher.
Bei Postgres werde ich noch weitere Tests mit anderen Indexkombinationen durchführen. Dort denke ich ist das Ende der
Geschwindigkeit noch nicht erreicht. SqLite ist bereits extrem schnell für Plotabfragen, bei komplexeren
Abfragen jedoch träge.

Findings bei den Tests:
# Die sqLite-DB wurde 2x corrupt, ohne Systemabsturz. Die Reperatur hat >30h gedauert.
# InnoDB konnte in manchen Konfigurationen keine 20Mio Datensätze auf einmal importieren.
  Fehlermeldung: "The total number of locks exceeds the lock table size insert into select from"


Schöne Grüße
Joe

Edit: Kommentar bezügl. clearReadings ergänzt

[DeeSPe]

Anbei ein kleines diff welches "set <name> count" als non-blocking implementiert.

EDIT: Hab's natürlich kurz mit meiner MySQL DB getestet.

Gruß
Dan

P.S. Hab jetzt nicht weiter gesucht! Ist dann alles non-blocking?

EDIT: Dateianhang entfernt.

[DeeSPe]

So richtig gefällt mir count nicht per set!!!
Nach dem Abschicken kehrt die Seite nicht schnell genug zurück um schon von lonpoll aktualisiert zu werden, aber nicht langsam genug dass der neue Wert aus dem Reading gelesen wird!
Also muss man manuell nochmal aktualisieren um das Ergebnis zu sehen!
Das finde ich suboptimal.

Wollen wir nicht ein get daraus machen?

Gruß
Dan

[betateilchen]

Ich habe keine Lust, jetzt durch 10 Seiten zu lesen, aber hat schon jemand darüber nachgedacht, DbLog irgendwann in einer MongoDB laufen zu lassen, die ja von haus schon nonblocking ist und auch noch ein paar andere Vorteile - beispielsweise kein Datenbankschema mehr und damit keine Diskussion über Feldlängen - bietet?

[betateilchen]

So richtig gefällt mir count nicht per set!!!
Wollen wir nicht ein get daraus machen?

Lass bitte den alten set count Befehl wie er ist und baue Deine nonblocking-Variante als get ein.

[JoeALLb]

Ich habe keine Lust, jetzt durch 10 Seiten zu lesen, aber hat schon jemand darüber nachgedacht, DbLog irgendwann in einer MongoDB laufen zu lassen, die ja von haus schon nonblocking ist und auch noch ein paar andere Vorteile - beispielsweise kein Datenbankschema mehr und damit keine Diskussion über Feldlängen - bietet?

Ich habe MongoDb hier testhalber am Laufen, jedoc nicht im im Livebetrieb, ich spiegle lediglich die Daten aus MariaDB mach MongoDB.
Hast Du eine bestimmte Erwartung ausser dem NonBlocking an diese Erweiterung?
Meine Hoffnungen wurden bisher nicht erfüllt (geringere Ressourcen beim Speichern der Daten, geringerer Speicherbedarf auf der SSD, etc...).

Wie weit ist dein Test mit SAP-Hana?

In meine Geschwindigkeits-Tests von oben konnte ich es noch nicht integrieren, da ich beim Auslesen der Daten für Plots noch Fehler erhalte, das möchte ich aber in nächster Zeit ergänzen.

[DeeSPe]

Lass bitte den alten set count Befehl wie er ist und baue Deine nonblocking-Variante als get ein.

Warum soll der als set und blocking drin bleiben wenn man ein get in non-blocking daraus macht?

Gruß
Dan

[betateilchen]

Wie weit ist dein Test mit SAP-Hana?

Meine configDB zuhause läuft problemlos mit SAP HANA

DbLog auf HANA zu nutzen, dürfte auch nicht weiter schwierig sein, HANA ist aus perl prinzipiell über einen ODBC Treiber anzusprechen. Die meiste Arbeit ist ausserhalb von FHEM notwendig, die HANA DB erstmal so weit zu haben, dass man irgendwas reinschreiben kann 

Für FHEM wird HANA m.E. kein Thema werden, diese Datenbank läuft schließlich nicht auf der FritzKotz.

[betateilchen]

Warum soll der als set und blocking drin bleiben wenn man ein get in non-blocking daraus macht?

Aus Kompatibilitätsgründen in bestehenden Anwendungen.
Und bei mir hat ein count noch nie irgendwas blockiert.

[DeeSPe]

Aus Kompatibilitätsgründen in bestehenden Anwendungen.

Okay, verstanden!
Aber das set könnte man dann auf die selbe non-blocking Funktion schicken, oder?
Oder gibt es einen Grund die blocking Variante zu behalten?

Gruß
Dan

[betateilchen]

Oder gibt es einen Grund die blocking Variante zu behalten?

siehe oben:

bei mir hat ein count noch nie irgendwas blockiert.

Man nimmt auch keine Kopfschmerztablette, wenn man keine Kopfschmerzen hat. Es sei denn, man ist drogensüchtig.

Ich möchte nicht noch mehr perl Prozesse haben.

[DeeSPe]

siehe oben:

Man nimmt auch keine Kopfschmerztablette, wenn man keine Kopfschmerzen hat. Es sei denn, man ist drogensüchtig.

Ich möchte nicht noch mehr perl Prozesse haben.

Okay!

Die Funktion ist wohl bei Dir zu schnell als dass das Blockieren auffallen würde. 

Wir hatten hier schon mal kurz über non-blocking count geschrieben.
Das ist auch nur ein Vorschlag von mir, ob und wie es in das Modul übernommen wird steht auf einem anderen Blatt.

Gruß
Dan

[betateilchen]

Die Funktion ist wohl bei Dir zu schnell als dass das Blockieren auffallen würde.

ich sag mal so: ich hatte noch nie irgendein blocking-Problem mit DbLog 

Das ist auch nur ein Vorschlag von mir, ob und wie es in das Modul übernommen wird steht auf einem anderen Blatt.

Der Vorschlag ist ja ok, und ich hatte lediglich einen Gegenvorschlag gemacht, der unser beider Anliegen lösen könnte

[DeeSPe]

ich sag mal so: ich hatte noch nie irgendein blocking-Problem mit DbLog 

Mein (Test)RPi1 hat am WE fast 6 Stunden blockiert während reduceLog lief...

Der Vorschlag ist ja ok, und ich hatte lediglich einen Gegenvorschlag gemacht, der unser beider Anliegen lösen könnte

Verstanden!

Gruß
Dan