Im Rahmen des Forschungsprojekts KOSMoS entwickelt inovex zusammen mit acht Projektpartnern eine Plattform für die unternehmensübergreifende Vernetzung von Produktions- und Prozessdaten zur Integration neuer Datenprodukte und Geschäftsmodelle. Eine technologische Fragestellung stellt die Wahl einer geeigneten Zeitreihen-Datenbank dar, die es erlaubt, hochfrequente Maschinendaten effizient zu speichern und für analytische Zwecke einfach verfügbar zu machen, dar. In diesem Artikel diskutieren wir unsere Erfahrungen mit den zwei populären Open-Source-Zeitreihen-Datenbanken TimescaleDB und InfluxDB.

Warum die Evaluation?

In Zeiten von Industrie 4.0, Industrial Internet of Things (IIoT) und Künstlicher Intelligenz werden Zeitreihendaten in zunehmend größeren Mengen erhoben. Die Verarbeitung dieser Daten kann Maschinenbauern und -betreibern unter anderem dabei helfen ihre Maschinen durch eine bedarfsgerechte Wartung und intelligente Betriebsmittelüberwachung länger im optimalen Bereich zu nutzen.

Neben positiven Aspekten, die die Erhebung der Daten mit sich bringt, werden auch neue Herausforderungen geschaffen. Wohin mit den Daten? Wie können die Daten verfügbar gemacht werden? Wer darf auf welche Daten zugreifen? Klassische Datenverwaltungssysteme, wie relationale Datenbanken, stoßen mit Blick auf Leistung, Verlässlichkeit und Anpassungsfähigkeit im Zusammenhang mit Zeitreihen schnell an ihre Grenzen. Wiederkehrende Aufgaben, wie das Schreiben von größeren Batches oder das Abfragen von Werten über einen längeren Zeitraum, mit zusätzlichen Restriktionen an die zeitliche Komponente, können im Verlust von Daten oder langen Antwortzeiten des Systems resultieren. Zeitreihen-Datenbanken sind hingegen speziell auf die effiziente Speicherung, Verarbeitung und Analyse von Zeitreihen ausgelegt.

Im Rahmen des Forschungsprojekts KOSMoS entwickeln wir als Teil eines Konsortiums eine Plattform für eine unternehmensübergreifende Vernetzung von Produktions- und Prozessdaten. Eine Herausforderung besteht in der Wahl einer geeigneten Zeitreihen-Datenbank, die es erlaubt, hochfrequente Maschinendaten effizient zu speichern und für analytische Zwecke einfach verfügbar zu machen. Um eine sinnvolle Auswahl treffen zu können, bieten Kriterien wie Beliebtheit oder Verbreitung zwar einen ersten Anhaltspunkt – für eine Entscheidung ist aber ein Vergleich der funktionalen und nicht-funktionalen Merkmale der Systeme notwendig. Daher haben wir uns exemplarisch die beiden quelloffenen Datenbankmanagementsysteme TimescaleDB und InfluxDB im Detail angesehen, die sehr unterschiedliche Lösungskonzepte implementieren.

Evaluation der funktionalen Merkmale

TimescaleDB ist eine Erweiterung (Plugin) der relationalen Datenbank PostgreSQL. Sie nutzt sogenannte Hypertables – eine abstrakte Sicht auf mehrere Tabellen –  und speichert mit Hilfe dieser die Zeitreihen sowohl zeitlich als auch nach Merkmalen segmentiert ab. InfluxDB ist hingegen eine komplette Neuentwicklung mit dem ausschließlichen Ziel des Speicherns von Zeitreihen. Durch ihren Aufbau ist sie nur bedingt für das Speichern von anderen, nicht zeitbezogenen Werten geeignet. Vergleicht man die funktionalen Merkmale der beiden Datenbanken miteinander (siehe Tabelle 1) fallen für unseren Anwendungsfall drei wesentliche Unterschiede auf – das zugrundeliegende Datenmodell, der Umfang an unterstützten Datentypen und die zur Verfügung stehenden Datenmanipulationssprachen.

