[DbLog] Erfahrungen Plattenplatz und Client/Server-Architektur

[Thorsten Pferdekaemper]

Hi,
ich beschäftige mich momentan mit einem Hardware-Upgrade meines FHEM-Systems. Ein paar Sachen laufen doch nicht mehr ganz so flott auf meinem RasPi 1. Dabei möchte ich auch so langsam auf DbLog umstellen.

Plattenplatz
Ich habe mir ausgerechnet, dass ich momentan so in etwa 500MB/Jahr an Logfiles produziere. Weiß jemand, ob man das mehr oder weniger auf die LogDb (wahrscheinlich mySQL oder MariaDB) übertragen kann? ...oder braucht man dann um Größenordnungen mehr Speicher.

Client/Server?
Gibt es Erfahrungswerte oder starke Meinungen dazu, ob man die Datenbank mit auf den FHEM-Rechner packt oder sie lieber auf einen eigenen Server legt? Momentan tendiere ich dazu, sie mit auf den FHEM-Rechner zu packen, aber vielleicht habe ich da etwas nicht bedacht.

Danke&Gruß,
   Thorsten

[arturDUS]

Hallo Thorsten,

Meine FHEM Installation läuft auf einem RASPI 3 der ja bekannter Maßen sein Filesystem auf einer externen SD-Karte hat.
Für mich war die Entscheidung, die Datenbank (DBLog) auszulagern und den mySQl Server meiner NAS zu nutzen, alleine getrieben durch die Tatsache das eine SD-Karte nicht unendlich viele Schreib-Zyklen zulässt und ich mir nicht die SD-Karte zerschießen will.
Mit meiner NAS und den hochwertigen Serverplatten da drin sehe ich die Zukunft da eher gelassen.
Außerdem habe ich so auch immer ein vernünftiges, automatisches Backup der Daten weil meine NAS einmal in der Woche die mySQL Datenbank auf eine externe USB-Festplatte schreibt.
Die Menge an Daten ist natürlich abhängig davon welche Daten Du loggst. Ich schreibe überwiegend nur dynamische Daten (Temperatur/Feuchte/Ventilstellung/Wasserverbrauch, ...) in meine Datenbank die ich später zur Auswertung - Bin halt ein Diagramm-Nerd - barauche. Daneben z.B. Fensterkontakte und Kontaktausgänge mit denen z.B. die Heizung angesteuert wird.. Das mache ich immer dann wenn sich ein Wert geändert hat oder ebend, wenn sich keine Daten geändert haben alle 5Minuten.

Viele Grüße,

Artur

[roedert]

Problem ist wie schon gesagt die SD-Karte - ich würde da auf jeden Fall auf eine SATA-SSD wechseln.
Entweder diese per Adapter am Pi oder besser noch gleich eine Hardware mit SATA-Anschluß wählen (Banana Pi, Cubietruck, Odorid etc)
Und evtl mal überlegen ob man Logfiles überhaupt nen Jahr braucht, und vor allem auch überlegen was man alles loggt.
Tut FHEM auch gut wenn an die Anzahl der Events reduziert (event-on-update-reading/event-on-change-reading). Aufeinanderfolgende gleiche Werte braucht man nicht loggen, und Graphen kann man daraus genausogut erstellen, evtl. mit Hilfe von logproxy.
Und Daten die man wirklich "historisch" aufbewahren möchte, kann man wunderbar ausdünnen - also zB nur noch wenige Werte oder min-max-Werte pro Tag aufheben.
Die Möglichkeiten mit einer Datenbank statt Logfiles sind da bedeutend umfangreicher!

Ne interessante Hardware wäre zB auch der ACEPC AK1 (knapp 180 Euro bei amazon), ist nen richtiger PC mit RAM und eMMC-Speicher fürs OS und sogar nem Slot für eine mSATA-SSD und optional auch noch ner richtigen 2,5er SATA-SSD. Debian ist darauf schnell und einfach installiert.

[DS_Starter]

Hallo Thorsten, @all,

zum Thema Plattenplatz:

Eine DB benötigt auf jeden Fall mehr Plattenplatz als Flatfiles. Der Mehrbedarf resultiert allein schon aus dem Vorhandensein von einem oder mehreren Indizes.
Nutzt man den Standardindex und einen primary key (PK) für history, entsteht ein Mehrbedarf von ca. 30%. Eine meiner produktiven MariaDBs enthält 2006MB Daten und 2856MB insgesamt, also 850MB für den Index.

