IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Microservices mit SAP HANA (Teil II): Das virtuelle Datenbankschema

Kategorie: Digitale Trends

Welche Vorteile entstehen, wenn die zwei Welten von Microservices und SAP HANA aufeinanderprallen, habe ich vor zwei Wochen in Teil I dieses Blogs bereits angerissen. Die Herausforderung der dezentralen Datenhaltung bei Microservices stand dabei im Vordergrund meiner Betrachtung. Wieso diese Zusammenführung des Problems Lösung verspricht und mit welchen technischen Möglichkeiten sie den Ansprüchen der zentralen Datenbasis genügt, möchte ich nun in dieser Fortsetzung mit Ihnen teilen.

Pflichtteil: Grundlagenwissen über SAP HANA

Wie Sie sicherlich aus den reichhaltigen Informationen der SAP rund um das Thema HANA wissen, befinden sich alle Daten, die Sie in einer SAP HANA ablegen ausnahmslos(!) im Hauptspeicher. Das unterscheidet sie von vielen anderen In-Memory-Datenbanken. Daten können deswegen mit sehr hoher Geschwindigkeit prozessiert werden. Die optimale Ausnutzung von aktuellen Multi-Core-Prozessoren wird gefördert und eine große Menge an parallelen Nutzern und Nutzeranfragen ist möglich. Die Speicherung aller Daten erfolgt in Spalten, was vor allem bei analytischen Abfragen (OLAP) eine bessere Performance ermöglicht. Die Performance für transaktionale Abfragen (OLTP) steht hier in keiner Weise nach. Ebenso die Möglichkeit, mit strukturierten und unstrukturierten Daten zu arbeiten, konnten wir in einer ganzen Reihe von Tests bestätigen. Die Datenbank ist außerdem darauf vorbereitet, mehrere Terabytes an Daten im Hauptspeicher einer einzelnen Instanz aufzunehmen. Durch mögliche Erweiterungen, z.B. mit Hadoop, lassen sich auch Themen wie Big Data erfolgreich abdecken. HANA hat ihre Fähigkeiten als ernstzunehmende Datenbank, auch im Non-SAP Kontext, erfüllt. Jetzt aber genug zur Pflichtübung, widmen wir uns nun den Microservice-typischen Themen!

Das virtuelle Datenmodell

In SAP HANA existiert ein Konstrukt, das ich in diesem Blog „virtuelle Views“ nennen möchte. Diese Views ermöglichen eine zentrale Datenhaltung für Microservices und bieten Ersatz für ein klassisches Datenmodell. Wie in der folgenden Abbildung zu sehen ist, können unterschiedliche Microservices ihre jeweils eigene Sicht auf die Daten einer SAP HANA-Datenbank haben. Diese virtuellen Views bilden ab, wie die Daten, auf denen der Microservice arbeiten kann, zueinander in Relation stehen. Es ist möglich, zwischen beiden eine 1:1 Beziehung herzustellen. Durch das Berechtigungskonzept in HANA kann anderen Microservices der Zugriff auf andere virtuelle Views untersagt werden. Detaillierte Informationen zu den virtuellen Views und ihren Ausprägungen finden Sie hier. Die unterschiedlichen Views lassen sich im SAP HANA Studio modellieren und sind in der Lage OLAP, OLTP-Anfragen sowie die Kombination aus beidem zu bedienen. Die Microservices können daher unabhängig voneinander auf die Daten in der SAP HANA zugreifen, teilen sich jedoch einen Datenbestand und ermöglichen somit eine zentralisierte Haltung.

Virtuelle Views in der SAP HANA

Weil virtuelle Views exklusiv nur einem Microservice zugeteilt sind, können neue Views in der Produktionsumgebung hinzugefügt bzw. verändert werden und haben somit keine Seiteneffekte. Das führt jedoch schnell zur Problematik der Datensperre. In den klassischen relationalen, plattenbasierten Datenbanken ist ein solches Konstrukt nur schwer durchführbar, denn da teilen sich in aller Regel die Microservices das gleiche Datenmodell. Änderungen wirken sich somit auf alle von ihnen aus, was eine Anpassung während der Laufzeit nahezu unmöglich macht. HANA leistet Abhilfe und erstellt für lesende Zugriffe immer kurzfristig einen Snapshot der Daten, welcher später wieder in den gesamten Speicher zurück überführt wird. Das Problem der Datensperre entfällt dadurch und Daten können ohne Wartezeit prozessiert werden. Schreibende Transaktionen müssen nacheinander erfolgen, was eine zumindest kurzfristige Blockade der Transaktionen zur Folge haben kann. Das in SAP HANA eingesetzte Sperrkonzept Multiversion Concurrency Control (MVCC) verhindert diesen Umstand nahezu vollständig. Vor allem bei hoher Parallelisierung von Anfragen und Nutzern bietet das MVCC-Konzept Vorteile gegenüber anderen Sperrmechanismen, ebenso auch gegenüber dem Mix aus ihnen, den wir in anderen Datenbanken vorfinden. Das parallele Arbeiten von vielen unterschiedlichen Microservices auf einem Datenbestand wird damit weiter unterstützt.

Die Kehrseite der Medaille?

All die oben genannten Vorteile nutzt SAP in ihrer eigenen S/4 HANA Lösung. In diesem Blog wende ich sie einfach auf den Non-SAP-Bereich an - Microservices in diesem konkreten Fall. Jedoch können auch alle anderen Applikationen im Non-SAP-Umfeld davon profitieren und mit HANA auf eine zentrale Datenbasis zurückgreifen. Applikationen können die Daten dann effektiv transaktional verarbeiten und sofort analytisch auswerten. Aber die Medaille hat wie immer zwei Seiten: Die zentrale Datenhaltung ermöglicht ein hohes Maß an Datenintegrität. Im Gegenzug geht ein Teil der Agilität verloren, die mit der freien Auswahl der Datenbank für einen Microservice und der damit einhergehende Autonomie in der Systemarchitektur zusammenhängt.

Für mich persönlich lohnt sich der Tausch, denn gerade der Verzicht auf Agilität mittels des beschriebenen Lösungsansatzes erhöht den Grad der Datenintegrität. Aber entscheiden Sie selbst! Welche Erfahrungen haben Sie mit der Datenhaltung bei Microservices gemacht?

Ich freue mich auf Ihr Feedback und die Diskussion mit Ihnen.

Über den Autor

Roman Bartlog
Roman Bartlog
Roman Bartlog ist Managing Enterprise Architect und kümmert sich um Themen rund um die digitale Transformation, u.a. SAP HANA, SAP Themen, Cloud, Microservices und die Integration von Cloud- und On-Premise-Lösungen.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.