neben dem IPS eigennen Datenlogging benutze ich noch das Dugtool, leider funktioniert beim Dugtool der Datenbank Zugriff sehr langsam, was daran liegen könnte das meine DB schon 800 MB groß ist. Deshalb will ich auch eine andere DB wechseln, aber welche? -hier im Forum hört man ja so einiges, wie z.B MySql oder PostgreSQL, wo für sollte man sich entscheiden, die PostgreSQL wurde hier im Forum ja schon ganz gut erklärt und nach den Rückmeldungen auch von Anfängern zu bedienen und die Größe soll ja fast unbegrenzt sein, ist nur die Frage ob bei großen DB’s der Zugriff auch noch schnell ist.
Ich verwende MySQL Datenbanken, die sind ziemlich gut in PHP integriert und es gibt gute Verwaltungstools dafür (wobei ich mit der neuen MySQL Workbench nicht richtig warm werde, mir gefallen die MySQL Tools besser).
Die Community Edition ist kostenlos - obwohl die mal von mir 10000€ für ne Developer Lizenz haben wollten, da ich in ipsHomecontrol MySQL verwende. Nachdem ich dennen aber gesagt habe, das ich dann eben auf MSSQL aufsetze haben die mir dqnn aber mitgeteilt das ich dann doch keine Lizenz brauche (da die Software nicht ausschliesslich auf MySQL aufsetzt).
Sicherheitshalber habe ich aber den MySQL Server aus dem install rausgenommen und lassen den vom User selber downloaden und silent installieren sowie einrichten.
Seitdem an habe ich nichts mehr von dennen gehört.
Von dennen gibt es aber auch Enterpriseprodukte, welche gröstenteils die selben Produkte sind.
Auch kommen viele andere Produkte damit zurecht, z.B. Mediaportal, Dugtools, ipsHomecontrol usw. - so brauchst du dann weniger Datenbankprodukte parallel zu installieren.
willst Du was ganz neues aufsetzten, oder willst Du die DUGTools nur mit einer anderen DB betreiben ? Der Werner (wgreipl) und der Uwe (bmwm3) haben die DUGTools in Richtung MySQL gebracht. Ich habe es mir gerade auch nochmal angeschaut (Dank an Uwe). Die Performance wurde zwar besser, aber immer noch nicht so, wie ich es mir gewünscht hätte. Vom Design her schreiben die DUGTools alles in eine flache Tabelle, da können echte Datenbank einfach nicht glänzen.
Zur allgemeinen Datenbanksituation kann man sagen, entweder eine rein lokale Lösung wie SQLite oder auch nur CSV-Tabellen, oder eine Client-Server wie Postgres, MySQL (kostenfrei), MS-SQL, Oracle (kostenpfichtig). Ich schlage mich beruflich mit den Microsoft/Oracle-DBs rum, für das IPS-Hobby würde ich aber MySQL empfehlen. Das ist aber eine Glaubensfrage.
Über das Thema haben wir übrigens lange bei Rainer im IPS-Stammtisch in Nidda diskutiert (siehe Link).
mit REDIS hatte ich noch nichts zu tun, MongoDB ist meines Wissens eher für weniger strukturierte Daten geeignet. Zumindest ich schreibe dumme Messwerte in gleichbleibender Struktur meistens in Minutentakt in die DB und das können die relationalen DBs ganz gut.
Wir sollte hier aber keinen Glaubenskrieg anfangen. Die beste DB für IPS wird die sein, die von Steiner und paresy direkt integriert wird. Ich hätte zwar noch gerne einen Schwenk von SQLite nach MySQL oder Postgres, aber ich kann auch mit der jetzigen Lösung leben (wenn denn mal alle Befehle offen liegen, AC_GET* und Co).
Also ich frag mich viel mehr für was in alles in der Welt brauchst du ein 800MB Archiv ?
Wäre es nciht viel sinnvoller den alten Kram wegzuwerfen oder zumindest auf ein vernünftiges Maß zu reduzieren als nach einer schnelleren Datenbank zu suchen ?
Reduziere doch einfach die Sampledichte von alten Daten und es flutscht wieder.
Ansonsten kann ich es mir nicht verkneifen mein Liebkind RRD mal wieder anzupreisen.
Einmal genau nachdenken -> einrichten -> nie wieder volle Datenbank und gleichbleibende Performance.
ich denke, das sollte man nicht so pauschal abtun:
ich erzeuge aktuell pro Tag 5MB Daten in der SQLite. Macht im Jahr 1,8 GB Daten. Da ich u.A. sowohl Verbrauchsdaten als auch Wetterdaten aufzeichne kommt ein Wegwerfen der Daten nicht in Frage. Was allerdings Sinn mmachen würde ist ein selektives Verdichten der historischen Daten um die Datenmenge zu reduzieren. Allerdings suche ich hier noch nach einer Lösung.
Dito…aber ne Lösung habe ich auch noch nicht. Aber mal im Ernst was kostet heute 1 GB ??? und persönlich bin ich der Meinung das die Datenmengen und Abfragekonstellationen einem DBMS mit ein wenig RAM nur ein Müdes lächeln anfordern dürften…
… schon mal 2-3 Jahre in die Zukunft gedacht?
warum soll sich IPS mit >5GB Daten rumschlagen wenn nur max. 0,5GB im Daily Doing benötigt werden (und der Rest nur hin und wieder mal)…
Natürlich schlägt sich bei mir nicht IPS mit den Gigabytes rum sondern ein dedizierter DB-Server und der nimmt begierig alle Daten, nicht nur von IPS, entgegen…so bleibt IPS schön klein und handlich…
mal abgesehen davon das mir hier das knowhow fehlt - ich bin mir noch nicht sicher was am sinnvollsten ist: ich tendiere momentan zur kompletten Datenhaltung innerhalb IPS.
Ich schätze, spätestens Ende des Jahres werd ich mich damit auseinandersetzen müssen.
Wünschenswert wäre hier, wenn der Hersteller von Hause aus irgendwann eine Datenhistorisierung anbieten würde:D
Ich kann mir schon vorstellen, dass mit der Zeit mehr und mehr User in das „Problem“ laufen.
Diese Abhängigkeit vom Hersteller wollte ich mir ersparen. Zumal man so sehr einfach die Last vom IPS, für generierung von Graphen, Abfragen usw, fernhalten kann. Damit bleibt IPS auch bei umfangreichen Logging, Auswertungen und ähnlichem reaktionsschnell…
sehr interessante Argumente, aus der Sicht spricht einiges für eine externe Lösung.
Wie machst Du das prinzipiell?
exportierst Du selektiv Datensätze und löscht diese dann in IPS (per IPS-PHP-Script?)? Kannst Du das mal kurz skizzieren?
prima, soweit verstanden.
zum obigen Satz hab ich noch Verständnisfragen:
holt es die Werte aus der IPS-SQLite oder greifst Du den Wert direkt aus der Variable ab? -> wie gehst Du mit den in der IPS-DB gespeicherten Werten um -> werden die nicht gelöscht?
