93_DbLog (MYSQL) funktioniert maximal 10 Minuten.

[betateilchen]

Dass regelmäßig nicht nach history geloggt werden kann, hat nix mit current zu tun.

Und mysql braucht sechs Stunden für eine Reorg? Auf was für einer Hardware hast Du denn Deine Datenbank laufen?

[JoeALLb]

Auf ne Rpi,  hab letztes Monat 163.000.000 Log Zeilen produziert,  leider etwas zu viele.  Ich bastle noch an einem (nachträglichen) "zusammenfassungsskript" für stündliche Werte. Diesen Monat bleibe ich unter 2.000.000

Gesendet von meinem Xperia Pro mit Tapatalk

[betateilchen]

mysql gehört mMn definitiv nicht auf einen Einplatinencomputer wie Rpi der BBB - das macht absolut keinen Sinn, dafür ist die Performance einfach nicht ausreichend. Ich warte auf den Tag, an dem jemand versucht ein IDES auf den Raspberry zu bringen...

[JoeALLb]

Da widerspreche ich dir eindeutig.  Du hast es wohl nie ordentlich versucht. Die Performance reicht leicht,  und die Handhabung (Zugriff während dem weiterleiten,  Daten umschreiben,  triggern,  backup)) ist um Welten schöner als mit sqlite. Jedoch verwende ich ein angepasstes Modul um keine Transaktionen zu starten, die sehe ich hier als fehl am Plätze
Zusätzlich experimentiere ich gerade mit tabellen-partitionen,  was auch viel versprechend ist . Ich werde Änderungen am Modul vorschlagen,  wenn ich diese erprobt habe.

Gesendet von meinem Xperia Pro mit Tapatalk

[betateilchen]

Da widerspreche ich dir eindeutig.  Du hast es wohl nie ordentlich versucht.

Wenn Du meinst...

Dass MySQL um Welten "schöner" ist als Sqlite steht übrigens ausser Frage.

[erwin]

Hi Tobias,
ich will jetzt noch nix endgültig sagen, ich hatte seit dem letzten change nur mehr einen event,
Das eval hat gegriffen, die DB wurde disconnected/reconnected, allerdings sind dann permanent Fehler vom rollback gekommen- geloggt wurde trotzdem, soweit ich das feststellen konnte. ich finde jetzt nur die Logeinträge nicht mehr....
Danke jedenfalls für deine Mühe!
l.g. erwin

Edit: Ich weiss jetzt auch, wie ich duplicate records produzieren kann: Einfach den gmail server kurz abstellen;) , dann zuckt das mailcheck-modul für 2 Minuten aus, fhem hängt - und nacher gibts etliche events mit dem gleiche Timestamp.......

[betateilchen]

Ich denke, ich werde mir mal die DbLog_Push() vornehmen, wenn nächste Woche wieder zu Hause bin Ich hab da schon ein paar Ideen.

[Tobias]

In aller kürze: current ist definitiv nötig. Wer es nicht braucht kann es ja per attr abschalten. Zb. im Text2Speech um Statistiken bzgl. Löschungen von nicht benötigten Soundfiles zu sammeln

Sicherlich ist DbLog noch ausbaufähig, bevor ich es übernommen hatte war es noch nichtmal im MainTree. Bzgl Datenlöschungen und damit verbundener Kennzahlbildung habe ich auch schon Ideen aber mangels Zeit bzw anderer Baustellen noch nicht umgesetzt.
Ich bin allerdings sehr dran interessiert das Modul benutzerfreundlicher zu gestalten und bin Patches sehr aufgeschlossen - Solange es übersichtlich und Modular aufgebaut ist und die Komplexität noch beherrschbar ist

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

(offtopic)

@Tobias: kennst Du das schon: http://forum.fhem.de/index.php/topic,19683.msg140767.html#msg140767

(/offtopic)

[Tobias]

ups, den kenne ich, aber den Hinweis mit Rudi hab ich wohl überlesen...
Eigentlich ließt Rudi immer rudemtär (**gg**) mit...

[betateilchen]

den Hinweis mit Rudi habe ich auch erst heute dort geschrieben

Meiner Meinung nach braucht man weder :CURRENT noch :HISTORY überhaupt noch in einer Plotdefinition, wenn man sich die Sourcecodes von 92_FileLog und 93_DbLog einmal genau anschaut. Und die 98_SVG braucht die auch nicht. Da taucht :CURRENT lediglich in der Doku auf.

[Tobias]

Dblog benötigt aber die Info HISTORY . Mit der get Methode kann man auch aus current lesen. Zufällig benötigt ein svg aber nur die history.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[JoeALLb]

Aber warum? Es ist doch relativ sinnlos, daten doppelt(in history und current) abzuspeichern!
Sogar unter Performance-Ansichten!
Wenn ich in beide Tabellen logge, ist mein RPI zu 100% ausgelastet. Wenn ich nur
in die HISTORY logge, dann zu deutlich weniger Protzent(ca. 25%) (dafür schwankend).

Wie genau lauten deien Überlegungen bezüglich Kennzahlbildung?
Soll ich(oder Betateilchen) da weiterüberlegen oder ist deine Idee schon relativ gereift?

[betateilchen]

Ich brauche die CURRENT weil ich die LETZTEN Daten EINES Readings EINES bestimmten Devices suchen will. Und das geht aus der CURRENT sehr viel einfacher als aus der History, weil da für jede Device/Reading Kombination genau EIN Datensatz existiert.

@Tobias: Du hast mich falsch verstanden. Ich bezog mich nur auf SVG. DbLog sollte einfach das "HISTORY" als default verwenden, wenn es im get() NICHT mit angefordert wird. Damit könnte man auf HISTORY und CURRENT bei der SVG-Definiton komplett verzichten. Meines Erachtens stammt doch diese Unterscheidung noch aus der Zeit, als DbLog zusätzlich zu FileLog eingeführt wurde und man diese Unterscheidung brauchte. SVG braucht das CURRENT definitiv nicht (weder für DbLog noch für FileLog, aber SVG-Definitionen werden immer automatisch mit :CURRENT angelegt, was mMn überhaupt keinen Sinn (mehr) macht.

[Tobias]

Es wird history verwendet wenn nichts angegeben wird. Ist default.
PS: bin jetzt 2 tage im urlaub

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk