(beantwortet) configDB, Vorteile vs. Nachteile

[joshi04]

Hallo Community,

ich bin gerade dabei meine Ersteinrichtung von einem RPi auf einen CT umzuziehen und habe mir die Frage gestellt, ob ich dabei auf die Verwendung von configDB umsteigen soll.
Zwar habe ich schon ein wenig gesucht, muss aber zugeben, dass ich nicht alle Threads gelesen habe. Bislang habe ich noch nichts konsolidiertes zu dieser Fragestellung gefunden, auch wenn ich mir auf der anderen Seite kaum vorstellen kann, dass diese Frage hier noch nicht diskutiert worden ist. Ja, das kann auch daran liegen, dass ich nicht unendlich gesucht habe, seht es mir bitte nach.

Ahja, um das gleich vorweg zu nehmen, mir geht es nicht um die philosophische Frage, ob die Verwendung von configDB richtig ist oder nicht, sondern um Eure sachliche Gründe. Viele Wege führen nach Rom und welchen man nimmt, kann am Ende jeder selbst entscheiden.
Mir geht es also um die Gründe, warum Ihr Euch entschieden habt, configDB einzusetzen und nicht, warum Andere es nicht tun.
Selbstverständlich sind auch Gründe nachvollziehbar, wie "Weil es geht, Proof of concept". Daher läuft meine erste Testumgebung auf dem CT nun ja auch schon einmal "mit" .  Ich habe aber den Eindruck, ich habe die wahren Vorteile noch nicht erkannt und bin daher am Zaudern .

Bei Dblog erwarte ich, dass der Vorteil der Performance offensichtlich ist. Hat configDB ebenfalls einen gravierenden Einfluss auf die Performance der Weboberfläche?
Bei der Konfiguration habe ich derzeit nur das Versioning auf der Haben-Seite, was am Anfang sicherlich nicht zu vernachlässigen ist, wenn man unterschiedliche Wege ausprobiert. Ich muss zugeben, dass ich das beim Entwickeln immer QuickandDirty mit Kommentarzeichen löse .
Ggf. ist auch das Filehandling ein Vorteil, da das ja alles in der DB stattfindet und man dafür dann keine Konsole zu öffnen mehr braucht. Vielleicht ist das für Euch DAS Kriterium, ich habe die wahren Vorteile nur noch nicht erkannt.

Ahja, noch was. Mir geht es auch nicht um die Aufwände bei der Ersteinrichtung. D.h. wie z.B. das Backup realisiert wird, ist unerheblich, wenn es umsetzbar ist. Da man sich da am Anfang in beiden Fällen sowieso einmal mit beschäftigen muss, ist das für mich kein wirkliches Entscheidungskriterium.
Mir geht es eher um die praktischen Vor- und Nachteile während des Betriebs und der Wartung.

Ich freue mich auf Eure sachdienlichen Hinweise.
Allen schon mal ein schönes WE,
John

[joshi04]

Ich bin selbst schon etwas weiter gekommen:

Einen Vorteil habe ich schon einmal:
Mit configDB dürfte es keine "Reihenfolge" der Defines geben, da die "Datenbank" ja immer eine Antwort hat und das auch beim Starten. Probiert habe ich das aber noch nicht.
Hintergrund: Ich habe mich am letzten Wochenende selbst ausgetrickst und ein HeatingControl vor der Definition der aufgerufenen Devices gemacht. Folglich gab es nach jedem reboot oder reread und nur danach eine Fehlermeldung:

Code Auswählen Erweitern

invalid Device, given Device <BD_Heiz> not found
Im Betrieb war dann natürlich alles ok und die Devices dann auch bekannt. Daher hat es ein bisschen gedauert, bis ich drauf gekommen bin, wo die Fehlermeldung herkam. Gleiches geht natürlich auch mit WeekdayTimer, im übrigen beides geniale Module, wenn man sie anzuwenden weiß! Danke für die Entwicklung!

Einen Nachteil gibt es leider auch aus meiner Sicht. Denn das Starten von FHEM ist zusätzlich von der sauberen Erreichbarkeit des Datenbankservers abhängig. Das ist und bleibt leider eine Tatsache. D.h. wenn der nicht läuft, läuft auch FHEM nicht. Klar, dagegen hilft im ersten Schritt watchdog. Wenn die Datenbank allerdings korrupt ist, hilft aber auch kein automatischer Re-boot mehr, sondern ggf. nur noch ein re-store.
Hintergrund:
Nachdem ich nach ein paar Tagen durch kombinierte Verwendung von Sysmon, Revolt und DbLog 700k Einträge hatte, hat die Anzeige einiger Plots eine Unendlichkeit gedauert. Ja, und dann war ich zu ungeduldig... Die Datenbank habe ich mir zwar nicht geschrottet, wohl aber irgendwann einen Reset gemacht, auch nicht so schön.
Da gibt es noch Potential nach oben, was das Handling der Logs und Datenbank angeht, aber das ist ein anderes Problem.
Die marginal geringere Zuverlässigkeit hält mich natürlich nicht grundsätzlich davon ab, Datenbanken zu verwenden, wenn es aber keine anderen Vorteile gibt...

