- Riesige Datenmengen in Höchstgeschwindigkeit analysieren.
- Abruf von Transaktionsdaten in Echtzeit.
- Innovationen ohne Unterbrechung des Geschäftsbetriebes realisieren.
Die SAP Verlautbarungen rund um HANA wecken hohe Erwartungen. Doch kann SAP die gestellten Zielsetzungen und versprochenen Möglichkeiten auch wirklich erreichen? Für welche Unternehmen lohnt sich die Anschaffung und genügt es SAP's „Wunderwerk“ einfach unter ein bestehendes SAP-System zu setzen?
Die nachfolgenden Ausführungen haben sich daher zum Ziel gesetzt, neben Funktionsweise und Stärken, SAP HANA aus unterschiedlichen Sichtweisen einer kritischen Betrachtung zu unterziehen.
Theoretische Grundlagen
Im folgenden wird auf die In-Memory-Technologie und Hauptspeicherdatenbanken im Allgemeinen eingegangen. Dabei geht es um Neuerungen, die Funktionsweisen von In-Memory-Datenbanken, Speicherhierarchien, die hardwareseitige Umsetzung, Zeilen- und Spaltenorientierung, sowie die Kompression von Daten.
Hauptspeicherdatenbanken
Traditionell werden Unternehmensanwendungen in OLAP und OLTP unterteilt. Die Entwicklungen und Forschungen gingen zunächst auf die Optimierung dieser beiden Teilbereiche ein. Während des letzten Jahrzehnts wurde zunehmend versucht eine einheitliche Lösung, der Integration von transaktionaler und analytischer Methoden (sog. OLXP), zu finden. Da sowohl die Hardware-Leistung (Mehrkern-CPUs, großer Hauptspeicher) zugenommen hat, als auch spaltenorientierte Datenspeicherung samt Kompressionsalgorithmen zum Einsatz kommen, können komplette Datenbanken von Unternehmen im Hauptspeicher vorgehalten werden. Die künstliche Trennung von OLTP und OLAP verfällt, sodass Datenbankabfragen auch auf eine gemeinsame Datenbasis gestellt werden können (vgl. Plattner et al., 2010).
OLTP-Abfragen treten im Tagesgeschäft, z.B. Wareneingang oder Warenausgang, eines Unternehmens auf. Im Vordergrund stehen hier Transaktionssicherheit und eine parallele Abfrageausführung. Es muss zudem nach Schneider und Werner (2007, S. 444 ff.), ungeachtet vieler Schreib- und Leseoperationen, die Datenkonsistenz durch das Datenbanksystem sichergestellt sein.
OLAP-Abfragen sind komplexer und operieren auf einem großen Datenvolumen. Relevant sind die Bearbeitungszeiten der Abfragen, da es sich hier meist um unternehmenskritische Prozesse handelt, auf deren Grundlage Entscheidungen getroffen werden (vgl. Bog, Sachs & Zeier, 2011, S. 417-418).
Moderne Hauptspeicherdatenbanken arbeiten dank leistungsfähiger Hardware schneller und ohne dabei auf Massenspeicher zugreifen zu müssen. Untersucht man die Dokumentationen von In-Memory-Datenbanken, so ergeben sich gleiche Funktionsprinzipien, nach denen die Datenbanken arbeiten. Ott und Stirnimann (2012, S.26) beschreiben folgende Gemeinsamkeiten:
- Datenhaltung
Beim Datenbankstart werden alle Daten von der Festplatte in den RAM geladen.
- Snapshot Images
Es findet ein regelmäßiger Datenabgleich mit dem persistenten Speicher statt.
- Transaction Logs
Änderungen werden zu Zwecken eines Backups geloggt.
- ACID-Kriterien
IMDBs stellen genauso wie RDBMS die ACID-Kriterien (Atomicity, Consistency, Isolation, Durability) sicher.
- Hochverfügbarkeit
Funktionalitäten wie Datenbankreplikation sind vorhanden und ermöglichen ein Failover im Fall eines Absturzes.
- Direct Connect
Die Datenbank lädt sich selbst in ihren eigenen Adressbereich, um zusätzlichen Overhead zu vermeiden.
Hauptspeicherdatenbanken nutzen meist eine spaltenbasierte Datenspeicherung, da hier die Daten besser komprimiert werden können und mehr Daten in den Hauptspeicher passen. Es gibt jedoch auch „hybride“ Datenbanken wie die SAP HANA DB, die sowohl eine zeilen- als auch spaltenbasierte Speicherung erlauben. In Kapitel 3 soll die HANA DB näher untersucht werden, um festzustellen welche Technologien dort zum Einsatz kommen.
In-Memory-Technologie
Anforderungen von Geschäftsanwendungen werden in der heutigen Zeit, analog zur fortschreitenden Entwicklung der Hardware, immer umfangreicher. Komplexere Anwendungen mit komplexeren Architekturen, sowie automatisierte Unternehmensprozesse mit kurzen Prozesslaufzeiten sorgen dafür, dass die zu verarbeitende Datenlast enorm ansteigt. Besonders zu Analysezwecken müssen Systeme Informationen möglichst in „Realtime“ verarbeiten und ihre Ergebnisse dem Kunden/Anwender ebenso schnell zur Verfügung stellen. Insbesondere Event- oder Sensordaten, aber auch entscheidungsunterstützende Systeme, bspw. im operativen Controlling stellen diese Anforderungen (vgl. Plattner, 2012, S.7-11 und Plattner, 2010, S.1-2).
Eine mögliche Lösung könnte die In-Memory-Technologie bieten, die mit In-Memory-Datenbanken (IMDB), Spaltenorientierung und effizienten Kompressionsalgorithmen, eine sehr viel schnellere Datenverarbeitung als die klassischen Systeme ermöglicht.
Die Gedanken an In-Memory-Datenbanken und Spaltenorientierung sind dabei nicht neu. Schon in den 1970er Jahren wurden Verfahren zur Spaltenorientierung entwickelt. Diese waren jedoch ohne die In-Memory-Technologie nicht effizient genug. Fallende Hardwarepreise, sowie die Möglichkeit der Adressierung von großen physikalischen Speicherbereichen haben die Realisierung der In-Memory-Technologie möglich gemacht (vgl. Plattner et al., 2010, S.2).
Funktionsweise von In-Memory-Datenbanken
Kernaspekt der In-Memory-Technologie ist die Verlagerung von Daten aus den relativ langsamen Sekundärspeichern in den sehr viel schnelleren Hauptspeicher, mit dem Ziel eine erhöhte Performance durch beschleunigte Zugriffszeiten zu erzielen. Ferner sollen Datenzugriffe durch die spaltenorientierte Speicherung der Daten auf analytische Verfahren wie bspw. OLAP hin optimiert werden.
Im Rahmen der In-Memory-Technologie werden die Daten einer Datenbank beinahe komplett im Hauptspeicher vorgehalten. Da der Hauptspeicher flüchtig ist, müssen die Daten in regelmäßigen Abständen auf Sekundärspeichern gesichert werden, um die ACID-Eigenschaften zu erfüllen. Änderungen die zwischen zwei Sicherungen erfolgen, würden bei einem Crash verloren gehen. Daher müssen Transaktionen zusätzlich mittels Logging gespeichert werden, um diese im Schadensfall wieder herstellen zu können.
Speicherhierarchie
Speicher unterscheiden sich u.a. in Sachen Latenz, Größe, Kosten und Persistenz. Je größer das Speichermedium, desto größer ist dessen Latenz zum Prozessor bei sinkenden Kosten pro Speichereinheit. Das kleinste und schnellste Speichermedium nach den CPU-Registern ist der L1-Cache. Dieser sitzt zumeist direkt auf dem Prozessor und sorgt somit bei gleicher Taktung für die schnellsten Zugriffszeiten. Der L1-Cache ist allerdings so klein, dass er sich nur zur Pufferung von sehr häufig benutzten Daten und Befehlen eignet. Hinter dem L1-Cache folgen weitere Caches (L2, L3, Ln usw.) mit abnehmenden Zugriffszeiten, steigender Größe und sinkenden Kosten. Auf die Caches folgt der Hauptspeicher (RAM), der schon um einiges langsamer getaktet ist als die CPU und fernab von dieser über den FSB angesprochen wird. Alle oben aufgelisteten Speichermedien sind Primärspeicher und somit in der Regel volatil (vgl. Plattner et al., 2010, S.3).
Auf die Primärspeicher folgen die Sekundärspeicher. Dazu gehören SSDs, Disk-basierte Festplatten, Bänder etc. Diese ermöglichen die persistente Speicherung von Daten, haben jedoch sehr viel längere Zugriffszeiten als physikalische Speicher.
Deutlich, dass der Zugriff auf den Hauptspeicher in diesem Beispiel um den Faktor 100.000 schneller ist als der Zugriff auf die Festplatte. Das liegt u.a. daran, dass eine herkömmliche Festplatte von mechanischen Komponenten abhängig ist, eine maximale Rotationsrate hat und durch die Blockorientierung zudem stark fragmentiert sein kann. Hinzu kommt, dass optimierte Algorithmen zum Zugriff auf Daten im Hauptspeicher leistungsfähiger sind.
Da sich die Latenzzeiten beim Zugriff auf den Arbeitsspeicher sowie die Speicherbandbreite - im Gegensatz zu anderen Faktoren - kaum verbessert haben, werden in Hauptspeicherdatenbanken n-schichtige Cache-Architekturen verwendet. Dies soll die In-Memory Datenbank näher an der CPU halten, die Latenzzeiten verschleiern und somit die Performance weiter verbessern. Zudem wird die Speicherbandbreiten-beschränkung eingeschränkt.
Es ist anzumerken, dass die Nutzung einer solchen Architektur eine Anpassung der verwendeten Algorithmen sowie Datenstrukturen zur Folge hat, da die Daten in der Regel in Cache-Lines zu 64 Bit gelesen werden müssen und eine effiziente Nutzung ohne die nötigen Anpassungen nicht möglich ist (vgl. Plattner, 2012, S.19-28).
Hardwareseitige Umsetzung
Ein In-Memory-System besteht hardwareseitig zumeist aus mehreren sog. Serverblades, welche einen Bladeserver bilden und über ein schnelles Netzwerk miteinander verbunden sind. Ein Serverblade verfügt bspw. über 8 CPUs mit jeweils 8 Kernen. Das ergibt eine Kernanzahl von 64 Kernen pro Blade. Jedem Serverblade kann bis zu 2 TB Hauptspeicher zur Verfügung gestellt werden. Im unten aufgeführten Beispiel wird 1 TB DRAM Hauptspeicher zur Verfügung gestellt. Die CPUs greifen mit Hilfe des NUMA-Verfahrens[2] effizient auf den Hauptspeicher zu. Zur regelmäßigen Sicherung der Persistenz werden SSDs[3] verwendet, welche in regelmäßigen Abständen Abbilder der Datenbank auf dem Sekundärspeicher erzeugen und diese bei Bedarf wieder in den Hauptspeicher laden können. In Abbildung 2 ist die Struktur einer hardwareseitigen Umsetzung eines In-Memory Systems dargestellt (vgl. Plattner, 2012, S.19ff, S.28).
Abb. 2: Strukturplan Hardware IM-System
Quelle: (Plattner, 2012, S. 28)
Quelle: (Plattner, 2012, S. 28)
Zeilen- und Spaltenorientierung
Neben der hardwareseitigen Umsetzung, spielt in IMDBS ferner die logische Organisation der Daten im Hauptspeicher eine wichtige Rolle. Sie hat u.a. Auswirkungen auf Performance und Speicherbedarf.
Datenbankensysteme speichern ihre Daten in der Regel zeilenorientiert, also in Tupeln bzw. aus technischer Sicht als eindimensionaler sequentieller Bytestrom auf dem Speichermedium. Diese Art der Speicherung ist bei sequentiellen Datenbankabfragen mit vielen Attributen, sowie geringer Zeilenbreite am effizientesten. Überwiegen jedoch Abfragen, die nur wenige Attribute über sehr viele Zeilen benötigen, wie es bei analytischen Systemen häufig der Fall ist, so ist eine spaltenorientierte Speicherung von Daten effizienter. Ein Großteil an Daten, nämlich der der nichtbenötigten Spalten, müssen so erst gar nicht gelesen werden.
Generell kann man sagen, dass für transaktionale Systeme wie OLTP die zeilenorientierte Speicherung von Vorteil ist, während analytische Systeme wie das OLAP zumeist auf die spaltenorientierte Datenhaltung oder einer Kombination aus beiden setzen sollten, denn analytische Systeme arbeiten häufig mit Aggregatfunktionen und bilden dabei Aggregate aus sehr großen Datenmengen innerhalb einer Spalte.
Spaltenorientierung wird auch vertikale Partitionierung genannt, da Spalten in Vektoren separat gespeichert werden. Spalten werden durch einen Positionsschlüssel identifiziert, welcher die Beibehaltung des logischen Tabellenschemas sichert.
Sollen während einer Analyse bspw. Durchschnittswerte aus großen Datenmengen ermittelt werden, so muss das DBMS bei Zeilenorientierung jede Zeile nach dem benötigten Attributwert durchsuchen. Ein spaltenorientiertes System durchsucht bzw. lädt nur diejenige Spalte, die benötigt wird (vgl. Plattner et al., 2010, S.4-5).
Kompression
Durch die Tatsache, dass eine einzelne Spalte immer nur über einen Datentyp verfügt, lassen sich auf eine Spalte sehr wirksame Kompressionsalgorithmen anwenden. Ein Beispiel für einen solchen Algorithmus ist die Domänenkodierung (engl. Dictionary Compression). Dieses Verfahren kann den zur Datenhaltung benötigten Speicherplatz um einen Faktor von bis zu zehn reduzieren, indem Attributausprägungen in einem zentralen Verzeichnis/Wörterbuch (Dictionary) hinterlegt und indiziert werden. Der Index nimmt dann die Position der eigentlichen Attributausprägung in der Datenbank ein. Das Verfahren führt zu einem Mehraufwand durch die Verwaltung und Pflege des Verzeichnisses, jedoch wird durch das häufige Auftreten der gleichen Attributausprägungen Speicherplatz eingespart.
Durch die Komprimierung innerhalb der Spalten wird die Informationsdichte in Bezug auf den verbrauchten Speicherplatz erhöht. Dadurch können relevantere Informationen zur gleichzeitigen Verarbeitung in den Cache geladen werden, was zu einer Erhöhung der Bandbreitennutzung führt.
Werden bspw. durch eine Transaktion 1-n Tupel verändert, so kann ein zeilenorientiertes DBMS ohne weiteres anhand der Primärschlüssel die relevanten Reihen identifizieren und die benötigten Operationen durchführen. In einem spaltenorientierten System muss das System von Spaltenvektor zu Spaltenvektor „springen“ (vgl. Plattner et al., 2010, S.5-6).
Insert-Only-Strategie
Die Insert-Only-Strategie beschreibt ein Verfahren in der Datenbanktechnologie, bei dem neue Datensätze in einer Datenbank grundsätzlich nur hinzugefügt und nicht überschrieben werden. Neue Datensätze werden bei der Speicherung mit einem Zeitstempel versehen, somit lässt sich eine Historie aller Datenmodifikationen sowie eine Historie aller Unternehmensdaten persistent speichern. Dies ist besonders auch aufgrund der gesetzlichen Anforderungen in vielen Ländern sehr wichtig.
Die Insert-Only-Strategie ermöglicht ebenfalls die Analyse historischer Daten. Ein positiver Aspekt ist die Snapshot Isolation, welche ohne explizites Sperrverfahren die Operation einer Transaktion auf Daten garantieren kann, ohne dass diese von anderen Transaktionen vorher verändert wurden.
Des Weiteren reduziert es das zu lesende Datenvolumen, da Werte die zum Zeitpunkt eines Snapshot nicht verändert wurden mit einem vordefinierten Standardwert versehen werden können (z.B. einem Boolean Wert „NichtGeändert“).
Der Hauptnachteil der Insert-Only-Strategie liegt darin, dass alle vorherigen Versionen gelesen werden müssen, um die aktuell gültige Version erstellen zu können. Je mehr Versionen vorgehalten werden, desto teurer wird dieser Prozess. Des Weiteren ist der erhöhte Speicherbedarf zu erwähnen, der durch das Vorhalten aller gespeicherten historischen Daten benötigt wird. Untersuchungen haben jedoch gezeigt, dass modifizierende Operationen im Unternehmensanwendungskontext wesentlich seltener vorkommen als angenommen wird. Zudem wächst beim Dictionary Encoding das Wörterbuch nur marginal an, da bereits eine Vielzahl von Attributwerten eingetragen sind (vgl. Plattner et al., 2010, S.6-7).
SAP HANA DB
Funktionsweise
Die SAP HANA Datenbank nutzt moderne Hardware optimal aus, um sich effizient und skalierbar auf komplexe Unternehmensanwendungen zu spezialisieren. Diese Entwicklung fand jedoch nicht nur wegen des technologischen Hardware-Fortschritts, sondern auch aus den Anforderungen moderner Unternehmensanwendung auf großer Datenbasis heraus statt. Die Idee OLTP- und OLAP-Anforderungen in einer Datenbank zu vereinen, wurde damit realisiert. Die Entwicklung der SAP HANA DB fand auch nicht von heute auf morgen statt, sondern verlief über Jahre hinweg. Auch der In-Memory-Ansatz hat seine Zeit gebraucht, bis er an die Anforderungen von Unternehmensanwendungen angepasst werden konnte. Zur Veranschaulichung zeigt Abb. 4: Evolution der SAP In-Memory-Technologie die historische Entwicklung von der SAP MaxDB unter Einflüssen von TREX, LiveCache und BWA, bis hin zur SAP HANA in der Version 1.0.
Quelle: (SAP HANA Essentials, 2012, S. 37)
SAP HANA ist eine „hybride“ Datenbank, die sowohl zeilen- als auch spaltenbasierte Datenspeicherung unterstützt. Die Art der Speicherung kann beim Anlegen der Tabelle festgelegt und später wieder geändert werden. Die Entscheidung für oder gegen eine bestimme Art der Speicherung muss im Einzelfall untersucht werden.
Neu am In-Memory-Ansatz ist lediglich, dass nun die operationale und analytische Datenbank komplett in den Hauptspeicher gelegt werden kann. Beim ersten Zugriff auf die Daten werden diese komplett in den RAM geladen, sodass Operationen auf den Daten im Arbeitsspeicher stattfinden können.
Ein HANA System hat typischerweise zwischen 16 GB bis zu derzeit zertifizierten 1 TB Hauptspeicher. Lauffähige Systeme mit noch mehr Terabyte RAM sind schon ebenfalls in Testphase. Derzeit unterstützt ein einzelnes HANA System maximal 1 TB RAM und bis zu 80 CPU-Kerne (SAP HANA Database – Administration Guide, S.5).
Die Verlagerung aller Daten von der Festplatte in den Hauptspeicher beschleunigt zweifelsfrei die Abarbeitung von Datenbankanfragen, verlangt jedoch auch die Anpassung der Anwendungen an die neue Technik (vgl. Ott & Stirnimann, 2012, S. 24). So müssen Transaction-Loggings die laufenden Änderungen protokollieren, sodass nach einem Absturz die Datenbank in den ursprünglichen Zustand wiederhergestellt werden kann. Weiterhin sind Snapshots, d.h. ein Abgleich der Daten im nicht-persistenten RAM, auf die persistente Festplatte erforderlich.
Persistenz
Da der Hauptspeicher flüchtig ist, muss ein Abgleich mit nicht-flüchtigem Speicher erfolgen, z.B. einer Festplatte. Die Persistenzschicht der SAP HANA speichert die Daten auf Festplatten bzw. Solid State Disks und stellt sicher, dass Datenänderungen gemäß den ACID-Kriterien dauerhaft sind. Auch im Falle eines Absturzes der Datenbank wird ein Delta-Backup mittels Logging sichergestellt.
Anwendungsschicht und Datenbankschicht
In der Regel werden die Daten zwischen Datenbank und Anwendung hin- und hergeschrieben. Zudem erfolgt diese Kommunikation meistens über ein Netzwerk und beansprucht zusätzliche Antwortzeiten. SAP HANA hingegen verlagert alle Berechnungen und Operationen in die Datenbankschicht, sodass diese Geschwindigkeitsverluste entfallen. Das Datenübertragungsvolumen nimmt ab und die Gesamtperformance nimmt zu.
Architektur
Ein IMDBMS verwaltet Datenbanken im laufenden Betrieb ausschließlich im Hauptspeicher und nutzt den Sekundärspeicher zur Datensicherung. Aufgrund dieser Architektur ist der Einsatz spezieller Techniken nötig, um etablierte Datenbankverfahren anzupassen. Bisher waren Zugriffsstrukturen auf eine Minimierung der Seitenzugriffe optimiert. Knoten von
B-Bäumen werden so in ihrer Größe an die Blockgrößen angepasst. Bei IMDBs spielt nun die Blockgröße keine Rolle mehr, alternative Zugriffsstrukturen kommen aber in Frage. Z.B. können nun ausbalancierte Binär-Bäume, trotz einer kleineren Knotengröße, genutzt werden (vgl. Saake & Heuer, 1999, S. 730ff). Die Anfrageoptimierung war bisher auf eine Minimierung der Plattenzugriffe ausgelegt, da diese um Größenordnungen teurer als Hauptspeicheroperationen sind. Bei IMDBs können und müssen andere Kostenfunktionen gefunden werden, zumal diese Zugriffszeitenunterschiede im laufenden Betrieb nicht mehr existieren.
B-Bäumen werden so in ihrer Größe an die Blockgrößen angepasst. Bei IMDBs spielt nun die Blockgröße keine Rolle mehr, alternative Zugriffsstrukturen kommen aber in Frage. Z.B. können nun ausbalancierte Binär-Bäume, trotz einer kleineren Knotengröße, genutzt werden (vgl. Saake & Heuer, 1999, S. 730ff). Die Anfrageoptimierung war bisher auf eine Minimierung der Plattenzugriffe ausgelegt, da diese um Größenordnungen teurer als Hauptspeicheroperationen sind. Bei IMDBs können und müssen andere Kostenfunktionen gefunden werden, zumal diese Zugriffszeitenunterschiede im laufenden Betrieb nicht mehr existieren.
Ferner müssen bei der Transaktionsverwaltung spezielle Vorkehrungen getroffen werden, da nun die Operationen im Hauptspeicher ablaufen. Ein Transaktionsabbruch hinterlässt keine Spuren mehr im Sekundärspeicher, sodass hier einfachere Verfahren eingesetzt werden können. Damit ein Commit tatsächlich dauerhaft ist, das System dadurch nicht blockiert wird und alle Änderungen fortlaufend auf die Platte geschrieben werden, bedarf es besonderen Techniken, wie dem Einsatz von Logging und darauf aufbauende Recovery-Methoden oder die Durchführung von Gruppen-Commits (vgl. Saake & Heuer, 1999, S. 677).
Die SAP HANA Datenbank ist im Kern nicht nur eine Datenbank, denn sie bringt viele Tools und Funktionalitäten mit. Programmiert ist die SAP HANA DB hauptsächlich in C++ und läuft bisher lediglich auf SUSE Linux Servern. Die unterschiedlichen Komponenten aus denen sich die SAP HANA DB zusammensetzt sind in Abb. 5 dargestellt.
Quelle: (SAP HANA Database Development Guide, 2011, S. 15)
Zunächst sorgt die Komponente Connection And Session Management für die Verwaltung aller von Clients zur Datenbank aufgebauten Verbindungen und Sessions. Steht die Verbindung, so erfolgt die Kommunikation i.d.R. mittels SQL-Statements, welche eine Transaction darstellen. Der Transaction Manager steuert die Datenbankanfragen und kommuniziert mit der Persistence-Layer, um alle ACID-Kriterien sicherzustellen. Auf der Persistence-Layer liegen auch die spaltenorientierte- und zeilenorientierte Datenbank-Engine auf, die für die entsprechende Ablegung der Daten im Speicher sorgen. Das Logging für eventuelle Backups und das Page Management geschehen ebenfalls im Persistence-Layer und im Disk Storage (vgl. Plattner & Zeier, 2011, S. 38ff). Die Komponente Request Processing And Execution Control analysiert und führt Benutzeranfragen letztendlich durch.
Neben JDBC bietet die SAP HANA DB auch diverse andere Schnittstellen, wie ODBC, BICS und den MDX-Standard (Multidimensional Expressions). Durch letzteren lässt sich die Datenbank an viele Analyseanwendungen, wie z.B. Business Objects Produkte anbinden.
Die SAP HANA eigene Skriptsprache SQLScript ist auf Optimierung und Parallelität konzipiert. Mit ihr lassen sich Operationen und Berechnungen direkt auf der Datenbank durchführen. SQLScript kann mit Stored Procedures verglichen werden, jedoch bietet es modernere und flexiblere Funktionen. Für die Ausführung der Berechnungen direkt auf der Datenbank ist die Komponente Calculation Engine zuständig.
Über den Metadata Manager erhält man Zugriff auf Metadaten zu Tabellen, Spalten, Indexen oder Prozeduren. Der Authorization Manager ist die Komponente, welche zu Zwecken der Überprüfung eines Benutzers und seiner Benutzerdaten durch andere Komponenten angesprochen wird.
Das SAP HANA Datenbanksystem besteht aus mehreren Servern, wie in Abb. 6 zu sehen ist. Die wichtigste Komponente ist dabei der Index-Server, welcher aktuelle Daten und die Engines zur Verarbeitung dieser beinhaltet. Der Index-Server nutzt den Preprocessor-Server, um die Daten zu analysieren und die gesuchten Informationen zu extrahieren. Der Name-Server beinhaltet Informationen zur Topologie des DBMS und weiß, auf welcher Instanz, auf welchem Server etc., die Komponenten laufen.
Der Statistics-Server sammelt Informationen zu Status, Performance und Ressourcenverbrauch. Die XS-Engine ist ein optionaler Bestandteil der HANA DB und erlaubt es das Persistence Model der Datenbank an ein Consumption Model zu mappen, welches dem Anwender dann über http angeboten wird (Kleis, Bendelac, & Boban, 2012, S. 18-19).
Als Frontend zur SAP HANA DB wird das SAP HANA Studio mitgeliefert. Dieses erlaubt die Administration und Datenverwaltung.
Anwendungsgebiete und Kunden
Um nochmal kurz auf die möglichen Einsatzszenarien von SAP HANA zu kommen, ist zu erwähnen, dass HANA als zentrale Plattform oder als Variante zusätzlich neben einer existierenden relationalen Datenbank (mit z.B. SAP BW-Installation), eingesetzt werden kann. Letzteres dürfte den niedrigsten Gewinn von der Mächtigkeit der SAP HANA abwerfen.
Angepriesen wird HANA als Anwendungsplattform mit einer völlig neuartigen Architektur, durch welche Manager die Möglichkeit erhalten, Szenarien in Echtzeit zu simulieren, Beziehungen zu analysieren und zu überprüfen. Laut der SAP heißt es zudem, dass bestehende Anwendungen der Kunden bei einem Wechsel auf SAP HANA nicht portiert werden müssen.
Der größte Mehrwert liegt wohl in den HANA-nativen Anwendungen, die aufbauend auf HANA speziell dafür geschrieben sind und somit in vollem Umfang von der Architektur profitieren. Solche Echtzeitanwendungen dienen für erweiterte Berichts-, Analyse- und Planungsfunktionen und sind z.B. SAP Sales and Operations Planning, SAP Cash Forecasting, SAP Planning and Consolidation, SAP Bank Analyzer (Finanzreporting), SAP Deposits Management (Analyse von Transaktionshistorien), SAP Sales Pipeline Analysis und einige andere.[4] Durch den Einsatz dieser Apps sowohl vor Ort als auch aus der Cloud heraus, dient HANA als eine Platform-as-a-Service-Lösung für SAP.
Unter anderem nutzt inzwischen die McLaren Group SAP HANA zur Verarbeitung von Telemetriesystemdaten, welche so mithilfe von Sensoren erfasst und in Echtzeit analysiert werden. Auch die größte Krankenversicherung Deutschlands (AOK) nutzt bereits die HANA-Plattform zur Analyse von mehr als sechs Millionen Krankheitsfällen pro Jahr, um so die Patientenversorgung weiter zu verbessern.[5] Zu den weiteren großen Kunden zählen u.a. die BSH Bosch und Siemens Hausgeräte GmbH, die Procter & Gamble Company oder die Charité als größtes Universitätsklinikum Europas. Die SAP will die Anwendungsmöglichkeiten für ihre HANA weiterhin kontinuierlich ausbauen. So lautete schon das Leitmotiv von Co-CEO Jim Hagemann Snabe: „HANA für alle”.
Weitere In-Memory-Datenbanken
Zu Beginn haben kleinere Anbieter wie Jedox[6] und QlikTech[7] In-Memory-Datenbanken auf den Markt gebracht. Erst mit großen Anbietern SAP oder IBM wurden diese von der breiten Masse wahrgenommen und es konnte den heutigen Anforderungen beigekommen werden. Dabei gibt es auch Lösungen, welche mit gängiger Standardhardware -und Software eine nicht unbeachtliche Zahl an Kunden aufweisen können. Nachfolgend sollen ausgewählte Beispiele im Vergleich zu der bereits vorgestellten SAP-HANA-Lösung aufgezeigt werden.
Oracle Exalytics
Oracle stellte im Herbst 2011 seine Analytics-Appliance Exalytics vor. Diese besteht im Kern aus der In-Memory-Datenbank TimesTen und dem Data Warehouse Essbase.
Die In-Memory-Datenbank TimesTen wird von Oracle seit 2005 angeboten und wird selbst immer weiter entwickelt. Zunächst war die Datenbank als zusätzlicher Cache für bestehende Oracle-Datenbanken ausgelegt. Aktuell kann TimesTen nun auch analytische Daten verarbeiten und beherrscht die Komprimierung von Spalten im Speicher. Auch sind mehrere Replikationsvarianten vorhanden, sodass bei einem Ausfall einer TimesTen-Instanz ein Failover initiiert werden kann (vgl. Ott & Stirnimann, 2012, S. 24).
Parallel zu Exalytics stellt Oracle 2011 auch eine neue Version seiner Business Intelligence Foundation Suite vor, welche die Ansteuerung der Exalytics Software optimieren soll. Die Hardware besteht aus Oracles Sun-Fire-Server mit 1 TByte RAM und einem Intel Xeon E7-4800. Die In-Memory Analytics Hardware skaliert auf bis zu 40 Kerne. Bei der Analyse und Auswertung der Daten soll es laut Oracle nicht von Bedeutung sein, ob diese relational, multidimensional oder unstrukturiert vorliegen. Dabei sorgt ein anpassungsfähiges In-Memory-Caching dafür, dass die Anwendungsdaten schnell in den Speicher geladen werden (vgl. Murthy & Goel, 2011). Abb. 7 zeigt einen Überblick des Oracle-Systems.
Quelle: (Murthy & Goel, 2011)
Ein direkter Vergleich zwischen HANA und Exalytics gestaltet sich schwierig, da die jeweils eingesetzte Architektur eine andere ist. Oracle setzt mit Exalytics nicht vollständig auf die In-Memory-Technik. Es werden auch relationale Datenbankstrukturen mit den zugehörigen Duplikationen und Aggregationen unterstützt. Vor allem durch Nutzung der TimesTen werden diese zu einer In-Memory-Lösung ergänzt. Der Vorteil dieser Lösung liegt jedoch v.a. darin, dass bestehende Anwendungen, Datenbanken und Data Warehouses direkt übertragbar sind. Aus Kostensicht ist diese Lösung nur ein Addon für eine schon bestehende Installation. Betreibt man also derzeit ein SAP-System auf einer Oracle Datenbank, so müssen weiterhin mit Kosten für bis zu vier Lizenzen gerechnet werden (Transaktionsdatenbank, Datawarehouse, TimesTen und/oder Essbase).[8]
IBM DB2 Analytics Accelerator
Die IBM-DB2-Analytics-Accelerator-Lösung[9] bietet die Möglichkeit, Datenbankabfragen zu beschleunigen und so für eine massive Reduzierung der Antwortzeit zu sorgen. Um dies zu erreichen, werden bestimmte Queries auf ein externes System ausgelagert, welche dann mit Hilfe eines Accelerators beschleunigt werden. Die Lösung besteht aus Hardware- und Softwarekomponenten und ist in ein DB2 for z/OS Data-Warehouse-Umfeld integriert.
So werden vor allem Kunden angesprochen, die ihr bereits bestehendes DB2-Umfeld beibehalten und keine Umstrukturierung vornehmen möchten. User und Anwendungen können wie gewohnt mit dem DB2 for z/OS System verbunden werden.
Der Accelerator selbst verwendet drei Komponenten (IBM Redbooks, 2012, S. 35): Es gibt zwei SMP-Hosts (Symmetric Multi Processing, auch Coordinator gennant). Diese sind dafür verantwortlich SQL-Requests entgegenzunehmen und zu optimieren, indem sie einen „Execution-Plan“ erstellen. Weiter gibt es je nach gewähltem Modell eine bestimmte Anzahl an S-Blades (Snippet-Blades). Auf diesen befinden sich Quad-Core-CPUs und FPGAs (field programmable gate array). FPGAs sollen sicherstellen, dass der jeweiligen CPU nur die nötigsten Daten zur Ausführung einer Query zugeteilt werden. Mit diesem Lösungsansatz wird vor allem der Performancegewinn des Systems erklärt. Laut IBM sollen Queries mit der Hybridlösung, bestehend aus DB2-System und Accelerator, bis 1908-mal schneller ausgeführt werden, als mit dem herkömmlichen DB2. Diese Ergebnisse stammen aus einem Beta-Test.[10]
Die nachfolgende Abbildung soll einen kurzen Überblick über den Aufbau der Hybridlösung geben.
Quelle: (IBM Redbooks, 2012, S. 38)
Zusammenfassend gliedert sich die Lösung in folgende Bestandteile (IBM Corporation Software Group, 2011) :
Software-Komponenten
- IBM DB2 Analytics Accelerator Software, die mit Hilfe von massiv paralleler, preisoptimierter Standard-Hardware eine High-Performance-Lösung implementiert und so für beschleunigte Query Results sorgt, die mittels Stored Procedures erreicht werden.
- DB2 for z/OS System
- IBM DB2 Analytics Accelerator Studio, basierend auf IBM Data Studio.[11]
- Massiv parallele Intel-Xeon-Systeme
- IBM System-Storage-Lösungen
BigMemory von Terracotta
Diese Lösung verspricht eine Realisierung der In-Memory-Technologie mit Standard Hard- und Software. Ziel ist es, den Hauptspeicher eines Servers mit BigMemory unbegrenzt nutzen zu können. Terracotta bietet dabei zwei Lösungsansätze an, welche sich in den beiden verfügbaren Versionen widerspiegeln. Es stehen die Version BigMemory Go und BigMemory Max bereit (vgl. Weiss, 2012). Bei BigMemory Go (s. Abb. 9) kann der gesamte Hauptspeicher eines Servers genutzt werden.
Die Max-Version (s. Abb. 10) bietet die Möglichkeit den Hauptspeicher mehrerer Server zu einem einzigen Speicher zu vereinen (In-Memory-Storage-Array).
SAP und Terracotta verfolgen mit ihren Lösungen dieselben strategischen Gemeinsamkeiten: Bestehende Anwendungsarchitekturen sollen erweitert und optimiert werden. Es soll die Möglichkeit nach neuen Architekturen geschaffen werden, welche dann auch ohne eine Datenverarbeitung über die Festplatte auskommen sollen.[12]
Dabei eignet sich SAP HANA vorwiegend für die Nutzung analytischer Anwendungen, mit der Anforderung an sehr schnelle Antwortzeiten. Terracotta hingegen eignet sich vorwiegend für die Nutzung von zeitkritischen und transaktionsintensiven Java-Anwendungen. Dabei werden von Terracotta derzeit auch APIs entwickelt und bereitgestellt, welche es ermöglichen sollen, dass auch Anwendungen, die nicht in Java implementiert sind, auf die Lösung zugreifen können (vgl. Weiss, 2012).
Ein Nachteil der SAP HANA-Lösung ist, dass Hardware und Software abgestimmt sein muss und diese damit sehr kostenintensiv ist. Terracotta ist dabei die günstigere Alternative. Die reine Server-Lösung lässt die verteilten Serverknoten unter Einsatz von Standardhardware hoch skalieren und ist durch Erweiterung um zusätzliche Server anpassbar. Die verteilte Caching-Architektur zeigt ihre Vorteile vor allem bei Java-Anwendungen, wie sie im Web anzutreffen sind, wobei die Verarbeitung der Zugriffe und Transaktionsdaten stark beschleunigt werden.
Zusammenfassend ist zu sagen, dass es neben der beschriebenen SAP HANA noch andere Möglichkeiten gibt in die In-Memory-Technologie einzusteigen. Zur Auswahl einer geeigneten Lösung muss immer das bereits verwendete System des Unternehmens betrachtet werden. Da der Schwerpunkt der vorliegenden Arbeit auf SAP HANA liegt, soll diese im weiteren Verlauf kritischer näher betrachtet werden.
Bewertung
Hier sollen nun unterschiedliche Sichtweisen zur SAP HANA Datenbank aufgezeigt werden. Zunächst erfolgt in kurzer Zusammenfassung die SAP Marketing-Sicht bzw. Marketing-Versprechungen. Hierzu wird der Grundtenor der SAP Marketing-Unterlagen[13] zusammengetragen, welche genutzt werden, um potentielle HANA-Kunden anzusprechen. Darauf folgt eine Betrachtungsweise unter Wirtschafts- und Informatikaspekten.
Aus Sicht des Marketing
Riesige Datenmengen in Höchstgeschwindigkeit analysieren
SAP HANA stellt den Kern eines jeden Echtzeitunternehmens dar und ermöglicht es Kunden, große Datenmengen aus fast jeder Quelle in Echtzeit zu analysieren. Laut SAP konnten bei einem Unternehmen der Bauwirtschaft Reportings bis zu 3.600-mal schneller als mit herkömmlichen Festplatten und Datenbanken ausgeführt werden. (Systemgrundlage war hierbei ein vierfach-Server mit acht Kernprozessoren, 0,5 Terrabyte Hauptspeicher, zwei Terrabyte SSD-Speicher und 1 GB Ethernet).[14]
Verarbeitung von strukturierten und unstrukturierten Daten
Mit SAP HANA lassen sich strukturiere als auch unstrukturierte Daten aus sowohl internen als auch externen Datenquellen verarbeiten. Zudem lässt sich SAP HANA in eine Vielzahl von Unternehmensanwendungen einbinden, wodurch es möglich ist, Daten von IBM DB2, Oracle Datenbanken als auch Microsoft SQL Server zu bearbeiten.
Weniger Ebenen, vereinfachte IT-Landschaft und niedrige Kosten
Im Gegensatz zu komplexen Data Warehouses reduziert oder vermeidet man Datenaggregationen, Indizierungen sowie ETL-Schritte (Extraktion, Transformation und Laden). Zudem spart man Kosten bei Echtzeitberechnungen.
Weitere Gründe laut SAP sind:
- Abruf von Transkationen entscheidender Geschäftsvorgänge in Echtzeit.
- Umfassende und vorausschauende Analysen liefern neue Erkenntnisse.
- Innovationen ohne Unterbrechung des Geschäftsbetriebs realisieren.
Aus Sicht der Wirtschaftsinformatik
Um die Vorteile von SAP HANA voll auszuschöpfen, genügt es nicht sie als „Golden Hammer“ einfach unter ein bestehendes SAP-System zu stellen. Unternehmen müssen überlegen für welche Aufgaben SAPs In-Memory-Technologie für sie am besten geeignet ist und den größten Mehrwert bietet. Schließlich sind mit der Anschaffung auch beträchtliche Kosten verbunden.
Kosten und Anpassungen
Vor einer entsprechenden Investition in die In-Memory-Datenbanktechnologie gilt es die Kostenseite zu betrachten. Hierbei sind Ausgaben zu nennen, welche aufgrund von Anpassungen bestehender Softwareanwendungen verursacht werden. So können laufende ERP- und BI-Anwendungen nicht ohne signifikante Modifikationen auf eine In-Memory-Umgebung übertragen werden. Die entstehenden Kosten für das Reengineering existierender BI-Prozesse oder für die Anpassungen (u.U. eigenentwickelter) Datenbankskripte können beträchtlich sein. Auch für die Anschaffung neuer Hardware wie bspw. Blade Server und ausreichend RAM ist mit Kosten zu rechnen. Die Höhe ist hierbei abhängig vom Stand der aktuellen Infrastruktur.
Basierend auf der Gesamtgröße des Speichers, der Anzahl an Prozessoren, sowie der User-Anzahl entstehen Kosten für Software-Lizenzen und Support für In-Memory Datenbanken. Diese können auch dann relevant sein, wenn ein Unternehmen den Ansatz verfolgt, bestehende Datenbanken und Data Warehouses mit neuen In-Memory-Datenbanken für OLAP zu verbinden („Hybridansatz“) (vgl. P. Loos, 2011, S. 388).
Architektur, Geschäftsprozesse und Performance
Durch die Verschiebung der Logik aus der Anwendungsschicht in die Datenbankschicht erlangt man eine deutliche Performance-Steigerung, jedoch werden dabei auch neue Architekturen und Konzepte für die Schichten und das Data Warehouse nötig.
Ein Vorschlag für den Einsatz von SAP HANA ist eine Umwandlung vom Kontrollfluss zu Datenfluss und damit zu einem datenzentrischen Entwurf. Die derzeitige Situation ist, dass ein Großteil betrieblicher Anwendungen kontrollflussorientiert strukturiert sind. Dabei müssen notwendige Daten an die nächsten Schritte mitgeschleppt werden. Will man die In-Memory-Technologie effizient einsetzen, so ist es notwendig die Modellierung und Implementierung von Geschäftsprozessen, sowie deren Anwendungen in einen Architekturansatz zu überführen, bei dem die Daten im Zentrum stehen. Die Daten bestimmen bei SAP HANA die Abarbeitungssemantik. Erste Versuche mit der SAP In-Memory-Technologie haben gezeigt, dass ein solcher Architekturansatz auf einer identischen Hardware bzw. Plattform, eine Laufzeitverbesserung in hohem Grad erzielen kann. Hieraus ergibt sich zudem die Gelegenheit zur erneuten Prozessuntersuchung und
Prozessoptimierungsmöglichkeit.
Komplexität
Durch SAP HANA kann die Komplexität, die meist durch Techniken zur Leistungsverbesserung verursacht wird, reduziert werden, wenn alle Daten im Hauptspeicher vorgehalten werden.
Daten, Logik und Algorithmen befinden sich bei SAP HANA auf nur einem Systembaustein und nicht verteilt auf separate Serverkomponenten, was dazu führt, dass der Transfer von Daten minimiert wird. Der Vorteil ist, dass Daten und Code viel effizienter interagieren können, allerdings natürlich nur unter der Voraussetzung, dass der Quellcode für diese Plattform geschrieben bzw. angepasst wurde. Leider ist ein Großteil der bestehenden SAP-Anwendungen und des SAP-Codes nicht optimal zur Verwendung auf HANA geeignet. Will man HANA-native Anwendungen entwickeln, so sind zunächst neue Skills gefragt, einschließlich des SAP SQL-Script und Datenmodellierungskenntnisse.
Weitere Vorteile
SAP HANA ermöglicht insgesamt extrem hohe Performance für Auswertungen und Echtzeitanalysen. Analysemodelle sind damit schnell erstellt. Die Datenanalyse bzw. Aggregation im Hauptspeicher ist optimiert für den SAP Netweaver BW. Zusätzlich funktioniert HANA als Platform-as-a-Service-Lösung für SAP, durch ein Angebot nativer HANA-Apps. SAP arbeitet mit Hochdruck an der Entwicklung dieser Anwendungen direkt auf der HANA DB. Ein Echtzeitzugriff wird damit auch unterwegs möglich.
Kritik und offene Fragen
Insgesamt darf man sich also nicht auf den ersten Blick hinreißen lassen von den Versprechungen und Visionen von SAP, sondern muss vor einer entsprechenden Investition vielerlei Faktoren berücksichtigen. So bringt der Einsatz einer neuen Datenbank und neuer Technologien auch stets Risiken mit sich. Sowohl Hardware als auch Software sind mit sehr hohen Kosten verbunden. Eine Skalierbarkeit ist dabei jedoch wenig gegeben und mit weiteren Kosten verbunden (Hardware-Erweiterung). Weiterhin sind die Qualitäten Sicherheit und Hochverfügbarkeit als nicht ausreichend zu benennen. Die Sicherheit leider darunter, dass derzeit eine Verschlüsselung zur Kommunikation mit HANA erst in Planung ist.[15] Eine Hochverfügbarkeit ist durch Replikation möglich, wobei jedoch eine Synchronisation mit einem zweiten HANA System teuer und zeitverzögert wäre. Ein Crash des ersten Systems könnte den Verlust noch nicht replizierter Daten bedeuten. Weiterhin muss erwähnt werden, dass derzeit lediglich SUSE Linux als Betriebssystem für SAP HANA unterstützt wird und eine Virtualisierung (VMware) nur beschränkt möglich ist. Ferner lohnt sich die HANA DB primär nur im Zusammenspiel mit SAP Software. Unklarheiten bestehen darüber hinaus bei Lizenzbedingungen, Interoperabilität, der Kompatibilität bei einer User-Anzahl von über 1000, einheitlichen Interfaces, tatsächlichen Preisen und ROI-Überlegungen.
Fazit
SAP verfolgt erfolgreich das Ziel der extremen Performance. Darunter leiden allerdings andere nicht-funktionale Eigenschaften des Systems. Für die SAP selbst ist dies zudem ein Paradigmenwechsel und neuer Markt mit unerforschten Herausforderungen. Nur mit einer starken interdisziplinären Zusammenarbeit von Anwendungswissen und Systemarchitektur ist die volle Mächtigkeit der In-Memory-Technologie auszunutzen. Es muss sich mit alternativen Strukturierungs-, Modellierungs- und Programmierungsansätzen beschäftigt werden. So müssen Datenstrukturen und Basisalgorithmen angepasst werden, damit die extreme hohe Verfügbarkeit an Parallelität genutzt werden kann.
Persistenz muss trotz In-Memory-Technologie zugesichert werden können. Besonders die Konsistenz und Beständigkeit der Daten erfordert entsprechende Strategien (Logging aller Transaktionen auf Festplatte) sowie spezielle Hardware für Backup und Recovery.
Ob ein Umstieg auf SAP HANA wirtschaftlich lohnenswert ist, hängt von vielen Faktoren und Überlegungen ab, da eine Migration Kosten für Hardware, Lizenzen, Aufwand und Wartung mit sich bringt. Weiterhin ist auch die Hochverfügbarkeit ein wichtiger Faktor für Unternehmen.
Fakt ist, dass heutige In-Memory-Datenbanken in den meisten Anwendungsfällen deutliche Performance-Vorteile gegenüber traditionellen Datenbanksystemen zeigen und in Zeiten fallender Hardware-Preise die Anschaffung eines In-Memory-Systems genauso für mittlere wie für kleine Firmen möglich wird.
Fakt ist, dass heutige In-Memory-Datenbanken in den meisten Anwendungsfällen deutliche Performance-Vorteile gegenüber traditionellen Datenbanksystemen zeigen und in Zeiten fallender Hardware-Preise die Anschaffung eines In-Memory-Systems genauso für mittlere wie für kleine Firmen möglich wird.
Trotz vieler Herausforderungen stellt der In-Memory-Ansatz unserer Meinung nach ein hohes Potential und eine viel versprechende Entwicklung für zukünftige BI-Anwendungen dar. Es wird langfristig eine weite Verbreitung von SAP HANA stattfinden, da die SAP das Produkt in den Mittelpunkt aller Anwendungen und Entwicklungen stellt. Die Antwort auf alle Fragen zum Datenmanagement ist HANA sicherlich nicht. Entgegen der Behauptung[16] von Oliver Bussmann (CIO, SAP AG), werden auch in Zukunft relationale Datenbanken ihren Einsatz in Unternehmen finden, welche auch künftig nicht alle ihre Daten in In-Memory-Datenbanken verwalten, sondern ebenso Lösungen von Drittanbietern einsetzen.
Ausblick
Die In-Memory-Technologie verursachte einen Umbruch, der sowohl Anwender als auch Anbieter betrieblicher Unternehmenssoftware, die aktuelle Lage aus einer anderen Sicht sehen lässt. Es ist ersichtlich geworden was die Datenhaltung im Hauptspeicher ermöglicht und was nicht. Selbstverständlich müssen zuerst Anwendungen nachgezogen bzw. angepasst werden, es ist jedoch out-of-the-box-Denken gefragt! Aus Sicht der Wirtschaftsinformatik müsste man hier die betriebswirtschaftlichen Anforderungen und die neuen technischen Möglichkeiten vereinen.
Es ist anzunehmen, dass viele Data Warehouses verschwinden werden, da komplexe Anfragen zur Entscheidungsunterstützung direkt aus der In-Memory-Datenbank beantwortet werden. Darüber hinaus entfallen Indizes, Views, etc., da die Daten bei Bedarf einfach komplett neu verarbeitet werden können. (Plattner, 2009, S.1-2). Damit findet auch eine Reduktion der Komplexität der Datenbankadministration statt.
Mit der In-Memory-Datenbank HANA hat SAP den Gedanken weiterentwickelt OLTP- und OLAP-Funktionalität in einer Hauptspeicherdatenbank zu vereinen. Informationen, welche in Giga- oder sogar Terabyte im RAM abgelegt werden, ergeben hohe Laufzeitverbesserungen. Laut Lenz (In-Memory ist Trumpf, 2012)[17] liegt in einigen Fällen „der Optimierungsfaktor bei 100“. Dafür wurden Hardware- und Softwarekomponenten eigens zertifiziert und bilden die Infrastruktur der SAP High Performance Analytic Appliance.
In-Memory-Datenbanken stellen heute in Sachen Performance eine gute Lösung dar, haben jedoch auch weiterhin ihre Schwächen, wie Hardware-Kosten oder wenn die Datenbankgröße mehrere Terabyte beträgt. Optimierungen und Weiterentwicklungen gehen aber voran. Erste Hersteller experimentieren schon heute mit dem noch schnelleren Prozessor-Cache als Zwischenspeicherung von Ergebnissen komplexer Analyseabfragen (vgl. Brenckmann & Pöhling, 2012). Auch der Einsatz von Grafik-Prozessoren statt CPUs wird in Zukunft ein interessantes Thema darstellen.
Zusätzlich wächst der Markt des Cloud Computing und hat seine Auswirkungen auf das Gebiet des Business Intelligence, sodass die Cloud in Zukunft die nötige Performance liefern könnte.
Zusätzlich wächst der Markt des Cloud Computing und hat seine Auswirkungen auf das Gebiet des Business Intelligence, sodass die Cloud in Zukunft die nötige Performance liefern könnte.
Eine der vier Regeln von Nathan Myhrvold (Ex-Technologiechef, Microsoft) lautet „software is a gas“, die hier auch auf „data is a gas“ übertragen werden kann. Wenn mehr Dateninformation gespeichert und verarbeitet werden kann, so wird dieser Raum auch ausgefüllt werden.[18] Noch hat sich das Gas der Daten aus Sicht der betrieblichen Anwendungen nicht ausgebreitet, aber dies wird sich wohl schnell ändern. Ein vielversprechendes Anwendungsgebiet dafür ist z.B. die Simulation und Prognose verschiedener Szenarien, anhand gesammelter (Sensor-)Daten.
Zum Schluss lässt sich zusammenfassen, dass nach einer Phase der dramatischen
Vereinfachung, wie sie gerade im Datenbankmanagement-Bereich stattfindet, eine Phase
zunehmender Komplexität stattfinden wird. Es bleibt zu hoffen, dass die Komplexität nur langsam ansteigen wird und der nächste Umbruch bald erreicht wird, sodass wiederum dramatische Vereinfachungen ausgelöst werden, bevor wieder die Komplexität heutiger Informationssysteme erreicht ist.
Online Quellen
[2] Non-Uniform Memory Architecture: Verfahren zur Bereitstellung eines lokalen, für eine CPU günstig zu erreichenden primären Speicherbereichs auf welchen andere CPUs über Remoteaufrufe ebenfalls zugreifen können. Ziel ist es den Speicherzugriff zu optimieren, eine CPU besser auszulasten und somit den FSB zwischen CPUs und Hauptspeicher (als Flaschenhals in UMA-Systemen) zu entlasten.
[3] Solid State Drive: Persistenter Massenspeicher, der sich aus Halbleitern zusammensetzt und im Gegensatz zu einer Festplatte über sehr viel schnellere Zugriffszeiten verfügt.
[13] Zehn Gründe, warum Unternehmen ihre Zukunft mit SAP HANA gestalten
[14] Zehn Gründe, warum Unternehmen ihre Zukunft mit SAP HANA gestalten, S.3
Weitere Quellen und Literatur
Bog, A., Sachs, K.& Zeier, A. (2011). Benchmarking Database Design for Mixed OLTP and OLAP. ICPE '11, S. 417-418.
Computerwoche. (13. Oktober 2012). Datenanalyse: Arbeitsspeicher statt Olap. Abgerufen am 29. November 2012 von http://www.computerwoche.de/heftarchiv/2006/42/1216466/
IBM Corporation Software Group. (2011). DB2 Analytics Accelerator for z/OS.
Abgerufen am 07.01.2013 von http://public.dhe.ibm.com/common/ssi/ecm/en/imb14125usen/IMB14125USEN.PDF
IBM Redbooks. (2012). Optimizing DB2 Queries with IBM DB2 Analytics Accelerator for z/os. Vervante.
Kleis, W., Bendelac, C. & Boban, C. (2012, Januar 1). SAP Architecture Bluebook - The SAP HANA Database
Murthy, V. & Goel, M. (2011). Oracle Exanalytics In-Memory Machine:A Brief Intorduction. Abgerufen am 07.01.2013 von http://www.oracle.com/us/solutions/ent-performance-bi/business-intelligence/exalytics-bi-machine/overview/exalytics-introduction-1372418.pdf
Ott, J., & Stirnimann, R. (März 2012). In-Memory-Datenbanken im Vergleich. Computerwoche, S. S. 24-27.
Plattner, H. (2009). A common database approach for OLTP and OLAP using an in memory column database.Proc ACM SIGMOD international conference.
Plattner, H., & Zeier, A. (2011). In-Memory Data Management.Heidelberg: Springer Verlag.
Plattner, H., Krueger, J., Grund, M., Tinnefeld, C., Eckart, B., & Zeier, A. (2010). Hauptspeicherdatenbanken für Unternehmensanwendungen. Abgerufen am 20. Dezember 2012 von http://ares.epic.hpi.uni-potsdam.de/apps/static/papers/Version_11.10.2010.pdf
Schneider, U., & Werner, D. (2007). Taschenbuch der Informatik (6.Ausg.). München: Hanser Verlag.
SAP AG. Zehn Gründe, warum Unternehmen ihre Zukunft mit SAP HANA gestalten.
Abgerufen am 05. Januar 2013 von http://download.sap.com/germany/download.epd?context=936867B8E0DC5325DADDF359031BA306F5F4B0BB9C081594F5B73B6E4AE5C681819D4D096904F1B1E4015D7646BAF6A18A6C264B40C7ABCD
Prof. Dr. Peter Loos. (2011). In-Memory-Datenmanagement in betrieblichen
Anwendungssystemen. Gabler-Verlag.
Weiss, H. (2012). Terracotta: In-Memory ohne Appliance. Abgerufen von http://www.heise.de/developer/artikel/Terracotta-In-Memory-ohne-Appliance-
1763366.html
