Hi Ingo,
vielen Dank für Deinen Vorschlag. Während wir einerseits dringend in Richtung Telemetriedatenformat v2 gehen wollen, wollen wir das Format v1 natürlich gerne behalten. Das entspricht strukturell der von Dir vorgeschlagenen Variante mit zwei Unterschieden:
- Das Feld
TMSTP.measuredheißt einfachtime. - Der
HIVE.ID-Identifier ist in der Adresse kodiert statt im Payload, siehe auch- Meßdaten an die Hiveeyes Plattform übermitteln und
- Gestaltung der anonymen Identifizierer (IDs) für die Adressierung von Imkern, Meßknoten und anderen Entitäten. Dadurch wird der Faktsatz agnostisch zur Anwendungsdomäne, woran der verwendete Kotori Data-Historian und die Gesamtarchitektur großes Interesse hat.
Kann man sich das in etwa vorstellen, wie man in einer relationalen Datenbank Relationen miteinander verknüpft?
Freilich, wir geben uns Mühe.
Das Thema Data Retention haben wir schon öfters diskutiert. Vor kurzem hatten wir uns auch einmal konkreter mit https://docs.influxdata.com/influxdb/v1/guides/downsample_and_retain/ beschäftigt (siehe zur Einführung z.B. auch https://towardsdatascience.com/influxdb-data-retention-f026496d708f), momentan ist es aber noch nicht akut und wir sind froh, dass InfluxDB bereits solche Dinge wie kontinuierlich-selektives Downsampling vorsieht [1] [2].
Das sind exzellente Fragen, danke. Eine umfassende Beantwortung oder eine etwaige Diskussion um alle möglichen Details innerhalb dieser Themen kann locker Bände füllen. Generell wollen wir auch hier in allen Aspekten flexibel bleiben und entsprechend auf die wachsenden Anforderungen reagieren.
Wir können gerne telefonieren und senden Dir über PM unsere Telefonnummer. Einstweilen vielen Dank für Deine Impulse.
Viele Grüße,
Andreas.
Du siehst, wir sind hier grundsätzlich sehr technologiegetrieben unterwegs, nichtsdestrotrotz wollen wir uns zukünftig weitere Gedanken über die Datenstrukturen machen, gerade bzgl. jeglicher Metadaten.
Aktuell ist fix, dass die Daten in einer InfluxDB-Datenbank gespeichert und in Grafana dargestellt werden. InfluxDB und Grafana sind für uns und andere derzeit das absolut dynamischste Duo vergleichbar mit der guten alten Parabel auf GNU/Linux.
– The Dynamic Duo: The Gnu and the Penguin in flight - GNU Project - Free Software Foundation
Wir schielen jedoch bereits stark rüber zu PostgreSQL mit TimescaleDB, siehe auch Looking at TimescaleDB und 4 Best Time Series Databases To Watch in 2019. Im Besonderen, weil wir vor kurzem durch die Erneuerung der Luftdatenpumpe bereits mit PostGIS in diese Richtung gegangen sind.
Während wir also Dimensionsdaten gerne bereits jetzt in einer PostgreSQL-Datenbank unterbringen können, werden die Zeitseriendaten wohl bis auf weiteres in der InfluxDB bleiben, gerade weil auch dort weiterhin ordentliche Innovationen rauspurzeln, mit denen unsereiner bisher noch von keinem anderen Datenbanksystem in dieser Art und Weise genußvoll in Berührung kommen durfte. Allen voran ist hier die neue Anfragesprache Flux zu nennen.
Die damit interaktiv gestaltbaren aggregierenden Abfragen übersteigen die Möglichkeiten von SQL bei weitem und haben uns bereits wertvolle Dienste beim gemeinsamen Erschließen der Daten geleistet. Hier wächst also in vorsichtiger Art und Weise ein wenig OLTP und OLAP zusammen, wie man es auch von Bemühungen anderer moderner Datenbanken ablesen kann. Diesen Weg, neue Technologien für uns zu erschließen, halten wir für sinnvoll – einiges das wir dadurch bisher erreichen konnten wäre ohne viele dieser wichtigen Implementierungsdetails nicht möglich. ↩︎
Wir könnten uns vorstellen, dass wir Dich als datenaffinen Menschen ebenfalls für die angesprochenen Technologien begeistern könnten. ↩︎