Größe der configDB

[betateilchen]

Macht es nicht vielleicht auch Sinn, dass du das mit auto_vaccum in deinem Workshop einbaust?

Nein.

[Amenophis86]

Ich liebe deine Antworten Und sagst du mir auch wieso? Hätte ich direkt dazu sagen sollen, habe ich vergessen. Sry

[Hauswart]

When the value of auto-vacuum is 2 or "incremental" then the additional information needed to do auto-vacuuming is stored in the database file but auto-vacuuming does not occur automatically at each commit as it does with auto_vacuum=full. In incremental mode, the separate incremental_vacuum pragma must be invoked to cause the auto-vacuum to occur.

https://www.sqlite.org/pragma.html#pragma_incremental_vacuum

Dazu habe ich eine Verständisfrage, auto_vacuum=2 aktiviert nur das Verkleinern, aber das aktive Verkleinern muss ich danach mit sqlite2 fhem.db vacuum ausführen?

@betateilchen wieso macht es keinen Sinn dies in den Workshop einzubauen? Bzw. oder ins Wiki (https://wiki.fhem.de/wiki/DbLog#Beispiel:_Anlegen_und_Nutzung_einer_SQLite-Datenbank).



Gruss

PS: Immer noch unschlüssig ob MySQL oder sqlite

[betateilchen]

Vielleicht könnten die Leute, die mir hier permanent versuchen, gute Tipps zu meinem Workshop zu geben, diesen erst einmal selbst absolvieren, dann erledigen sich viele Vorschläge von ganz alleine.

• der Workshop hat das Bestreben, für den Teilnehmer so einfach wie möglich verständlich zu sein.
• in dem Workshop wird überhaupt keine Datenbank neu angelegt.
• das Datenbankverhalten und die Zugriffsverfahren von DbLog und configDB sind grundsätzlich unterschiedlich und sollten nicht dauernd durcheinander geworfen werden.
• WIKI Einträge zu meinen Modulen mag ich genauso sehr wie Fußpilz. Unsinn, der aus gefährlichem Halbwissen resultiert, weil irgendjemand meint, meine Module besser beschreiben zu können als ich in der commandref, ist unglaublich schwer wieder aus den Köpfen derjenigen rauszukriegen, die ihn einmal gelesen haben. Und ich selbst werde nicht zwei Dokumentationen pflegen - für mich ist das verbindlich, was in der commandref steht.

PS: Immer noch unschlüssig ob MySQL oder sqlite

Völlig egal.

Meine produktive configDB liegt aktuell in einer SAP HANA Datenbank, ich wollte einfach wissen, ob/wie das geht.

[Hauswart]

Mmh eine Frage habe ich dazu aber noch, die configDB.db im Contrib-Ordner hat diese das Attribut schon gesetzt oder würdest du zum Manuellen anlegen der DB raten (siehe Commandref) und das Setzen empfehlen?

Die Unterschiede bei Dblog und configDB sind mir ehrlich gesagt nicht ganz klar (bin bisher nur mit Files für Konfig & Logs unterwegs), da ich in der Commandref bei dblog (und auch im Contrib bei dblog) nichts gefunden habe, auto_vacuum auch bei dblog aktivieren?

Meine produktive configDB liegt aktuell in einer SAP HANA Datenbank, ich wollte einfach wissen, ob/wie das geht.

Das finde ich nun sehr interessant. Leider liegt unser SAP auf einem MySQL und wird es wohl auch noch länger... Völlig egal - naja. Eine Migration von sqlite zu MySQL bzw. andersherum ist leider kaum machbar, d.h. es ist quasi mehr oder weniger eine Grundsatzentscheidung (Thematik: Dblog und configDB).

[Prof. Dr. Peter Henning]

WIKI Einträge zu meinen Modulen mag ich genauso sehr wie Fußpilz

Das Vorhandensein von Fußpilz richtet sich aber nicht nach dem "Mögen" oder "Nichtmögen".

LG

pah

[Beta-User]

Eine Migration von sqlite zu MySQL bzw. andersherum ist leider kaum machbar, d.h. es ist quasi mehr oder weniger eine Grundsatzentscheidung.

Na ja, man kann immer noch hergehen und den Umweg über die Speicherung einer aktuellen fhem.cfg machen (attr. global, im Wiki verlinkt). Diese kann man dann wieder in das nächste DB-System einspeisen. Andere Files kann man über die Export-Funktion rausspeichern, sofern erforderlich (nutze nur fhem.cfg@sqlite).

Kann also Interessierten nur empfehlen, configDB mal auszutesten. Der Vorteil, den ich als normaler User sehe ist der, dass die fhem.cfg-Variante sehr empfindlich ist, wenn Devices, die fhem als "hart" vorhanden voraussetzt (z.B. 1-wire@OWX) löscht, wenn sie nicht erreichbar sind. Speichert man dann die config, ist das Device weg und man muss es über Sicherungskopien reparieren.

Nachteil (bitte nicht verhauen, wenn es nicht stimmt): Die Reihenfolge zu ändern, in der Devices gespeichert werden, ist unmittelbar in der DB kaum möglich. Ob das erforderlich wäre, kann ich nicht sagen, ich bräuchte mal eine ruhige Minute, um z.B. eine VCCU einzurichten und dann das IO/device von CUL (zu löschen) auf serielles PI-Modul umzustellen. Aber auch configDB scheint nichts daran zu ändern, dass die Devices in einer sinnvollen Abfolge geladen werden müssen.

Just m2ct.

@pah und die anderen Kritiker von betateilchens klarer Kante:
Man muß diese Position nicht mögen, aber die Dinge sind in sich konsistent und entsprechen den Vorgaben (verpflichtend ist NUR eine englische Commandref)! M.E. weisen wir nur zu selten auf diesen Umstand hin .

[Prof. Dr. Peter Henning]

Das ist ein Missverständnis - keineswegs kritisiere ich seine "klare Kante" (ausgerechnet ich ...).
Man muss nur immer aufpassen, dass man das Kind nicht mit dem Bade ausschüttet - und das scheint mir der Fall zu sein, wenn man komplett auf eine erläuternde Dokumentation verzichtet.

Ist eine Frage der pädagogischen Erfahrung sozusagen.

LG

pah

[Amenophis86]

Hab jetzt noch keinen Grund gehört, wieso der Vaccum Befehl nicht in den Workshop sollte, außer, dass er einfach sein soll. Sehe ich jetzt nicht als komplizierten Schritt an, besonders, wenn er in der Commandref drin steht und im Workshop nicht. Das ist für mich nicht verständlich. Und versucht dir zu erklären, wie es besser geht, habe ich auch nicht, lediglich nachgefragt. Aber gut, habe verstanden, dass du es nicht willst und damit soll es für mich auch gut sein. Mehr als Fragen kann und will ich nicht

@Beta-User: Sehe nicht wo ich seine Kante kritisiert habe. Im Gegenteil:

Ich liebe deine Antworten Und sagst du mir auch wieso? Hätte ich direkt dazu sagen sollen, habe ich vergessen. Sry

[Beta-User]

@pah und wer auch immer sich potentiell angesprochen fühlt:
...das mit "Kritik" war nicht böse gemeint, ich wollte nur zum Ausdruck bringen, dass ich diese Haltung nach meinem ersten (zugegebenermaßen sehr irritierenten) Kontakt damit nunmehr für ok halte, zumal die Doku in der Commandref m.E. vollständig zu sein scheint und der Wiki-Artikel exisitert, wenn auch im Wesentlichen nur mit dem Hinweis, dass die Commandref zu Rate zu ziehen ist. So landet man wenigstens zielgerichtet beim aktuellen "Stand der Dinge" (allerdings nicht bei dem die Einrichtung für DAU's vereinfachenden workshop, warum auch immer...).

Dass das deutlich werbewirksamer geht, ist wohl wahr, andererseits verhindert diese sehr technische Darstellung, dass sich die falschen Leute auf configDB einlassen und erfüllt gerade damit möglicherweise den beabsichtigten Zweck (oder ist doch eine flächendeckende Einführung von configDB angestrebt?).

Eine Anmerkung noch zum workshop (und zum Beitrag von Amenophis86): kaum ein minderbegabter Normaluser wie ich wäre darauf gekommen, dass die Vorlage für sqlite einem schon das Einrichten von auto_vacuum abnimmt (so habe ich den Beitrag vn Hauswart verstanden). Insoweit wäre vielleicht ein Hinweis auf diesem Umstand im workshop eine Anregung, nur für den Fall, dass jemand sich die Mühe macht, parallel den workshop durchzuarbeiten und in die commandref zu schauen .

Unbedarfte Grüße,

Beta-User

[Amenophis86]

Eine Anmerkung noch zum workshop (und zum Beitrag von Amenophis86): kaum ein minderbegabter Normaluser wie ich wäre darauf gekommen, dass die Vorlage für sqlite einem schon das Einrichten von auto_vacuum abnimmt (so habe ich den Beitrag vn Hauswart verstanden).

Wenn dem so sein sollte, was ich leider nicht nachvollziehen kann, da ich keine Editor für die db Datei habe, dann wäre es natürlich schön. Dann wiederum verstehe ich auch, wieso es nicht im Workshop steht, weil es schon dabei ist und eh nicht jede Funktion erklärt wird und warum es in der CommandRef steht, wo quasi die komplette DB angelegt wird. Und ich sage mal so, wenn man vielleicht diesen Halbsatz zum "Nein" noch dazu geschrieben hätte, wäre die komplette Diskussion hinfällig. So hatten wir wenigstens alle ein bisschen Spaß

[Hauswart]

Eine Anmerkung noch zum workshop (und zum Beitrag von Amenophis86): kaum ein minderbegabter Normaluser wie ich wäre darauf gekommen, dass die Vorlage für sqlite einem schon das Einrichten von auto_vacuum abnimmt (so habe ich den Beitrag vn Hauswart verstanden). Insoweit wäre vielleicht ein Hinweis auf diesem Umstand im workshop eine Anregung, nur für den Fall, dass jemand sich die Mühe macht, parallel den workshop durchzuarbeiten und in die commandref zu schauen .

Das war bisher nur eine unbestätigte Vermutung.

Die Konfig kann ich aus sqlite wieder exportieren und danach in z.B. MySQL importieren, aber wenn ich sqlite für die Konfig einsetze, dann auch für die Logs von daher muss ich es mir vorher schon überlegen Wenn sqlite dann alles, wenn MySQL dann alles

Gruss

[mahowi]

Gibt es eigentlich Vor-/Nachteile von sqlite bzw. MySQL, die einem die Entscheidung für das eine oder andere erleichtern?

[Beta-User]

Das war bisher nur eine unbestätigte Vermutung.

Hoffentlich bekommen wir dazu eine fachkundige Antwort, ebenso zu Deiner Frage, ob man das dann jeweils auch gesondert anstoßen muß...

aber wenn ich sqlite für die Konfig einsetze, dann auch für die Logs von daher muss ich es mir vorher schon überlegen Wenn sqlite dann alles, wenn MySQL dann alles

Einerseits nachvollziehbar (war auch mal mein Ansatz), andererseits ist das nicht zwingend. Man kann durchaus sqlite für configDB nehmen und MySQL für die logs (macht u.U. schon deswegen Sinn, weil eine "lokale" config fhem jendefalls starten läßt und (@mahowi) MySQL auf einem PI eher wenig Spaß zu machen scheint). So man die logs überhaupt umstellt (scheint entgegen den Werbeaussagen eher zu einem trägen System zu führen bzw. geführt zu haben ). Nicht jeder hat schließlich einen performanten MySQL-Server zuhause .

Richtig ist jedenfalls, dass dblog und configDB zwei unterschiedliche Paar Schuhe sind.

[n0bbi]

Also auf meinem PI hat die Umstellung auf logdb einen enormen Geschwindigkeitszuwachs gebracht.

Was mir allerdings noch nicht ganz klar ist, ist was mir die Configdb für Vorteile bringt? Geschwindigkeit kann es ja eigentlich kaum sein, gibt es andere Gründe umzustellen?

Danke

Gesendet von meinem Nexus 5X mit Tapatalk