Relationale Datenmodellierung vs. Tag-Sets

Der relationale Ansatz der PostgresQL wurde für die Datenstrukturen der TimescaleDB beibehalten. Wie in Abbildung 1 skizziert werden die Zeitreihendaten in Tabellen abgespeichert. Die zugehörigen Meta-Informationen der Zeitreihen werden über einen Schlüssel zugeordnet – angedeutet durch den Pfeil in Abbildung 1 –  jedoch nicht direkt in der Tabelle mit den Messwerten abgelegt.

Abbildung 1: Relationales Modell der TimescaleDB (in Anlehnung an [1]).

Bei der InfluxDB werden statt relationaler Strukturen Tag-Sets verwendet, deren Konzept auf sogenannten Measurements basiert (Abbildung 2). Measurements sind in diesem Kontext Tabellen, die für eine bestimmte Messung den Wert, oder auch eine Gruppe von Messungen die Werte, enthalten. Durch ein Tupel von Tags sind die Einträge ununterscheidbar.

Abbildung 2: Aufbau der sogenannten Measurements in der InfluxDB (in Anlehnung an [1]).

Durch einen Einsatz der TimescaleDB sehen wir für ein Projekt im IIoT Umfeld den Vorteil, dass die Verwaltung von relational strukturierten Metadaten in der gleichen Datenbank erfolgen kann.  Das ist nützlich, um beispielsweise Informationen wie Maschinentyp oder Betriebsmittel zu speichern und zur Verfügung zu stellen.  Ohne Mehraufwand kann auch ein Entity-Relationship-Modell implementiert werden, um beispielsweise bei späteren Analysen die Interpretation der Ergebnisse  zu vereinfachen. Bei der Verwendung von InfluxDB muss dagegen für die Verwaltung von Metadaten eine zusätzliche, relationale Datenbank eingesetzt werden.

Datentypen

Beide Datenbanksysteme unterstützen die Datentypen String, Float, Integer und Boolean. Das ist für die meisten Fälle ausreichend, wie beispielsweise bei der Erfassung von Temperaturwerten (Float), Zählern (Integer), Zuständen (Boolean) und Statusupdates (Strings). TimescaleDB unterstützt darüber hinaus viele weitere komplexe Datentypen und ermöglicht dadurch beispielsweise eine flexible Ablage von Datenstrukturen, selbst wenn diese nicht vollständig bekannt sind, etwa JSON Dateien ohne ein bekanntes Schema. Eine gezielte Verarbeitung oder Analyse dieser Daten kann zu einem späteren Zeitpunkt erfolgen.

 TimescaleDBinfluxDB
AbfragesprachenSQLinfluxQL und Flux
Besonderheiten bei den Abfragesprachenklassisches SQL (wichtig: "SORT BY time")erweiterte Funktionen, wie DERIVATIVE, DIFFERENCE, MOVING_AVERAGE, ...
DatentypenInteger
Float
String
Boolean
Timestamp, date, time … AND arrays, JSON blobs, geospatial dimensions, currencies, binary data and customized data types
Integer
Float
String
Boolean
Auflösung ZeitstempelMikrosekundenNanosekunden
ImplementierungsspracheCGo
Zugriffskonzepte [3]ADO.NET
JDBC
native C library
ODBC
streaming API for large objects
HTTP API
JSON over UDP

Tabelle 1: Auswahl von funktionalen Merkmalen der influxDB und TimescaleDB

Abfragesprachen

