Daten im Fluss

von Ariane Rüdiger

Das Industrial Internet of Things, kurz IIoT, lebt von der Verfügbarkeit und Auswertbarkeit von Daten durch Algorithmen aus KI und ML. Doch weil es sich um sehr unterschiedliche Datentypen und sehr oft zumindest partiell um Echtzeitanforderungen handelt, reichen traditionelle Datenbanken hier nicht aus. Wir werfen einen Blick auf die speziellen Anforderungen an DB-Systeme im IIoT und stellen geeignete Datenbanktypen und Produkte vor.

Laut Mordor Intelligence haben inzwischen 87 Prozent der Entscheidungsträger in der Fertigungsbranche die IIoT-Technologie bereits eingeführt [1]. Diese Entscheider bewerten IIoT als wesentlichen Erfolgsfaktor. Unternehmen versprechen sich davon unter anderem weniger Ausfallzeiten, bessere datengesteuerte Entscheidungen und mehr Gewinn. Typische Anwendungen sind zum Beispiel das Asset Tracking, die Erhöhung der Lebensdauer der teuren Fertigungssysteme und Remotewartung, also weniger Vor-Ort-Einsätze.

Allerdings geht nicht jedes IoT-Projekt gut. Der Systemintegrator HMS, der auf (I)IoT im Maschinenbau spezialisiert ist, nennt in einem Whitepaper den unterschätzten Implementierungsaufwand als wesentlichen Grund des Scheiterns. Voraussetzung für das Gelingen von IIoT-Projekten ist unter anderem die Verfügbarkeit von ausreichend vielen und ausreichend vielfältigen Daten sowie geeigneten Aufbewahrungs- und Analyseinstrumenten für diese Daten. Hier stoßen konventionelle SQL-Datenbanken schnell an ihre Grenzen.

Spezialisierte IIoT-Anforderungen

Bei IIoT-Projekten fällt eine große Menge an Daten an – je nachdem wie viele Maschinen überwacht, wie viele Datenpunkte je Maschine ermittelt werden und wie oft das geschieht. Das kann bei mehreren Produktionsstandorten und Maschinenstraßen recht schnell in sehr vielen Informationen resultieren . Dazu sind die Daten meistens unstrukturiert. Sensordaten etwa werden häufig als verschachteltes JSON-Dokument gespeichert.

Geht es um die Ortung von Gegenständen, kann es sein, dass geostationäre Koordinaten gespeichert und ausgewertet werden müssen. Dazu kommen Zeitreihen, die Prozesse verfolgen. Die einzelnen Datenpunkte tragen hier Zeitstempel, die ebenfalls in die Auswertung einfließen.

Viele dieser Datentypen laufen kontinuierlich in kleinen Mengen als Datenstrom (Streaming) ein. Die Softwarewerkzeuge zu ihrer Handhabung müssen mit diesen Streams fertig werden und natürlich müssen sie sich auch gut in bestehende Infrastrukturen integrieren.

Außerdem müssen Datenbanken für IIoT-Umgebungen schnell skalieren: Wird eine weitere Fertigungsstraße gebaut, soll diese samt aller von ihr erzeugten Daten natürlich auch sofort in eine bestehende IIoT-Umgebung integriert werden. Das bedeutet Massen neuer Daten. Wenn hier die Skalierung schwierig und langwierig und die Kosten hoch sind, bedeutet das einen Verlust an Profitabilität. Auch die Möglichkeit, eine Zeitreihen-Datenbank zu verteilen und die Fähigkeit einer verteilten Architektur, tatsächlich parallel ohne Leistungseinbußen zu funktionieren, gelten als Kernanforderung, um mehr Performance und Ausfallsicherheit zu garantieren.

Resilienz und hohe Verfügbarkeit sind wichtige Anforderungen. Denn das IIoT-System soll auch bei Ausfall eines Servers oder einer Maschine weiterlaufen und Ausfälle der IT-Hardware sollen nicht dazu führen, dass unzählige Daten verloren gehen, weil nichts sie speichern kann. Nützlich ist nicht zuletzt die Fähigkeit, möglichst viele oder auch mehrere Datentypen parallel speichern zu können.

Daten oft am Edge

Weiter verkompliziert sich die Situation dadurch, dass häufig Daten am Edge entstehen und auch direkt dort entweder an oder in der überwachten Maschine oder in einem nahe zum Entstehungsort befindlichen Edge-Datacenter analysiert werden müssen. Das gilt beispielsweise, wenn es um einen sofortig steuernden Eingriff bei plötzlichen Fehlfunktionen geht, die über vedächtige Messwerte auf sich aufmerksam machen.

