Hallo Leute So langsam beginne ich zu verzweifeln Wie im Betreff erwähnt gibts Probleme mit dem im Betreffe genannten und ich die Documentation von InfluxData wirft mehr fragen bei mir auf als Antworten. Nun zu meinem kleinen Problem. Ich sammle Daten von verschiedenen Sensoren und wollte diese in die InfluxDB eintragen. Dann wollte ich die Datenmenge in verschienden Zeitintevallen zusammen fassen was ja eigentlich ganze infach sein sollte und mit Influx ja möglich ist. Als Große Spielwiese habe ich zum Testen InfluxDB mit Telegraf installiert und versuche hier nun die Daten mittels einer Retention Policy jede Stunde zu löschen und mit einer Continuous Query zu jeweils 15 Minuten Packeten zusammen zufassen. Leider bsi jetzt ohne Erfolg Ich würde mich freuen wenn mir einer ein paar Hilfestellungen geben könnte wie ich an die Sache ran gehen muss und wo ich genau drauf achten muss. Als Info alles läuft auf einem Raspberry Pi mit Strech, InfluxDB 1.7 Freue mich über jede Antwort Gruß Alex PS: An die Admins habe diesen Beitrag noch im Unterforum PC- Hard&Software eingestellt da ich mir bei der Auswahl nicht sicher war wo es besser passt.
InfluxDB: "A Time Series Database (TSDB) is a database optimized for timestamped (or “time series”) data." Was es alles gibt. Reicht für so einen trivialen Furz nicht einfach eine andere relationale DB die meist sowieso schon installiert ist und man damit umzugehen weiss? Wieso sich so einen Exoten ans Bein binden?
Forenschimmel schrieb: > Was es alles gibt. Reicht für so einen trivialen Furz nicht einfach eine > andere relationale DB die meist sowieso schon installiert ist und man > damit umzugehen weiss? Wieso sich so einen Exoten ans Bein binden? ...eine sehr wage Behauptung! Du hast dich schon mal mit der Materie beschäftigt? Dann solltest du aber auch wissen, dass mit relationalen Datenbanken Zeitreihen und vor allem deren Auswertung relativ unkomfortabel und nicht besonders performant sind.
50c schrieb: > ...eine sehr wage Behauptung! Du hast dich schon mal mit der Materie > beschäftigt? Ja bisher habe ich nur Marketingbla von den Herstellern dieser zweifelhaften Produkte gefunden. > Dann solltest du aber auch wissen, dass mit relationalen > Datenbanken Zeitreihen und vor allem deren Auswertung relativ > unkomfortabel Sagt der Hersteller der sein zweifelhaftes Produkt verkaufen will, Was soll daran mit einer klassischen relationalen DB schwierig sein? Da ist die ja nicht mal ansatzweise gefordert. > und nicht besonders performant sind. Sagt der Hersteller von Zeitreihendatenbanken. Hast du dafür auch Belege?
Forenschimmel schrieb: > Was soll daran mit einer klassischen relationalen DB schwierig sein? > Da ist die ja nicht mal ansatzweise gefordert. ...ich habe nicht behauptet, dass es unmöglich ist, aber... Forenschimmel schrieb: > Hast du dafür auch > Belege? ...na dann versuche mal folgendes: Du hast eine Tabelle mit Messwerten mehrere Sensoren, sagen wir mal 10 pro Minute und du möchtest alle Messwerte zwischen vorgestern und gestern eines Sensors haben, diese aber zusammengefasst (gemittelt) im Minutentakt. Wie sieht die Query für eine relationale Datenbank dafür aus?
50c schrieb: > Wie sieht die Query für eine relationale Datenbank dafür aus? Sowas ist Kinderkram. Jede primitive kommerzielle Datenbank kennt das Problem von der Generierung von Statistiken wie Bestellungen, Bedarfe, Lieferungen, Buchungen über die Zeit. Mit einem einfachen SQL-Select ist es da natürlich nicht getan. Der Bedarf für spezialisierte Datenbanken besteht meiner Erfahrung nach erst bei Queries auf viele Millionen von Datensätzen. Eine vereinfachende, problemorientierte Querysprache ist schon eher sinnvoll. Meist wird dabei von der existierenden Datenbankstruktur abstrahierend vorgegangen. Darunter reicht dann eine einfache relationale DB. Gruß, Michael
Hallo, ein Nachtrag. Der Gipfel erfindungsreichen Marketings, quasi die Lizenz zum Gelddrucken, war mal ein Produkt, welches Seriennummern generiert. Das war eine API, welche in den Stammdaten eine Seriennummer aus festen Strings und einem variablem Bereich konfiguriert war und bei jeder Anfrage den variablen Teil um 1 erhöhte. Das eigentlich erwähnenswerte war das Lizenzmodell, welches pro Installation, Anzahl der Seriennummern usw. Kohle generierte. Die Seriennummern wurden dann über eine ebenfalls gekaufte Software in einer Oracle Datenbank gespeichert. Die eingebauten Nummern-Generierer (Sequences) wurden aus Unwissenheit nicht verwendet. Gruß, Michael
Michael A. schrieb: > Sowas ist Kinderkram. ...na dann versuche es doch mal! Michael A. schrieb: > Mit einem einfachen SQL-Select ist es da natürlich nicht getan. ...doch, es würde schon ein SQL-Select dafür ausreichen, der aber schon recht komplex aussieht... Michael A. schrieb: > Der Bedarf für spezialisierte Datenbanken besteht meiner Erfahrung nach > erst bei Queries auf viele Millionen von Datensätzen. ...definiere "viele Millionen"! Obiges Beispiel (10 Messungen pro Minute) mit (nur) 100 Sensoren ergibt schon pro Tag 1440000 Datensätze, pro Woche 10 Millionen, pro Monat 43,2 Millionen, pro Jahr 519,4 Millionen...
50c schrieb: > ...definiere "viele Millionen"! > Obiges Beispiel (10 Messungen pro Minute) mit (nur) 100 Sensoren ergibt > schon pro Tag 1440000 Datensätze, pro Woche 10 Millionen, pro Monat 43,2 > Millionen, pro Jahr 519,4 Millionen... Was willst Du mir damit sagen ? Wenn der TO nur wenige Datensätze hat, dann kann er auch mit MariaDb spielen und dabei was lernen. Wenn er pro Jahr 519,4 Datensätze bekommt, dann macht eine optimierte Kaufsoftware Sinn. Wo liegt nun der Streitpunkt ? Gruß, Michael
Michael A. schrieb: > Wo liegt nun der Streitpunkt ? ...darin! Forenschimmel schrieb: > Was es alles gibt. Reicht für so einen trivialen Furz nicht einfach eine > andere relationale DB die meist sowieso schon installiert ist und man > damit umzugehen weiss? Wieso sich so einen Exoten ans Bein binden? ...sprich, daran, dass du einfach mal so ein paar (recht arogante) Sätze in den Raum wirfst, ohne mal über das Thema nachzudenken. Michael A. schrieb: > Wenn der TO nur wenige Datensätze hat ...wo hat er geschrieben, wieviel Datensätze er hat/erwartet/bekommt? Michael A. schrieb: > Wenn er pro Jahr 519,4 Datensätze bekommt, dann macht eine optimierte > Kaufsoftware Sinn. InfuxDB ist Open Source, da brauche ich keine Scheine in irgend einen Briefkasten reinwerfen!
... 50c schrieb: > Forenschimmel schrieb: >> Was es alles gibt. Reicht für so einen trivialen Furz nicht einfach eine >> andere relationale DB die meist sowieso schon installiert ist und man >> damit umzugehen weiss? Wieso sich so einen Exoten ans Bein binden? ...wobei diese Aussage nicht von dir (Michael A.) zu kommen scheint, aber du ins gleiche Horn geblasen hat...
Furchtbar das hier immer alles mit Belanglosigkeiten am Thema vorbei diskutiert wird. Meiner Meinung ist es die Richtige Lösung für das Problem, einfach das passende Werkzeug für die Problemstellung hernehmen. Das wäre die entsprechende Doku mit Beispielen: https://docs.influxdata.com/influxdb/v1.7/guides/downsampling_and_retention/ Was genau ist unklar? Was hast du wo eingegeben? Benutzt du das Kommandozeilentool oder ein Telegraf Interface? Ich setze bisher Influx mit Grafana ein. Läuft allerdings schon mehrere Jahre Problemlos und schaue seit dem nur noch hübsche Graphen an. Konfiguriert hab ich es damals mit dem Kommandozeilentool von Influx und nur die Queries in Grafana zusammengestöpselt. Forenschimmel schrieb: > Ja bisher habe ich nur Marketingbla von den Herstellern dieser > zweifelhaften Produkte gefunden. Zweifelhafte Produkte... Der beste Beweis für mich das hier keine Substanz für ein Gespräch liegt. Besonders zweifelhafte Firmen wie mozilla, IBM, PayPAl und ebay setzen es ein.
Das ich so eine Diskussion über Datenbanken breittrete hätte ich nicht gedacht. > Also um mal einige Punkte aus dem Weg zuräumen > Ich kenne aktuell keine Datenbank die mit der Informationflut zurecht kommt mit der zurechnen ist. Wir reden hier über mehrer SP Steuerungen die mit all ihrern Sennsordaten auf die Datenbank einprügeln werden. Also viele 1000 Daten und viele Zugriffe in kurzer Zeit. Um das jetzt nur mal anzureißen, möchte auch nicht näher drauf eingehen, kann auch egal sein denke ich. Aber wie bereits gesagt kenne ich keine Datenbank die damit zurecht kommt und gleichzeitig noch Zugriffe ermöglicht Daten zu optimieren und zu entrümpeln. Hoffe das es jetzt verständlich ist warum Influx hier meine Lösung war und zur info Influx ist OpensSource was die Kostenfrage wohl gänzlich aus der Welt schafft @blabla Erst mal danke für das Eindämmen der Datenbankdisskussion und ein zweites Danke für den Link, den hab ich so noch nicht wahrgenommen auf der Seite von influxdata Also ich arbeite mit der Kommadozeile. Zum Anzeigen aktuell noch Chronograf da ich mit Grafana noch meine Probleme hab was wo zu finden und einzustellen ist, würde da gerne noch mal auf dich zurück kommen. Nun ich habe bis jetzt die Datenbank erzeugt und eine Retention Policy angelegt. Dazu noch eine Continous Query. Scheint auch bis jetzt zu funktionieren endlich :D Meine Daten zu Testzwecken binde ich noch mit Kommandozeilenbefehl >>Insert<< ein Strucktur sieht also wie folgt aus (alles natürlich nur vereinfacht jetzt für zum Rumspielen und auf einem Raspberry Pi mit Fake Infos) >CREATE DATABASE messung >USE messung >CREATE RETENTION POLICY "oneday" ON "messung" DURATION 24h REPLICATION 1 ---> Hier stellt sich mir die Frage was genau mit REPLICATION gemeint ist, da in der Doku etwas mit 1 bis 3 beschrieben war und etwas mit n . würde mich da auf eine kurze Erklärung freuen :D >CREATE CONTINUOUS QUERY "one_hour" ON "messung" BEGIN >SELECT mean("temp-motor") AS "mean_temp-motor", ...... >INTO "oneday"."mean_temp" >FROM "temp" >GROUP BY time(15m) >END >INSERT temp,building=werkstatt,room=maschinenraum temp-motor=80.5,temp-raum=36.8 ..... ..... Aktuell werden die Daten für dieses Beispiel von einem Raspberry Pi mittels Python script in die Datenbank geschoben, aktuell jede Sekunde. So nun zu dem aktuellen Problem oder dem unverständnis was noch herscht da ich in der Zwischenzeit durch ausprobieren herausbekommen habe. Die eingetragen Messwerte werden aktuell nichg mehr in messungen.autogen eingetragen sonderen in messungen.oneday und haben nun den namen mean_... Ist das so korrekt oder hab ich hier irgendwo einen Fehler gemacht Zu dem geschicht das Aufräumen nur hin und wieder korrekt, zumindest schient es so. Gibt es hier ein besonderes Zeitschema mit dem Influx arbeitet? Das Zusammenfassen funktioniert mittlerweile auch nur das die Daten auch in der eigentlichen "Tabelle" temp abgelegt werden und zusätzlich in mean-temp, was das betrachten in Chronograf leicht verwirrend gestalltet. In der Konolse werden die Daten jedoch richtig Angezeigt. Woran kann das liegen? Vielen Dank für die Mühe und fals ich mich mit etwas unverständlich Ausgedrückt habe einfach mal lieb nachfragen. Gruß Alex
50c schrieb: > ...doch, es würde schon ein SQL-Select dafür ausreichen, der aber schon > recht komplex aussieht... Ach watt. Beispiel MS-SQL Server, Tabelle werte(zeit datetime, wert float): select convert(char(16),min(zeit),120) as zeit, avg(wert) as wert from werte group by cast(cast(zeit as float)*144.0 as integer); Wenn du so'n Kinderkram für komplex hältst, hast du noch nie wirklich komplexe Abfragen gesehen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.