Auf die Erhebung von Zeitreihendaten folgt in der Regel auch deren Auswertung. Für diese Aufgabe sind zwei wichtige Faktoren zu berücksichtigen – die Mächtigkeit der Abfragesprache und die Abfragezeit. Für den geplanten Einsatz muss bewertet werden, wie wichtig die Mächtigkeit der mitgelieferten Abfragesprache des Systems ist. Reicht der Funktionsumfang der Sprache SQL aus, da die meisten Analysen in weitere Programme (Machine Learning Modelle, Analyse-Skripte, etc.) ausgelagert werden? Oder sollen Analysen möglichst ohne weitere Programme durchgeführt werden? Für diesen Fall liefert die InfluxDB mit ihrer eigenen Abfragesprache Flux dem Anwender einen mächtigen Werkzeugkasten mit zahlreichen bereits vorimplementierten Funktionen. Deutlich wird dieser größere Funktionsumfang unter anderem bei dem Vergleich der Komplexität von umfangreichen Abfragen – siehe identische Beispielabfragen für Flux und SQL unten. Anzumerken ist aber auch, dass die Verwendung von Flux möglicherweise gerade zum Einstieg einen gewissen Lernaufwand mit sich bringt, da die Syntax der Sprache meistens erst erlernt werden muss. Auch oder gerade für Nutzer, die versiert in der Nutzung von  SQL sind.

 

Evaluation der nicht-funktionalen Merkmale

Bei der Wahl einer geeigneten Datenbank spielen nicht nur die funktionalen Merkmale eine Rolle. Auch Kriterien, wie die Performance beim Schreiben und Lesen von Daten, der Bedarf an Ressourcen und die generelle Verlässlichkeit müssten in eine Entscheidung einfließen. Dazu haben wir einige Tests durchgeführt.

Schreiben von Daten

Um verschiedene, beliebig komplexe Testszenarien für die Datenspeicherung abzubilden, generiert ein Skript in unserer Testumgebung eine Sequenz von Zufallszahlen. Variierbar sind die Anzahl erzeugter Werte, die Komplexität der Metainformationen und der Abstand zwischen zwei Zeitpunkten.  Ein Testszenario ist wie folgt aufgebaut:

Es gibt eine Produktionshalle, ausgestattet mit zwei Werkzeugmaschinen.
Jede dieser Werkzeugmaschinen enthält fünf Sensorboxen.
Von jeder Sensorbox werden in einem zeitlichen Abstand von einer Sekunde drei Messwerte erfasst (Temperatur, Zähler und Luftfeuchtigkeit).
Die Tabelle 2 enthält exemplarische Zeitreihen-Daten einer Werkzeugmaschine:

ZeitpunktMaschinenIDSensorboxIDTemperaturZählerLuftfeuchtigkeit
01/04/20 10:00:001120.010.22
01/04/20 10:00:001221.310.23
...
01/04/20 10:00:011120.520.22
01/04/20 10:00:011220.920.23
...

Tabelle 2: Beispiel für erzeugte Zeitreihen-Daten einer Werkzeugmaschine inklusive der Metainformationen.

Dieses Szenario haben wir insgesamt in 5 Durchläufen simuliert und dabei den Speicherbedarf für 100.000, 200.000, 500.000, 750.000 und 1.000.000 Einträge (Zeilen) bestimmt. Die Ergebnisse des Speicherbedarfs sind in Abbildung 3 gegenübergestellt.

Abbildung 3: Speicherbedarf der Datenbanken InfluxDB und TimescaleDB im Szenario mit zwei Werkzeugmaschinen.

Es wird deutlich, dass die TimescaleDB im Schnitt mehr Speicher als die influxDB verbraucht – im beschriebenen Testszenario immerhin durchschnittlich 57% mehr.

Neben dem Speicherbedarf ist auch die zur Verfügung stehende Rechenleistung der eingesetzten Hardware ein weiteres Kriterium für die Wahl eines geeigneten Datenbank-Managementsystems. Im Bereich Industrie 4.0 können die Ressourcen von einem leistungsstarken Cluster in der Cloud bis hin zu einem einfachen Industrial Edge Device variieren. Während der Durchführung des obigen Testszenarios hat sich gezeigt, dass die TimescaleDB teilweise bis zu 50% weniger Arbeitsspeicher verwendet und hierdurch – zumindest während unserer Tests – bezüglich Out-of-Memory-Fehlern beobachtbar weniger anfällig ist. Natürlich können die entsprechenden Ressourcen einfach erhöht und dieses Kriterium somit unnötig gemacht werden. Besteht aber eine wie zuvor erwähnte Limitierung der Rechenleistung, muss dieses Kriterium unbedingt in die Auswahl einer Datenbank mit einfließen.

