Essential Guide

SAP HANA: Die In-Memory-Lösung von SAP verstehen und nutzen

Eine umfassende Auswahl von Artikeln, Videos und mehr, die von unseren Redakteuren gewählt wurden.

Experten-Tipp: Datenbank-Modellierung mit SAP HANA verstehen und maximale Performance erzielen

SAP HANA vereint die traditionellen Datenbank-Modelle. Dennoch ist SAP HANA einzigartig. Unser Experte erklärt, wie Sie maximale Performance erzielen.

SAP HANA bietet neue Sphären bezüglich Datenmodellierung. Sie haben damit wesentlich mehr Möglichkeiten als mit...

traditionellen relationalen Datenbank-Systemen (RDBMS). Um die maximale Performance aus dem System zu holen, müssen Sie mit den Daten allerdings anders umgehen.

SAP HANA speichert die Daten weiterhin in Tabellen. Allerdings unterscheidet sich das Design des Data-Storage-Modells grundlegend von dem der traditionellen Datenbanken. Speichert man die Daten in säulenartigen Tabellen, ist eine bessere Komprimierung möglich und das Lesen beschleunigt sich. Um diesen Vorteil voll ausnutzen zu können, muss das Daten-Modell aus zwei Gründen viel flacher als bei traditionellen reihenbasierten RDBMS ausfallen.

Redundante Daten sind nicht mal annähernd ein so ein großes Problem wie bei reihenbasierten Tabellen. In den säulenartigen Tabellen werden die Daten lediglich einmal abgelegt. Kommen Sie mehrfach vor, wird das über Zeiger referenziert. Wenn Daten weiterhin nicht in einer Tabelle abgelegt und über mehrere Tabellen verteilt oder normalisiert sind, könnten die Verknüpfungen (Joins) einen negativen Einfluss haben. SAP HANA bietet zwei Engines an. Die eine ist reihenbasiert, die andere setzt auf Säulen. Die Software verarbeitet die Daten entsprechend unterschiedlich. Müssen Daten für eine Weiterverarbeitung nun physikalisch von einer Engine zur anderen wandern, ist der Aufwand für die Joins logischerweise höher (Join Cost). Aus diesem Grund sollten Sie die Daten nach Möglichkeit in einer Engine lassen und dort verarbeiten. Im Falle von SAP HANA ist die bessere Lösung die Säulen-basierte Engine.

Dank Indexierung und Normalisierung sind Join Costs in traditionellen Datenbanken keine Schwierigkeit. Bei SAP HANA kann es aber schnell zu einem Problem ausarten, wenn die Abfragen nicht mit den unterstützten Funktionen der säulenbasierten Struktur im Einklang sind. Sollte eine Verarbeitung in der säulenbasierten In-Memory-Engine nicht unterstützt sein, muss die Software das Ergebnis physikalisch an die reihenbasierte ausliefern. Diese Datenverschiebung im Speicher kann die Performance empfindlich belasten. Somit ist während der Provisioning-Phase bezüglich SAP HANA immer noch Datenmodellierung notwendig. Es unterscheidet sich lediglich vom Datenmodell, das Sie für ein traditionelles RDBMS entwerfen würden.

Nachdem die Daten modelliert, verfügbar gemacht und / oder geladen wurden, müssen sich Firmen mit den Metadaten auseinandersetzen. Die Reise beginnt an dieser Stelle mit der Modellierung der Views „Attribute“ und „Analytic“. Diese basieren wiederum auf den in den säulenartigen Tabellen zur Verfügung gestellten Daten. Im Prinzip funktionieren diese Views wie die Verwandten in den traditionellen Datenbanken. Attribute Views stellen die Master-Daten in einen gewissen Zusammenhang. Sie liefern aussagekräftige Werte, wie zum Beispiel Beschreibungen für ID-Säulen oder Namen anstelle der eigentlichen ID-Werte aus.

Bei Analytic Views kommen Kalkulationen und Aggregationen zum Tragen. Attribute Views und Analytic Views sind die beiden Stützpfeiler, um die „Calculation“ Views zu erschaffen. Calculation Views verbinden und erweitern sowohl Analytic als auch Aggregate Views. Es ist sozusagen ein Verbund oder ein Schnittpunkt. Aussagekräftige Beschreibungen in einem Attribute View werden mit den Ermittlungen einer Aggregate View vereint. Dieses auf Metadaten basierendes Modell, bei denen Laufzeitberechnungen im Speicher stattfinden, ist einer der größten Vorteile von SAP HANA. Die Metadaten-Schicht beseitigt oftmals die Notwendigkeit, Daten auf weiteren Ebenen vorzuhalten, die über die anfänglich zur Verfügung gestellten Tabellen hinausgehen.

