We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

InfluxDB – eine Einführung

00:00

Formale Metadaten

Titel
InfluxDB – eine Einführung
Serientitel
Anzahl der Teile
49
Autor
Lizenz
CC-Namensnennung 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Viele Daten, wie sie z. B. im IoT-Umfeld (Internet of Things) anfallen, sind Sensor- und Zustandswerte über die Zeit. Natürlich können solche Zeitreihen in herkömmlichen SQL-Datenbanken abgelegt werden, aber seit einigen Jahren gibt es für solche Anwendungsszenarien spezielle Datenbankmanagementsysteme (DBMS). InfluxDB ist einer der Vertreter dieser Zeitreihen-DBMS, welcher sehr weit verbreitet ist. Im Rahmen dieses Vortrages wird InfluxDB, auch im Vergleich zu den „herkömmlichen“ DBMS, anhand konkreter Beispiele vorgestellt. Ein kurzer Ausflug zu Grafana und Telegraf runden den Vortrag ab. Viele Daten, die z.B. im IoT-Umfeld (Internet of Things) anfallen, sind Sensor-, Zustandswerte o.ä. die zu einem definierten Zeitpunkt ermittelt werden. Um Auswertungen, Statistiken u.ä. anzufertigen, oder auch nur den historischen Verlauf dieser Werte zu dokumentieren, landen sie häufig in Datenbanken. Bei einer großen Menge solcher Sensor- und Zustandsdaten, sollte das verwendete Datenbankmanagementsystem (DBMS) komfortabel und performant agieren können. Die typischen Vertreter, klassischerweise SQL-Datenbanken, sind dazu ohne weiteres in der Lage. Aber hat jemand schon mal eine SQL-Query bauen müssen, die z.B. folgendes ausgeben soll: „...den Verlauf der Luftdrucktendenz, der im Minutentakt abgelegten und im 5-Minutenraster zu mittelnden Luftdruckwerte, in Bezug auf dem ebenfalls zu mittelnden Wert von vor 3 Stunden, für den Zeitraum der letzten 24 Stunden...“? Spätestens ab da kann es unübersichtlich werden und man fragt sich, ob es nicht etwas einfacher geht? ...ja, natürlich, seit einigen Jahren gibt es für solche Anwendungsszenarien spezialisierte Zeitreihen-Datenbanksysteme! Ein weit verbreiteter Vertreter ist das DBMS InfluxDB. Die Open Source Software wird im Rahmen dieses Vortrages vorgestellt. Ziel ist es, den Begriff „Zeitreihen-DBMS“ zu verstehen. Für ein konkretes Anwendungsszenario soll die Arbeit mit InfluxDB erklärt werden. Letztendlich sollen die erarbeiteten Lösungen einer vergleichbaren Umsetzung mit Hilfe eines „klassischen“ DBMS gegenübergestellt werden. Für den Referenten ist (war) die Vorbereitung zu diesem Vortrag, ein Experiment. Es soll(te) ergründet werden, ob die, bei den eigenen Wetterdatenaufzeichnungen, anfallenden Massendaten, in einer InfluxDB besser aufgehoben sind. Da dabei ein Hauptfokus auf die spätere Visualisierung der Daten liegt, erfolgt abschließend auch ein Ausflug zu Grafana und Telegraf.
23
Vorschaubild
20:06
25
Vorschaubild
38:54
27
31
Vorschaubild
50:36
32
PunktwolkeChatten <Kommunikation>SmileyComputeranimation
DatenbankEchtzeitsystemParallelenLINUXHardwareSoftwareentwicklerMySQLGRADEMicrosoftObjektorientierungIndexTabelleDatensatzPlotterAbfrageKorrelationDiagrammEinflussgrößeKurveDivergente ReiheDatenbanksystemEchtzeitsystemMengeZeitreiheAlgorithmusQuantenzustandAbbildung <Physik>Strom <Mathematik>Algebraisches ModellRahmen <Statistik>Beobachter <Kybernetik>DatenbankFlächentheorieHöheGebiet <Mathematik>Spielraum <Wahrscheinlichkeitstheorie>Machsches PrinzipSuchmaschineFormation <Mathematik>InformationsmanagementRelationales DatenbanksystemZeitreiseORACLSStatistische AnalyseDruckverlaufFlächeComputeranimationBesprechung/Interview
EchtzeitsystemParallelenMultiplikationZellularer AutomatDatenmodellIBMRang <Mathematik>Version <Informatik>WINDOWS <Programm>FreeBSDBetriebssystemLINUXOpen SourceProgrammDatenverarbeitungssystemDistributionenraumRepository <Informatik>DownloadingDienst <Informatik>Nabel <Mathematik>KonfigurationsraumZeitreiheRechnenWINDOWS <Programm>KonfigurationsraumDatenbankOpen SourcePostgreSQLDistributionenraumORACLSDatensatzBiproduktServerRelationales DatenbanksystemBetriebssystemLINUXRepository <Informatik>PunktDatenbanksystemDownloadingZeitreiheTabelleProgrammiergerätVersion <Informatik>DatenmodellNabel <Mathematik>GRADEWort <Informatik>PlatteUnternehmensarchitekturRALLY <Programm>IndexDynamisches RAMMeterMicrosoftClientInformationsmanagementGoogleMacOSEigenwertproblemFlächentheorieInternetComputeranimation
MatroidZeichenketteIndexVersion <Informatik>Nabel <Mathematik>BetriebssystemZahlenwertSicherungskopieDatenbankRechnenNoSQL-DatenbanksystemChatten <Kommunikation>HilfesystemRelationales DatenbanksystemZahlZeichenketteRechenschieberIndexParametersystemWINDOWS <Programm>LINUXDatentypGRADEFehlermeldungSchwimmkörperDateiformatOrdnungsbegriffKonfigurationsraumAuflösungsvermögenDoS-AttackeEinfacher RingKopfrechnenConstraint <Künstliche Intelligenz>UNIXARM <Computerarchitektur>Sukzessive ÜberrelaxationZahlenbereichDatenbanksystemInstanz <Informatik>Installation <Informatik>Organic ComputingZeitreiheInformationsmanagementComputeranimation
KommunikationDatenbankHTTPFeuchtigkeitMatroidDatenbankEinflussgrößeDatensatzFeuchtigkeitAbfrageDatentypRechnenCurl <Programmiersprache>NullLogarithmusCommandosDateiInstanz <Informatik>NIS <Programm>RAMDatenendgerätGIPSY <Programm>InformationsmanagementDatenbanksystemVerschlingungRandZufallszahlenTabelleDatenverarbeitungssystemDynamisches RAMInsight.xla 2.0Schreiben <Datenverarbeitung>Computeranimation
FeuchtigkeitSQLAbfrageVersion <Informatik>GRADEQuick-SortGesetz <Physik>ZahlenbereichUmfangÄhnlichkeitsgeometrieDatenbankZeitreiheComputeranimation
ZeitbereichZählenUpdateTropfenICQMittelwertAbfrageGRADELokales MinimumZeitbereichMathematikUpdateFunktion <Mathematik>ParametersystemDurchschnitt <Mengenlehre>KurveBefehl <Informatik>LinieZeiger <Informatik>DatenbanksystemWort <Informatik>MittelungsverfahrenPunktSelektorComputeranimation
SicherungskopieDatenbankAudiovisualisierungSicherungskopieRetrievalspracheDatenbankDefaultMittelwertVisualisierungDatenstromDatensatzPlug inQuelle <Physik>ValiditätInternetNoten <Programm>PlotterGNU <Software>ProgrammiergerätSkriptspracheZeitreiheSummeWeb logAbfrageStrom <Mathematik>QuellcodeCodierungDatenbanksystemARM <Computerarchitektur>Computeranimation
RechnenInformationPlug inRetrievalspracheDiagramm
ServerNoten <Programm>DatenbankFormation <Mathematik>RuhmasseAbfrageUnternehmensarchitekturSchnittstellePlug inDatenbanksystemVersion <Informatik>Schnitt <Mathematik>Quelle <Physik>DatensatzHardwareChatten <Kommunikation>Computeranimation
PunktwolkeJSONXMLUML
Transkript: Deutsch(automatisch erzeugt)
Das ist so ziemlich mein erster Online-Vortrag. Normalerweise bin ich irgendwie so ein Typ, der ein bisschen mit seinem Zukunft, mit seinem, mit seinen Zuschauern rum spielt und auch gerne mal den Leuten in die Augen schaut, ob sie das verstehen, was ich erzähle oder nicht. Ist relativ schwierig jetzt hier. Aber trotzdem coole Geschichte, mal eine neue Erfahrung.
Und ja, wenn ihr Fragen habt, halt mir das am besten so, dass ihr das in den Chat einschreibt. Ab und zu gucke ich dann auch mal auf den Chat und wenn ich die Fragen dann beantworten kann, wässe dann vielleicht auch beantworten. Okay.
Ach so, und dann bin ich noch der Typ, der ein bisschen rummalt. Also das sieht man hier auch gerade an diesem, soll so ein Smiley sein. Also die Folien werden dann zum Schluss ganz wild aussehen. Mal sehen. Okay, gut. InfluxDB, eine Einführung. Vielleicht ganz kurz erst mal zu mir, wer ich bin, wer mich noch nicht gesehen hat.
Normalerweise bin ich auch immer bei den Präsenzveranstaltungen der Frosconn und beim CLT mit dabei. Mein Name ist Uwe Berger, komme aus Brandenburg, aus der Stadt Brandenburg. Also es gibt tatsächlich eine Stadt Brandenburg, im Land Brandenburg. Im richtigen Leben bin ich Softwareentwickler in einem großen Maschinenbaubetrieb und in der Freizeit baue ich auch komische Hardware.
Man sieht da so ein bisschen an den Bildern, meine Lieblingsstecken fährt, sind irgendwelche Uhren bauen und ja, okay. Organisiert bin ich in der Brandenburger Linux User Group. Das Logo seht ihr da oben auf dem Bild. Und was ich da so trinke, das ist irgendwas gesundes, hat aber nicht besonders gut geschmeckt.
Okay, wir wollen heute ein bisschen InfluxDB machen, dann stellt sich jetzt natürlich die Frage, warum InfluxDB? Ich habe hier bei mir im Haus eine ganze Menge Sensoren rumzuliegen und rum funken.
Tun die auch noch, aus dem Garten gibt es auch noch irgendwelche Sensoren, die Wetterdaten aufnehmen, Luftfeuchtigkeit, Temperaturen, Druckdrücke und was es da so alles gibt. Und ich habe mal so ein paar Bilder gemacht, wie das bei mir so aussieht oder wie es bis jetzt immer so aussah.
Also irgendwelche Daten in irgendwelchen SQL-Datenbanken aufgenommen und dann mit GNU Plot irgendwelche Bilder gezeichnet. Irgendwann war ich es dann mal leid gewesen, also gerade hier solche Bilder hier oder man zwar nicht an, aber hier versteckt sich eine komplizierte Rechnung dahinter, das dann mit SQL abzubilden.
Und gerade für diese Geschichte, also die rechte hier, ist es eine relativ komplizierte SQL-Abfrage, so eine Heatmap hinzubekommen. Und jetzt komme ich vielleicht doch mal auf das links oben. Das ist der Luftdruck, das ist die lila Kurve hier. Und die grüne und die blaue Kurve, das ist im Prinzip die Luftdruck-Tendenz.
Also da gibt es so einen genommten Wert, der von jetzt minus dem von vor drei Stunden oder so, das ist dann die Tendenz steigend und fallend und das kann man sich, kann man auch schön in Diagrammen darstellen. Um das dazu zu zeichnen, ist das relativ kompliziert, eine SQL-Abfrage zu machen.
Und deswegen dachte ich mir irgendwann mal, okay, ein Sensormodul, was ich da mal gebaut habe, was dann auch WLAN-fähig war, probieren wir doch einfach mal InfluxDB, ob man genau so eine Geschichten auch hinkriegt und vielleicht auch einfach hinkriegt.
Und daher resultiert auch dieser Vortrag. Das war im Prinzip, habe ich da Ende letzten Jahres damit angefangen. Und es war eigentlich ein Experiment und die Erfahrung bzw. die Geschichten, die ich da so rausbekommen habe, die wollte ich jetzt einfach in diesem Vortrag mal verpacken und vielleicht ein paar Leute noch ein bisschen anfixen, dass sie sich vielleicht auch mal mit InfluxDB beschäftigen oder nicht.
Okay, Daten, die fallen im Prinzip heutzutage überall und ständig an, werden auch überall, werden auch in großen Datenbanken abgespeichert. Keiner weiß, was man damit machen kann, größtenteils.
Aber man speichert sie erstmal ab. Das interessante bei Datenbanken, bei Daten ist im Prinzip, dass sie verschiedene Eigenschaften haben. Und genau diese Eigenschaften bestimmen dann eigentlich auch die Datenbanken, indem man sowas reinpumpt.
Und früher, kommt jetzt auch gleich auf der nächsten Folie. Ja, die landen im Prinzip in Datenbanken, werden unterschiedlich weiterverbeidet. Kommen wir mal gleich auf die nächste Folie. Früher gab es nur so die zwei, drei bekannten Platzhörer, wie Oracle, Microsoft SQL, Postgres, MySQL und was es da so alles gibt, die im Prinzip versucht haben, alles irgendwie abzubilden.
Und gerade bei so einen speziellen Daten wie Zeitreihen, auf dem Begriff kommen wir dann gleich nochmal, um eben ein bisschen besser zu definieren, kann man natürlich in solchen Platzhörern oder in so einen riesen Datenbanken, so ein Alles Tools, kann man das natürlich alles reinpumpen.
Die Frage ist dann natürlich, kann man das vernünftig auswerten? Haben die da überhaupt den richtigen Platz gefunden oder gibt es da nicht was Besseres? Und deswegen haben sich sehr, sehr viele Hersteller in der letzten Zeit spezialisiert und haben gesagt, naja, okay, jetzt schreiben wir mal Datenbanken, die nur für bestimmte Anwendungsgebiete,
jetzt habe ich es durchgestrichen falsch, also für bestimmte Anwendungsgebiete optimiert sind. Und wenn man mal so ein bisschen sucht, habe ich mal ein paar Beispiele rausgesucht, klar, das ist jetzt genau das, was ich sagte. Diese Platzhirsche, irgendwelche SQL-Datenbanken, die mit Relationen in den Tabellen arbeiten.
Dann gibt es natürlich aber auch dokumentenorientierte Datenbanken, objektorientierte Datenbanken, Diagramm-Datenbanken kannte ich bis jetzt noch gar nicht, fand ich bloß lustig. Suchmaschinen-Datenbanken kennen wahrscheinlich jeder und dann eben halt auch Zeitreihen-Datenbanken. Und die unterscheiden sich im Prinzip im Datenbankmodell.
Und wir werden uns einfach heute mal ein bisschen mit Zeitreihen-Datenbanken beschäftigen. Gut, Zeitreihen, was sind dann eigentlich Zeitreihen? Bei einem Präsenzvortrag würde ich jetzt die Frage stellen und warten, was ihr mir so antwortet. Jetzt muss ich die Frage selber antworten. Sind also im Prinzip irgendwelche Serien von Messungen, von Beobachtungen, von Zuständen,
von, keine Ahnung, irgendwas, wo das Wichtige ist. Aber ob diese Messungen sind auf aufeinander folgenden Zeitpunkten, also wie zum Beispiel Wetterdaten, Monitoringdaten, Börsenkurse,
wenn man jetzt in die E-Technik in Labore geht, irgendwelche Strömme oder was auch immer alles, was man irgendwie über die Zeit abbilden kann. Und wozu speichert man die logischerweise ab? Klar, um die darstellen zu können, wie vielleicht in die Diagramm ganz am Anfang,
um diese Verläufe zu archivieren. Und natürlich auch, ganz, ganz wichtig, vielleicht hat ja dann irgendjemand, also irgendein Tool oder irgendein Algorithmus gefunden, mit dem man statistisch Analysen machen kann. Was ganz Besonderes, was es vorher noch nie gab. Und dann kann man auch über diese Daten mal dieses neue Verfahren ausprobieren.
Sehr, sehr viele Zeitreihen-Datenbanken haben schon so einen statistischen Analysen-Algorithmen drinnen, mit denen man Trends-Zyklen berechnen kann, Bandbreiten und Korrelation der Werte untereinander, also ganz interessant. Wer ich heute nicht erzählen, aber vielleicht mal so im Hinterkopf behalten,
dass das auch eine interessante Geschichte ist. Okay, gut, Zeitreihen-Datenbanken. Also das sind dann im Prinzip die Datenbanken, wo man Zeitreihen reinpumpt. Welche Anforderungen haben die? Also wichtigste Anforderungen, steht gleich ganz so um.
Die Daten sind nach der Zeit organisiert. Sprich also, ich muss nicht so wie bei einer SQL-Datenbank, wenn ich da auch so eine Zeitreihen-Daten reinpumpten möchte, einen Index über die Zeit legen, um da besonders effizient dann solche Abfragen zu machen
über diese Messwerte, sondern das ist schon von Haus aus, out of the box, nach Zeit organisiert und auch optimiert. In der Regel gibt es auch ganz, ganz viele Schreibvorgänge. Also in Echtzeit werden da Daten reingepumpt aus den unterschiedlichsten Stellen. Das muss eben halt auch sehr performant geben.
Auch sehr viele parallele Datenquellen sind in der Regel bei solchen Zeitreihen-Datenbanken dran. Und lässt sich jetzt drüber streiten, ob es wirklich eine Anforderung ist, aber ist zumindest sehr, sehr smart, eine hohe Flexibilität bei der Definition und Typisierung von Daten.
Also dass man sich keinen Kopf machen muss, was pumpe ich da einfach rein, sondern ich pumpt es erstmal rein und dann schauen wir mal, was dann passiert. Eine andere sehr interessante Geschichte ist der zweite Anstrich hier. Bei Zeitreihen wird man sehr, sehr selten Aktualisierungen machen. Also es sind ja im Prinzip Aufnahmen der Realität und die jetzt im Nachhinein nochmal zu manipulieren,
ist ja irgendwo Blödsinn. Das sind Messreihen, die sind so gewesen und sollte man vielleicht nicht manipulieren. Und deswegen bieten sehr, sehr viele Zeitreihen-Datenbanken entweder sehr, sehr wenig Möglichkeiten an, Datensätze oder Messungen zu manipulieren.
Also was weiß ich, wenn die Temperatur 26 Grad ist oder höher 26 Grad, dann machst du auf 0 Grad oder irgend sowas, bieten sehr, sehr wenig Zeitreihen-Datenbanken an. Influx-DB zum Beispiel gar nicht. Dann wäre ich aber an entsprechender Stelle nochmal drauf hinweisen.
Und der dritte Punkt ist auch eine ganz smarte Geschichte, meine Wetterdaten. Also kommt vielleicht nachher auch noch ein Folie, muss man sich vorstellen, ich nehme die Wetterdaten nachher jede Minute auf und das über 10 Jahre, dann sammeln sich dann Millionen von Datensätzen an. Wer braucht die noch? Wozu muss ich wissen, im Jahr 2000 war die Temperatur um,
was haben wir jetzt, 1439, 10 Grad braucht kein Mensch. Also in der Regel hält man sich so eine Daten vielleicht einen Monat vor, dann komprimiert man die und löscht die ursprünglichen Daten und so eine Geschichte.
Und Zeitreihen-Datenbanken stellen Mechanismen zur Verfügung, wo man genau das machen kann, also das Automatisierte löschen und komprimieren von Daten. Also man muss nicht so wie bei SQL-Datenbanken irgendwelche Jobs laufen lassen,
die dann vielleicht viel schlagen oder so was, sondern das ist alles auch out of the box in so einer Zeitreihen-Datenbank drin und dann werden automatisch Daten gelöscht oder komprimiert oder und so weiter. Gibt es auch nachher noch eine Folie dazu. Okay, gut, ich habe hier mal eine Übersicht der Zeitreihen-Datenbanken aus dem Februar,
das ist diese Liste. Ich habe gestern nochmal nachgeguckt, die sieht jetzt immer noch so ähnlich aus. Wollte jetzt plus die Folie nicht ändern. Das ist so die prominentesten Zeitreihen-Datenbanken, die es gerade so auf dem Markt gibt. InfluxDB eben auch zurzeit sehr, sehr weit verbreitet.
Prometheus wird vielleicht noch jemand kennen. RRD-Tools kennen bestimmt auch noch einige. Aber wir werden uns im Prinzip heute ein bisschen mit InfluxDB beschäftigen. Okay, dann fangen wir doch einfach mal an. InfluxDB, der Hersteller, der sitzt in San Francisco.
Influx Data Incorporation. Das erste Release kam da 2013 raus. Zurzeit, ich habe jetzt gestern nicht nachgeguckt, ob es jetzt schon die 182 gibt. Das aktuelle Release, so wie ich es jetzt kenne, aus dem Juli heraus, ist 181.
Wird sehr, sehr, sehr forsch weiterentwickelt. Es gibt auch eine Beta, die nennt sich dann InfluxDB 2.0. Da sind die Mechanismen teilweise grundverschienen zu der 1. Version. Wird jetzt auch nichts in dem Vortrag zu dieser 2. Version kommen.
Aber ist auch eine interessante Geschichte, sich das noch mal später anzugucken. Okay, es gibt InfluxDB in drei Varianten. Einmal die Open Source Variante, die werde ich heute auch ein bisschen vorstellen. Wobei das, wo ich da heute rumkratze, ist es eigentlich vollkommen egal, welches von diesen drei Varianten das ist.
Die erste Variante ist eine Open Source Variante mit der MIT-Lizenz. Die ist kostenlos. Die beiden folgenden Influx Cloud und Influx Enterprise, die sind dann kostenpflichtig. Gerade die letzte, also die Influx Enterprise, die ist dann auch clusterfähig skalierbar
und man kriegt auch einen tollen Support. Muss natürlich dafür ein Geld bezahlen. Klar. Betriebssystem sind da aufgelistet. Wir beschäftigen uns heute mit einer Linux. Wobei das aber auch wieder egal ist, was es ist. Aber für Windows gibt es das zum Beispiel auch. Ich habe in einer Firma, habe ich letztens auch mal eine InfluxDB-Instanz aufgezogen.
Reagiert genauso wie eine Linux-Installation. Und ohne Probleme, also für Linux, FreeBSD, Windows, Mac OS gibt es eben halt InfluxDB. Das Ganze ist in Go programmiert. Da ist jetzt Spiel gemeint, falls das jemand kennt, sondern eben diese Google-eigene Sprache.
Sehr, sehr schlank. Also die Ressourcen, die da verbraucht werden, sind sehr, sehr wenig auf dem Server. Und was auch sehr, sehr gut ist bei Influx Data Incorporation, die Dokumentation. Also InfluxDB ist ja nur ein Produkt. Es gibt noch ein paar andere Produkte. Gibt es vielleicht nachher auch noch eine Folie, wenn wir es nachher schaffen.
Gibt es sehr, sehr gute Dokumentationen. Und die lohnen sich auf jeden Fall bei den einzelnen Punkten sich dann auch nochmal genauer anzugucken. Deswegen wird es jetzt auf den Folien auch immer diese Links geben zu der entsprechenden Dokumentation, zu der Geschichte, die dann gerade dort erklärt wird. Gut.
Ja, Installation. In der Regel macht man das aus einem Repository seiner Distribution. Kriegt man natürlich nur die Version, die da jetzt gerade gepackt wurde für die Distributionsversion, die man da gerade hat. Wenn man da mit der neuesten Version von InfluxDB irgendwas machen will,
dann sollte man das Zeug sich schon runterladen und von Hand installieren. Bei Windows ist es schon so notwendig, dass man dort ein Download macht und das installiert, was aber sehr, sehr problemlos geht. Wenn man das Ganze installiert hat, dann hat man im Prinzip zwei Programme auf seinem Rechner.
Das ist einmal der Daemon, Influx D. Das ist der eigentliche Serverdienst. Und man hat noch einen Command Line Interface. Das nennt sich Influx. Also das ist im Prinzip die Shell dazu. Wie auch bei anderen Datenbanken. Also bei MySQL, bei Oracle und Microsoft SQL. Weiß ich gar nicht, ob es eine Shell gibt.
Aber bei Oracle zum Beispiel, Postgres und sowas, gibt es auch eine Shell, mit der man dann auf Kurzweile Influx-Commandos absetzen kann. Was ganz, ganz wichtig ist, man sollte, es ist ja eine Zeitreihen-Datenbank, und man wird das nachher auch in den Beispielen sehen. Normalerweise, wenn ich da irgendwas reinhemmere in die Datenbank,
in die Datenbank, gibt man keinen Timestamp an. Sondern es wird der Timestamp des Ereignisses, dass der Datensatz oder der Messpunkt jetzt in diese Datenbank kommt. Also das ist im Prinzip die Serverzeit zum Zeitpunkt des Inserts. Und jetzt kann man sich natürlich vorstellen, wenn das überall vom Netz her kommt,
dann sollten die Rechner schon irgendwo synchronisiert sein, damit man da irgendwie eine gleiche Zeitbasis hat. Und deswegen empfiehlt es sich natürlich, einen Zeitdienst auf seinen Rechnern zu haben. Also nicht nur auf dem Server, sondern auch auf den Clients, die da irgendwas in die Datenbank reinpumpen.
Okay. Konfiguration. Ja, es gibt auch, natürlich kann man auch Influx DB konfigurieren. Es gibt da ein zentrales File. Der Ort ist dort aufgezeigt, befindet sich irgendwo unter ETC. In der Regel braucht man erstmal nichts konfigurieren,
außer vielleicht den Speicherort. Also ich habe bei einem meiner Server, auf dem ich eine Influx DB habe, eine SSD-Platte drin und eine normale mechanische Platte drin, also eine HD. Und dann hatte ich mir gedacht, naja, okay, SSD, wenn da ständig Daten raufknallen, vielleicht geht sie dann irgendwann mal kaputt.
Und deswegen habe ich dann den Speicherort für die Files, wo die Daten abgelegt werden, auf die HDD gelegt, was man am Anfang ändern sollte bei der Konfiguration, wenn man so eine Konstellation hat. Ansonsten reicht das erstmal.
Die Dokumentation für diese Konfiguration ist sehr, sehr ausführlich. Also da kann man wirklich Gott und die Welt einstellen. Auch Influx DB.conf, die ist auch sehr, sehr gut konfiguriert. Was wichtig ist natürlich, wenn ich die Konfiguration geändert habe, dann sollte man natürlich auch den Dienst starten, damit die neue Konfiguration irgendwo wirksam wird.
Gut, jetzt ein paar Begrifflichkeiten, weil Influx DB oder eine Zeitreinbankenbank, naja, nein, bleiben wir mal nur bei Influx DB, unterscheidet sich schon von irgendwelchen relationalen Datenbanken und deswegen diese zwei Worte auch wirklich vorangestellt.
Es ist ein schema-loses Datenmodell, also arbeitet mit einem schema-losen Datenmodell. Ich habe vielleicht noch Datenbanken, aber ich habe dann keine Tabellen, keine Spalten, keine Spaltentypen oder sonst was, sondern es ist wirklich schema-los. Und das sei jetzt mal vorangestellt.
Und es gibt dann so ein paar Begriffe, einen hatte ich schon genannt, Databases, es gibt also Kena, wo man eine oder mehrere Zeitreihen reinpusten kann oder organisieren kann. Und dann unterscheidet sich das aber schon von einer ganz normalen SQL-Datenbank oder einer relationalen Datenbank,
und zwar unter den Datenbanken sind dann die Messungen, also die Measurements, sind im Prinzip die eigentlichen Zeitreihen. Es ist vergleichbar bei einer relationalen Datenbank vielleicht mit der Tabelle, wobei, aber wie gesagt schema-los. Also ich schicke es einfach so rein, werden wir dann auch gleich noch sehen,
und dann ist diese, in Anführungsstrichen, Tabelle da, also die Messung da und so, wie ich es dort eingefügt habe. Eine Zeitreihe, also eine Measurement, da drin befinden sich dann im Prinzip die Datenpunkte, sind vergleichbar vielleicht mit den Tabellenzeilen
einer relationalen Datenbank, und die werden dann im Prinzip beschrieben durch Tech-Values, Field-Values und durch den Timestamp. Also Tech-Values, das sind so eine Dinge, sehen wir dann auch in den Beispielen, also die beschreiben die Messungen, also ich habe jetzt einen Temperaturwert, 24 Grad,
okay, jetzt ist natürlich die Frage, ist es innen Temperatur, ist es außen Temperatur, war es der Sensor 1, war es der Sensor 2, ist es in Fahrenheit oder ist es in Grad Celsius oder in Kelvin, solche Dinge würde man mit einem Tech-Value beschreiben. Dann die eigentlichen Messwerte, das sind die sogenannten Field-Values,
das ist dann eigentlich der richtige Wert, und Timestamp muss man nicht angehen, hatte ich ja vorhin schon gesagt, es ist der Zeitpunkt, wann der Datensatz oder der Datenpunkt in die Datenbank kommt, wird normalerweise automatisch gesetzt, es gibt aber auch eine Syntax-Ausprägung,
wo man den Timestamp auch angehen kann, aber letztendlich auch der Timestamp definiert im Prinzip den Datenpunkt, der ist immer da. Gut, so muss man sich das dann ungefähr vorstellen, also wir haben einmal hier die Messung, die heißt jetzt in dem Fall zum Beispiel Temperatur,
durch ein Komma getrennt und kein Leerzeichen hier zwischen, kommen dann die Tech-Values, also die Beschreibung, dann wirklich ein Leerzeichen,
kommen die Field-Values, die haben jeweils immer, Tech-Values, die haben immer einen Key, also beim Tech-Value hier, der da gerade abgebildet ist, ist der Key der Ort und die Ausprägung, also der eigentliche Tech ist dann zum Beispiel das Bad, Field-Value genauso, der Wert ist der Key im Prinzip,
und der eigentliche Wert, das Field ist dann diese 24,2 Grad. Man kann auch mehrere Field-Values angehen, auch wieder durch Komma getrennt, kein Leerzeichen dazwischen und so viel man möchte, kann man nochmal durch ein Leerzeichen getrennt,
also an dieser Stelle hierher, können nochmal den Timestamp angehen. Man muss es machen, also wenn man es wirklich nicht macht, dann wird der Zeitpunkt des Insorts genommen, ansonsten der Wert, den man dort angibt. Jetzt um eine Frage vielleicht voraus schon zu beantworten,
wann, wann, wann gebe ich denn, wann könnte man so einen Timestamp dort angeben, ist zum Beispiel bei Asynchronen Datenimporten von irgendeiner Datenbank in eine Influx-TV interessant, also zum Beispiel meine, keine Ahnung wie viele Millionen Werte, die jetzt auf irgendeiner SQL-Datenbank herumdümpeln,
möchte ich eine Influx-TV haben, möchte natürlich auch die richtigen Timestamps haben, hab fünf Jahre und keine, und haste nicht gesehen, dann gibt man eben halt den Timestamp an und dann wird das so auch in die Influx-TV reingespeichert. Okay, ich hatte ja gesagt,
schemalos, dass das Typen mitdefiniert werden müssen, sondern die werden so genommen, wie man im Prinzip dort hinschreibt bei dem Insert. Es gibt ein paar Einschränkungen, aber bei Field-Values im Prinzip können die Values Strings, Integer, Float
und Boolean sein. Was da jetzt hinten in Klammern steht, sollte man ernst nehmen, wenn man komische Fehlermeldungen bekommt bei Inserts. Wenn man dann einmal einen Field-Value, zum Beispiel XFLOAT in die Datenbank reingespeichert hat, dann kann man den mit einem nächsten Insert
den gleichen Wert nicht an Strings nehmen oder XBoolean oder irgendwas, sondern man muss dann schon, wenn man festgelegt hat, welcher Typ es ist, muss man auch Typ reinbleiben. Zweite Geschichte, die ich auch erst durch Experimentieren rausgekriegt habe, also wenn man Zahlenwerte hat und man sagt nicht implizit, dass es ein Integer
sein soll, dann wird die Anzeigenähe Integer- und Float-Werte. Wir haben eine 64-Bit-Auflösung, also schon ganz mächtig. Timestamps, Kleinstauflösung in Nanosekunden,
finde ich auch sehr sportlich. Bei Linux auch kein Problem. Bei Windows bin ich mir mal gar nicht so sicher, ob das Betriebssystem in Nanosekunden auflöst. Auf jeden Fall InfluxDB speichert Timestamps in Nanosekunden. Gut, und Keys und Tags sind dann im Prinzip String, also auch
diese Werte hier. Ich gehe nochmal ganz kurz zurück. Also das sind hier Strings. Auch wenn ich da jetzt eine Zahl hinschreiben würde, dann wäre es auch ein String. Ja, und die können relativ lang sein. Ich hatte den Vortrag schon einmal gehalten irgendwo, da hatte dann irgendwie jemand nebenbei geguckt, wie lang die Strings sein können. Also das sind ein paar Kilobyte
Größe, also keine Sorge, da kriegt man schon alles runter, was man vielleicht eventuell braucht. Okay. Ja, das ist noch so eine interessante Geschichte, wenn man so eine Messreihe plant. Wann nehme ich einen Tagvalue und wann nehme ich einen Fieldvalue?
Ich habe mich da in der ersten Zeit auch relativ schwer getan, das vernünftig zu machen, bis ich dann irgendwie eine schöne Faustregel gefunden habe, die ich jetzt genau auf diese Folie gebracht habe. Wenn man in einer Relationalen Datenbank über einen Spalt, obwohl wir ja keine Spalten haben, ein Index legen würde, um zum Beispiel
ein Group By zu machen oder bis ein Sortierkriterium darüber zu legen, dann wäre es ein Tagvalue. Und wenn das nicht der Fall ist, also keinsterweise irgendwie ein Index oder ein Group By oder was auch immer, dann könnte es höchstwahrscheinlich ein Fieldvalue sein. Also wenn man diese Faustregel irgendwo immer ein bisschen im Hinterkopf
hat, dann kann man auch sagen, ja, okay, das sollte jetzt vielleicht mal ein Tagvalue werden und das andere ein Fieldvalue. Gut. Ich schaue mal ein bisschen auf den Chat, ob es bis dahin irgendeine Frage gibt. Das ist alles so ein bisschen allgemeines Geplenke und
so ein bisschen Einführung und die Erklärung, wie die Begriffe da so sind. Aber scheint es nicht zu geben. Okay. Ja. Ich habe mir jetzt bei diesem Vortrag einfach gespart, mal eine Live-Demo zu machen. Also ich habe den schon mal online gehalten,
diesen Vortrag bei uns in der Bra-Log und da kam dann ein Vortrag von 150 Minuten raus. Es war dann dem dem geschuldet, dass ich das, was jetzt im Prinzip demnächst, also jetzt folgend auf Folien kommt, live gemacht habe. Das werde ich mir jetzt sparen, sondern ich habe die Folien jetzt ein bisschen anders aufgebaut, die Slides.
Also es kommen jetzt so ein paar Dinge, die man im Prinzip einfach mal mit Influx, also Command-Line-Interfaces mal ausprobieren sollte oder kann. Und ich habe es so aufgebaut, dass die Eingaben immer schwarz sind und die Ergebnisse blau
sind. Gut. Also Influx. Das ist ja ein Prinzip, das ich jetzt gerade noch eine Frage im Chat die ich aber jetzt nicht beantworten kann so richtig. Letztendlich ist ja die Zeitreinen-Daten-, also die Frage heißt Unterschied zu anderen NoSQL-Datenbanken.
So ganz weitläufig gesehen ist glaube ich eine Zeitreinen-Datenbank auch eine NoSQL-Datenbank. Auch wenn der Syntax vielleicht SQL-lastig ist, der dann später kommt und den ich noch ein bisschen erklären werde. ist wahrscheinlich auch eine Philosophiefrage. Deswegen werde ich jetzt auch nicht genauer darauf eingehen.
Command-Line-Interfaces. Also Influx ist das Command-Line-Interfaces, was ja bei der Installation mitinstalliert wird. Mit Influx minus Help kann man ich glaube das sind immer zwei Minuszeichen. Also falsch geschrieben sozusagen sind immer zwei Minuszeichen. Mit Help kann man sich
ein bisschen anzeigen lassen was die Parameter sind. Und jetzt die nächsten drei sind also so mal die typischen Parameter mit denen man dieses Command-Line-Interfaces aufruft. Gerade schon bei der zweiten Zeile kommt eine interessante Geschichte oder erahnt man und auch bei der Ausgabe, die dann kommt, das Ganze läuft über
HTTP. Deswegen ist jetzt auch alles das was dann in der Folge kommt, auch über HTTP. Ich werde an den möglich und ich werde das auch an den entsprechenden Stellen nochmal kurz zeigen. Also klar, wenn man zweite Zeile sind wir gerade. Wenn man die Influx-Instanz auf dem
gleichen Rechner hat, wo man mit dem Command-Line-Interfaces rumfummelt, dann Logelhost oder man gibt es überhaupt nicht an und das 8086 ist das Standard-Port. Es gibt noch 8088. Achso, da braucht man fürs Backup irgendwie. Aber 8086 ist das Standard-Port. Kann man aber übrigens auch in der
Config ändern, wenn man es braucht. Okay, so. Dann dritte Zeile ist vielleicht eine Geschichte ungewöhnlich. Ich nehme meine Kakel alle weg. Precision. Und zwar gibt man hier die Auflösung des Timestamps an und auch die Präsentation des Timestamps.
Also gerade wenn man RFC 3.3.9 benutzt, dann ist es auch ein lesbares Format. Ansonsten ist es eben halt Unix-Sekunde, Unix-Stunde, Unix-Nano-Sekunde. Wenn man nicht gut im Kopf rechnen ist, dann sollte man vielleicht RFC 3.3.9 nehmen, um zu gucken,
wie die Daten da in der Datenbank drin sind. Vierte Zeile ist vielleicht nur noch interessant, wenn man mit Batch irgendwas machen möchte. Also man kann auch Kommandos über die Kommandozeile, über Influx loslassen und kann auch dann festlegen, welche Formate die Ausgaben haben sollen
oder so eine Geschichten. Okay, also wenn man Influx aufruft, dann kriegt man im Prinzip diese Ausgabe und kann dann im Prinzip loslegen. Gut. Ja. Also wenn man sich jetzt angemeldet hat an der Datenbank über Influx, über das Kommando-Line-Interface, dann sollte man...
Also ich hatte ja am Anfang erzählt, es gibt Datenbanken, also das ist eine leere Instanz, dann gibt es nur eine interne Database und zwar Underline-Internal. Da werden im Prinzip irgendwelche Daten intern von InfluxDB abgelegt, Logs und haste nicht gesehen,
Aufteilungen der Dateien und ich habe einmal reingeguckt, gleich wieder zugemacht, da habe ich gedacht, ja okay, die werden sich dabei schon was gedacht haben, wenn man es braucht, dann braucht man es. Ich habe es nicht gebraucht. Gut, aber um jetzt im Prinzip selber irgendeine Messreihe in so eine Influx-Datenbank reinzulegen, muss man also eine Datenbank
anlegen, das macht man mit Create-Database und sagt dann, wie der Name ist, in dem Fall wäre es jetzt Frostcon und wenn man nochmal ein Show-Database macht, dann kommt dann die Internal und die Frostcon. Gut. Mehr muss man schon gar nicht machen, außer vielleicht
die Datenbank auswählen, indem man jetzt die nächsten Commandos absetzen möchte. Also wir haben jetzt Frostcon angelegt und müssen wir also sagen, use Frostcon und dann sind wir im Prinzip in der Datenbank drinne. Wenn man das jetzt nicht machen würde, dann würde, glaube ich, bei der nächsten Zeile jetzt bei dem Insert, dann kommt dann
Du musst erstmal eine Datenbank auswählen, also use Frostcon in dem Fall und dann landen die nächsten Inserts, die so wie sie jetzt hier auf dieser Folie sind, in dieser Datenbank. Gut. Ich habe jetzt einfach mal ein paar Inserts gemacht oder jetzt auf diese Folie
gebracht. Die nächsten Folien beziehen sich auch immer wieder auf diese handvoll Datensätze, die ich da jetzt reingeführt habe. Wenn man jetzt hier so ein bisschen drüber guckt. Ein paar Folien vorher war ja dieser Syntax-Messung. Tech-Values, Field-Values, Timestamp
findet man jetzt genau im Prinzip hier wieder. So, und davor noch das Insert und dann wird genau dieser Messpunkt in die Datenbank gebracht. So, also die Messung bei der Zeile, die ich jetzt gerade markiert habe, beziehungsweise ich mache hier nochmal alles weg. So, die Messung heißt im Prinzip Temperatur. Dann
kommen zwei Tech-Values, also die die Messung beschreiben, einmal der Ort, einmal der Sensor. Dann kommt wieder eine Leerzeile und dann kommt der eigentliche Value. So, das kann man beliebig machen. Zum Beispiel hier in der Zeile gibt es zum
Beispiel den Wert Sensor nicht. Also den Tech-Value wird Sensor nicht. Stört die Datenbank nicht, ist ja schemalos, wird einfach reingepumpt und dann ist gut. Hat dann natürlich Auswirkungen auf die Auswertung, die man drüber fahren kann. Wenn ich dann vielleicht auch versuchen werde zu zeigen. Auf jeden Fall, ich habe
keine Tabellen angelegt. Ich habe nur die Datenbank angelegt und schreibe jetzt im Prinzip Messreihen oder Messpunkte zu Messreihen in die Datenbank rein. Und hier sehen wir jetzt genau drei Messreihen und zwar Temperatur, Luftdruck und Feuchtigkeit. Und der letzte hier für die Temperatur, der ist nochmal ein bisschen speziell. Da habe ich das nochmal gezeigt, wenn man jetzt hinten
einen Timestamp angibt. Das ist jetzt eine Nanosekunde, deswegen so viele Nullen. Dann wird genau dieser Timestamp, den man hier angibt, als Timestamp in der Datenbank angenommen. Fragen hier zu diesen
Inserts. Ich denke, das ist noch relativ easy und mehr ist ja eigentlich auch gar nicht. Also so hämmert man einfach Daten in eine Influgsdatenbank rein. Ist natürlich ein bisschen mühsam, wenn man das jetzt alles per Commandline Interface macht. Ich hatte vorhin schon mal kurz angedeitet,
HTTP ist die Technologie der Wahl bei der ganzen Geschichte, bei InfluxDB. Das heißt also im Prinzip, ich habe jetzt hier mal ein kleines Bash Skript geschrieben, mit Curl kann man genauso Werte in die Datenbank reinbringen. Es gibt dafür auch noch eine
Beschreibung. Und das jetzt nicht irgendwie alles zusammensuchen, aber Beschreibung zusammensuchen, der Synthak. Immer anders. Geh auf diesen Rechner mit diesem Port. Wir schreiben genau diesen Wert
hier rein. Also diesen Messpunkt. Und zwar die Messung heißt random. In dem Fall keine Tag-Values. Das habe ich übrigens noch gar nicht vorhin gesagt. Tag-Values muss man nicht angehen. Also man kann es auch so machen ohne Tag-Value. Es muss aber mindestens ein Field-Value dabei sein. Also in dem Fall jetzt heißt der hier Value und dann eine Zufallzahl.
So kann man natürlich auch eine Datenbank befüllen. Man kann natürlich auch irgendwelche Keys benutzen, die auch zur Verfügung gestellt werden. Also gibt es alles. Aber hier mal eben halt wie man Daten in die Datenbank reinbekommt.
Okay. Jetzt haben wir die Daten da drinnen. Jetzt ist natürlich das hier. Ich gehe mit zwei Folien zurück. Nehmen wir das gekritzt. Field und Tag-Values, die sehen alle irgendwie ein bisschen anders
aus. Also ich habe hier Temperatur zum Beispiel auch mal variiert. Heißt der Field-Value nicht Value, sondern es sind zwei Field-Values da, Luft und Penis. Aber jetzt ist natürlich die Frage
ja, woher weiß ich jetzt? Was sind die Tag-Values? Und dafür gibt es eben halt ein paar Kommandos, mit denen man das im Prinzip rausbekommt. Also auf der linken Seite hier das Kommando Show Measurements. Man kann sich im Prinzip die
Messungen anzeigen, die man, die Messreihen anzeigen, die in der Datenbank sind. Cost ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... die sich. Da gibt es jetzt den Befehl Show-Series. Gut, okay, bei Feuchtigkeit, Luftdruck und Random,
da sahen die Messreihen und die Punkte, die ich da eingefügt habe, alle irgendwie ein bisschen gleich aus. Bei Random gab es überhaupt keine Tech-Values. Bei Feuchtigkeit und Luftdruck wurde jeweils nur ein Datensatz eingeführt, aber bei Temperatur ist es
interessant. Mit diesem Befehl im Prinzip listet er jetzt alle Kombinationen auf an Messungen mit Tech-Values, die da irgendwo existieren für diese Messung. Also wir haben da irgendwie einen Messpunkt, da ist nur der Tech-Value Ort gesetzt und dann aber auch zwei Mal Bart,
aber die Unterscheinungen sind halt in dem Tech-Value-Sensor und da gibt es die
unterschiedlichen Messungen, wo die sich unterscheiden. Hilft schon mal, wenn man jetzt wirklich ganz spezielle Messpunkte, Messreihen sehen möchte, so eine Übersicht, dass man sich das mal anguckt, was ich da in meiner Datenbank habe. Man kann auch noch ein bisschen tiefer reingucken, man kann sagen Show Tech-Keys, dann würden alle Tech-Keys, die bei Messungen
angezeigt werden, angezeigt werden. Ist jetzt hier ein bisschen unglücklich, weil überall Ort und Sensor irgendwo mal mindestens einmal mit drinne hatte. Das Einzige, was man jetzt hier vielleicht sieht oder sich fragen könnte, Random ist nicht da. Ja, waren keine Tech-Values
dabei, deswegen wird das hier nicht aufgelistet, aber hier ist es mit bei. Es gibt da noch den Befehl für die Field-Keys. Man kann sich alle Field-Keys aller Messungen angucken und da würde dann zum Beispiel Random den Field-Key-Value haben und vom Typ Flo. Also hier sieht man
dann im Prinzip dann auch nochmal, mit welchem Datentyp er das angelegt hat, mit welchem Bonus, mit dem man gucken kann, ja, was habe ich da jetzt für Messungen, wie sehen die aus, ist eben halt auch interessant, wenn ich die verschiedensten Selects absetzen möchte.
Okay, gut, dann Abfragen. Also es gibt da auch wunderschönes Manual Data Exploration. Die Abfragen der 1. Version ist FluxQL, also Flux Query Language,
hat einen SQL-ähnlichen Syntax und ist relativ umfangreich. Bei der 2. Version nennt sich das Ganze dann, glaube ich, Flux und das sieht dann schon fast zu mir aus, als wenn ich da jetzt eine kleine Procedure schreibe oder sowas. Ich habe es mir nicht,
ich habe es nur einmal überflogen, war ganz spannend, aber das, was jetzt hier kommt, das ist FluxQL und also wenn man im SQL irgendwo raubt, kommt man auch sehr, sehr leicht mit FluxQL zurecht. Gut, also wie man das schon sieht, ich werde jetzt nur ein paar Selects, wer und group by, erklären. Woher stammt eigentlich der
Name Flux, weiß ich auch nicht, keine Ahnung, also einfach mal googeln. Die Firma hieß übrigens auch, die haben sich irgendwann erst umbenannt, die hieß vorher, ich habe es schon wieder vergessen, die haben sich, keine Ahnung, was das Flux bedeutet, weiß ich nicht. Gut, ja, also man sieht schon, select, wer, group by, gibt es auch im
SQL, kann man nichts falsch machen, wenn man SQL kann, dann kann man auch Flux db-Daten abfragen. Okay, dann machen wir das doch mal einfach, das gibt es die Messung Temperatur gibt, kann man natürlich auch sagen, select, Stern,
Form, Temperatur. Ja, und dann kommen alle Werte dieser Messe. Und nun ist natürlich, sieht das hier alles ein bisschen komisch aus. Ja, also gerade hier auf dieser Seite, also das sind die Timestamps, ist klar. So, was jetzt natürlich hier schwierig ist,
er gibt jetzt alles aus, weil ich ja nichts weiter eingegrenzt habe, also select, Stern, Form, Temperatur. Wir haben da vier oder fünf Messwerte jetzt drin gehabt. Das ist glaube ich der mit dem Timestamp, den ich da eingeführt hatte. So, und jetzt
sind manchmal ein paar Spalten gefüllt und ein paar Spalten nicht gefüllt. Ja, das ist natürlich dem geschuldet, dass es eben halt bei diesen drei Messwerten oder Messpunkten, Datenpunkten, im Teil kein Value Fenster und Luft gibt. Ja, oder hier und hier wurde der Tech-Value-Sensor nicht gesetzt im Insert.
Jetzt kommt natürlich auch gleich wieder die Frage, ja, woher erkenne ich jetzt eigentlich das Setz, dass das ein Field Value ist, dass das ein Field Value ist und dass das ein Field Value ist und dass das ein Tech-Value ist und dass das auch ein Tech-Value ist, sieht man leider diese Ausgabe nicht
an. Aber dafür gibt es ja diese anderen Kommandos, die ein, zwei Folien vorher kamen, also Show Tech Keys und Show Field Keys, da kann man es dann abgrenzen, was es ist. Gut, aber was uns hier gerade gezeigt wird, auch wenn die Werte nicht gesetzt sind, sondern irgendwie so ein Wert gesetzt ist und ich frage es mit Stern ab, dann listet er wirklich alles, was er da
irgendwo findet. Wenn ich das jetzt ein bisschen mehr spezifiziere und sage Select Value from Temperatur, dann listet er mir tatsächlich nur diese Spalten auf, die auch wirklich einen Wert im Value haben, also im Field Value Value. Ja, jetzt kommen hier glaube ich noch ein paar mehr Beispiele.
Genau, hier zum Beispiel jetzt ein Field Value und ein Tech-Value, er listet alle auf, die ein Field Value haben und zwar Value und wenn ein Sensor gesetzt ist, dann wird auch Sensor mit ausgegeben, ansonsten nicht,
weil ich habe gesagt, ich will auch die Werte haben. Gut, ist gewöhnungsbedürftig, aber bringt irgendwie Sinn, wenn man drüber nachdenkt. Es gibt auch ein paar lustige Optionen, die glaube ich ein paar Folien später noch kommen, mit denen man dann genauso eine Löcher ausfüllen kann. Okay, ja, das zweite Select hier auf dieser
Folie soll einfach nochmal zeigen, dass ich natürlich auch mit Field Values rechnen kann. Also ich hatte ja zwei Messpunkte mit Luft und Fenster als Field Value eingegeben gehabt, als Insert und ich kann natürlich auch rechnen und es werden natürlich nur die Zeilen hier
in dieser Spalte berechnet, die auch wirklich in Luft und Fenster hatten. Jetzt bitte aber nicht die Frage stellen, wenn nur Luft gesetzt wird und Fenster gesetzt wird. Ich hatte es letztes Mal geguckt, ich habe es aber schon wieder vergessen, entweder wird dann dieser Wert
nicht mit angegeben, weil eine Differenz von irgendwas mit nichts gibt es nicht oder es wird null ausgegeben, also jeder mal selber ausprobieren. Aber auf jeden Fall werden wirklich nur die Zeilen angegeben, wo mindestens einer oder beide Werte gesetzt werden. Die anderen werden landen unterm Tisch, also sie werden nicht
ausgegeben. Okay, jetzt mit Wer-Klausel, klar, ich kann jetzt sagen, zeig mir alle Werte, wo der Ort Bad ist, ergibt dann sowas hier. Oder ich kann natürlich auch sagen, alle Werte, wo der Value größer ist, jetzt habe ich das Value weggenommen, also die Temperatur
größer 24 Grad ist, kann man natürlich alles angeben. Also da findet man sich, wenn man SQL kann, sehr, sehr leicht wieder und kann da schon interessante Abfragen machen. Group-by geht natürlich auch. Das Ausgabeformat ist dann etwas gewöhnungsbedürftig. Da wird im Prinzip zuerst die Messung
angegeben und dann wird gruppiert nach Ort. Ich habe zwei unterschiedliche Werte im Ort, in dem Tech-Value-Ort, einmal Bad und einmal Keller, werden dann im Prinzip die entsprechenden Werte angezeigt, die diesem Kriterium entsprechen. Okay, gut.
Ja, es ist eine Zeitreihen-Datenbank, also muss ich ja mit Zeit auch was Cooles machen können. Und jetzt kommen zwei, drei Dinge, wo das genau darum gehen wird. Also, einfachste Abfrage ist natürlich, gib mir jetzt
alle Werte von der Messung random. Das war die Messung, die da jede Sekunde was reingepumpt hat, wobei bei dem Beispiel, glaube ich, alle 20 Sekunden, nee, jede Sekunde, okay. Und da die letzten Werte, die Werte der letzten zwei Stunden, das sagt im Prinzip dieses Time-Größe-Now minus zwei Stunden
an. So sieht das im Prinzip aus. Und das Coole ist eben halt bei der Geschichte, es gibt halt diese Geschichten, ich sage dann eben einfach minus zwei Stunden, also minus zwei H, oder für einen Tag minus zwei D, oder für einen Monat ein M und für ein Jahr ein Y und diese
ganzen Geschichten. Also, da braucht man sich jetzt nicht groß in den Unix-Time und hast du nicht gesehen und wieder zurückrechnen und überlegen, sondern nein, man sagt dann einfach now minus zwei und dann kriegt man die Werte der letzten zwei Stunden oder so was. Now ist im Prinzip der Zeitpunkt jetzt gerade, wo die Abfrage gestartet wurde. Okay, so sieht das aus.
So und jetzt gibt es natürlich ein paar interessante Geschichten. Wir haben eine Zeitreihen-Datenbank und wir wollen ja, ich hatte ja auch gesagt, ein bisschen komprimieren und machen und tun. Jetzt gibt es da natürlich ein paar lustige Mechanismen, die sehr, sehr interessant sind. Also hier auf der linken Seite sieht man nochmal die Abfrage von der vorhergehenden Folie, also Folie gibt mir
also alle Werte der letzten zwei Stunden. Okay, rauschen jetzt vielleicht keine Ahnung, wie viele Tausend durch. So, aber eigentlich interessieren mich ja nur die Mittelwerte im Zehn-Sekunden-Raster. Also, ich will die Zehn Werte, die innerhalb von Zehn
Sekunden waren, die will ich als Mittelwert zum Beispiel ausgegeben haben, mir das einfach reicht. Genauso bei der Temperatur. Ich messe jede Minute die Temperatur, ja gut nach drei Monaten reicht das mir, wenn ich weiß, um 13.00, um 14.00, um 15.00 und da interessieren mich die 60 Werte dazwischen überhaupt nicht mehr. Und da gibt es dieses Wunderwort Time und dann
gibt man im Prinzip das Intervall an, zu dem man das zusammenfassen möchte. Also hier im Zehn-Sekunden-Raster, das Ganze, dem Ganzen stellt man noch ein Grub bei voraus und dann sagt man natürlich auch noch, was man mit diesen Werten machen möchte. Min ist in dem Fall der Durchschnitt und dann
passiert das so. Also so bildlich gesprochen soll es dieses Dreieck mal zeigen. Also diese Zehn Werte hier werden zu diesem Wert hier zusammengefasst. So muss man sich das ungefähr vorstellen. Jetzt gibt es natürlich hier auf der rechten Seite ein paar Löcher.
Weil einfach keine Werte da waren. Also da hatte ich vielleicht mal das Skript unterbrochen oder was auch immer. Es geht bei solch einer Angabe auch bis zum jetzigen Zeitpunkt. Oder beziehungsweise, was diese Wehrklausel beinhaltet. So und wenn es da keinen Messpunkt gab, aber der Zeitpunkt ist ja da.
Sprich also, man sagt sich InfluxTV, ja okay, ich habe keinen Messwert, aber ich gebe das Raster aus und da war eben halt nichts. So, jetzt gibt es natürlich ein paar Wunderworte, oder so einen wunderschönen Befehl, Fill, oder ein Parameter ist das eigentlich mehr, mit dem man sagen kann, was mache ich
mit diesen Löchern. So und auf der linken Seite sage ich zum Beispiel Fill Null. Und dann wird für alle Werte oder für alle Zeilen in der Ausgabe, wo es keinen Messwert gibt, also wo man nichts zusammenrechnen konnte, weil es einfach keinen Messwert gibt, eine Null ausgegeben. Oder wenn ich Non angebe, dann werden
diese Messpunkte weggelassen. Also diese zusammengefassten Messpunkte. Es gibt noch ein, zwei andere Ausprägungen. Man kann auch Prevalue sagen, dann wird der vorhergehende Value für dieses Loch angenommen. Also hier würde dann bei der Null würde dann diese 18759, irgendwas
dann stehen und so weiter. Oder man kann auch linear sagen, dann wird zwischen dem und dem Wert dann im Prinzip eine lineare Kurve reingelegt automatisch und dann wird das, wenn diese Werte damit gefüllt. Also da gibt es mehrere Ausprägungen, ich verweise ja aufs Manual für Phil, ist
eine ganz smarte Geschichte. Also gerade wenn man so eine Hitmaps zum Beispiel machen will, wie ich es eingangs mal gezeigt hatte, ist es eine sehr hilfreiche Geschichte. Gut, ja, Datenbank abfragen.
Funktionen gibt es natürlich ganz viele. Minen hatte ich kurz gezeigt. Braucht man immer irgendwie. Es gibt natürlich ganz, ganz viele Aggregationen, Selektoren, mathematische Funktionen, Analysefunktionen, von dem ich ja noch nie was gehört habe. Keine Ahnung, ganz lustige Geschichten, verweise ich aufs Manual. Logischerweise klar, immer
mit Abgrenzung über Group By und irgendwelche Tech-Values oder Zeitbereiche, wie wir es gerade vorhin gesehen haben, wo ich Zeitbereiche zusammenfassen möchte. Einfach mal nachgucken. Also das würde jetzt den Rahmen des Vortrags hier sprengen, wenn ich jetzt auf jede Funktion eingehe. Okay, gut, Datenpunkten manipulieren
hatte ich ja schon gesagt eingangs. Es gibt wirklich kein Update bei InfluxDB und es gibt ein sehr, sehr eingeschränktes Delete, mit dem man im Prinzip wirklich nur Delete from Measurement sagen kann, aber nur über Tech-Values. Also ich kann nicht sagen,
lösche alle Datenpunkte, wo die Temperatur und die Temperatur ist jetzt ein Field-Value größer 100 Grad ist. Geht nicht, lässt da nicht zu. Ich kann nur sagen, lösche alle Datenpunkte, die im Bad aufgetreten sind, wobei das Bad dann ein Tech-Value war. Ja, was anderes geht nicht. Ich kann eine Messung eigentlich nicht verfälschen. Was natürlich immer geht, ich kann
eine gesamte Messung löschen. Also ich kann jetzt sagen, Temperatur ist jetzt ernst doof. Sag ich, Drop, ich weiß jetzt gar nicht, ob ich Measurement, ja doch, Drop, Measurement, Temperatur und dann wird insgesamt Temperatur gelöscht. Okay. Genau, das ist noch ganz lustige
und wichtige Geschichte bei Influx DB, Continuous Queries und Retention Queries. Wir haben nicht mehr allzu viel Zeit, deswegen gehe ich mal ein bisschen im Schnelldurchlauf durch, verweise immer irgendwie auf die Doku. Ich hatte ja eingangs gesagt, es wäre ganz cool, wenn es irgendwie Mechanismen gibt, wo man Daten rein zusammenfassen kann und wo man
veraltete Daten löschen kann. Das sind genau die beiden Mechanismen, Continuous Queries und Retention Queries. Also hier nochmal als Beispiel, ich nehme jede Minute einen Wert auf. Nach einem Monat oder nach einem Tag interessiert mich das nicht. Also schreibe ich irgendwie eine Continuous Query, was auf fünf Minuten verdichtet und immer so weiter.
Man kann das unendlich kaskadieren und die Werte, die dann übrig sind, also diese Minutenwerte, die lösche ich dann eben halt nach einem Tag mit einer Retention Policy. So muss man sich das ungefähr vorstellen. Sollte man möglichst auch sich mal auf dem Blatt vorher aufzeichnen, wie man das haben möchte, dass sich das nicht irgendwie
überkreuzt. Und aber das sind auf jeden Fall die beiden Mechanismen dazu. Auf den nächsten drei Folien ist das jetzt mal als Quelltext, als Kommandos mal aufgezeichnet. So wird eine Continuous Query angelegt, also ist vergleichbar vielleicht wie ein Trigger
unter SQL oder sowas. Also fasse jede Minute, ne, fasse die Werte in einer Minute zusammen oder andersrum. Also ich kreiere eine random eine Minute, die in der Datenbank CLT ist. Ich will den Mittelwert haben.
Das soll auf dieser Messung dann landen. Das ist der Ursprung. Und ich will die Werte im Ein-Minuten-Raster zusammengefasst haben. Also das bedeutet im Prinzip diese Zeile. Und der Wert, der nächste Wert wird dann genau dann geschrieben, wenn diese eine Minute
vorbei ist. Dann wird, dann wird von den zehn random Werten oder sowas ein random eine Minute geschrieben oder wie auch immer man das gerade definiert hat. Ok, so muss man sich das ungefähr vorstellen. Es gibt auch natürlich auch ein Kommando, mit dem man, mit dem man sich die Gürtchen Continuous Queries angucken kann,
ist da unten aufgezeichnet. Hier ist es nochmal bildlich. Also diese drei grünen Werte ergeben dann diesen und so weiter und sofort in einer neuen Messung im Prinzip und immer so weiter. Ja, Retention Policies ist im Prinzip das Haltbarkeitsdatum
auf dem Joghurt. Ich schmeiße immer einen Tag später, wenn der Joghurt, wenn das Haltbarkeitsdatum abgelaufen ist, schmeiße ich immer den Joghurt weg zum Ärger meiner Frau. Die würde den zwar immer noch essen, aber ich nicht. Und Retention Policy muss man sich im Prinzip genauso vorstellen. Ich verweise auch jetzt erst mal wegen der Zeit auf das Manual.
Aber letztendlich kann man mehrere, genauso wie Continuous Queries, mehrere Retention Policies definieren und eine ist immer Default. Und man kann mehrere definieren, die nicht Default sind. Wenn man im Prinzip beim Insert
dann nicht angibt, ich will es mit dieser Retention Policy machen, dann gilt die Default Policy. Ansonsten muss ich es mit angeben, dass ich das unter dieser Retention Policy in die Datenbank schreiben und dann würde in dem Fall nach einer Stunde der Messung verschwinden. Hat ein paar Auswirkungen auch auf, wie gesagt, auf das Insert und auch auf das Select.
Aber wenn man es einmal verstanden hat, dann kommt man auch mit, denke ich, zurecht. Einfach mal im Manual lesen. Gut. Ja, das ist so eine Geschichte, wenn ich asynchrone Datennahmen aus einer SQL-Datenbank, wie ich die dann in so eine Influx-DB reinbauen, rein hämmern kann.
Das sind hier zum Beispiel meine Wetterdaten aus einer SQL-Datenbank. Habe ich mir einen Skript geschrieben, wo genau das das Input-File ist, was hier angegeben ist. Und ich will das in die Datenbank, in die Influx-Datenbank Wetter rein jubeln. Das Ganze mit einem Curl-Kommando und dann macht er das sogar bei Millionen von Datensätzen
relativ schnell, also extrem performant des Influx-DB. Gut. Das ist jetzt alles das, was ich nicht erzählt habe heute. Also Backup gibt es natürlich, User-Management gibt es natürlich, wie Daten organisiert werden, die Stellschrauben dafür, die ganzen Abfragefunktionen,
die es da noch alles gibt. Ich verweise einfach mal aufs Manual. Ist eine interessante Geschichte. Und wie gesagt, die Manuals sind auch ganz, ganz gut geschrieben. Wie viel Zeit und Lust haben wir noch? Ich mache mal einfach ein bisschen weiter. Jetzt habe ich natürlich eine Influx-Datenbank,
kann ich Messwerte reinlegen, aber woher kommen jetzt diese Messwerte? Und klar, man kann jetzt irgendwelche Programmeskripte schreiben, wo das Zeug reingejubelt wird, also irgendwo herausgelesen wird und dort reingeschrieben wird in die Influx-Datenbank. Aber es gibt auch ein paar ganz coole Tools, mit denen man auch Daten generieren kann oder irgendwo herholen kann
und in eine Zeitreihen-Datenbank reinschreiben kann. Beispielhaft, einfach mal Telegraph ist auch von Influx-Data, also dem Hersteller von Influx-DB. Man muss sich das so vorstellen, das ist irgendwie so ein Tool mit ganz vielen Input- und Output-Plugins und auch Funktionsplugins, wo man aus verschiedenen Quellen
irgendwelche Daten lesen kann, also sei es jetzt MQTT-Nachrichten, sei es irgendwelche Textdateien, sei es keine Ahnung irgendwas. Also gibt es ganz, ganz viele Plugins und die kann man einfach von dort, also mit Telegraph, einlesen und dann zum Beispiel in eine Influx-Datenbank reinschreiben.
Chronograph ist auch von Influx-Data. Habe ich mir nie angeguckt. Kapazitor habe ich mir auch nie angeguckt. Das eine Chronograph ist ähnlich wie Grafana, Visualisierung von Zeitreihen-Daten und Kapazitor. Okay, ja, das muss man sich
so wie eine Kreuzung vorstellen, wo Datenströme umgelenkt weitergeleitet und was sich nicht alles können. So muss man sich das ungefähr vorstellen. Ich habe jetzt in den folgenden Folien mal so ein Beispiel für Telegraph, Grafana, als Ersatz für Chronograph und auch mal
mal Notred, weil dort gibt es ein Note, mit dem man auch Daten in eine Zeitrein-Datenbank, also sprich in einer Influgsdatenbank schreiben kann, deswegen mal nur kurz das aufgezeigt. Also so würde das zum Beispiel unter Notred aussehen. Notred, denke ich, kennt so ziemlich jeder.
Okay, ich habe gerade im Chat gelesen. Kriegen wir hin, die drei Minuten. Also es gibt Notes für Influgsdatenbanken und dann kann man da sein Floh zusammenschreiben, Notred, und dann funktioniert das ganz toll. Hier mal ein Beispiel für Grafana, wo eine Influgsdatenbank
darunter ist, das sind zum Beispiel meine Metamesswerte, um jetzt auch nochmal das Heatmap dazuteigen, was ich eingangs auch auf X-GNUplot hatte, kann man natürlich unter Grafana
auch ganz toll machen. Was haben wir noch? Achso, und hier mal ein Beispiel, Telegraph sendet irgendwelche Werte in eine Influgsdatenbank und die werden dann über Grafana visualisiert. Das wäre jetzt lustigerweise übrigens der Rechner, also Systemmonitoring über dem Rechner,
wo meine Influgsdatenbank, also meine Haupt-Influgsdatenbank läuft. Telegraph hat zum Beispiel Pluginsysteminformationen aufsammeln und das in eine Influgsdatenbank zu schreiben und das könnte dann so aussehen. Dieses Gezackte kommt übrigens tatsächlich wirklich wegen irgendwelchen Retention Policies und Continuous Query zustande. Also
das ist hier der Plattenplatz und man sieht dann wirklich, steigt an, steigt an und dann irgendwann nachts ist er da in der Meinung, jetzt räumt er mal auf, also schlägt dann mal die Policy zu und dann geht es wieder runter und dann baut es sich über den Tag
wieder auf. Gut, hier nochmal ein paar Informationsquellen. Also die Folien, denke ich, werde ich auch zur Verfügung stellen, wie gewohnt im Voskorn-Programm, dass man sich das im Nachhinein nochmal angucken kann. Danke für das Zuhören. Fragen? Kommen
keine Fragen? Okay, also die erste Frage kam von der Simone. Nutzt du FluxDB weiter,
also InfluxDB meinst du, denke ich? Ja natürlich, klar. Also ich stelle gerade meine ganzen komischen Sensoren, die ich hier irgendwo bis jetzt die Daten in eine SQL-Bank reinpumpen gelassen habe, stelle ich gerade jetzt alle auf InfluxDB um und ja,
werde ich weiter benutzen und dann kam noch eine Frage im Chat. Performance-Vergleich zu bekannten SQL-Datenbanken habe ich nicht gemacht, aber für mich war das damals schon beeindruckend, als ich den Import gemacht habe von meiner alten SQL-Datenbank, die jetzt nicht vergleichbar ist, das ist eine SQLite-Datenbank gewesen. Also da hat
das Rauslesen länger gedauert, als das in die Influx-Datenbank reinzuschreiben und es waren wirklich mehrere Millionen Datensätze und das waren innerhalb von drei, vier, fünf Minuten war das Zeug in der entsprechenden Influx-Datenbank drin. Also performance-mäßig wirklich sehr schnell und ich könnte mir vorstellen,
wenn man da noch diese Enterprise-Version hat, die dann auch clusterfähig ist und skalierbar ist, dass man das noch besser steuern kann, die Performance, und dass alles noch schneller geht. Neue Projekte mit InfluxDB 1 oder 2 anfangen.
Ansichtssache weiß ich nicht, weil ich mich mit 2 noch nicht so richtig beschäftigt habe. Sagen wir mal so, es gibt ein paar Mängel oder ein paar Dinge fehlen zum Beispiel unter der 1er-Version, also gerade diese Geschichte Luftdruck minus drei Stunden, blablabla, um die Luftdruck-Tensenz auszurechnen. Es gibt keinen Timeshift in der 1er-Version,
also X-Abfrage-Funktion. Gibt es in der 2er-Version, gut ich hab mir jetzt im Grafana durch ein Grafana-Plugin geholfen, da gibt es so einen Plugin, das nennt sich Meta-Data-Sources, mit denen kann man auch ein Timeshift simulieren, aber es gibt mit Sicherheit ein paar Features in der
2er-Version, die es in der 1er-Version nicht gibt und die interessant werden könnten. Also was braucht man und was brauche ich dazu? Also überlegt man sich ja vorher sowieso immer. Wenn man aber so eine Dinge machen möchte, wie ich, reicht wahrscheinlich die 1er-Version. Welche Hardware braucht man für IoT-Sensoren?
Kommt drauf an. Also, ja, irgendein Sensor, der irgendwo was ins Netz pusten kann, sei es jetzt ein ESP, sei es keine Ahnung oder irgendein Arduino oder ein Zigbee, gab es gestern zwei schicke Vorträge
von Marald und weiß gar nicht, wie der andere hieß, und dann irgendwie aufs Netz oder irgendwie HTTP-Schnittstelle und dann kann man das in die Influgsdatenbank rein pusten. Bei mir sind das zur Zeit ESP-Module, die zwar jetzt zwischendrin noch ein Not-Red haben,
bevor es in die Influgsdatenbank landet, aber ich könnte im Prinzip auch MQTT-Nachrichten schicken von diesen ESP-Modulen, dass du diese MQTT-Nachrichten von einem MQTT-Broker empfangen lassen und dann Telegraph zum Beispiel dahinter schalten und sagen, die Daten schreibst du jetzt in eine Datenbank,
in die Influgsdatenbank und dann ist okay. Ja, angeblich ja, ich hab's nie probiert, die Frage war, reicht ein Raspberry für die Datenbank? Angeblich ja, ich hab's nie probiert, ich hab einen vernünftigen Server dahinter, ich hab aber in der Literatur gelesen oder im Netz gelesen, dass es auch sehr
viele Leute gibt, die sowas auf dem Raspberry haben. Die Frage, die man sich da natürlich stellen muss, wie lange hält die SD-Karte oder benutze ich eben halt eine HDD-USB-Platte an dem Raspberry? Also, es wird schon relativ extensiv geschrieben, wenn man auch sehr, sehr viele Daten in die Influgsdatenbank reinbekommt.
Okay, noch eine Frage, ansonsten denke ich, sollte mal gut durch sein. Ja, vielen Dank auf jeden Fall, Uwe, schon mal für deinen Vortrag. Gibt es denn noch Fragen? Also, ein paar Minuten hätten wir auf jeden Fall noch.
Wenn das nicht der Fall ist, dann würde ich sagen, vielen Dank für eure Aufmerksamkeit zum Zuschauen.
Vielen Dank, Uwe, für deinen Vortrag. Ich möchte auch noch gerne einen Dank aussprechen an euch, die in so schweren Zeiten, wie sie gerade sind, trotzdem die Frostkomm nicht sperren lassen haben und alles für die Speaker getan haben, dass trotzdem diese Vorträge möglich waren und auch das Equipment, was sie uns zur Verfügung gestellt haben, ist eine coole Geschichte.
Also herzlichen Dank an alle Leute, die da tatkräftig unterwegs waren.