Daraus ergeben sich spezielle Anforderungen für Datenspeicherung und -analyse: einerseits die Fähigkeit der Tools, mit den schnell einlaufenden, in der Regel kleinen Datenpaketen fertig zu werden, andererseits ein relativ schmales Format der jeweiligen Datenbank. Denn am Edge stehen in der Regel weitaus weniger Ressourcen bereit als in zentralen Rechenzentren.

IIoT-Systeme müssen Daten, die Sensoren oder andere Elemente der Anlagenüberwachung erzeugen, zusammenbringen. Sie müssen diese unter Umständen mit anderen Daten aus der Bestell-, der Material-, der Reparatur- oder einer sonstigen Datenbank anreichern. Diese liegen meist in konventionellen SQL-Datenbanken. Das erfordert Integrationsmöglichkeiten, die möglichst nicht erst vom Anwender individuell entwickelt werden sollten.

ACID nicht unbedingt erforderlich

Da IoT-Sensordaten oder -Messreihen üblicherweise nicht in datenbankübliche Transaktionen eingebunden sind und teilweise auch nach einer relativ kurzen Frist weiterverarbeitet oder gelöscht werden, sind manche Anforderungen sogar weniger streng. Das gilt für die Transaktionssicherheit, definiert im ACID- oder AKID-Modell (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit). Allerdings gibt es inzwischen auch Datenbanklösungen für IIoT, die Transaktionssicherheit bieten.

Auf jeden Fall müssen Anwender aber ein passendes Betriebsmodell wählen: Wollen sie ihre IIoT-Datenbank oder -Datenbanken selbst betreiben oder lieber von außen als Service beziehen? Eine Alternative sind Datenbankservices (DBaaS) der großen Cloudbetreiber immer dann, wenn entweder der Invest in eine eigene Infrastruktur zu hoch oder die Kritikalität und der Sicherheitsbedarf der betroffenen Daten niedrig genug ist, um sie aus der Hand zu geben. Heute gibt es viele Datenbankprodukte, neben einer On-Premises-Variante auch als DBaaS. Bei den bekannteren haben Anwender meist auch die Wahl zwischen unterschiedlichen Betreibern.

Es folgen IoT-geeignete Datenbanktypen mit der kurzen Beschreibung einiger Produktbeispiele aus der jeweiligen Kategorie. Welcher Datenbanktyp und welches Produkt IT-Verantwortliche letztlich wählen, ist sehr individuell. Denn jedes Einsatzfeld ist anders. Es gilt also genau über die Detailanforderungen und deren Passung mit den von einem Datenbankprodukt angebotenen Features nachzudenken, um Fehlinvestitionen und teure Wechsel der Datenbankinfrastruktur zu vermeiden.

No-SQL-Datenbanken

NoSQL steht für "nicht/nicht nur SQL" und bedeutet verteilte Datenbanken, denen kein Tabellenschema und kein relationales Modell zugrunde liegt. Schemata und Relationalität beschränken die Leistungsfähigkeit von Datenbanken, was sich besonders bei der Indexierung großer Datenmengen oder beim Umgang mit Streaming-Daten bemerkbar macht. Wenn viele und kleine Datenmengen geschrieben werden müssen, gibt es hier häufig Schwierigkeiten. Genau dieses Thema wird aber bei IIoT virulent.

NoSQL-Datenbanken haben genau bei solchen Einsatzszenarien ihre Stärken, was allerdings auf Kosten der Konsistenz geht. Sie muss meist über zusätzliche Softwarekomponenten hergestellt werden. Die meisten Datenbanken, die in IIoT-Umgebungen Verwendung finden, sind NoSQL.

Es gibt verschiedene Varianten von NoSQL-DBs, je nachdem, welche Datenformate und Auswertemechanismen zum Einsatz kommen. Eine wichtige sind die dokumentenorientierten Datenbanken. Jedes Dokument erhält hier einen eindeutigen Identifikator (Schlüssel), über den es sich in jedem Fall finden lässt, und steht in einer Zeile der Datenbank (Schlüssel-Wert-Schema). Anders als in reinen Key-Value-Stores sind die Dokumente aber veränderbar. Dokumente können alles sein: Bilder, Texte, Videos, BLOBs et cetera. In der Regel speichern derartige Datenbanken Dokumente semistrukturiert, etwa in JSON, YAML oder XML. Eine Normalisierung der Daten erfolgt in der Regel nicht.