Lesen von Daten

Wie bereits im Abschnitt funktionale Merkmale beschrieben, sollten die Abfragesprachen die Anforderungen an die Mächtigkeit des Sprachumfangs erfüllen – abgeleitet vom jeweiligen Anwendungszweck. Als weiteres Kriterium spielt die Abfragezeit eine große Rolle. Wie lange braucht beispielsweise die Datenbank um eine Tabelle vom Umfang \(N\) mit bestimmter Komplexität \(K\) zu aggregieren? Um die beiden Datenbank-Managementsysteme in diesem Punkt zu testen, haben wir aufbauend auf den erzeugten Daten aus dem vorherigen Testszenario zwei exemplarische Abfragen geschrieben. Die erste Abfrage liefert die durchschnittlichen Messwerte für alle Maschinen ID und Sensor ID Tupel über den gesamten Erfassungszeitraum. Die zweite Abfrage baut auf der ersten Abfrage auf und ist um ein Clustering in fünf Minuten Intervalle erweitert. Der Vergleich der gemessenen Abfragezeiten von TimescaleDB und InfluxDB hat gezeigt, dass sich diese im Durchschnitt nicht bemerkbar voneinander unterscheiden.

Abbildung 4: Abfragezeiten in Sekunden für die beiden durchgeführten Abfragen (1 und 2).

Zusammenfassung

Betrachten wir noch einmal die gesamte Evaluierung, können wir zusammenfassend sagen:

Flexibilität

  • Für das einfache Ablegen von (zeitabhängigen) Messreihen ist die InfluxDB eine einfache Möglichkeit, ohne hohen Aufwand für ein relationales Design.
  • Fallen aber neben den einfachen Messreihen komplexere Daten und Metainformationen an, sollte für eine bessere Strukturierung zu einer Lösung wie der TimescaleDB gegriffen werden.

Abfragesprachen

  • InfluxDB bietet hier durch die Abfragesprache Flux ein mächtiges Werkzeug für Abfragen.  Jedoch ist der mögliche Mehraufwand für das Lernen der Sprache zu berücksichtigen.
  • Anders bei der TimescaleDB. Diese kommt mit der klassischen Sprache SQL, welche vielen Entwicklern und Data Scientist bekannt ist und dadurch einen schnellen Einstieg ermöglicht. Der Sprachumfang wird durch spezifische Funktionen für die Analyse von Zeitreihen ergänzt.

Arbeitsspeicher, Datenspeicher und Performance

  • TimescaleDB verbraucht im Vergleich zu InfluxDB weniger Arbeitsspeicher. Hierdurch ist auch ein Einsatz auf schwächeren Geräten (Edge-Devices, Embedded Systems, …) möglich.
  • TimescaleDB verbraucht gegenüber InfluxDB in den Test im Durchschnitt 57% mehr Datenspeicher.
  • InfluxDB und TimescaleDB unterscheiden sich zeitlich bei der Durchführung von Abfragen nicht merklich.

 


Die Inhalte dieser Arbeit stammen aus dem Projekt KOSMoS – Kollaborative Smart Contracting Plattform für digitale Wertschöpfungsnetze. Dieses Forschungs- und Entwicklungsprojekt wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Programm „Innovationen für die Produktion, Dienstleistung und Arbeit von morgen“ (Förderkennzeichen 02P17D026) gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autor:innen.

 

Quellen

[1] https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/, aufgerufen am 29.7.2020

[2] https://blog.timescale.com/blog/sql-vs-flux-influxdb-query-language-time-series-database-290977a01a8a/, aufgerufen am 29.7.2020

[3] https://db-engines.com/de/system/InfluxDB%3BTimescaleDB, aufgerufen am 29.7.2020