In-Memory Technologie. Untersuchung der Ersetzbarkeit von OLTP-basierten Datenbanken


Seminararbeit, 2016

22 Seiten, Note: 1,7


Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einführung und Zielsetzung

2 Erläuterung der Begrifflichkeiten
2.1 In-Memory Technologie
2.2 Säulen der In-Memory Technologie nach Plattner und Erläuterung der SanssouciDB
2.3 Reihenbasierte Speicherungsstruktur (OLTP) versus Spaltenbasierte Spei- cherungsstruktur (OLAP)

3 Ablösung der OLTP-basierten Datenbanken
3.1 Exklusiver Einsatz von OLAP-basierten In-Memory Datenbanken
3.2 Verwendung einer hybriden Struktur
3.3 Bewertung dieser Einsatzmöglichkeiten

4 Fazit und Ausblick

A Anhang
A.1 Tabelle für die Bewertung von EXASOL
A.2 Tabelle für die Bewertung von SAP HANA

Literaturverzeichnis

Abbildungsverzeichnis

2.1 In-memory Technologie

2.2 Architektur der SanssouciDB

2.3 Verteilung der Anfragearten

Tabellenverzeichnis

2.1 Demonstration der Unterschiede von Speicherarten

3.1 Demonstration einer hybriden Speicherstruktur

3.2 Demonstration des Data Dictionary

3.3 Datenlexikon für die Spalte Land

3.4 Komprimierte Tabelle unter Anwendung des Data Dictionary Algorithmus

3.5 Bewertung der vorgestellten Lösungen EXASOL und SAP HANA

A.1 Begründete Bewertung der vorgestellten Lösung EXASOL

A.2 Begründete Bewertung der vorgestellten Lösung SAP HANA

1 Einführung und Zielsetzung

Das Thema In-Memory Data Management (IMDM) ist aktuell im Rahmen der Diskussion um Big Data und Data Mining im Fokus. Hierbei stellt Welker (2015, o. S.) grundsätzliche Fragen zu der Zukunft des Business Intelligence und dem Data Warehouse. Er stellt heraus, dass die In-Memory Technologie hier deutliche Vorteile für die Analyse der Daten bringen kann. Zudem betont er auch, dass In-Memory nicht nur für analytische Zwecke, sondern auch für transaktionale Funktionen (Online Transactional Processing (OLTP)) Vorteile bieten kann. Ferner wird von Vaisman und Zimányi (2011, S.13) diskutiert, ob Real-Time Data Warehousing die Lösung des Problems, das immer mehr Daten in Echtzeit analysiert werden müssen, sein könnte.

Diese geforderte Aktualität und die Handhabung großer Datenmengen wird zuneh- mend mithilfe der In-Memory Technologie versucht zu lösen. Es stellt sich jedoch die Frage, ob die Technologie in der Lage ist, sowohl transaktionale als auch analytische Ope- rationen auszuführen. Diese Verknüpfung könnte den entscheidenden Vorteil bringen, da somit die Daten, die später analysiert werden müssen, bereits in diesem System erfasst und bearbeitet werden können. Das könnte einen erheblichen Performancegewinn bringen. Wie Matt (2012, S. 229) hervorhebt, ist es für Unternehmen durch den zunehmenden in- ternationalen Wettbewerb wichtiger geworden, schnell Entscheidungen treffen zu können. Diese Geschwindigkeit kann nur erreicht werden, wenn Daten, die für die Entscheidung notwendig sind, in Echtzeit vorliegen und ausgewertet werden können. Die gemeinsame Verarbeitung von Daten in einem System wäre ein wichtiger Schritt, da somit die reinen transaktionalen OLTP-basierten Systeme überflüssig wären und die IT-Infrastruktur da- mit erheblich vereinfacht werden könnte. Es würde nur noch analytische Systeme geben, die auch für den operativen, transaktionalen Bereich (z.B. Enterprise-Resource-Planning- System) eingesetzt werden können. Auf diesen können sehr schnell Analysen mit Echt- zeitdaten durchgeführt werden und ein zeit- und rechenaufwändiger Extract-Transform- Load-Prozess (ETL) wäre nicht mehr notwendig.

