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.