Ich betreibe alle MariaDB-Datenbanken auf meinem Synology-NAS und nutze dort sowohl die Versionen 5 und 10. D.h. die DB's sind von den FHEM-Servern getrennt und DbLog schiebt die Daten über das Netzwerk in die DB. Momentan sind 2 produktive (und weitere 3 Test) MariaDB-Datenbanken in Benutzung. Eine für die langfristige Datenspeicherung der für mich wichtigen Energie- und PV-Anlagendaten und eine weitere DB deren Inhalte ich regelmäßig ausdünne bzw. nach 90-180 Tagen lösche. Dies DB enthält nur Daten für die aktuelle Anzeige aller möglichen Plots und Auswertungen.
Die PV-Daten will ich langfristig aufbewahren um Monats- und Jahresvergleiche anfertigen zu können bzw. die Alterung der Solarelemente über die Jahre einschätzen und erkennen zu können.

Ich persönlich würde die DB immer getrennt von FHEM betreiben um im Falle eines notwendigen FHEM-Restores nicht auch die DB anfassen zu müssen und auch um die Annehmlichkeiten des NAS für die Backupstrategie nutzen zu können.
Außerdem habe ich vor DbLog (bzw. dessen Nachfolger MDbLog für MariaDB) mandantenfähig zu machen und so die Speicherung von mehr als einer FHEM-Instanz in dieselbe DB zu ermöglichen. Das geht zwar prinzipiell jetzt bereits, doch werden bei Plots etc. alle Daten berücksichtigt unabhängig von deren Herkunft.
Und in diesem Umfeld halte ich eine zentrale DB auf einem anderen Nicht-FHEM-System für angebrachter.

Grüße,
Heiko

[Thorsten Pferdekaemper]

Hi,
Danke erst einmal für die bisherigen Anregungen!

Meine FHEM Installation läuft auf einem RASPI 3 der ja bekannter Maßen sein Filesystem auf einer externen SD-Karte hat.

In dem Fall ist es klar. Datenbank und SD-Karte ist nicht so der Hit.
Darum ging's mir auch nicht unbedingt. Mein neuer FHEM-Host wird jedenfalls so in der Gegend von 250GB SSD bekommen.

Außerdem habe ich so auch immer ein vernünftiges, automatisches Backup der Daten weil meine NAS einmal in der Woche die mySQL Datenbank auf eine externe USB-Festplatte schreibt.

Geht das nicht mit normalen "Bordmitteln" auch? D.h. was spräche dagegen, dass der FHEM-Server selbst das Backup macht?

Die Menge an Daten ist natürlich abhängig davon welche Daten Du loggst.

Das ist klar, deswegen habe ich ja meine 500MB/Jahr als Größenordnung mitgegeben.

Problem ist wie schon gesagt die SD-Karte - ich würde da auf jeden Fall auf eine SATA-SSD wechseln.
Entweder diese per Adapter am Pi oder besser noch gleich eine Hardware mit SATA-Anschluß wählen (Banana Pi, Cubietruck, Odorid etc)

Naja, wenn ich schon aufrüste dann richtig. Momentan habe ich einen ZOTAC BI329 (Intel N4100) mit 8GB RAM und 250GB SATA 6 SSD. Das dürfte bezüglich Stromverbrauch noch im Rahmen liegen und hat ein bissel mehr Wumms als der ganze Pi-Krams.

Und evtl mal überlegen ob man Logfiles überhaupt nen Jahr braucht, und vor allem auch überlegen was man alles loggt.

Deswegen ja die Frage nach dem Plattenplatz. Wenn ich mal von 500MB/Jahr ausgehe, dann reichen meine 250GB ungefähr 500 Jahr. Da sehe ich jetzt nicht unbedingt die Notwendigkeit, mir da sooo viele Gedanken zu machen.

Ne interessante Hardware wäre zB auch der ACEPC AK1 (knapp 180 Euro bei amazon), ist nen richtiger PC mit RAM und eMMC-Speicher fürs OS und sogar nem Slot für eine mSATA-SSD und optional auch noch ner richtigen 2,5er SATA-SSD. Debian ist darauf schnell und einfach installiert.

Ja, das ist so eine ähnliche Kiste wie die BI329, nur halt langsamer und braucht wahrscheinlich mehr Strom, soweit ich das überblicke.
Am liebsten hätte ich was im 19-Zoll Rack mit 1HE, aber da wird's dann wirklich teuer und Stromspar-Kram ist auch nicht einfach zu finden.

Eine DB benötigt auf jeden Fall mehr Plattenplatz als Flatfiles. Der Mehrbedarf resultiert allein schon aus dem Vorhandensein von einem oder mehreren Indizes.

Das ist mir klar. Mir geht es hier auch nicht um 30%, sondern eher um die Größenordnung. So lange aus meinen 500MB nicht plötzlich 5000MB werden ist ja alles gut.