Mit dieser Arbeit soll untersucht werden, ob die In-Memory Technologie die bei- den Welten verknüpfen kann. Im ersten Schritt wird die In-Memory Technologie kurz vorgestellt und es werden die Begrifflichkeiten OLTP und Online Analytical Processing (OLAP) erläutert. Anschließend wird untersucht, ob eine reine OLAP-basierte Datenbank die transaktionalen Funktionalitäten abdecken kann und ob diese eine rein reihenbasierte Speicherung ersetzen kann. Nach dieser Untersuchung wird die hybride Struktur beleuch- tet, ob sie die OLTP-basierten Datenbanken ablösen kann. Anschließend wird eine Bewer- tung dieser Möglichkeiten durchgeführt und ein Fazit gezogen. Da der Umfang der Arbeit begrenzt ist, sei der Leser bei grundlegenden Zusammenhängen auf die Literaturliste wie beispielsweise Plattner (2012) verwiesen.

2 Erläuterung der Begrifflichkeiten

In diesem Kapitel soll zunächst erläutert werden, was unter der In-Memory Technologie verstanden wird und warum diese seit den letzten Jahren aktuell ist. Die Vorteile und Einsatzmöglichkeiten runden das erste Unterkapitel ab. Anschließend werden eine Über- sicht über die Technologien angeführt und die Sanssouci Datenbank skizziert. Daran an- schließend werden die Unterschiede zwischen der reihenbasierten und der spaltenbasierten Speicherstruktur diskutiert.

2.1 In-Memory Technologie

Hauptspeicherdatenbanksysteme speichern die Daten nicht auf der Festplatte, wie es tra- ditionellen Datenbanksystemen (DBS) machen, sondern im Hauptspeicher. Das hat nach Loos (2011, S. 383) zur Folge, dass schneller auf die Daten zugegriffen werden kann und kei- ne zeitintensiven Zugriffe auf die Festplatte von Nöten sind. Diese Ideen sind grundsätzlich nicht neu, da es nach Loos (2011, S. 384) bereits in den 1980er Untersuchungen zu diesem Thema gab. Jedoch hat das Thema erst in den letzten Jahren an Auftrieb gewonnen, da sich die technischen Möglichkeiten verbessert haben. So sind nach Matt (2012, S. 229) die Arbeitsspeicherpreise gefallen und die Entwicklung von 64-bit Prozessoren förderte die In-Memory Technologie zusätzlich, da nun auch größere Datenbestände im Hauptspei- cher gehalten werden können und keine Beschränkung mehr bei vier Gigabyte besteht. Neben diesen beiden Fortschritten ist auch die Entwicklung der Multi-Core-Prozessoren (Multicore CPUs) förderlich gewesen, da nun auf einem Chip mehrere Hauptprozessoren vorhanden sind und damit mehrere Prozesse (z.B. Datenverarbeitung) gleichzeitig laufen können. Auf der Grundlage der technischen Fortschritte ergeben sich Möglichkeiten einer innovativen, zeitgemäßen Datenhaltung.

Ein wichtiger Vorteil der In-Memory Technologie ist vor allem die schnellere Verfügbar- keit von Daten. Nach Matt (2012, S. 230) können Prozesse nahezu in Echtzeit laufen und somit sind beispielsweise Ad-hoc Reports in Meetings möglich. Resultierend können Ent- scheidungen auf Basis der aktuellen Datenlage getroffen werden. Die schnellere Verfügbar- keit der Daten ermöglicht den Verzicht des ETL-Prozesses, der im traditionellen Data Warehouse die Daten von den operativen Systemen in die Auswertungsdatenbank lädt und gleichzeitig transformiert und vereinheitlicht. Der ETL-Prozess ist hier nicht notwen- dig, da die Analysen direkt auf die Daten in der Datenbank zugreifen können und nicht erst in ein anderes DBS geladen werden müssen. Neben diesem wichtigen Vorteil ist auch die vereinfachte Datenanalyse ein wichtiger Grund für die In-Memory Datenbanken. Nach Matt (2012, S. 230) können verschiedene Daten aus unterschiedlichen Einzelsystemen (z.B. ERP-System und Webanwendung) einfacher zusammengeführt werden, ohne dass zuvor eine aufwendige Konsolidierung stattfinden muss. Wie bereits angesprochen, entfällt der

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Säulen der In-Memory Technologie nach Plattner (2012, S. XXXII)

