Redis Umstellung ja oder nein?
-
Aaaaaaaaalso:
Für kleine bis "normale" Installationsgrößen reicht der "Standardmechanismus". Dieser besteht aus einem von Bluefox geschriebenen "Memory-Key-Value-Store" wo alle States abgelegt werden und regelmäßig (glaube alle 30s bei Änderungen) auf Platte geschrieben werden als JSON File. Einerseits ist es halt ein in nodejs implmentierter Store der ggf nicht der 100%ig performanteste ist und auch das regelmäßige schreiben des states.json verursache je nach größe halt I/O und bei SD Karten einfach Schreibzyklen. Also je mehr States man hat desdo unperformanter wird das ganze.
Die objects.json wird mit dem gleichen mechanismus behandelt ist aber nicht so problematisch an der Stelle weil sich die Objekt-Metabeschreibungen eher selten ändern, aber ist als File meist größer.
Vorteil ist: Ein ioBroker-Backup enthält JSON Files mit und damit ist alles enthalten.
Zusätzlich gibt es die Option die States in einem "Redis Memory-Key-Value-Store" abzulegen. Redis ist hochperformant für genau diesen zweck entwickelt und damit sehr performant. ABER es ist halt ein weiteres "Stück Software" was Leute installieren, verstehen, maintainen müssen und das Backup darf auch nicht vergessen werden.
Früher in ersten ioBroker-Versionen war Redis mal eine Zwangsanforderung und das Ergebnis war das es die User nicht hinbekommen haben weil zu viele Vorbedingungen erfüllt sein mussten. Daher wurde der oben beshriebene Standardmechanismus geschaffen.
Bei Redis muss man sich um das Backup selbst kümmern weil der Standardmäßig alles NUR im Speicher hält. Ein Restart des prozesses sorgt also für einen leeren Zustand. Das geht weil die States ja über die Zeit wieder reinkommen, aber man verliert ggf für Skripte sinnvolle "initialwerte". Also man muss das bei seinen Skripten berücksichtigen.
ODER man muss sich mit den Persistenzoptionen von Redis auseinandersetzen. Grob: Man kann Redis nach Anzahl Änderungen in Zeit zwingen seinen Stand auf Platte zu schreiben oder mit einem eigenen Befehl. Dann liesst er den zuletzt gespeicherten Stand beim Start ein. Oder Redis schreibt alles in eine Art "Log"-File und kann somit immer den letzten Stand wiederherstellen.
Persistenz bei Redis verursacht also auch I/O, je nachdem weniger oder mehr als der ioBroker-Eigene Mechanismus. Dennoch konnten die meisten eine Performancesteigerung bemerken, vor allem ausgedrückt durch weniger CPU-Last.
Zur Absicherung vor SD-Karten schäden kann man Redis-Slaves anlegen die dann auch alle State-Daten haben und so sicherstellen das eine neue installation die letzten State-Daten hat. Aber da gehts in Richtung Notfallkonzepte was noch spezieller wird.
Daher aus meiner Sicht: Wenn die Installation langsam größer wird und man merkt das der js-controller "viel" CPU braucht und man sicher ist das nicht die SD-Karte gerade in die Knie geht und man sich in das Thema reinarbeiten will, kann man sich mal mit Redis beschäftigen. man muss es dann aber auch … sonst wundert man sich plötzlich warum alle States leer sind
Ingo
-
Aaaaaaaaalso:
Für kleine bis "normale" Installationsgrößen reicht der "Standardmechanismus". Dieser besteht aus einem von Bluefox geschriebenen "Memory-Key-Value-Store" wo alle States abgelegt werden und regelmäßig (glaube alle 30s bei Änderungen) auf Platte geschrieben werden als JSON File. Einerseits ist es halt ein in nodejs implmentierter Store der ggf nicht der 100%ig performanteste ist und auch das regelmäßige schreiben des states.json verursache je nach größe halt I/O und bei SD Karten einfach Schreibzyklen. Also je mehr States man hat desdo unperformanter wird das ganze.
Die objects.json wird mit dem gleichen mechanismus behandelt ist aber nicht so problematisch an der Stelle weil sich die Objekt-Metabeschreibungen eher selten ändern, aber ist als File meist größer.
Vorteil ist: Ein ioBroker-Backup enthält JSON Files mit und damit ist alles enthalten.
Zusätzlich gibt es die Option die States in einem "Redis Memory-Key-Value-Store" abzulegen. Redis ist hochperformant für genau diesen zweck entwickelt und damit sehr performant. ABER es ist halt ein weiteres "Stück Software" was Leute installieren, verstehen, maintainen müssen und das Backup darf auch nicht vergessen werden.
Früher in ersten ioBroker-Versionen war Redis mal eine Zwangsanforderung und das Ergebnis war das es die User nicht hinbekommen haben weil zu viele Vorbedingungen erfüllt sein mussten. Daher wurde der oben beshriebene Standardmechanismus geschaffen.
Bei Redis muss man sich um das Backup selbst kümmern weil der Standardmäßig alles NUR im Speicher hält. Ein Restart des prozesses sorgt also für einen leeren Zustand. Das geht weil die States ja über die Zeit wieder reinkommen, aber man verliert ggf für Skripte sinnvolle "initialwerte". Also man muss das bei seinen Skripten berücksichtigen.
ODER man muss sich mit den Persistenzoptionen von Redis auseinandersetzen. Grob: Man kann Redis nach Anzahl Änderungen in Zeit zwingen seinen Stand auf Platte zu schreiben oder mit einem eigenen Befehl. Dann liesst er den zuletzt gespeicherten Stand beim Start ein. Oder Redis schreibt alles in eine Art "Log"-File und kann somit immer den letzten Stand wiederherstellen.
Persistenz bei Redis verursacht also auch I/O, je nachdem weniger oder mehr als der ioBroker-Eigene Mechanismus. Dennoch konnten die meisten eine Performancesteigerung bemerken, vor allem ausgedrückt durch weniger CPU-Last.
Zur Absicherung vor SD-Karten schäden kann man Redis-Slaves anlegen die dann auch alle State-Daten haben und so sicherstellen das eine neue installation die letzten State-Daten hat. Aber da gehts in Richtung Notfallkonzepte was noch spezieller wird.
Daher aus meiner Sicht: Wenn die Installation langsam größer wird und man merkt das der js-controller "viel" CPU braucht und man sicher ist das nicht die SD-Karte gerade in die Knie geht und man sich in das Thema reinarbeiten will, kann man sich mal mit Redis beschäftigen. man muss es dann aber auch … sonst wundert man sich plötzlich warum alle States leer sind
Ingo ` Hallo Ingo,
würdest du redis auch rüber SQL Datenbank vorziehen? Ich war bisher der Meinung, das wäre noch am sichersten, wenn man bereits eh eine auf einen anderen Gerät hat…?!
VG Thorsten
PS: ich nutze die Datenbank nur zum ablegen, auskennen tue ich mich noch nicht so sehr
Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
-
Da vermischt Du aber zwei Themen.
SQL ist für die Speicherung der aktuellen Daten von ioBroker (State, usw.) viel zu langsam. Entweder auf Platte (das oben beschriebene Verfahren) oder aber Redis (alles ins RAM), was natürlich viel schneller ist.
SQL wird, wie der History-Adapter (speichert auch in eine Datei) oder Influx, usw. auch, für die Aufzeichnung (Historisierung) von Daten verwendet, um dann Diagramme daraus zu erzeugen.
Gruß,
Eric
Von unterwegs getippert
-
Korrekt, die History/SQL/InfluxDB-Adapter die Daten Historisieren haben mit der Speicherung der States nichts zu tun.
Auch wenn leicht Off-Topic: Hier aber auch: History speichern JSON-Files auf der Platte und vor allem bei Abfragen bzw Diagrammen werden nötige Daten immer wieder von der Platte geladen. Also kommt hier wieder I/O ins Spiel. Das ist also nicht wirklich performant. SQL-Datenbanken oder InfluxDB sind auf solche Aufgaben Spezialisiert, aber auch wieder Komplexer weil "Software" die man installieren, updaten, backuppen und so muss.
-
Bei Redis muss man sich um das Backup selbst kümmern weil der Standardmäßig alles NUR im Speicher hält.
Grob: Man kann Redis nach Anzahl Änderungen in Zeit zwingen seinen Stand auf Platte zu schreiben oder mit einem eigenen Befehl. Dann liesst er den zuletzt gespeicherten Stand beim Start ein.
Oder Redis schreibt alles in eine Art "Log"-File und kann somit immer den letzten Stand wiederherstellen.
Zur Absicherung vor SD-Karten schäden kann man Redis-Slaves anlegen die dann auch alle State-Daten haben und so sicherstellen das eine neue installation die letzten State-Daten hat.
Ingo `
Also ich lese diese 4 Punkte raus wo es zu beachten gilt. Gibt es denn ein HowTo dafür?
-
ich denke bisher hat sich jeder das Wissen selbst angesammelt (oder auch nicht) bzw ist verstreut in Forums-Einträgen
Aber die Idee ist gut.
ich schreibs mal auf meine Liste das aufzuschreiben, bin aber auch nicht böse wenn jemand anders schneller ist. Ich kann gern - vor allem zu "persistenz" die Begriffe und Richtungen vorgeben und mal meine Konfig mit dazugeben
-
Kurze Frage zu Redis im Multihost-Betrieb muss ich die Einstellungen für Redis (setup iobroker custom) auch auf dem Slave machen )
-
Ja!
und zu der IP des Masters leiten.
Und unbedingt die IP des slaves (oder alle) in der konfig von redis freigeben.
http://www.iobroker.net/docu/?page_id=3 … _mit_redis
Gruß
Rainer
-
Bald können wir alle Dokus nur noch hier im Forum ablegen …. auf die Webseite scheint keiner mehr zu schauen oder dort mal zu suchen. [emoji6]
Von unterwegs getippert
-
Na die doku habe ich schon genutzt, aber die Frage die ich gestellt hatte, hab ich in der Anleitung nicht gefunden.
-
Die Frage ist jetzt aber beantwortet?
oder reicht die Doku im Link nicht?
Gruß
Rainer
-
Kurze Frage zu Redis im Multihost-Betrieb muss ich die Einstellungen für Redis (setup iobroker custom) auch auf dem Slave machen ) `
ja, aber aufpassn nur für "Type of states DB" nicht für "Type of objects DB"
-
Die Frage ist jetzt aber beantwortet?
oder reicht die Doku im Link nicht?
Gruß
Rainer `
Nein ist alles gut, Habe die Umstellung nun hinbekommen.
Allerdings hatte ich dann im Nachinein Probleme im Multihostbetrieb (Konnte den Slave nicht mehr connecten) setup custom habe ich nach Anleitung gemacht. Auf dem Master hatte Redis problemlos funktioniert. Da mir der Multihostbetrieb aber wichtiger ist, habe ich nach einem Wochenende Frickelei mit Redis/Multihost Montag früh Redis wieder abgeschaltet. (Habe aber noch ein anderes, grösseres Problem) Leider habe ich im Forum dazu noch keine Antwort erhalten und stehe da bisschen auf dem Schlauch. http://forum.iobroker.net/viewtopic.php?f=37&t=10665
-
Den Abschnitt über dem verlinkten hast du aber auch gelesen und befolgt?
http://www.iobroker.net/docu/?page_id=3 … ersion_110
Gruß Rainer
-
Ja habe ich alles gemacht.