Ich betreibe alle MariaDB-Datenbanken auf meinem Synology-NAS

Diese NAS-Dinger mag ich nicht mehr. Ich will meine Debian-Kommandozeile mit dem normalen Paketmanager etc. Da habe ich eher das Gefühl, ich habe alles unter Kontrolle.

Eine für die langfristige Datenspeicherung der für mich wichtigen Energie- und PV-Anlagendaten und eine weitere DB deren Inhalte ich regelmäßig ausdünne bzw. nach 90-180 Tagen lösche. Dies DB enthält nur Daten für die aktuelle Anzeige aller möglichen Plots und Auswertungen.
Die PV-Daten will ich langfristig aufbewahren um Monats- und Jahresvergleiche anfertigen zu können bzw. die Alterung der Solarelemente über die Jahre einschätzen und erkennen zu können.

Was würde passieren, wenn Du nichts löschst? Wie viel wäre das nach 10 Jahren oder so?

Ich persönlich würde die DB immer getrennt von FHEM betreiben um im Falle eines notwendigen FHEM-Restores nicht auch die DB anfassen zu müssen

Was wäre denn so ein Fall des FHEM-Restore, bei dem man die DB auch anfassen müsste? Klar, wenn man die ganze Kiste neu aufsetzt, aber warum schmiert eher der FHEM-Rechner ab als die NAS? Auf der NAS läuft ja im Zweifelsfall viel mehr, das man nicht unter Kontrolle hat.

und auch um die Annehmlichkeiten des NAS für die Backupstrategie nutzen zu können.

Welche wären das?

Außerdem habe ich vor DbLog (bzw. dessen Nachfolger MDbLog für MariaDB) mandantenfähig zu machen und so die Speicherung von mehr als einer FHEM-Instanz in dieselbe DB zu ermöglichen. Das geht zwar prinzipiell jetzt bereits, doch werden bei Plots etc. alle Daten berücksichtigt unabhängig von deren Herkunft.
Und in diesem Umfeld halte ich eine zentrale DB auf einem anderen Nicht-FHEM-System für angebrachter.

Das klingt erst einmal interessant, aber DB-Integration ist ja so 90er... (SCNR)
Ich habe (momentan?) nur ein produktives FHEM-System, aber was nicht ist kann ja noch werden.

Ich glaube, dass ich erst einmal auf einem einzelnen Server bleibe und mir lieber ein paar mehr Gedanken über Indizes und Backupstrategie mache. Sollte ich irgendwann merken, dass das doch blöd war, dann kann ich ja immer noch umziehen. Ein paar GB zu kopieren tut nicht wirklich weh...

Danke&Gruß,
   Thorsten

[DS_Starter]

Hi Thorsten,

Was würde passieren, wenn Du nichts löschst? Wie viel wäre das nach 10 Jahren oder so?

Keine Ahnung ... was ich nicht mehr brauche lösche ich eben. Ich habe da noch keine Religion daraus gemacht. 

Welche wären das?

Zum Beispiel die täglichen Sicherungszyklen mit inkrementellen Sicherungen und Generationenverwaltung out of the Box.
Betrifft ja nicht nur die DB sondern alles was sich auf dem NAS befindet sowie die Sicherung der VM's auf dem NUC. Die DB dort einzubeziehen liegt nahe.
Das NAS ist bei mir "eh da", soll heißen läuft ohnehin rund um die Uhr.

Das klingt erst einmal interessant, aber DB-Integration ist ja so 90er... (SCNR)

Diese Zeit hat mich geprägt ... 

Grüße
Heiko

[eldrik]

Moin,

meine Infrastruktur ähnelt im Großen und Ganzen der von Heiko unterscheidet sich jedoch an einigen Stellen.

Die FHEM Umgebung läuft derzeit vollständig virtualisiert mit Hilfe von VMWare esxi 6.0.

Die Rechenpower stellt ein MacMini Server late 2012 Quad Core i7 2,3Ghz mit 16GB RAM zur Verfügung als Backup dient ein kostengünstiges Mini ITX Systen auf Basis Athlon 5350 2Ghz.

Für die Datenhaltung sorgt ein Synology DS214+ im Raid1 bestehend aus WD Red Platten, welches die LUNs per iSCSI als auch NFS, für die esxi Datenspeicher, zur Verfügung stellt

Ein Backup der LUNs erfolgt auf externe USB3.0 Datenträger.

Die in esxi vorhandenen VMs werden zudem separat, auf externe USB3.0 Datenträger, gesichert. Sollte das NAS tatsächlich einmal ausfallen kann ich die Umgebung kurzfristig über den USB3.0 Datenträger und der dort vorhandenen VMs wieder an den Start bringen.

