NEWS
Redis Umstellung ja oder nein?
-
Mit SQL habt ihr mich verwirrt. SQL ist doch "nur" für den history und Redis für alle States im laufenden Betrieb, oder hab ich das falsch verstanden? `
Das war nicht meine Absicht! :oops:
Ich kann auch nur das so wiedergeben, wie ich das bisher so verstanden habe.
Ich hab schob öfters mit dem Gedanken gespielt auf Redis umzusteigen, da ja immer wieder zu lesen ist das es Geschwindigkeit bringt und das Speichermedium schont. `
Ich werde das demnächst auch so in Betrieb nehmen, wenn mein Orange Pi kommt, und ich dafür dann ein fertiges Image verwenden will. Mal sehen, was da so passiert! :)
Aber andererseits gibt es hier im Forum auch etliche Beiträgen mit Problemen bei Redis und bei Dingen wie Backup/Multihost gibt es wohl auch etliches zu beachten. Ich persönlich bin wohl zuviel Noob als das ich mir so richtig zutraue umzustellen, reizen würde es aber wegen der Vorteile schon. `
Ja, das habe ich so auch schon gelesen, für mich ist jetzt die Frage, ob es denn so wichtig ist, wenn die States nicht gleich wieder da sind, oder ob man damit leben kann, dass wohl von den Sripten jede Menge Fehlermeldungen kommen,weil alle Datenpunkte leer sind.
Ich muss mir das mit der Extrasicherung der States dann nochmal genau ansehen, bin da auch totaler Neuling! :?
Enrico
-
Steht doch alles drin, warum soll da noch jemand anderes was schreiben?
Ich müsste jetzt suchen nach irgendwas wie "redis is back" da habe ich damals (als die Dinosaurier noch über die Erde liefen) einiges geschrieben.
Gruß
Rainer
-
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
-
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
-
Die Frage ist jetzt aber beantwortet?
oder reicht die Doku im Link nicht?
Gruß
Rainer
-
-
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
343
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge