Time Series Database: A More Technical Approach

Aber auch in der Industrie haben die M2M-Networks Einzug gehalten. Fertigungslinien, die mit Sensortechnik die Qualität der Produkte überwachen und automatische Temperaturregler sind hier nur zwei Beispiele. Ein Ziel des IoT ist eine intelligente Automatisierung der Kommunikation der Geräte untereinander auf Basis von detailliert gewonnenen Daten. Aber nur Auslesen und Abspeichern der Daten genügt nicht. Man muss die Daten auch auswerten und Schlüsse daraus ziehen. Durch die Eigenart, dass die Daten dauerhaft erhoben werden und im Sekunden- oder Millisekundentakt entstehen, sind diese produzierten Datenmengen schnell unübersichtlich und für klassische relationale Datenbanken nicht mehr gut handhabbar. Darum wird hier auf das Konzept der Time Series Databases (TSD) ausgewichen, deren Konzepte eine bessere Alternative darstellen. (Anmerkung: Dieser Artikel bezieht sich insbesondere auf spaltenorientierte Time Series Databases, die in einem Netzwerk vorliegen.) Time Series Datenbanken sind auf den Datentyp der Zeitreihendaten optimiert. Insbesondere wenn sehr viele Maschinen sensorüberwacht und gesteuert werden, hat man es mit parallel laufenden Datenströmen zu tun, die mehr oder weniger gleichzeitig anfallen. Ein Datensatz beinhaltet typischerweise einen Zeitstempel, den gemessenen Wert und etwaige Metainformationen – sogenannte „Tags“. Diese Datenströme müssen verwaltet werden und hierfür werden TSDs gerne eingesetzt. Im Gegensatz zu relationalen Datenbanken, die mit SQL arbeiten, werden TSDs anders angesprochen. Da es sich um ein nicht-relationales Datenbankkonzept handelt, findet SQL mit seinen select-from-where-Abfragen keine Anwendung. Bei TSDs wird mit NoSQL gearbeitet.

Zum Einstieg ein wenig SQL… Die Structured Query Language ist die geläufigste Abfragesprache für relationale Datenbanken. Die Basisabfragen sind etwa insert (Daten einfügen), update (Daten updaten), delete (Daten löschen) und select (Daten auswählen und lesen). Eines der Grundkonzepte ist die Redundanzfreiheit, also dass Daten nur einmal angelegt werden (um sie ggf. auch nur einmal ändern zu müssen). Dadurch ist es nötig, Tabellen mithilfe von Joins (kombinierte Datenstrukturen aus mehreren Untertabellen) zu verknüpfen, um die benötigten Informationen aus der Datenbank herausziehen zu können. Komplexe Joins gehen allerdings zu Lasten der Laufzeit, weswegen nicht selten bewusst Redundanzen in Kauf genommen werden. Im Vergleich zu SQL-Datenbanken (relational) werden bei NoSQL-Datenbanken durchaus viele Redundanzen geduldet, um die Performance zu verbessern. Häufig liegen Teile der Datenbank mehrfach in verschiedenen Knoten des Datenbanknetzwerks vor. Das zeigt, dass die Verfügbarkeit der Daten in NoSQL-Systemen wichtiger ist als deren Konsistenz. Durch diese Redundanzen erhält man eine erhöhte Geschwindigkeit, besonders für die unzähligen Schreib- und Lesevorgänge. Die Geschwindigkeit wird zusätzlich durch Indizierung der Datensätze mittels Hashtabellen verbessert. Auch diese können redundant in verschiedenen Knoten des Netzwerks vorliegen, was eine erhöhte Ausfallsicherheit zur Folge hat. Der Hauptunterschied zwischen SQL- und NoSQL-Datenbanken liegt also in der wesentlich erhöhten Schreib- und Lesegeschwindigkeit von NoSQL. Vor dem Hintergrund der Menge der eingehenden Daten ist das sehr nützlich. Dies geht aber auf die Kosten von Änderungsanfragen. Diese werden in Time Series Databases aber nur sehr selten gebraucht.

