Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Blockmove]

@sammy-r said in Datenbank, Historie, Trockner-Tracker:

Vermute ich richtig, dass das der Fall wird, wenn man zu viele Datenpunkte hat und die JSON-Speicherung nicht mehr ausreicht?

Für solche Fälle unterstützt ioBroker Redis als Datenbank.

Ausser für die Aufzeichnung gibt es kaum Notwendigkeiten für andere DBs.
Interessant für sowas ist die Integration von NodeRED in ioBroker.
NodeRED kann hervorragend als Gateway zu anderen System wirken.

[Homoran]

@sammy-r sagte in Datenbank, Historie, Trockner-Tracker:

Vermute ich richtig, dass das der Fall wird, wenn man zu viele Datenpunkte hat und die JSON-Speicherung nicht mehr ausreicht?

kann ich nicht bestätigen.
Mein Konstrukt war erst nur als Test gedacht, inzwischen sind es >200DPs, einiges davon im 6-Sekundentakt.

Ich arbeite im Moment sogar noch mit file und nicht jsonl

[Ein ehemaliger Benutzer]

@sammy-r sagte in Datenbank, Historie, Trockner-Tracker:

Frage 5:
Ich habe wahrgenommen, dass InfluxDB ist für Historien und Zeitreihen die bessere Lösung ist und frage mich, welchen Einsatzgrund es dann für eine SQL-DB gibt.
Vermute ich richtig, dass das der Fall wird, wenn man zu viele Datenpunkte hat und die JSON-Speicherung nicht mehr ausreicht? Da hilft das spezielle Datenmodell von InfluxDB ja vermutlich nicht.

Moin,

Zum ersten Teil Deiner Frage, ja, influxDB ist entwickelt worden, genau für solche Anwendungsfälle, wo eine große Menge an zeitlichen Daten anfallen, aber jetzt kommt der Unterschied, influxDB ≠ SQL Datenbanken, ich möchte hier nicht tiefer darauf eingehen, dazu gibt es genug Informationen im Internet, der entscheidende Punkt ist, dass sich die Abfragesprachen unterscheiden, bei den klassischen SQL Datenbanken ist das, oh Wunder, SQL, bei influxDB ist das aktuell, noch FLUX oder influxQL. Daher nutzen mache User lieber eine SQL Datenbank, da sie die Abfragen lieber/besser in SQL formulieren können.
Bei influxDB tut sich was, bezüglich der Abfragesprache, aber wie das dann am Ende aussieht, steht noch nicht ganz fest, habe mich damit noch nicht befasst.

Beim zweiten Teil, kann ich nicht ganz folgen, influxDB kann zwar mit JSON Umgehen, aber es wird da nichts in JSON gespeichert, das Speichern in influxDB oder auch in der klassischen SQL Datenbank ist ein datenbanktypisches Format, der History Adapter nutz glaube ich das JSON Format.

Oder meinst Du die zwei ioBroker internen Objekt-, Status Datenbanken, die als JSONL vom ioBroker angelegt werden? Da ist dann aber der Zusammenhang zu der obigen Datenbanken nicht mehr gegeben, wenn damit Probleme, wegen irgendwelcher Flaschenhälse auftauchen, dann muss man sich tatsächlich wie @Blockmove geschrieben hat, mit Redis auseinandersetzen, das ist aber ein ganz anderes Thema und ich würde dann lieber erst einmal von einer SD-Karte hin zu einer SSD am RasPI tendieren.

VG
Bernd

[Homoran]

@dp20eic sagte in Datenbank, Historie, Trockner-Tracker:

der History Adapter nutz glaube ich das JSON Format.

jepp
jeder Tag ein Verzeichnis, darin jür jeden DP ein JSON

[Sammy R.]

Ich danke Euch für die weiteren Ausführungen.

Ich habe also gelernt, dass eine SQL-DB für den Betrieb von ioBroker erst bei wirklich viel Last notwendig wird und dass dafür Redis bereit steht.
Dass z.B. Node-Red eine SQL-DB benötigt habe ich gar nicht bedacht. War aber ja auch nur aus Interesse.

Dann bin ich da ja gut unterwegs, starte erstmal mir dem History-Adapter und nehme mir dann irgendwann man Influx vor. SQL beherrsche ich prinzipiell, im Zweifel muss ich da aber bei inner-left-chuck-norris-Joints auch wieder nachlesen :-)

Hab jetzt eine Idee, wie ich weiter machen kann. THX

[Blockmove]

@sammy-r said in Datenbank, Historie, Trockner-Tracker:

Dass z.B. Node-Red eine SQL-DB benötigt habe ich gar nicht bedacht. War aber ja auch nur aus Interesse.

Node RED braucht keine Datenbank. Jedoch ist Node RED das Schweizer Taschenmesser für IoT-Anwendungen.
Wenn man also einen Austausch zwischen ioBroker und einer Datenbank braucht, dann ist Node RED ein einfach handelbares Gateway

[Sammy R.]

@blockmove OK. Danke für die Korrektur, das hatte ich falsch verstanden.

[Ein ehemaliger Benutzer]

@sammy-r sagte in Datenbank, Historie, Trockner-Tracker:

Ich habe also gelernt, dass eine SQL-DB für den Betrieb von ioBroker erst bei wirklich viel Last notwendig wird und dass dafür Redis bereit steht

Moin,

Du verdrehst da was, aber so richtig.

Bleib doch erste einmal nur bei den Datenbanken, da ist es so, dass einige/viele lieber eine "richtige" Datenbank haben wollen, nicht den History Adapter, denn der ist nur mit ioBroker internen Adaptern lauffähig, wohingegen, die influxDB oder SQL Adapter die Anbindung an Datenbanken außerhalb des ioBrokers ermöglichen und dann kannst Du auch andere, mächtige Tools zur grafischen Darstellung nutzen, siehe -> https://play.grafana.org/dashboards.

Redis hat was mit den internen Datenbanken des iobrokers zu tun! Nicht mehr und nicht weniger, das hat nichts mit historischen Daten in einer Datenbank zu tun!

VG
Bernd

[Sammy R.]

@dp20eic
Das hatte ich schon alles so verstanden.

Ich habe im Moment aber nichts, was ausserhalb vom ioBroker 'existiert', geschweige denn Unmengen an Daten produziert. Deshalb möchte ich erstmal den kürzesten Weg zum Herumspielen mit Zeithistorien nutzen und das ist dann eben der History-Adapter.

Wenn dann das Thema Visualisierung ansteht oder sich eine 'echte' Anwendung auftut oder ich Lust auf Grafana & Co bekomme, dann installiere ich halt ein 'echte' DB.
Redis ist solange egal, wie ich keine Performance-Probleme oder Lust auf Stress habe :-)

[Ein ehemaliger Benutzer]

@sammy-r sagte in Datenbank, Historie, Trockner-Tracker:

Redis ist solange egal, wie ich keine Performance-Probleme oder Lust auf Stress habe

Moin,

mir ging es nur darum, klarzustellen, dass Rdeis nichts mit Historisierung oder influxDB, SQL Datenbanken zu tun hat!

VG
Bernd

[Sammy R.]

@dp20eic
Ja, das war mir nach den vorherigen Erklärungen klar.
Redis ist eine in Key-Value-In-Memory-DB, Historisierung/Zeitreihen sind optimal in InfluxDb oder auch SQL und SQL ist halt SQL ;-)
Vielleicht war Performance hier doppeldeutig. Das war auf das Verhalten vom Pi/ioBroker bezogen.
Aber auf jeden Fall besser, Du gehst auf Nummer sicher als dass ich voll gegen die Wand renne :-) Thx.