Wichtige Beispiele aus diesem Bereich sind MongoDB [2] und CouchDB [3]. Beide entstanden im Open-Source-Bereich. MongoDB nutzt für Dokumente das BSON-Format, ein um weitere Datentypen erweitertes JSON, CouchDB JSON. Die Abfrage von CouchDB erfolgt über HTTP-REST, MongoDB hat eine eigene Abfragesprache entwickelt. Letztere ist zudem transaktionssicher. Allerdings stellt MongoDB die Datenbank nur noch sehr eingeschränkt kostenlos zur Verfügung, die freie Variante steht zudem auf einem älteren Versionslevel und wurde in letzter Zeit nicht mehr aktualisiert – nicht ganz unüblich bei sich kommerzialisierenden Open-Source-Playern.

Inzwischen hat sich deshalb mit dem Startup Ferret [4] ein Unternehmen gebildet, das eine voll zu MongoDB kompatible, selbst programmierte Datenbank nach Open-Source-Standard anbietet. Zudem hat Ferret vor nicht allzu langer Zeit mit einigen Mitstreitern die Non-Profit-Organisation "Open Doc Database Initiative" gegründet. Ziel der Organisation ist es, einen offenen Basisstandard für Dokumentendatenbanken als Basis kommerzieller Produkte, vergleichbar mit SQL für strukturierte Datenbanken, zu entwickeln.

Exemplarisch ist auch das ursprünglich quelloffene Elasticsearch [5], das mit JSON-Format und RESTful-Webschnittstelle arbeitet. Jeder Index bei Elastic wird in Stücke geteilt und verteilt. Das Haupteinsatzgebiet sind Suchen im hochverfügbaren Rechnerverbund. Inzwischen wird aber auch hier für die Cloudnutzung eine Lizenz benötigt, weshalb sich OpenSearch als offenes Nachfolgeprojekt gebildet hat. Mit dabei sind AWS, Red Hat, SAP und Capital One. Weitere Beispiele aus dem Feld dokumentenorientierter Datenbanken sind RavenDB [6] oder BaseX {7].

Graph-Datenbanken

Graph-Datenbanken, ebenfalls eine Form von NoSQL-Datenbanken, stellen Beziehungen zwischen Daten grafisch in Form von Diagrammen dar. Sie sind bei IIoT-Anwendungen nützlich und verbreitet, beispielsweise um die Zusammenhänge zwischen Ereignissen oder Objekten zu analysieren und darzustellen oder Muster zu vergleichen. So könnte eine solche Datenbank erkennen, welche Komponente bei einer immer wieder auftretenden Störung die Ursache bildet. Andere Beispiele sind die Berechnung des optimalen Wegs von Gütern durch die Produktionshalle, oder die Optimierung des Verlaufs von Versorgungsleitungen.

Graph-Funktionen werden gelegentlich an andere Datenbanken angeflanscht. So besitzt auch Apache Spark mit GraphX [8] eine Funktion, mit der sich Graphen auf Spark-Daten erzeugen lassen. Daneben stehen Standalone-Produkte. Sehr bekannt ist neo4j [9], derzeit in Version 2025.03.0 erhältlich. Die Open-Source-Software gibt es kommerziell als AuraDB [10]. Das System basiert auf Knoten und Kanten, die Knoten verbinden. Die kostenlose Version ist inzwischen begrenzt auf einen Knoten, was in der Branche Kritik hervorgerufen hat. Der Hersteller hat mit Cypher eine eigene, grafisch orientierte Abfragesprache entwickelt und Open-Source gestellt, was natürlich dem Produkt zu mehr Marktvolumen verhelfen soll.

Eine Alternative ist Arango DB [11]. Die Datenbank erlaubt Graphen-, Vektor- und Volltextsuche und reklamiert für sich eine besonders hohe Flexibilität. Auch unterschiedliche Datenzugriffsstrukturen werden unterstützt. Freunde der Cloud können Amazon Neptune wählen. Die hochskalierbare Graph-Datenbank arbeitet serverless, Anwender haben mit der Infrastruktur gar nichts mehr zu schaffen. Sie mieten lediglich die Funktion. ArangoDB ermöglicht bis zu 15 Lesereplikate auf demselben Speicher, was die Leseleistung erhöht. Die Datenbank ist hochverfügbar und hat vielfältige Sicherheitsfunktionen.

