Edit: Ich habe den Titel dieser Nachricht geändert, da es sich am Ende um ein spezifisches Leistungsproblem von Gladys handelte.
Hallo
Es handelt sich nicht wirklich um eine eigentliche Smart-Home-Funktion und es ist etwas, das eine große Entwicklung erfordert ^^
Aber ich denke, es wäre nützlich, bei der Installation von Gladys die Wahl zwischen einer SQLite- oder MySQL-Datenbank zu haben.
Warum dieser Bedarf?
Wenn man viele Module auf einem Dashboard hat, insbesondere Grafiken, zeigt SQLite seine Grenzen (etwa 10 Sekunden, um mein Haupt-Dashboard anzuzeigen).
Eine MySQL-Datenbank würde Gladys bei mehreren parallelen Abfragen leistungsfähiger machen und die Flüssigkeit der Dashboards verbessern.
Meine Meinung: Wenn du mich bei der Installation zur Auswahl aufforderst, installiere ich nicht, weil ich es nicht verstehe und denke, dass es nichts für mich ist
Aber ich nehme an, die technische Entscheidung, die getroffen wurde, ist/war gut durchdacht (und kann sicherlich bei Bedarf weiterentwickelt werden )
Ich stimme tatsächlich zu, dass eine solche Wahl einen großen Teil der Benutzer verlieren würde und dass SQLite für die große Mehrheit der Installationen ausreicht.
Dieser Wahl könnte sich beispielsweise in einem Reiter „Erweiterte Einstellungen“ befinden, der dann funktionsfähig wäre.
Aber es ist sicherlich eine große Entwicklung für, wie ich denke, eine Minderheit der Benutzer.
Ich glaube nicht, dass MySQL die Lösung für dein Problem ist. SQLite ist für diesen Zweck genauso leistungsfähig, nur weil „Lite“ im Namen steht, heißt das nicht, dass es langsamer ist, im Gegenteil
Das Problem mit der Performance sollte eher in Gladys gelöst werden
Würde es dich stören, mir deine Datenbank (privat) zur Verfügung zu stellen, damit ich auf meiner Seite Performance-Tests durchführen kann?
Ich weiß, dass SQLite sehr leistungsfähig ist, aber jede Datenbankverwaltung hat ihre Vor- und Nachteile. Deshalb bleibt das Thema eine Vorschlag
Du kennst dich am besten mit der Funktionsweise von Gladys und der Datenbank aus
Kein Problem, bei der Optimierung zu helfen!
Gladys läuft auf einer M2 SSD, Schreibgeschwindigkeit nach Benchmark: zwischen 350 und 380 MB/s
Prozessor: 2,7 GHz, 4 Kerne
RAM: 8 GB + 1 GB Swap
Danke @Checconio für die DB, die du mir privat geschickt hast, ich konnte eine kleine Leistungsüberprüfung an deinen Daten durchführen und es hat mir sehr geholfen, ich habe das Problem gefunden!
Zuerst war das Problem sehr klar, es war sogar auf meinem Entwicklungsrechner, der recht leistungsstark ist, extrem langsam, ich weiß nicht, wie du das aushältst, es war ultra langsam ^^
6 Sekunden für eine Abfrage, die nichts zurückgibt, das ist viel!
Ich habe also den Faden aufgegriffen, es gibt 2 Bedingungen in dieser Abfrage (WHERE device_feature_id = ? AND created_at >= ?), und diese beiden Attribute haben tatsächlich einen Index…
Ich führe EXPLAIN QUERY PLAN aus, um zu verstehen, was SQLite tut, und ich verstehe.
SQLite konnte den Index auf device_feature_id verwenden, um alle Zustände dieser Funktion zu finden, aber dann führte es einen sequenziellen Scan durch, um nach Datum zu filtern: der Index auf dem Datum wurde nicht verwendet.
Die Lösung ist ganz einfach, es reicht, einen Index hinzuzufügen, der die 2 Attribute abdeckt, die bei der Abfrage verwendet werden.
Ich habe also 2 Indizes auf device_feature_state und t_device_feature_state_aggregate hinzugefügt, die die Attribute abdecken, die bei den Abfragen des Dashboards verwendet werden.
Ich habe einen Build auf dem dev-Tag laufen, ich halte euch auf dem Laufenden, wenn es fertig ist
In unserem Anwendungsfall (Embedded-Programm) ist SQLite am besten geeignet, deshalb verteidige ich es Client/Server-Datenbankmanagementsysteme (MySQL/PostgreSQL) sind geeignet, wenn man einen Datenbankserver hat, der von mehreren Clients im Netzwerk abgefragt wird.
Nach 26 Minuten Update meiner Datenbank aufgrund deines Patches bestätige ich den enormen Geschwindigkeitszuwachs bei den Dashboards.
Ich kann alle Dashboards in einer Schleife fast sofort laden. Zuvor ließ ich Gladys 5 bis 10 Sekunden auf meinen Dashboards mit vielen Grafiken „abstürzen“.
@pierre-gilles, ich habe gestern Abend versucht, Gladys auf meinem Desktop-PC zu installieren, meine aktuelle Datenbank zu verwenden, um dann Features zu löschen.
Mein Desktop-PC verwendet eine NVMe-SSD, also sollte es super schnell sein, viel schneller als mein RPi, der 10 Stunden braucht, um die 8 GB meiner Datenbank zu verarbeiten und die Features zu löschen…
ABER, da der Zigbee2MQTT-Dienst verwendet werden muss und er nicht in der Entwicklerinstanz läuft, die ich auf meinem PC installiert habe, ist es unmöglich, auf die Geräte zuzugreifen, um die Features zu löschen.
→ Hast du einen Trick, damit ich die Features auf meinem Desktop-PC löschen und dann diese modifizierte Datenbankversion auf meinem RPi wiederverwenden kann?
)
Danke für die Analyse und die Korrektur, sehr interessant.