Die vollständige IT Infrastruktur und zentrale Stromversorgung, für die im Haus verbauten Sensoren, Switche, Kameras etc.  (via 48V auf 12V und 5V POE Wandler) ist über eine APC USV gegen Überspannung und kurzfristige Stromausfälle geschützt.

Meine FHEM Hauptinstanz läuft auf einer Debian VM, neben der Hauptinstanz gibt es noch eine weitere Debian VM, die vier FHEM Instanzen beeinhaltet, welche sich nur um die 1Wire Kommunikation kümmern, da diese zum Teil dafür sorgen, dass FHEM blockert wurden die Moduldefinitionen ausgelagert.

Die Kommunikation mit der Hauptinstanz erfolgt via FHEM2FHEM, geloggt wird alles via DBLOG.

Die DBLOG Datenbank (Postgres ca. 200GB Größe Datenhaltung von ca. 2-3 Jahren) läuft ebenfalls auf einer separaten Debian VM, neben dem esxi VM Backup, wird die Datenbank zusätzlich über Datenbankmittel gesichert, das ich mich hier gegen die direkte Platzierung, auf dem NAS oder Installation auf der Hauptinstanz entschieden habe, hat mehrere Gründe.

a) der MacMini hat schlichtweg mehr Computingpower und RAM Ressourcen, die sich über esxi einfach besser Skalieren lassen und das NAS soll sich bei mir, mit seinen begrenzten Systemressourcen, um seine Hauptaufgaben kümmern (Netzwerkspeicher + Synology Surveillance Station (Kameraüberwachung)).

b) bei Ausfall des NAS habe ich weiterhin die Möglichkeit kurzfristig auf die zuletzt gesicherte Datenbank VM zurückzugreifen und sollte es der Aufwand wert sein, kann das Datendelta aus der Backup VM wieder in die Wiederhergestellte VM übertragen werden

c) mit einem vollwertigen Debian gehen Systemarbeiten einfach besser von der Hand als mit der abgespeckten OS Umgebung des NAS und  Datenbanktätigkeiten, Upgrades etc. lassen sich,  in Vebindung mit esxi, mit einem Backup oder vorherigen SNAP einfach besser absichern bzw. testen

d) durch die Trennung der Datenbank von der Hauptinstanz stehen mir unterschiedliche Patchzyklen zur Verfügung z.B. patche ich das OS meiner FHEM Hauptinstanz aus Sicherheitsgründen einfach häufiger, da dies die Instanz ist, mit der Kommunikation zur Aussenwelt darstellt.

Die Uptimezähler von MacMini, NAS und Core LAN und POE Switchen haben bei mir, in der jetzigen Kombination, schon mehrmals > 365Tage erreicht ohne, dass dazwischen eine ungeplante Downtime, durch einen Hardwaredefekt, vorhanden war.

Greetz
Eldrik

[Thorsten Pferdekaemper]

Keine Ahnung ... was ich nicht mehr brauche lösche ich eben. Ich habe da noch keine Religion daraus gemacht. 

Klar, man will ja auch ein bisschen Ordnung haben. Ich dachte nur, dass Du vielleicht ein Gefühl dafür hast, um wie viel das ganze pro Jahr oder so wachsen würde. Wenn nicht, dann ist auch ok. Ich habe mir mal eine Test-Instanz auf meinen Laptop gebastelt. Die braucht in der history-Tabelle inklusive Index 54,1MiB für 325750 Einträge. Das sind 174 Byte pro Eintrag. Wenn ich das mit FileLog vergleiche, dann komme ich ungefähr auf einen Faktor 3. D.h. DbLog braucht dreimal mehr Platz als FileLog. Das ist natürlich nur eine ganz grobe Abschätzung, aber mir reicht's erstmal.

Zum Beispiel die täglichen Sicherungszyklen mit inkrementellen Sicherungen und Generationenverwaltung out of the Box.

Ah, ok. Da habe ich mir sowieso schon was selbst gebastelt. Bei mir steht da für's Backup eine eigene Kiste mit zwei dicken Platten, die per btrfs gespiegelt sind. Das Ding zieht sich jede Nacht alles sicherungswürdige von allen Rechnern. (Darunter auch ein kleines NAS...)

Danke&Gruß,
   Thorsten

[Tedious]

Läuft bei mir auf einem Brix mit SSD.

Daten dünne ich per reducelog 3 täglich aus. Einmal im Jahr schicke ich per HeidiSQL ein Statement an die DB (Zeitraum), exportiere die Ergebnisse in ein komprimiertes Zip-File (csv), im Anschluss denn ein OPTIMIZE TABLE. DB Größe ist immer <1Gb.