mikrocontroller.net

Forum: PC-Programmierung InfluxDB Queries und Retentions


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Alexander Becker (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Forenschimmel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: 50c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Forenschimmel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 50c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael A. (micha54)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael A. (micha54)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 50c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael A. (micha54)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 50c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: 50c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...

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...

Autor: blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander Becker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.