Von Ontotext stammt GraphDB [12]. Mit diesem Produkt lassen sich Daten über ein gemeinsames konzeptionelles Modell vereinheitlichen. Fehlinterpretationen werden mittels formeller Semantik vermieden. GraphDB ermöglicht Anwendern, ihre Datenqualität aktiv zu verwalten und die Herkunft aller Daten zurückzuverfolgen. Eine Reasoning-Funktion entdeckt neue Beziehungen zwischen Daten. Die RDF-Engine (Ressource Description Framework) wurde mit der LDBC Social Network Analysis Benchmark geprüft. Diese Benchmark wurde eigens für die Analyse von großen Graphen auf parallelen und verteilten Plattformen entwickelt.

Zeitreihen-Datenbanken

Eine wichtige Rolle spielen bei IIoT Zeitreihen-Datenbanken, da Steuerungsvorgänge meist eine Zeitkomponente haben und Prozesse Vorgänge in der Zeit sind. Sie gehören zu den spaltenorientierten NoSQL-Datenbanken. Gespeichert werden Zeitstempel, Wert und Metadaten, so gewünscht. Die Indexierung erfolgt über den Zeitstempel. Diese Datenbanken sind für zeitbezogene Abfragen optimiert und können etwa dauerhaft über einen bestimmten Zeitraum Mittelwerte berechnen.

Auch hier gibt es viele offene Produkte, etwa Prometheus [13], das vor allem zum Servicemonitoring und für Echtzeitbenachrichtigungen in der IT-Überwachung zum Einsatz kommt. Im industriellen Bereich sind beispielsweise CrateDB [14] und InfluxDB [15] beliebt, auch Time-scaleDB [16] gehört zu den geläufigeren Produkten.

Influx DB befindet sich derzeit in Version 3.0. Die Software besteht aus den vier relativ unabhängigen Komponenten Data Ingest, Data Querying, Data Compaction und Garbage Collection. Metadaten werden in einem Katalog gespeichert, die Daten in einem S3-Objektspeicher. Kleinere Write-Ahead-Logs dienen dazu, Daten im Fall eines Crashs an die Ingestion zu übergeben. Daten werden partitioniert, dedupliziert und vom System selbständig zugeordnet. Das System validiert sie während des Schreibens und bewahrt sie als Parquet-File auf. Kleine Dateien werden vom Compactor zu größeren zusammengeführt, um die Speicher- und Abfrageeffizienz zu verbessern. Bei Anfragen versteht InfluxDB auch SQL und greift auch auf noch nicht persistente Daten und den Cache zurück.

CrateDB unterstützt vielfältige Datentypen, darunter Geodaten und Fließkomma-Vektoren. Die Datenbank löst sich von der reinen Fokussierung auf Zeitreihen, bleibt diesem Bereich jedoch weiterhin verbunden. Volltext- und Vektorsuche sind möglich, die Indexierung erfolgt automatisch, Abfragen laufen über natives SQL. Die Zeitauflösung ist geringer als bei InfluxDB: Millisekunden statt Nanosekunden.

Edge-Datenbanken

Wie erwähnt, müssen Datenanalysen aus Bandbreitengründen im IIoT sinnvollerweise oft direkt am oder in der Nähe des Netzwerkrandes erfolgen. Das erspart große Datenübertragungskapazitäten und sorgt für schnellstmögliche Reaktion. Auch hierfür sind inzwischen spezielle Datenbanken entstanden.

Das derzeit marktführende Beispiel ist Azure IoT Edge [17] von Microsoft – lesen Sie dazu auch unseren Artikel auf Seite 78. Die Software kann in einem einzigen Container untergebracht werden und passt daher zu jedem Edge-Device. Sie integriert Zeitreihen und Datenstreaming-Fähigkeiten. Edge bringt weiter analytische Fähigkeiten mit und kann mit Graphen arbeiten. ARM- und x64-Architekturen werden genauso unterstützt wie Windows, Linux und Kubernetes. Die Engine ist dieselbe wie bei Azure SQL. Zu den Sicherheitsmechanismen gehören Datenmaskierung und ständige, transparente Verschlüsselung.