Was habt Ihr für Erfahrungen?
Schöne Grüße,
John

PS: Hoffentlich ist das hier die richtige Stelle? Sonst bitte verschieben.

[betateilchen]

Irgendwie beschreibst Du hier permanent Nachteile, die Dir begegnet sind, die wohl eher auf DbLog zutreffen als auf configDB.

configDB hat nämlich beispielsweise gar nichts damit zu tun, wie lange die Anzeige von Plots dauert...

Du solltest configDB und DbLog bitte nicht durcheinanderwürfeln, da stecken völlig unterschiedliche Philosophien dahinter.

[joshi04]

Hallo betateilchen,

Irgendwie beschreibst Du hier permanent Nachteile, die Dir begegnet sind, die wohl eher auf DbLog zutreffen als auf configDB.

Das ist nicht meine Absicht. Wenn DbLog aber dazu führt, dass configDB auch nichts mehr vom Server hört, was natürlich an meiner derzeitigen Verwendung von DbLog liegt, das ist klar, bleibt leider am Ende configDB auch auf der Strecke. Gut, wenn der SQL-Server den CT insgesamt in die Knie zwingt, ist auch mit config-files nicht mehr viel zu wollen. Also eigentlich doch kein Nachteil.
Meine Verwendung von DbLog ist derzeit noch ein anderes Problem (läuft erst seit 3 Tagen) und nicht Thema dieses Threads. Ich habe gelesen, Du hast 2Mio Datensätze auf vermutlich vergleichbarer Hardware. Also liegt es erstmal an meiner Konf.

configDB hat nämlich beispielsweise gar nichts damit zu tun, wie lange die Anzeige von Plots dauert...

Das erwarte ich auch nicht. Vermutlich kam das falsch rüber.
Vollkommen unabhängig davon habe ich allerdings noch nicht verstanden, welche Vorteile mir grundsätzlich die Verwendung von configDB gegenüber config-files bringt, denn genau, für die Performance erwarte ich keine Änderung.

Du solltest configDB und DbLog bitte nicht durcheinanderwürfeln, da stecken völlig unterschiedliche Philosophien dahinter.

Das habe ich verstanden. Bei der Philosophie von configDB hadere ich allerdings noch. Was sind die Gründe für Dich gewesen, das Modul zu schreiben?

Bitte verstehe mich nicht falsch. Ihr Entwickler schreibt geniale Module. Ich möchte nur verstehen, warum die Verwendung des Moduls configDB besser als config-files ist, um seine Vorteile optimal einzusetzen. Das habe ich derzeit tatsächlich noch nicht. Sicherlich bist Du als Maintainer des Moduls eine der Besten Quellen.

Vielleicht unterschätzte ich ja auch das Versioning. Um zu wissen, was hinter den "daraus immer wieder resultierenden Probleme" (ref commandref) steckt, setzte ich FHEM noch nicht lange genug ein. Vermutlich muss ich configDB einfach mal eine Weile einsetzen, um meine eigenen Erfahrungen zu machen.

Schöne Grüße,
John

[betateilchen]

Wenn DbLog aber dazu führt, dass configDB auch nichts mehr vom Server hört,

Spielt keine Rolle. configDB braucht den SQL Server lange bevor DbLog überhaupt ins Spiel kommt. Und im laufenden Betrieb braucht configDB den Server überhaupt nicht mehr.

[joshi04]

Ja, richtig, wird nach dem Start ja als erstes in den Speicher geladen.

Ich habe mich zu ungenau ausgedrückt. Ich meinte natürlich, dass wenn der SQL-Server nahezu 100% belegt, bedingt durch meine derzeitige DbLog-Konfiguration, der Prozess fhem und alle anderen auch nur noch wenig zum Zuge kommen und deutlich länger brauchen als gewohnt. Aber das Argument hatte ich ja vorher bereits grundsätzlich entkräftet, dass dieses überhaupt kein Nachteil in dieser Form ist.

Die Interpretation geht an dem vorbei, was ich ursprünglich sagen wollte. Mir ging es da eher um den Vergleich der Datensicherheit und Datenintegrität, für den Fall, dass man mal einen Stromausfall o.ä. hat. Vermutlich ist in diesem Zusammenhang aber die Bezeichnung "Nachteil" zu hoch gegriffen, denn dafür hat man ja sein Backup.

Schöne Grüße,
John

Edit: Korrektur s.o., 50 mio Datensätze, mittlerweile vermutlich noch deutlich mehr.

[Wuppi68]

bei ConfigDBsehe ich den extremen Vorteil der Ausfallsicherheit
Geht der FHEM Server kaputt, kann man super schnell die komplette Installation auf einen anderen Computer umziehen, so man die gleiche Hardware verfügbar hat. Dabei sollte aber die Datenbank nicht auf dem FHEM Server laufen ...

[marvin78]

Nun. Das geht auch, wenn man das Backup auf eine andere Maschine schiebt.

[Wuppi68]

