Neue Datenbankgeneration

SAP HANA - weniger In-Memory-, mehr operationale Datenbank

14.01.2016
Von 


Axel Angeli schreibt als Experte zu technologischen Aspekten für Cloud, SOA, e-Business und SAP. Er ist Gründer von Logosworld , einem Beratungshaus, das sich auf technologische Managementberatung und Realisierung von komplexen industriell genutzten SAP-Installationen und verteilten Softwarelandschaften spezialisiert hat. Axel Angeli ist bekannt als Autor, Blogger und Technologieexperte für sehr große verteilte Computerlandschaften wie sie bei Big Data oder hochskalierbaren E-Commerce-Lösungen zum Einsatz kommen. Als Analyst und Mentor für Entscheidungsträger bereist er die Welt, um SAP fokussierten Industrieunternehmen Grundlagen und Nutzen von SOA und Cloud nahezubringen und mit ihnen Konzepte zu entwickeln, womit sie den größten Gewinn aus ihren IT-Investitionen erzielen.

Austauschbare Storage Engine ist das Herz einer Datenbank

Die Storage-Engine ist das Herzstück jedes DBMS und in aller Regel austauschbar. Bei der Open-Source Datenbank MariaDB (alias MySQL) zum Beispiel können Anwender standardmäßig zwischen Varianten einer Speicher-Engine wählen, zum Beispiel für Speicherung nach dem ERM (InnoDB, XtraDB), transaktionsfreie Speicherung wie MyISAM oder CSV, einer In-Memory-Option (MEMORY alias HEAP) sowie einer Option für verteilte Datenspeicherung über mehrere Server (CLUSTER) - und das sind noch längst nicht alle Möglichkeiten.

File-System Storage Engine: Eine File-System Storage Engine speichert Daten in einzelnen Betriebssystem-Dateien ab und greift grundsätzlich durch das Betriebssystem auf die Daten zu. Typischerweise sind die Daten einer Tabelle einer relationalen Datenbank pro Datei abgespeichert, und innerhalb der Datei werden Daten zeilenweise abgelegt. Typischer Vertreter ist das klassische dBase. Um Daten zwischen Tabellen zu verknüpfen, ist es erforderlich, mehrere Dateien zu öffnen und diese auch sequentiell zu durchsuchen. Das macht diese Methode wenig effizient.

File Storage Engine: Um diese Einschränkungen des File-Systems zu umgehen, werden üblicherweise die Daten in einer eigenen großen Datei abgelegt. Die Verwaltung der Daten innerhalb der Datei übernimmt das DBMS selbst. Dadurch müssen Daten auch nicht mehr Tabelle für Tabelle und innerhalb der Tabellen zeilenweis abgelegt werden.

Spaltenweises Abspeichern: Eine alternative Speichermethode ist das spaltenweise Speichern der Daten. Üblicherweise werden Datensätze nur nach einer Spalte durchsucht. Wenn nun die Felder einer Spalte nacheinander liegen, kann man die ganze Spalte als einen Block in den Hauptspeicher laden und durchsuchen, was sehr viel schneller geht und eine Art In-Memory Effekt darstellt. Scheinbarer Nachteil ist zunächst, das die Daten wieder in die ursprüngliche Form arrangiert werden müssen. Der Nachteil ist nur scheinbar, denn tatsächlich muss eine Datenbank die Daten ohnehin in ein Ausgabeformat aufbereiten. Da die Daten aber aus dem Hauptspeicher geholt werden, spielt es kaum eine Rolle, dass die Daten nicht reihenweise abgelegt sind.

Hash-Verfahren: Eine weitere Optimierung wird erzielt, indem man die Werte einer Datenbank nicht unmittelbar abgelegt, sondern die Werte einer Tabelle auflistet und durchnummeriert. Dadurch verhindert man, dass Datenwerte mehrfach gespeichert werden müssen. Das spart Speicherplatz und das Suchen außerhalb von Schlüsselfeldern funktioniert erheblich schneller. Das Verfahren nennt man HASH.

In-Memory: In-Memory, auch HEAP genannt, ist ein Verfahren, welches zur Lagerung von temporären, unkritischen Daten dient. Üblicherweise nutzt man dies zum Zwischenspeichern von Teilergebnissen, die zum Ende einer kompletten Transaktion nicht mehr benötigt werden. Durch die zunehmende Popularität von Solid-State-Disks (SSD) ist dieses Verfahren nicht mehr zeitgemäß. Fast alle DBMS bieten eine solche Storage Engine an. Besonders populär waren diese aber selten und fristeten deshalb eher ein Nischendasein Erst durch SAPs HANA erlangte das Thema wieder mehr Popularität.

Cluster: Cluster-Storage-Engines speichern Daten nicht in einer einzigen Datei auf einem einzigen Datenträger ab, sondern in verteilten Landschaften. Die bekannten Tablespaces sind bereits ein Ansatz in diese Richtung. Jedoch reicht das Clustern weiter: Ähnlich wie RAID-Systeme lassen sich die Daten auch redundant auf verschiedenen Systemen ablegen. Durch aktive Synchronisation können so Daten auf einem lokalen, schnellen Medium abgelegt werden, zum Beispiel einer RAM-Disk oder besser SSD, und werden dann in sogenannten "Totzeiten" der CPU auf den endgültigen Speicherplatz verschoben. Cluster-Storage-Engines decken übrigens die Vorteile von In-Memory ab und sind diesen meist überlegen, wenn es um das Thema Geschwindigkeitsoptimierung geht.

Graphen-basierte Speichertechnologie

Einen anderen Ansatz verfolgen die Graphen-basierten Speichermethoden. Grundidee dabei ist, dass Daten als Assoziationen in Form von miteinander durch Listen verbundenen Knoten abgelegt werden, ähnlich wie es der vereinfachten Vorstellung von der Funktionsweise des Gehirns von Säugetieren entspricht. Wir kennen das Konzept von der Programmiersprache LISP. Der Ursprung liegt genau wie das Konzept der Objektorientierung mit Smalltalk und SIMULA in den 1960ger Jahren. Ein Beispiel:

  • Das Material 4711 heißt "Kölnisch Wasser"

  • Die Flasche 4711 wiegt 2 kg.

  • Kunde "MAIER" kaufte an folgenden Tagen das Material 4711: 2015.06.01 - 12ST, 2015.08.15 - 23ST

Das Potential der Graphen-Technologie ist enorm, vor allem weil die Möglichkeiten weit größer sind, als die anderer Speichertechnologien. Aber wie schon bei LISP wird eine Verbreitung wegen mangelnder Ausbildung der Informatiker behindert. Graphen erfordern ein tieferes mathematisches Verständnis, welches in der Informatik meist wenig gefördert wird. Es gibt verschiedene Varianten der Graphen-basierten Methode: Die am weitesten fortgeschrittene darunter ist RDF, auch Triple Store genannt, welche Teil der Spezifikationen des WWW-Konsortium ist und als primäres Ziel das Speichern unstrukturierter Daten verfolgt.