ETL-Prozess und deshalb entstehen hierbei keine Transformations- und Übertragungs- fehler. Dementsprechend ist die Datenqualität bei In-Memory Datenbanken höher.

Eine wichtige Einsatzmöglichkeit der In-Memory Technologie ist das Controlling eines Unternehmens. Aufgrund der schnelleren Datenbereitstellung können Kennzahlen rascher abgerufen werden und Berichte stehen zeitnah zur Verfügung. Ein weiterer Nutzen zeich- net sich für das Management eines Unternehmens ab. Die Manager können mithilfe aktu- eller Live-Daten Entscheidungen treffen und Simulationen durchführen. Eine Einführung eines solchen In-Memory Systems ist jedoch mit einem hohen Aufwand verbunden, da viele Anpassungen in den operativen Systemen nötig sind. Des Weiteren muss die IT- Architektur des Unternehmens bereits auf eine 64-bit Infrastruktur umgestellt sein. Des- halb empfiehlt Matt (2012, S. 230) die Einführung nur bei einer hohen Anzahl an zeitlich kritischen Prozessen und Systemen.

2.2 Säulen der In-Memory Technologie nach Plattner und Erläute- rung der SanssouciDB

Mit In-Memory Datenmanagement (IMDM) werden verschiedene Technologien verstan- den. Die Abbildung 2.1 verdeutlicht die einzelnen Technologien, die mit IMDM in Ver- bindung gebracht werden. So stehen die Daten im Zentrum der Technologie und die In- Memory Datenbank soll als einzige Quelle der Wahrheit (single source of truth) im Unter- nehmen gelten. Die Daten können analysiert (Analyze) werden und sie stehen für Vorher- sagen (Predict) zur Verfügung. Auch werden sie für die Ausführung der Geschäftsprozesse verwendet (Execute). Sie stehen demnach sowohl für analytische als auch für transaktio- nale Systeme zur Verfügung beziehungsweise werden mithilfe dieser Systeme erzeugt. Die genannten Systeme können real-time auf die Daten zugreifen, da hier kein aufwändiger ETL-Prozess notwendig ist.

Die vier zentralen Säulen werden im Folgenden genauer erläutert:

- Multi-Core CPUs Heutzutage werden nach Plattner (2014, S. 118) Serversysteme mit mehreren CPUs hergestellt, die wiederum mehrere Kerne haben (sog. Mehrkernprozessor). Dadurch können Prozesse (z.B. Datenbankabfragen) parallelisiert und die Performance erheblich gesteigert werden.
- In-Memory Der Unterschied zu traditionellen Datenbanksystemen ist die Speicherung der Daten im Hauptspeicher. Nur aus Datensicherungsgründen werden Kopien der Daten auf einer Festplatte benötigt.
- Column and Row Store Nach Plattner (2012, S. XXXII) werden die Daten in spalten- und reihenbasierten Speicherstrukturen vorgehalten. Die Verknüpfung dieser unterschiedlichen Strukturen wird als hybride Struktur bezeichnet und die Unterschiede werden in Kapitel 2.3 erläutert.
- Insert-Only Es werden nur Daten hinzugefügt und bei Änderungen oder Löschun- gen nur Kopien der Datensätze eingefügt. Dieser Ansatz kann nach Plattner (2012, S. 123f.) durch zwei Wege umgesetzt werden. Entweder werden nur die Unterschie- de von dem neuen zu dem alten Datensatz gespeichert oder es wird der komplette Datensatz ein zweites Mal gespeichert und der alte Datensatz wird als ungültig markiert.