Viele der Konzepte, die bei TSDs genutzt werden, werden besonders deutlich, wenn man sich die Arbeitsweise an einem Beispiel ansieht. Nehmen wir eine Smart-Home-Anwendung oder -Applikation , die Temperatur, Beleuchtung und Musik eigenständig steuern kann. Um die Temperatur zu regulieren, müssen in kurzen Zeitabständen Messungen der Raumtemperatur vorgenommen werden, damit gegebenenfalls gegengesteuert werden kann. Die Beleuchtung läuft vielleicht über Bewegungssensoren, die in regelmäßigen Abständen abgefragt werden, damit das Licht auch tatsächlich angeht, wenn der Raum betreten wird. Musik wird in aller Regel per Sprachsteuerung angefragt, wobei auch hier dauerhaft überwacht werden muss, ob eine Anfrage gestartet wird. Wenn die so im Laufe der Zeit vorliegenden Daten analysiert werden, kann das System eigenständig Regeln zur Regulierung (z. B. der Raumtemperatur) anlegen: Aufheizen vor dem Aufstehen und bevor man von der Arbeit nach Hause kommt, kühler dazwischen. Eine sehr wichtige Funktion der TSD ist die Kompression von Daten. Da die Menge der Daten schnell in die Petabytes geht, ist eine gute Kompression unerlässlich. Gängige Kompressionsalgorithmen sind hierbei die Integer Compression und die Data Agnostic Compression. Die TSDs sind nicht auf ein festes Datenschema angewiesen, stattdessen sind sie so konzipiert, dass Datenschemata sehr flexibel sein dürfen. Das macht die Entwicklung und Implementierung neuer Anwendungen vergleichsweise einfach. Auch inkonsistente Daten werden zugelassen, d. h. die Datensätze dürfen in verschiedenen Typen und Formaten vorliegen. Zwischen den Datensätzen besteht nur eine Beziehung, wenn sie aus der gleichen Quelle stammen, darum ist keine Verwaltung dieser Beziehungen notwendig. Insgesamt gibt es zwar sehr viele Dateneinträge von sehr vielen Quellen, aber die einzelnen Einträge sind recht klein. Das Einlesen erfolgt sequenziell und in der realen zeitlichen Reihenfolge, in der sie generiert werden.

Aber wozu der ganze Datenzauber? Die wohl prominenteste Anwendungsmöglichkeit ist das Internet of Things (IoT). Speziell in Optimierung und Wartung von Abläufen, aber auch in der Vorhersage und Nachverfolgung saisonaler Muster oder wiederkehrender Ereignisse kann diese Technologie eingesetzt werden. Als Beispiele kann man die Überwachung einer Fertigungsanlage, das Echtzeit-Tracking eines Fuhrparks sowie die Nutzung in der Analyse und Vorhersage des Einkaufsverhaltens von Kund*innen nennen, also ganz unterschiedliche Fragestellungen. Die Stärken der TSDs lassen sich vor allem in Bereichen ausspielen, in denen sehr viele Daten gleichzeitig in sehr kurzen Intervallen entstehen – u. U. mit nicht ganz gleichförmigen Strukturen (Datentypen) – und eine Analyse gewünscht ist. Bei sehr strukturierten und standardisierten Anwendungen sind relationale Datenbanken häufig effizienter. Hier kann man beispielweise Personalmanagement und Lohnabrechnung nennen.

Im Vergleich zur relationalen Datenbank kann die TSD wesentlich besser mit großen Datenmengen und auch mit sehr vielen Inputstreams aus unterschiedlichen Quellen umgehen. Darüber hinaus bringen etliche marktübliche TSD-Lösungen Analysetools mit, sodass die Auswertung der erhobenen Daten vereinfacht wird. Das Internet of Things mit seinen unzähligen Anwendungsfällen bietet hier sehr viele Möglichkeiten eben diese Freiheiten und Stärken der TSDs auszunutzen.

Konsistenz: Beschreibt den Zustand, dass alle Clients zur gleichen Zeit die gleichen Daten sehen können. Verfügbarkeit: Beschreibt akzeptable Antwortzeiten. Skalierbarkeit: Änderung von Ressourcen und Anordnung der Inhalte je nach Anspruch (kann über die Zeit auch wechselnd sein). Hierbei wird in 3 Datendimensionen unterschieden, die skaliert werden können: Menge der Daten, Größe der Abfragen und Anzahl der Abfragen. NoSQL: „Not only SQL” bezeichnet das Konzept einer spaltenorientierten nicht-relationalen Datenbank. Skalierung erfolgt horizontal, wird auch als structured storage bezeichnet. Horizontale Skalierung (Upscaling): Vergrößerung der Ressourcen durch Hinzufügen von Speicher Vertikale Skalierung (Outscaling): Vergrößerung der Ressourcen durch Hinzufügen von Knoten im Netzwerk Hashtabelle: Datenstrukturen, mit denen man Datensätze indizieren kann.