Weitere Beispiele für Zeitreihendatenbanken sind Gel, früher EdgeDB, Harper, SQLite und Realm. EdgeDB arbeitet mit PostgreSQL. Allerding wurden die wesentlichen Systemkomponenten neu entwickelt. Die Version 1.0 kam nach jahrelanger Entwicklung im Jahr 2022 auf den Markt. Dadurch soll die Datenbank wesentlich besser mit der verteilten Natur von Datenquellen und Abfragen zurechtkommen beispielsweise in IIoT-Umgebungen.

Stream-Verarbeitung

Die Handhabung verschiedener, in eine IIoT-Lösung einlaufender Datenströme übernehmen heute häufig Streaming-Frameworks, die speziell für diese Aufgabe entwickelt wurden. Grundprinzip dieser Softwaresysteme ist es, zahlreiche Datenquellen und -senken über sogenannte Datenpipelines zu verbinden. Diese Datenpipelines definieren, was mit den einlaufenden Daten geschieht, wer sie erhält und wie sie verarbeitet werden.

Das wohl bekannteste derartige Produkt ist Apache Kafka [18]. Ursprünglich von LinkedIn entwickelt, wurde die Software 2012 an die Apache Foundation übergeben. Im Kern von Kafka steckt ein verteiltes Transaktions-Log: Ein Cluster aus Brokern speichert Schlüssel-Wert-Nachrichten und dazugehörige Zeitstempel in Topics, die zusammengehörige Daten enthalten. Die Topics werden in Partitionen unterteilt, repliziert und im Cluster verteilt. Nachrichten werden in der Schreibreihenfolge gespeichert und Abfragen erfolgen ohne Arbeitsspeicher direkt über den Netzadapter von der Festplatte. Wer Daten in den Cluster schreibt, ist ein Producer, wer Daten daraus abfragt, ein Consumer.

Mit der Verarbeitungssoftware Streams lässt sich in Kafka sogar Transaktionssicherheit herstellen, denn Nachrichten dürfen hier nur genau einmal verarbeitet werden. Nachrichten lassen sich für eine Woche oder unlimitiert speichern. Neue Nachrichten, die alte aktualisieren, werden unter demselben Schlüssel gespeichert. Die neueste Nachricht ist nicht löschbar. Kafka liefert APIs für Producer, Consumer, Drittsysteme und Datenströme. Confluent heißt die wichtigste kommerzielle Umsetzung von Kafka.

Apache Flink [19], ein weiteres Open-Source-Streaming-Framework, beherrscht außer der Stream- auch die Batchverarbeitung. Die Software kann also Datenstapel und Datenströme parallel verarbeiten und deshalb mehrere Aufgaben gleichzeitig bewältigen. Außerdem unterstützt sie nativ die Ausführung von Näherungsalgorithmen.

Apache Spark [20] eignet sich ebenfalls zur Verarbeitung von Streaming-Daten, ist allerdings in erster Linie ein Framework für Cluster Computing. Die zugrunde liegende Datenstruktur basiert auf nach logischen Regeln gebildeten Teildatenbeständen, sogenannten RDD (Resilient Distributed Dataset). Diese werden über mehrere Clusterknoten verteilt. Die RDDs können aus externen oder internen Quellen durch Umformungen gewonnen werden. Mit Spark SQL lassen sich RDDs in Dataframes verwandeln, die wiederum mit SQL durchsucht werden können. Spark Streaming unterteilt Streams in einzelne Datenströme. Mit der Bibliothek SparkML kann die IT aus Spark heraus auf ML-Algorithmen zugreifen.

Fazit

Wer IIoT-Umgebungen aufbaut, braucht für eine erfolgreiche Implementierung unbedingt die richtige Datenbank. Die Auswahl ist inzwischen groß und unübersichtlich. Eine sorgfältige Definition der individuellen Anforderungen ist daher genauso wichtig wie eine detaillierte Analyse der Produktfähigkeiten. Andererseits ist die Auswahl an Open-Source- und kommerziellen Produkten mit teils hochspezialisierten Fähigkeiten inzwischen so groß und differenziert, dass das Richtige für jede Applikation dabei sein dürfte. Wer hier Sorgfalt walten lässt, hat eine erhebliche Fehlerquelle für sein IIoT-Projekt vermieden.

Die richtigen Datenbanken für IIoT

Daten im Fluss

Spezialisierte IIoT-Anforderungen

Spezialisierte IIoT-Anforderungen

Daten oft am Edge

ACID nicht unbedingt erforderlich

No-SQL-Datenbanken

Graph-Datenbanken

Zeitreihen-Datenbanken

Edge-Datenbanken

Stream-Verarbeitung

Fazit