das stimmt natürlich ...
es macht die Sache aber etwas entspannter und hat man auch wirklich immer nach jedem Save ein Backup?

[marvin78]

Nachteil wäre in dem Fall, dass mit FHEM auch auf jeden Fall und zu jeder Zeit noch ein zweiter Server laufen muss (Stromverbrauch etc...). Das muss bei der Backup-Lösung nicht sein.

[tobias.gj]

Hi,
bin vor kurzen auch auf einen CT umgezogen und habe beides im Einsatz DBlog und ConfigDB unter SQLite.
Filelogging habe ich komplett eliminiert.
Und in der Folge natürlich die Plots komplett auf DBLog umgestellt.

Die Performance ist in Summer erheblich besser.
Hat aber m.E.  erstmal nichts mit der ConfigDB zu tun.

nun zur ConfigDB.
Ich habe aufgrund der Größe meiner Umgebung mit einer ganzen Reihe von Config Dateien gearbeitet um die Übersicht nicht zu verlieren.
Meine fhem.cfg war mir zu groß und unübersichtlich geworden. Das brachte für mich aber auch eine ganze Reihe von Nachteilen mit sich.
Das hat sich für mich mit dem Einsatz der ConfigDB erledigt.

Ich denke es kommt darauf an wie man sein System aufsetzt und generell managed. Je größer und komplexer es wird um sehr mehr macht meiner Meinung die ConfigDB Sinn.

LG Tobias

[Rince]

Was der Tobias sagt.
Kann man nur unterschreiben.

[joshi04]

Hallo zusammen,

Derzeit arbeite ich auch noch mit einer Struktur aus Dateien, in die ich die Konfiguration aufgeteilt habe. Alles in einer fhem.cfg zu managen wäre mir tatsächlich auch jetzt schon zu unübersichtlich.
Dass aber auch dieses Vorgehen irgendwann an seine Grenzen stößt, kann ich mir vorstellen und habe vorher gar nicht dran gedacht.

Dass man bei größeren Installationen eine Datenbank für die Konfiguration gut brauchen kann bzw. vielleicht gar nicht mehr ohne auskommt, kann ich nachvollziehen. Ich muss zugeben, bei mir ist es mit der Übersichtlichkeit gerade noch ok aber auch schon grenzwertig.

Darüber hinaus muss ich nach dem Wechsel sicherlich meine Arbeitsweise anpassen, so wie Tobias geschrieben hat, "wie man sein System managed". Da bin ich vermutlich noch zu umständlich unterwegs.

Zwar werde ich kurzfristig den Umstieg noch einmal zurückstellen, wie oben beschrieben läuft das Logging noch suboptimal, eins nach em anderen, ConfigDB werde ich aber in jedem Falle im Hinterkopf behalten. Dank der Migrationsfunktion ist der Umstieg ja sehr einfach. Und solange kann ich noch mit meiner umständlichen aber gewohnten Arbeitsweise weiter managen...

Ich glaube auf alle Fälle, das Potential besser verstanden zu haben, vielen Dank erst einmal für Eure Antworten,
Schöne Grüße,
John

[chris1284]

ich lese immer wieder "viel, große, unübersichtliche Konfigurationsfiles". warum machen einige alles in Konfigurationsfiles und rechtfertigen so den einsatz einer configdb bei vielen devices?
ich meine mal gelesen zu haben das genau dies einer der Hauptgründe für configdb war, um nicht in Versuchung zu geraten in den Konfigurationsfiles zu manipulieren. legt ihr in der configdb dann auch immer schön alle Devices per Hand an  (insert bla into blub)? ich denke nicht.

den Grund das die Konfigurationsfiles unübersichtlich sind würde ich nicht als pro für configdb gelten lassen (diese ist ja eigentlich nichts anderes als eure unübersichtlichen, zeilenweise eingelesenen Files hübsch in eine Tabelle verpackt die sich die meisten eh nicht anschauen werden, genau so wie sie die Konfigurationsfiles nicht anschauen müssten) . man muss weder in der DB noch direkt in den Files arbeiten!

ich nutze configdb noch nicht. aber ich denke die Vorteile sind: Versionierung der configs mit der Möglichkeit einfach und schnell zurück zuspringen bei Fehlern, zentrale Konfigsammlung für mehrere fhem-instanzen auf einem dbserver (-> einfaches backup, Spiegelung , failover), evtl. Geschwindigkeitsvoreile)

[betateilchen]

genau dies einer der Hauptgründe für configdb war, um nicht in Versuchung zu geraten in den Konfigurationsfiles zu manipulieren

Genau das war die ursprüngliche Intention. Ich hatte einfach die vielen "Problem-Threads" hier im Forum satt, die lediglich daraus resultierten, dass nichtsahnende User sinnlos und ohne zu verstehen, was sie tun, in ihren Konfigurationsdateien rumpfuschen.

Ich wollte damals mit configDB einfach den Beweis antreten, dass es keinen (!) Grund gibt, irgendwelche Konfigurationen manuell bearbeiten zu müssen. Man kann alles über die fhem Bordmittel im Frontend erledigen.