Beim Modellieren in SAP HANA stürzt man sich oft direkt auf Calculation, Analytic oder Attribute Views. Allerdings kann man gar nicht genug betonen, wie wichtig das richtige Provisioning der Daten im Speicher ist. Daten müssen immer an die Bedürfnisse der Storage-Strukturen angeglichen werden. Nur so können Sie die Mittel der Datenbank oder Plattform am effizientesten nutzen. Bei SAP HANA ist das nicht anders. Als Star-Schemata angelegte Datenmodelle lassen sich bei traditionellen RDBMS direkt portieren. Beim Data-Provisioning bezüglich SAP HANA lohnt es sich allerdings, die Daten vorher genau zu untersuchen. Danach designen Sie dementsprechend ein Modell.

Wie geht SAP HANA mit Daten um?

In den frühen Versionen von RDBMS wurden Daten in physikalische reihenbasierte Tabellen geformt und dann auf Festplatten gespeichert. Das waren eben die verfügbaren Technologien. Danach indexierte man die Daten, um mittels SQL-Abfragen schneller Zugriff darauf zu haben. Indexierung war und ist immer noch notwendig. Datenbanken sind nun mal so ausgelegt, mit reihenbasierten transaktionalen Daten zu arbeiten.

Bei dieser Plattform war das Lesen von Daten nicht der primäre Zweck. Die Strukturen wurden so angelegt, Daten hinein und nicht heraus zu bekommen. Die später entwickelten OLAP-Datenbank-Strukturen (Online Analytical Processing) galten als das Heilmittel gegen Performance-Limits des reihenbasierten Reportings. OLAP war der erste Versuch, sich rein auf das Lesen von Daten zu konzentrieren. Der Nachteil war, dass man Daten zunächst aufbereiten musste. Dazu wurden sie auf zusätzlichem permanenten Storage vorgehalten. Dieser Prozess ist aber mühsam und teuer. Das gilt sowohl für Storage als auch für die Bearbeitung.

Säulenartige, Disk-basierte Datenbanken kamen im Anschluss als Alternative. Sie speicherten Datenstrukturen in einer Form, damit man schnelles Reporting betreiben konnte. Daten werden in diesem Fall wesentlich effizienter gespeichert und die zusätzlichen Aufbereitungsschichten sind unnötig. Die Lese-Performance ist viel besser. Allerdings dauert es auch länger, Daten dort hinein zu schreiben. Der Grund ist die Methode der Datenspeicherung in traditionellen säulenbasierten Datenbanken.

Und nun gibt es SAP HANA. Irgendwie ist das eine Ansammlung aus all den bisher beschriebenen Designs mit einem einzigartigen Unterschied: SAP HANA speichert auch Full Data Sets im Arbeitsspeicher.

SAP HANA ist bei der Kombination all dieser Herangehensweisen einzigartig und hält Daten so nah wie möglich an der CPU vor: im Arbeitsspeicher. Die Daten sind physikalisch im Speicher vorhanden. Dort liegen sie entweder reihenbasiert oder säulenartig. Um Cube-basierte Storage-Strukturen zu emulieren, lassen sich auch bestimmte Varianten von Logicals Views erstellen.

Über den Autor: Don Loden ist ein Principal Business Intelligence Consultant mit Entwicklungs-Erfahrung in allen möglichen Data-Warehouse-Umgebungen. Er ist ein SAP-zertifizierter Applikations-Mitarbeiter bei SAP BusinessObjects Data Integrator. Weiterhin tritt er weltweit auf zahlreichen SAP- und ASUG-Konferenzen auf. Sie können Ihn via Email unter don.loden@decisionfirst.com oder auf Twitter (@donloden) erreichen.

Folgen Sie SearchEnterpriseSoftware auf Twitter @sentsoftwarede.

Artikel wurde zuletzt im Juni 2013 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Essential Guide

SAP HANA: Die In-Memory-Lösung von SAP verstehen und nutzen

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close