© ZinetroN/Shutterstock.com
Time Series Databases – die Datenbank der Dinge

Neue Probleme, neue Lösungen


Das Aufkommen des Internets der Dinge hat die IT-Landschaft durch die Bank verändert: Ein Bereich, in dem massive Neuerungen auftreten, betrifft die für das „Entgegennehmen“ der Datenflut notwendigen Datenbanken. In diesem Artikel möchten wir erste Überlegungen zu Time Series Databases anstellen.

Zur Motivation möchte der Autor den Leser ins Jahr 1958 entführen: Eine der damals brandneuen Tupolev-104A-Düsenmaschinen geriet (Stichwort: The Grab) aufgrund eines kleinen Konstruktionsfehlers außer Kontrolle. Der diensthabende Kapitän wies sein Personal geistesgegenwärtig dazu an, bis zum Einschlag in die kalte russische Erde, Informationen über den Flugzeugzustand per Funk ans Headquarter zu liefern. Diese ermöglichten dem KoB schließlich, das Höhenruder umzukonstruieren und zukünftige Abstürze zu vermeiden. Lektion dieser kleinen Heldenerzählung ist, dass das Haben bzw. Nichthaben von Informationen in vielerlei Bereichen – denken Sie beispielsweise an Predictive Maintenance – über Erfolg und Fehlschlag eines Systems entscheiden kann.

Analog zur Digitalfotografie gilt dabei, dass ein „Mehr“ an Daten – insbesondere bei automatischem Training der Informationen der ML-Modelle – immer auch zu einem „Mehr“ an Datenqualität führt. Gestört wird dieser Zusammenhang durch die extrem hohe Leistungsfähigkeit moderner Sensormikrocontroller: Selbst der (nach Meinung des Autors nicht wirklich empfehlenswerte) Raspberry Pi Pico ist in der Lage, mit seinen vier AD-Wandlern bis zu 4 MB an Informationen zu liefern. Wenn man sich nun ein System mit mehreren Dutzenden oder gar hunderten Sensoren vorstellt, ist klar, dass gewöhnliche Datenbanken hier schnell an ihre Grenzen kommen. Denkt man dann noch daran, dass in diesen vier Megabyte 4 x 500 000 Punkte unterkommen, wird das Problem noch deutlicher.

Ein neues Datenbankmodell muss her

Klassische relationale Datenbanken stehen den Bedürfnissen des Internet of Things nicht gut vorbereitet gegenüber. Ursache dafür ist, dass SQL und Co. an sich für das Abbilden von Datensätzen vorgesehen sind, die eine Beziehung zueinander aufweisen. So ist Schlomo Normalentwickler beispielsweise ein Vielflieger, der am liebsten am Flughafen Sarmellek in die VIP-Lounge geht. Turbinendaten haben für derartige Informationen nicht wirklich bzw. nur geringe Priorität; wichtiger ist, dass die Turbine zum Zeitpunkt XYZ so und so viel Prozent Drehzahl aufwies und so und so viele Vibrationen produzierte. Time Series Databases sind Systeme, die auf das Vorhalten derartiger Informationen optimiert sind. Das vergleichsweise einfache Design der Datenhaltung ermöglicht den Entwicklern dann, aggressiv zu skalieren. Es handelt sich dabei witzigerweise um kein wirklich neues Konzept, solche Datenbanken bzw. ihre Grundidee gibt es schon seit langer Zeit.

Neu ist vor allem, dass diesbezügliche Datenbanksysteme im Laufe der letzten Jahre Komfortfunktionen eingeschrieben bekamen. So gibt es beispielsweise häufig SQL-Interfaces, die das Generieren von Abfragen und Reports – zumindest teilweise – am Datenbankserver ermöglichen und Schlomo Normalentwickler vor dem für ihn herausfordernden Handhaben der großen Datenmengen isolieren bzw. schonen. Befragt man Google nach Schlagwörtern wie Time Series Database oder IoT Database, so findet man Dutzende von Resultaten, die sich im Bereich der Funktionalität unterscheiden. Wir wollen in den folgenden Schritten – mehr aus Lustigkeit als aus anderen Gründen – mit GridDB arbeiten. Für dieses Datenbanksystem spricht unter anderem, dass es vom Halbleiter- und IoT-Schwergewicht Toshiba mitentwickelt wird.

Beachten Sie, dass die meisten IoT-Datenbanksysteme unter einer „dualen“ Lizenz stehen. Die kommerziellen Angebote können dabei sehr teuer sein – bei CrateDB bezahlt man pro Jahr für drei Nodes schon einmal mehr als 15 000 Euro.

Einrichtung des Datenbanksystems

Auch wenn der Windows-Server im Bereich der Datenbank-Hosting-Payloads immer wieder Achtungserfolge einheimsen kann – der Betrieb von IoT-Datenbanken ist im Allgemeinen eine Arbeit, die unter unixoiden Betriebssystemen erfolgt. Im Fall von GridDB werden dabei die Betriebssystemversionen CentOS 7.6 (gcc 4.8.5), Ubuntu 18.04 (gcc 4.8.5) und openSUSE Leap 15.1 (gcc 4.8.5) unterstützt – wir wollen in den folgenden Schritten mit Ubuntu 18.04 arbeiten, weil der Autor dieses Betriebssystem sowieso auf seiner Achtkernworkstation hat. Eine manuelle Kompilation von GridDB erweist sich unter anderem deshalb als arbeitsintensiv, weil Ubuntu mittlerweile eine wesentlich neuere Version von GCC mitbringt, und es während der Kompilation zu verschiedenen Fehlern kommt. Erfreulicherweise gibt es aber eine Gruppe von fertigen Binärpaketen [1] – wer unter Ubuntu arbeitet, muss im ersten Schritt die Option Server auswählen und sich danach für GridDB CE entscheiden. Lohn der Mühen ist die Datei griddb_4.5.2_amd64.deb, die wir in einen bequem zugänglichen Ort im Dateisystem ablegen. Im nächsten Schritt können wir die eigentliche Installation nach folgendem Schema befehligen:

t@T18:~/Downloads$ sudo dpkg -i griddb_4.5.2_amd64.deb User gsadm and group gridstore have been registered.

Wichtig ist in diesem Zusammenhang eigentlich nur, dass das Paket im Rahmen der Auslieferung erstens den User gsadm und zweitens die Benutzergruppe gridstore anlegt – sie sind für die Abarbeitung von GridDB unbedingt erforderlich. Beachten Sie, dass der Gutteil der GridDB-Administrationsaufgaben nur unter dem Benutzer gsadm erfolgen darf, da nur er die nötigen Umgebungsvariablen und sonstigen Einstellungen in seiner Path-Umgebung aufweist. Hierzu reicht es aus, ein Sonderregime des sudo-Kommandos einzusetzen, das über den Parameter -q den neuen Benutzernamenkontext entgegennimmt. Den erfolgreichen Wechsel des Users erkennen wir daran, dass vor dem Maschinennamen T18 nun ein anderer Username-String auftaucht:

t@T18:~/Downloads$ sudo -u gsadm bash [sudo] password for t: gsadm@T18:~/Downloads$

Interessanterweise sind wir damit noch nicht am Ziel – unter Debian-basierten Betriebssystemen führt die Ausführung eines GridDB-Kommandos nach folgendem Schema zu einem Fehler, der auf nicht vorhandene Umgebungsvariablen hinweist:

gsadm@T18:~/Downloads$ gs_passwd admin A00105: GS_HOME, GS_LOG environment variable not set.

Der einfachste Weg, um dieses dem Entwicklerteam bekannte Problem zu umgehen [2], besteht dar...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang