Kommentar von Gregor Bauer, Couchbase Wenn die Datenbank Daten für Echtzeit-Services liefern muss

Anbieter zum Thema

Couchbase Germany GmbH

Board Deutschland GmbH

QUNIS GmbH

BigData-Insider

Eine schnelle Preisabfrage, ein aktuelles Angebot, eine dringende Service-Meldung? Darauf möchte niemand lange warten. Im Hintergrund laufen dafür Queries und Analytics auf Hochtouren. Und die Datenbank spielt dabei immer die zentrale Rolle.

Stellen wir uns einmal folgende Situation vor: Wir stehen nach drei Stunden im Flieger am Flughafen, die Maschine hatte Verspätung, der Anschluss-ICE ausnahmsweise einmal nicht. Wir brauchen auf die Schnelle einen Mietwagen und die Schlange vor dem Car Rental Shop ist länger als unser Geduldsfaden. Also wird online gebucht, um quasi elegant an den Kopf der Schlange zu kommen.

Was nun passiert ist Operational Analytics in Reinkultur – und das in Echtzeit. In Sekundenbruchteilen werden Parameter wie Bestand, Verfügbarkeit, Zeit und aktueller Preis korreliert und daraus ein konkretes Angebot berechnet. Währenddessen ist die Schlange vor dem Tresen eher länger als kürzer geworden.

Die Trennung von operativen und analytischen Daten …

Bei Operational Analytics geht es um Daten, deren Aktualität und Verknüpfung. Dementsprechend zentral ist die Rolle der Datenbank, respektive der Datenbanken. Denn für die schnelle Datenanalyse und Entscheidungsfindung ist es sinnvoll, die operativen und analytischen Daten in eigenen Datenbank-Clustern zu halten, die auf separaten physischen Speichern untergebracht sind.

Bei Echtzeit-Services sind die Zeiten für die üblichen, aus dem Befüllen von Data Warehouses bekannten ETL-Vorgänge (Extract – Transform – Load) allerdings zu lang, die Latenzzeiten wären viel zu hoch. Echtzeit-Antworten sind so nicht möglich. Stattdessen werden operative und analytische Daten im Hintergrund auf verschiedenen Datenbankknoten synchronisiert, die Analysedaten damit ständig aktuell gehalten und die Latenzen minimiert. Zeitraubende ETL-Jobs werden dadurch überflüssig, sofern die Datenbank dies unterstützt.

Außerdem ist es praktisch unmöglich, vorab Indizes für Ad-hoc-Abfragen zu erstellen da es schwierig ist zu antizipieren, welcher Query gerade in einem bestimmten Use Case oder Szenario benötigt wird. Stattdessen wird die Berechnung der getrennt gehalten operativen und analytischen Daten wie bei einem gut organisierten Teamwork auf verschiedene Knoten verteilt.

Bei einer Abfrage berechnet dann jeder Knoten lediglich einen ganz bestimmten Teil der dort gespeicherten Daten. Nicht mehr und nicht weniger. Dieses Parallelisieren der Aufgaben in Form von Multi Parallel Processing beschleunigt die Antwortzeiten auf Abfragen enorm.

… und deren Zusammenführung

Die Entscheidung darüber, welches Daten-Subset ein bestimmter Knoten berechnen soll, übernimmt der sogenannte Orchestrator. Er verteilt die Arbeitspakete und fügt die Teilergebnisse anschließend auf einem separaten Knoten zu einem finalen Resultat zusammen. Wichtig ist es dabei, die Daten zur schnelleren Bearbeitung in einem gemeinsamen Cluster zu halten.

Zusätzliche Beschleunigung erfahren die Abfragen durch die automatisierte Optimierung der SQL-Statements auf Suchebene. Voraussetzung dafür ist der sogenannte Cost-Based Query Optimizer. Dieses Tool verfasst keine eigenständigen SQL-Statements, es optimiert als Teil des Orchestrators vielmehr selbstständig die Ausführung dieser Queries auf Suchebene.

Für deren Ausführung werden durch die Storage-Compute-Separation nur die gerade benötigten Daten und Dateien in den Arbeitsspeicher geladen. Die In-Memory-Aktionen erfolgen also ausschließlich für die tatsächlich benötigten Daten. Die Datenmenge ist dementsprechend schlank und schnell berechnet.

Dabei muss es egal sein, aus welcher Datenquelle sie stammen, seien es nun Daten aus Block-Storage oder aus S3-Speichern aus der Cloud. Auch dies beschleunigt die Ausgabe der gewünschten Ergebnisse. Gleichzeitig senkt es die Kosten für eigene Storage- und Compute-Hardware, da diese in der Datenbank angelegte Quellenagnostik prinzipiell alle bekannten IT-Architekturen unterstützt, sei es on-premises, Cloud oder Edge – und natürlich deren unzählige hybride Mischformen.

Operational Analytics und KI

Natürlich darf Künstliche Intelligenz bei der Optimierung von Realtime Operational Analytics nicht fehlen. Für Analytics Services ist die Option wichtig, KI-Modelle direkt in der Datenbank laufen und arbeiten lassen zu können. Für die Anwendung von Machine Learning (ML) auf Daten wird ein Backend für die Berechnungen und die Analysen benötigt. Idealerweise ist die Datenbank dafür ausgelegt, die ML-Modelle hochladen zu können und sie direkt im Analytics Service laufen zu lassen. Dadurch ist auch die direkte Verbindung zu RESTful-Services und dem SDK gegeben. Das vereinfacht das Handling enorm. So kann beispielsweise eine ML-Funktion zur Analyse von Patientendaten direkt in der Datenbank ausgeführt und so eine Anfrage zur aktuellen Höhe einer Lebensversicherungsprämie in Echtzeit beantwortet werden.

Bei Echtzeit-Analytics für die Entscheidungsunterstützung sind zudem eine Reihe von weiteren Datenbank-Features hilfreich. Dazu zählen unter anderem das erwähnte REST-Interface und die Möglichkeit zur direkten Anbindung von Analyse- und BI-Tools wie Tableau oder PowerBI.

Ein nicht zu unterschätzender Vorteil ist auch die Option, die weltweit verbreitetste Abfragesprache SQL++ für Queries in NoSQL-Datenbanken nutzen zu können. Das vereinfacht die Abfragen und erweitert den Kreis der dafür qualifizierten Datenbank-Spezialisten, die aktuell ja händeringend gesucht werden.

(ID:50072008)