Tommy Lee Walker - stock.adobe.c
Eine heterogene Datenbanklandschaft konsolidieren
IIoT- und Big-Data-Anwendungen verarbeiten jede Menge Daten. Hierfür kommen unterschiedliche Datenbanksystem zum Einsatz. Tipps für die Konsolidierung der Datenbanklandschaft.
Sowohl das Industrial Internet of Things (IIoT) als auch Big Data zeichnen sich dadurch aus, dass sie jede Menge Daten brauchen und verarbeiten, um sinnvoll zum Einsatz zu kommen. Die dabei verwendeten Datenbanken sind in der Regel durch eine heterogene Infrastruktur gekennzeichnet.
Ein stetig wachsender Administrationsaufwand mit einem wachsenden Datenbankwildwuchs ist eine Folge. Ein Blick auf die verwendeten Datenbanken ist daher nicht nur sinnvoll, sondern mitunter unerlässlich, damit alle Prozesse langfristig fehlerfrei ablaufen. Klappt das nicht mehr, kann eine Konsolidierung der Datenbanken Abhilfe schaffen.
Hohe Kosten durch verschiedene Datenbanksysteme
Natürlich ist es nachvollziehbar: Für fast jeden Zweck scheint es eine spezielle Datenbanktechnologie zu geben. NoSQL für die skalierbare Datenanalysen, relationale Datenbanken, Zeitreihendatenbanken (TSDB) und spezielle Graphdatenbanken.
Jede Technologie hat ihre Vor- und Nachteile beim Einsatz im IIoT und sie gleichen einander doch am Ende aus. Leider ist es auf lange Sicht ineffizient und kostspielig so zu denken. Denn diese Systeme werden in der Regel nicht nur an verschiedenen Standorten verteilt, von den Räumlichkeiten im Unternehmen oder in Ihrem eigenen Rechenzentrum bis zu den verschiedenen Clouds, sie verursachen darüber hinaus auch enorme Wartungs- und Betriebskosten.
Dazu kommt die zum Teil unterschiedlichen Programmiersprachen: Manche Systeme erfordern eigene Sprachen und so können Standardwerkzeuge häufig nicht für mehrere Systeme verwendet werden. Jede neue Version ist also eine Herausforderung für die Verwaltung der Datenbanken. Bedenkt man die zahlreichen Änderungen, die durch Updates im jeweiligen Datenbanksystem zu Tage treten, wird der administrative Aufwand schnell komplex und auch das Hoffen auf den SQL-Standard ist eher vergeblich, da die wenigsten hochskalierbaren Datenbanksysteme diesen unterstützen.
Stattdessen sind sowohl strukturierte Daten aus relationalen Systemen wie ERP-Anwendungen, als auch große Mengen unstrukturierter Daten wie JSON und möglicherweise auch Binärdaten (BLOB) in den meisten Anwendungsfällen erforderlich. Doch die kontinuierliche Zusammenführung dieser Daten, die Synchronisierung und die gegenseitige Verknüpfung, sind erforderlich und verursachen erhebliche Kosten, da sie auf dem Betrieb mehrerer Datenbanken bauen.
Diese wildwachsende Datenbankstruktur macht unmöglich, ein System in seiner Gesamtheit von möglichst wenigen Personen bedienen zu lassen. Dazu kommen Schulungen, die das Fachpersonal besuchen muss, um stets auf dem neuesten Stand zu bleiben. Und das treibt nicht nur die Nerven an den Abgrund – sondern auch die Betriebs- und Personalkosten in die Höhe. Und das ausgerechnet an der Stelle, wo durch den Einsatz von Datenbanken die Kosten eigentlich reduziert werden sollen.
Die Vorteile einer Konsolidierung
Diese Kosten langfristig im Rahmen zu halten, ist einer der Vorteile einer gelungenen Konsolidierung, denn es können sowohl Server- beziehungsweise Cloud-Kosten als auch Leistungen eingespart werden. Da mitunter zwei oder drei Systeme auf eine relationale und unstrukturierte Daten verarbeitende Datenbank konsolidiert werden können, kann eine optimierte Architektur einige Kostenersparnisse erzielen.
Doch abgesehen davon macht der Einsatz bestehender Werkzeuge innerhalb des SQL-Standards und die leichte Integration neuer Applikationen beziehungsweise ein einfacher Austausch vorhandener Applikationen die Arbeit der eingelernten Teams wesentlich leichter.
Die Konsolidierung selbst erfolgt dabei in zwei Schritten: Erstens die Vereinheitlichung und Integration der heterogenen Datenbankformate in ein neues Datenbanksystem. Zweitens die Datenkonsolidierung, ein direkter Eingriff in die vorhandenen Daten, um Abfragen quer durch alle Datensätze zu ermöglichen. Hierbei stehen zusätzlich das Enrichment und das Data Cleaning im Fokus, die es ermöglichen, Dubletten zu beseitigen, Inkonsistenzen auszugleichen und Fehler zu bereinigen.
Ehe näher auf die Bedingungen für eine erfolgreiche Konsolidierung eingegangen wird, noch ein kurzes Beispiel, das deutlich macht, welche Idee dahintersteckt: Im Industrial IoT (IIoT) ist es üblich, die Daten von Sensoren zunächst in einer Zeitreihendatenbank (TSDB) zu speichern. In Form von aggregierten Daten werden sie von dort in ein NoSQL-System überführt, da sie dort leichter und schneller analysiert werden können. Die Vor- und Nachteile der beiden Datenbanksysteme werden also ausgeglichen.
Wie eingangs angedeutet, erscheint dies zunächst logisch, da so das Optimum aus der Masse der Daten herausgeholt werden kann. Was dabei jedoch mitunter keine Beachtung in der Planung findet, ist die Tatsache, dass sich auch das Angebot der Datenbankanbieter auf diese Situation eingestellt hat. Mit anderen Worten: Unabhängig vom Nachteil der organisch gewachsenen Datenbankgrößen, gibt es bereits eine neue Generation an Datenbanken, die speziell für Maschinendaten entwickelt worden ist und die Vorteile von NoSQL und TSDB und gleichzeitig den SQL-Standard mit Postgres unterstützen.
Die erfolgreiche Konsolidierung
Hat man sich einmal für eine Konsolidierung der eingesetzten Datenbanken entschieden, sollte der einmalige Mehraufwand dieser Maßnahme aber nicht unterschätzt werden. Dieser amortisiert sich zwar schnell, aber um hier nachhaltig zu wirtschaften, ist die optimale Bereitstellung der Dateninfrastruktur auf Basis von Standards eine wichtige Voraussetzung.
Denn wer hier optimieren möchte, will natürlich möglichst umfassend von aktuellen Trends wie künstlicher Intelligenz und Machine Learning oder Realtime Data Analytics profitieren und die vollen Möglichkeiten des Industrial IoT auskosten.
„Diese Kosten auch langfristig im Rahmen zu halten, ist einer der Vorteile einer gelungenen Konsolidierung.“
Christian Lutz, Crate.io
Zu Beginn steht daher die genaue Planung von Bedarf und Zielen. Es ergeben sich folgende Fragen:
- Welche Daten und Datenbanken sind Gegenstand der Konsolidierung?
- Welche Use Cases profitieren davon?
- Welche neuen Use Cases werden dadurch ermöglicht?
Nachdem diese Fragen beantwortet sind, geht es an die technische Seite der Konsolidierung. Konnektoren zwischen Quell- und Zieldatenbank stellen sicher, dass die Datenformate einheitlich sind. Fehlen diese, sollten zumindest auf beiden Seiten der Konsolidierungs-Pipeline Import-/Export-Filter für ein gemeinsames Zwischenformat wie XML vorhanden sein, um auch ältere oder exotische Datenformate in die Zieldatenbank importieren zu können.
Auch hier erleichtert der vorhandene SQL-Standard den Vorgang, einerseits weil fast jedes Tool einen Postgres-Treiber hat, aber auch, weil die Daten mit SQL herstellerunabhängig leicht gelesen, verschoben und gespeichert werden können.
Über den Autor:
Christian Lutz ist Mitgründer und Geschäftsführer von Crate.io. Seit über 15 Jahren ist er als erfolgreicher Serial-Entrepreneur und Operational-Manager mit umfangreichen Kenntnissen in den Bereichen Telekommunikation, (mobiles) Internet, Software, Medien und Konsumgüter tätig.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