In der Literatur wird vor allem die Verbindung von spalten- und reihenbasierten Spei- cherstrukturen kontrovers diskutiert. Aus diesem Grund wird in Kapitel 3 ein anderer Ansatz vorgestellt, der sich von dem In-Memory Verständnis nach Plattner und Zeier unterscheidet.

Im Nachfolgenden wird anhand der Sansoussi-Datenbank der Aufbau einer In-Memory Datenbank erläutert. Die SansoussiDB ist am Hasso-Plattner-Institut entwickelt worden und stellt die Grundlage für SAP HANA dar. Die Datenbank, die in der Abbildung 2.2 aufgeführt ist, kann nach Plattner (2014, S. 33) in drei Schichten eingeteilt werden. So ist die erste Schicht (Distribution layer at Server) für die Kommunikation mit den Anwendungen zuständig. Sie führt Anfragen aus, speichert die Metadaten und kontrolliert die Datenbankanfragen.

In der zweiten Schicht ist die eigentliche Datenhaltung (main store) aufgeführt. Im Hauptspeicher werden die Daten entweder zeilenweise, spaltenweise oder in der hybri- den Speicherstruktur, auf die im nächsten Kapitel genauer eingegangen wird, gespeichert. Dieser Hauptspeicher ist nach Plattner (2014, S. 167) für Leseoperationen optimiert und bietet so bei Analysen einen schnellen Zugriff auf die Daten. Jedoch würde bei größe- ren Einfüge- oder Änderungsoperationen dieser zu stark überlastet werden, sodass eine zusätzliche Datenhaltung (differential buffer oder delta store) enthalten ist. Nach Plattner (2014, S. 167) werden hier alle Einfüge-, Änderungs- und Löschoperationen durchgeführt, indem der Datensatz in den Delta Store kopiert wird. Der Delta Store wird regelmäßig mit

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Architektur der Sanssouci Datenbank (Plattner (2014, S. 35)

dem Main Store zusammengeführt und die Änderungen werden wirksam. Jedoch muss bei Leseoperationen sowohl im Main Store als auch im Delta Store gesucht werden, da es noch nicht zusammengeführte Änderungen geben kann. Um definieren zu können, welcher der redundanten Datensätze korrekt ist, wird der Datensatz im Main Store bei einer Einfüge-, Änderungs- oder Löschanfrage als ungültig markiert. Somit kann der geänderte Datensatz ohne Probleme einfach aus dem Delta Store in den Main Store verschoben werden. Neben dem Main Store und dem Delta Store werden in dieser Schicht auch noch die Indizes gespeichert, die für einen performanteren Zugriff auf die Daten sorgen sollen.

Damit beispielsweise bei Stromausfall die Daten im flüchtigen Hauptspeicher jederzeit wiederhergestellt werden können, gibt es zusätzlich einen nicht-flüchtigen Speicher in der dritten Schicht. Hier werden passive Daten, die selten benötigt werden, auf SSDs oder Festplatten gespeichert. Die Auslagerung hat nach Plattner (2012, S. 93) den Vorteil, dass nur die Daten, die wirklich benötigt werden, auch aktiv im Main Store vorgehalten werden und der aktive Speicher nicht zu groß wird. Außerdem finden weitere Sicherheits- mechanismen statt. Es werden Logs geschrieben und sogenannte Snapshots der Datenbank aufbewahrt, um jederzeit den aktuellen Stand der Datenbank wiederherstellen zu können.

2.3 Reihenbasierte Speicherungsstruktur (OLTP) versus Spal- tenbasierte Speicherungsstruktur (OLAP)

Der OLTP-Ansatz geht meist von einer Datenquelle aus und das System verwendet zeit- nahe Daten, die in der Größenordnung von Megabyte bis Gigabyte vorhanden sind (vgl. Humm und Wietek (2005, S. 5)). Meist erfolgt ein Zugriff auf einzelne oder wenige Datensätze. Die Daten sind oftmals aktuell und auf einem niedrigen Detaillierungsgrad und sollen das operative Geschäft unterstützen. Ein Beispiel ist das Anlegen eines Kunden im ERP-System. Dieser Ansatz wird nach Plattner (2014, S. 61) in der Regel mit einer reihenbasierten Speicherungsstruktur kombiniert.

Der OLAP-Ansatz ist nach Farkisch (2011, S. 51ff.) analyseorientierter und nutzt mehrere Datenquellen. Die Daten werden von anderen Datenbanksystemen integriert und liegen abgeleitet vor. Die Daten werden konsolidiert und sind über eine längere Zeit verfügbar. Da sie nicht gelöscht werden, sammelt sich Datenmaterial im Umfang von Gigabyte bis Petabyte im Laufe der Jahre an. Dieser Ansatz wird meist im Data Ware- house benötigt, da hier die Daten für Analysen und Entscheidungen aufbereitet und in verdichteter Form vorliegen. Ein Mitarbeiter will beispielsweise wissen, welche Kunden welche Produkte in welchem Land bevorzugt kaufen. Die Anfrage kann durch eine multi- dimensionale Abfrage mithilfe des OLAP-Ansatzes in einem analytischen System bearbei- tet werden. Hierbei stehen vor allem Lese- und Einfügeoperationen im Vordergrund, da hier keine Daten geändert oder gelöscht werden. Nach Plattner (2014, S. 61) wird dieser Ansatz mit einer spaltenbasierten Speicherungsstruktur kombiniert.

Beide Ansätze sind als sehr verschieden betrachtet worden und sind deshalb mithilfe von zwei unterschiedlichen Arten von Softwaresystemen umgesetzt worden. So wird der OLTP-Ansatz in operativen Systemen verwendet, während der OLAP-Ansatz in analyse- orientierten Systemen wie einem Data Warehouse angewandt wird. Jedoch konnten Krüger (2012, S. 62f.) feststellen, dass bei einer OLTP-basierten Datenbank nicht, wie meist ange- nommen wird, schreibende Tätigkeiten im Vordergrund stehen. Sondern der Workload ist in den beiden Speicherstrukturen OLAP und OLTP vergleichbar (siehe Abbildung 2.3). Der Leseanteil bei OLTP ist bei über 80 Prozent, während er bei OLAP-Systemen über 90 Prozent ist. Hier unterscheiden sich beide Ansätze nur darin, dass bei OLAP öfters größere Bereichs- und Tabellenanfragen und bei OLTP einfachere Leseanfragen bearbei- tet werden. Schreibanfragen werden zu 17 Prozent bei OLTP und zu sieben Prozent bei OLAP bearbeitet.

Diese Untersuchung zeigt, dass OLAP und OLTP nicht so verschieden sind, wie in der Literatur oft angenommen wird und dies die Frage aufwirft, ob sich operative Systeme und analytische System nicht ähnlicher sind als gedacht. Der OLAP-Ansatz wird mit einer spaltenbasierten Speicherung umgesetzt, während der OLTP-Ansatz mit zeilenbasierten Speicherstrukturen arbeitet. Die Art der Speicherung hat natürlich auch Konsequenzen für die Datenbankabfragen. Im Folgenden werden die Möglichkeiten der Speicherung mithilfe der Beispieltabelle 2.1 in Anlehnung an Plattner (2014, S. 61) erläutert.

Die zeilenbasierte Speicherung lautet er“. Hierbei liegt der Vorteil darin, dass ”1,Hans,Müller;2,Lisa,Huber;3,Maria,Mei- Änderungen an einem Datensatz leicht durch-

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Verteilung der Anfragearten bei OLAP und OLTP (in Anlehnung an Krüger (2012, S. 35)

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2.1: Demonstration der Unterschiede von Speicherarten

geführt werden können, da nur der Schlüssel (hier die Nummer) gesucht werden muss, und sogleich Änderungen an den Daten durchgeführt werden können. Ferner kann ein neuer Datensatz schnell hinzugefügt werden, da dieser nur nach dem letzten Datensatz am Ende angefügt wird.

Die spaltenbasierte Speicherung lautet ”1,2,3;Hans,Lisa,Maria;Müller,Huber,Mei- er“. Bei dem Lesen vieler Zeilen einer oder weniger Spalten ist die Speicherart besonders vorteilhaft, da die Zeilen einer Spalte nacheinander gelesen werden können. Beispielsweise können hier Beträge sehr einfach aufsummiert werden.

Zusammenfassend kann nicht eine Speicherart präferiert werden, da es auf die Da- tenbankanfrage ankommt, welche der beiden schneller ausgeführt werden kann. Bei der zeilenbasierten Speicherung sind zeilenbasierte Zugriffe (z. B. einen Datensatz lesen) bes- ser, da hier die Daten direkt nebeneinander stehen. Bei der spaltenbasierten Speicherung hat der spaltenbasierte Zugriff (z.B. Lesen einer Spalte über alle Zeilen) eine bessere Performanz, da hier die Werte einer Spalte hintereinander gespeichert sind.

3 Ablösung der OLTP-basierten Datenbanken

Nachdem in Kapitel 2 die Begriffe In-Memory, OLAP und OLTP erläutert worden sind, soll nun im Folgenden darauf eingegangen werden, ob OLAP-basierte In-Memory Datenbanken mit der spaltenbasierten Speicherung auch in operativen, transaktionalen Systemen eingesetzt werden können. Des Weiteren wird diskutiert, ob es zukünftig nur noch eine Speicherstruktur geben muss und damit auch die operationale mit der analytischen Welt verknüpft werden kann. Die Erläuterungen werden anhand von zwei unterschiedlichen Herangehensweisen durchgeführt. Zum einen wird geprüft, ob auf OLTP komplett verzichtet und OLAP als alleiniger Ansatz eingesetzt werden kann. Zum anderen wird untersucht, ob eine Verknüpfung der beiden Ansätze sinnvoll ist und ein Einsatz dieser hybriden Struktur einen Mehrwert bringt. Am Ende werden diese beiden Möglichkeiten verglichen und es wird eine Empfehlung ausgesprochen.

Für die Untersuchung wird auf eine Marktstudie der Beratungsgesellschaft areto con- sulting GmbH zurückgegriffen (vgl. Mense (2015)). In dieser umfassenden Marktstudie werden die größten Anbieter von In-Memory Datenbanken, darunter SAP, Oracle, IBM etc., untersucht. Den Herstellern ist unter anderem auch die Frage gestellt worden, wie die Daten im Hauptspeicher und in der persistenten Speicherung gehalten werden. So werden bei drei der untersuchten Datenbanken die Daten in einer reihenbasierten Form gespeichert, während bei zwei Anbietern (EXASOL und TIBCO) ausschließlich die spal- tenbasierte Form möglich ist. In den anderen sechs Datenbanken ist beides möglich und meist hat der Anwender auch die Wahl zwischen zeilen- und spaltenbasierter oder der hy- briden Speicherform. Die Angaben beziehen sich auf beide Speichermedien, weil es keine Unterschiede zwischen Hauptspeicher und Festplatte / SSD bei den einzelnen Herstellern gibt.

3.1 Exklusiver Einsatz von OLAP-basierten In-Memory Daten- banken

Es soll nun untersucht werden, ob eine Speicherstruktur genügt, um Daten in einem In- Memory System zu speichern, zu ändern und darauf Analysen zu betreiben. Es gibt hierfür nicht sehr viele Anbieter, die eine exklusive Strategie haben, da beispielsweise Oracle (mit Oracle Database 12c) und SAP (mit SAP HANA) auf eine Verbindung von spalten- und reihenbasierten Strukturen setzen. So ist auch in der oben genannten Studie der deut- sche Spezialist für Datenbankmanagementsysteme EXASOL einer der wenigen, die eine reine OLAP-basierte In-Memory Datenbank anbieten. Es gibt beispielsweise bei Oracle noch die Kombination von einer OLTP-basierten In-Memory Datenbank (Oracle Times- Ten In- Memory Database for Exalytics) und der zugehörigen OLAP-basierten Oracle Exalytics In-Memory-Machine. Jedoch ist Exalytics nur ein zusätzliches System, das wei- terhin OLTP-basierte Vorsysteme und ein Data Warehouse als Datenlieferanten benötigt und ausschließlich für die Auswertung und Analyse der Daten von Nutzen ist (vgl. Weiss (2012, o.S.)).1

Im Folgenden soll nun untersucht2 werden, ob der OLTP-Ansatz gänzlich durch den Einsatz einer OLAP-basierten In-Memory Datenbank, die sich durch eine spaltenbasierte Speicherung auszeichnet, ersetzt werden kann. Für diese Untersuchung wird die Funktionalität der In-Memory Datenbank von EXASOL untersucht. Diese spaltenbasierte InMemory Datenbank wird ausgewählt, da sie eine der ersten ihrer Art war, als sie vor mehr als 15 Jahren veröffentlicht worden ist.

Nachdem EXASOL sich auf die spaltenbasierte Speicherung fokussiert, werden vor allem OLAP-Funktionalitäten wie etwa Gruppierungen oder Joins besonders unterstützt. Grundsätzlich bedingt die Art der Datenbankabfrage den Einsatz einer spalten- oder zeilenbasierten Speicherung (siehe Kapitel 2.3). Jedoch muss diese Faustregel in Zeiten von In-Memory nochmals überprüft werden, da beispielsweise EXASOL auch verschiedenste Möglichkeiten anbietet, um typische OLTP-Funktionalitäten abzudecken. Es werden etwa Anfragen in einem Cache gespeichert, um sie schneller mehrmals auszuführen. Es können nicht nur Business Intelligence (BI) Dashboards schneller mit aktuellen Daten gefüllt werden (klassisch OLAP), sondern auch die Darstellung einfacher Listen aus der gleichen Datentabelle (klassisch OLTP) ist schneller möglich..

Außerdem nutzt EXASOL drei zentrale Funktionen, um Anfragen schneller auführen zu können. Zum einen werden Daten komprimiert (mit Data Dictionary Compression), um alle Daten im Hauptspeicher halten zu können. Zudem werden Daten (v.a. kleinere Tabel- len) mehrmals gespeichert, um Joins zu vermeiden. Der Grund hierfür liegt darin, dass das System Attribute, die öfters gemeinsam abgefragt werden, in einer Tabelle zusammen ab- speichert. Des Weiteren wird versucht, vorherzusagen, welche Daten benötigt werden, um diese bereits im RAM oder im Cache vorzuhalten. Die Funktionen sollen vor allem klassi- sche OLAP-Funktionalitäten wie beispielsweise GROUP BY unterstützen. Ferner profitie- ren nicht nur diese davon, auch Datenmanipulationen als klassische OLTP-Funktionalität können damit performanter ausgeführt werden. So ist die EXASOL Datenbank darauf eingerichtet und ist zudem ACID-konform.

Änderungen an den Daten führen nicht automatisch zu einer Neuorganisation der Datenbank (z.B. Aufbau von Indizes), sondern diese wird erst durchgeführt, wenn die Last gerade gering ist. Vorerst werden beispielsweise nur die zu löschenden Daten als gelöscht markiert. Bei dem Einfügen weniger Daten werden fortlaufende Indizes verwendet und nur diese werden in die Tabelle eingefügt. Alle anderen Daten des neuen Datensatzes werden in einer Art Cache für die eigentliche Tabelle gespeichert. Änderungen an den Daten werden direkt an den Daten ausgeführt. Laut Hersteller ist dieses Vorgehen schneller, als den Umweg über ein Delete und ein Insert der neuen Daten zu gehen.

Hierbei wird deutlich, dass EXASOL auch technische Möglichkeiten anbietet, um klassische OLTP-Funktionalitäten abzudecken. Jedoch wird bei der Produktdarstellung betont, dass eine spaltenorientierte Speicherung Nachteile bei manchen OLTP-basierten Funktionen hat (vgl. EXASOL (2014a, S. 12)). Vor allem das Laden von kleinen Daten-mengen, wie es bei der Anzeige und Anpassung der Daten beispielsweise in ERP-Systemen üblich ist, wird nicht gut unterstützt. Das bedeutet, dass EXASOL zwar OLTP-fähig ist, aber diese Datenbanken nicht ablösen kann. Hierfür gibt Plattner (2012, S. 72f.) ein an-schauliches Beispiel. Bei dem klassischen Laden eines Datensatzes (SELECT * FROM table WHERE a4 = ?) in einer reihenbasierten Struktur wird eine Zeile in dem Cache benötigt und alle anderen müssen erst gar nicht geladen werden. Bei der spaltenbasierten Struktur müssen alle Zeilen geladen werden, da die Daten eines Datensatzes in einer Spal-te über alle Zeilen hinweg gespeichert worden sind. Daraus resultiert ein Mehraufwand und einen Performanzverlust bei der spaltenbasierten Speicherung. Deshalb ist es für EX-ASOL und andere spaltenbasierten In-Memory Datenbanken trotz jeglicher Bemühungen schwerer solche transaktionale Funktionen performant zu unterstützen.

3.2 Verwendung einer hybriden Struktur

Aufbauend auf der Feststellung, dass eine reine spaltenbasierte Speicherung die OLTP- Funktionen nur unzureichend abdeckt, wird in diesem Kapitel untersucht, ob eine Kom- bination aus spalten- und reihenbasierter Speicherung die reine reihenbasierte Lösung ablösen kann. Hierfür wird die Umsetzung bei der SAP HANA Datenbank untersucht. Diese Datenbank hat ihren Ursprung in der Sanssouci Datenbank (siehe Kapitel 2.2).

Eine Verbindung von spalten- und reihenbasierter Speicherung wird als hybride Struk- tur bezeichnet, welche auf zwei Arten umgesetzt werden kann. Zum einen kann sie bis auf Spaltenebene hinunter angewandt werden. Die hybride Struktur auf Spaltenebene soll an der Beispieltabelle 3.1 in Anlehnung an Plattner (2014, S. 63) verdeutlicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 3.1: Demonstration einer hybriden Speicherstruktur

Die Angaben zu Nummer, Vorname und Nachname werden häufig zusammen abge- fragt. Deshalb werden diese auch physikalisch zusammen gespeichert. Es bietet sich die reihenbasierte Speicherung an, weil die drei Daten zu einer Person zusammen abgefragt werden.

[...]


1 Für weitere Informationen hierzu sei auf Murthy (2014) verwiesen.

2 Die Untersuchungen stützen sich vor allem auf Publikationen des Unternehmens (vgl. EXASOL (2014a) und EXASOL (2014b)). Für genauere Informationen zu dieser Technologie sei darauf verwiesen.

Ende der Leseprobe aus 22 Seiten

Details

Titel
In-Memory Technologie. Untersuchung der Ersetzbarkeit von OLTP-basierten Datenbanken
Hochschule
Duale Hochschule Baden-Württemberg, Ravensburg, früher: Berufsakademie Ravensburg  (Wirtschaftsinformatik)
Veranstaltung
Integrationsseminar zu ausgewählten Themen der WI
Note
1,7
Autor
Jahr
2016
Seiten
22
Katalognummer
V335518
ISBN (eBook)
9783668254480
ISBN (Buch)
9783668254497
Dateigröße
1209 KB
Sprache
Deutsch
Schlagworte
HANA, Informatik, SAP, OLAP, OLTP, Datenbank, Data Warehouse, In-Memory
Arbeit zitieren
Carina Butz (Autor:in), 2016, In-Memory Technologie. Untersuchung der Ersetzbarkeit von OLTP-basierten Datenbanken, München, GRIN Verlag, https://www.grin.com/document/335518

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: In-Memory Technologie. Untersuchung der Ersetzbarkeit von OLTP-basierten Datenbanken



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden