Auswirkungen von In-Memory-Datenbanken auf die Datenqualität in Unternehmen

Andreas Flaig Masterarbeit im Fach Information Systems Auswirkungen von In-Memory-Datenbanken auf die Datenqualität in Unternehmen Themasteller: Prof. Dr. Ali Sunyaev Vorgelegt in der Masterprüfung im Studiengang Information Systems der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität zu Köln Köln, Mai 2013

II Inhaltsverzeichnis Abkürzungsverzeichnis...IV Abbildungsverzeichnis...V Tabellenverzeichnis...VI 1 Einleitung...1 1.1 Problemstellung...1 1.2 Zielsetzung...2 1.3 Vorgehensweise...2 1.4 Aufbau der Arbeit...4 2 In-Memory-Datenbanken...5 2.1 Begriffsdefinition...5 2.2 Verwendete Literatur...6 2.3 Ausgewählte Eigenschaften von In-Memory-Datenbanken...8 2.3.1 Verwendung des Primärspeichers...8 2.3.2 Spaltenorientierte Datenspeicherung...12 2.3.3 Kompressionsverfahren...16 2.3.4 Insert-Only-Verfahren...17 2.3.5 Recovery-Mechanismen...18 2.4 Vergleich zu konventionellen Datenbanken...21 3 Datenqualität...23 3.1 Begriffsdefinition...23 3.2 Ursachen für Datenqualitätsprobleme...25 3.3 Datenqualitätsdimensionen...34 4 Auswirkungen von In-Memory-Datenbanken auf die Systemlandschaft...39 4.1 Bisherige Trennung von OLTP- und OLAP-Datenbanken...39 4.2 In-Memory-Datenbank für OLTP...43 4.3 In-Memory-Datenbank für OLAP...45 4.4 Integrierte In-Memory-Datenbank für OLTP und OLAP...47 5 Auswirkungen von In-Memory-Datenbanken auf die Datenqualität...50 5.1 Auswirkungen beim Nutzungsszenario In-Memory-Datenbank für OLTP...50 5.2 Auswirkungen beim Nutzungsszenario In-Memory-Datenbank für OLAP...53 5.3 Auswirkungen beim Nutzungsszenario Integrierte In-Memory-Datenbank...55 6 Fazit...61

III Literaturverzeichnis...63 Anhang...69 Erklärung...70 Lebenslauf...71

IV Abkürzungsverzeichnis DRAM OLAP OLTP SSD USV Dynamic Random-Access Memory Online Analytical Processing Online Transaction Processing Solid State Drive Unterbrechungsfreie Stromversorgung

V Abbildungsverzeichnis Abb. 2-1: Speicherhierarchie mit Zugriffszeiten...10 Abb. 2-2: Physische Umsetzung von Tab. 2-2 bei zeilenorientierter Datenspeicherung (schematische Darstellung)...15 Abb. 2-3: Physische Umsetzung von Tab. 2-2 bei spaltenorientierter Datenspeicherung (schematische Darstellung)...15 Abb. 4-1: Zusammenhang zwischen OLTP- und OLAP-Datenbanken...43 Abb. 4-2: Integrierte In-Memory-Datenbank für OLTP und OLAP...47

VI Tabellenverzeichnis Tab. 2-1: Übersicht über die verwendete Literatur...8 Tab. 2-2: Ausschnitt aus einer beispielhaften Kundentabelle...15 Tab. 3-1: Einfluss von In-Memory-Datenbanken auf mögliche Ursachen für Datenqualitätsprobleme...34 Tab. 5-1: Auswirkungen möglicher Nutzungsszenarien von In-Memory-Datenbanken auf die Datenqualitätsdimensionen...61

1 1 Einleitung 1.1 Problemstellung Aus technischer Perspektive versprechen In-Memory-Datenbanken sehr große Potentiale zur Verbesserung der Leistungsfähigkeit von Datenbanksystemen. In der Praxis werden In-Memory-Datenbanken bisher allerdings kaum in Unternehmen eingesetzt. So geben in einer Studie lediglich 16% der befragten Unternehmen an, bereits In-Memory-Technologien, zu denen insbesondere In-Memory-Datenbanken zählen, im Einsatz zu haben. 1 Zwar planen weitere 31% der befragten Unternehmen In- Memory-Technologien in Zukunft einzusetzen, jedoch steht eine Mehrheit von 53% der befragten Unternehmen diesen Technologien skeptisch gegenüber und plant daher nicht ihre Nutzung. Ein Grund für die ablehnende Haltung vieler Unternehmen gegenüber In- Memory-Technologien und damit auch In-Memory-Datenbanken liegt möglicherweise darin begründet, dass die Folgen des Einsatzes dieser Technologien, u. a. auch im Hinblick auf die Datenqualität, bisher kaum eingeschätzt werden können. Da In- Memory-Datenbanken bei ihrem Einsatz in einem Unternehmen jedoch Teil des Datenverarbeitungsprozesses werden und sie darüber hinaus große Unterschiede zu den bisher verwendeten konventionellen Datenbanken aufweisen, ist ihre Nutzung gegebenenfalls mit Auswirkungen auf die Datenqualität verbunden. Dabei ist die Datenqualität für Unternehmen allgemein ein wichtiges Thema, weil jede positive oder negative Veränderung letztlich Einfluss auf den wirtschaftlichen Erfolg eines Unternehmens haben kann. 2 Im Rahmen dieser Arbeit wird daher der Frage nachgegangen, welche Auswirkungen In-Memory-Datenbanken auf die Datenqualität in Unternehmen haben. In der bisherigen Forschung werden In-Memory-Datenbanken vorwiegend aus einer technischen Perspektive betrachtet. 3 Neben der prinzipiellen Funktionsweise stehen vor allem Methoden und Algorithmen zur Verbesserung von technischen Aspekten im Zentrum der wissenschaftlichen Betrachtung. Daneben existieren zwar auch wenige informationswirtschaftliche Untersuchungen, in denen z. B. die Auswirkungen von In- 1 Vgl. zu diesem und dem folgenden Satz o. V. (2012), S. 14. 2 Vgl. Wang, Strong (1996), S. 6 sowie Ge, Helfert, Jannach (2011), S. 2. 3 Vgl. z. B. DeWitt u. a. (1984), Garcia-Molina, Salem (1992) sowie Plattner (2009).

2 Memory-Datenbanken auf Geschäftsprozesse betrachtet werden. 4 Eine explizite Untersuchung der Auswirkungen von In-Memory-Datenbanken auf die Datenqualität in Unternehmen findet jedoch nicht statt. Um diese Forschungslücke ein Stück weit zu schließen, werden in dieser Arbeit daher die Auswirkungen von In-Memory- Datenbanken auf die Datenqualität in Unternehmen untersucht. 1.2 Zielsetzung Ziel der Arbeit ist die Untersuchung der Auswirkungen von In-Memory-Datenbanken auf die Datenqualität in Unternehmen. Dazu ist es zunächst notwendig, die Eigenschaften von In-Memory-Datenbanken im Vergleich zu konventionellen, d. h. auf Sekundärspeicher basierenden Datenbanken, zu untersuchen. Ferner soll das Konzept der Datenqualität erläutert werden, wobei der Fokus vor allem auf den verschiedenen Datenqualitätsdimensionen liegt, aus denen Datenqualität bewertet werden kann. Daneben sollen mögliche Ursachen für Datenqualitätsprobleme aufgezeigt und dabei der Frage nachgegangen werden, welche dieser Ursachen einen Zusammenhang zur verwendeten Datenbanktechnologie aufweisen, um mögliche Auswirkungen des Einsatzes von In-Memory-Datenbanken ableiten zu können. Darüber hinaus sollen die Auswirkungen von In-Memory-Datenbanken auf die Systemlandschaft in Unternehmen untersucht und dazu exemplarische Nutzungsszenarien für den Einsatz von In-Memory- Datenbanken aufgezeigt werden. Dabei soll auch der Frage nachgegangen werden, wie durch den Einsatz von In-Memory-Datenbanken möglicherweise die Trennung zwischen dedizierten Datenbanken für das Online Transaction Processing (OLTP) und das Online Analytical Processing (OLAP) aufgehoben werden kann. Letztlich sollen für jedes zuvor entwickelte Nutzungsszenario mögliche Auswirkungen von In-Memory- Datenbanken auf die einzelnen Datenqualitätsdimensionen abgeleitet werden. 1.3 Vorgehensweise Die Ergebnisse der vorliegenden Arbeit basieren auf der Durchführung einer Literaturuntersuchung. Dazu wurde zum Themenbereich In-Memory-Datenbanken eine Literaturrecherche in den Suchportalen ACM Digital Library, AIS Electronic Library (AISeL), EBSCOhost, IEEE Xplore Digital Library, ProQuest und ScienceDirect durchgeführt. Als Suchbegriffe wurden in memory, main memory und memory 4 Vgl. Wessel, Köffer, Becker (2013).

3 resident jeweils in Kombination mit dem Begriff database verwendet und untereinander mit einem logischen OR verknüpft. Beim Begriff database wurde explizit darauf geachtet, dass sowohl Singular als auch Plural gefunden werden. Falls möglich wurde die Suche auf Titel, Abstract und Schlüsselwörter beschränkt. Ansonsten wurden lediglich die Metadaten durchsucht. Ebenso wurde darauf geachtet, dass database jeweils nicht zu weit weg von den ersten drei Begriffen steht. Dazu wurde, sofern vom jeweiligen Suchportal unterstützt, mit Hilfe eines speziellen Operators ( ONEAR/1, P/1 bzw. PRE/1 ) definiert, dass jeweils maximal ein zusätzliches Wort zwischen einem der ersten drei Begriffe ( in memory, main memory, memory resident ) und database stehen darf (z. B. "in memory" ONEAR/1 database). Dadurch konnte die Ergebnismenge eingeschränkt werden, ohne jedoch relevante Treffer auszuschließen, die z. B. den Begriff In-Memory Column Database beinhalten. Falls ein solcher Operator in einem Suchportal nicht zur Verfügung stand, wurde im Titel mittels AND -Verknüpfung gesucht, wohingegen Abstract und Schlüsselwörter in der restriktiveren Variante mit dem verbundenen String (z. B. in memory database ) durchsucht wurden. Daneben erfolgte eine Beschränkung der Suche auf wissenschaftliche Publikationen. Der letztlich für jedes Portal verwendete Suchstring ist im Anhang dieser Arbeit aufgeführt. Anschließend erfolgte eine Filterung der Suchergebnisse und Auswahl der auszuwertenden Literatur anhand der folgenden Kriterien: Die auszuwertende Literatur soll grundlegende Konzepte von In-Memory-Datenbanken behandeln. Dabei werden sowohl Publikationen herangezogen, die einen allgemeinen Überblick über den Forschungsstand von In-Memory-Datenbanken geben, als auch solche, die sich vornehmlich auf bestimmte, für diese Arbeit relevante Teilaspekte von In-Memory-Datenbanken (z. B. Recovery-Mechanismen) beziehen. Allerdings wurden all jene Publikationen, die sich vorwiegend auf allzu spezifische technische Aspekte von In-Memory-Datenbanken konzentrieren (z. B. Abfrageoptimierungen, konkrete Implementierungen von Datenbank-Operatoren), aus der Auswertung ausgeschlossen, da in dieser Arbeit nur die grundlegenden technischen Eigenschaften von In-Memory- Datenbanken im Vergleich zu konventionellen Datenbanken dargelegt werden. Für das eigentliche Thema der Untersuchung der Auswirkungen von In-Memory-Datenbanken auf die Datenqualität in Unternehmen spielen allzu spezifische technische Aspekte dieser Datenbanktechnologie keine Rolle.

4 Darüber hinaus wurden mittels Rückwärtssuche weitere Veröffentlichungen identifiziert und in die Auswertung miteinbezogen. Zum Themenbereich Datenqualität wurde auf die fünf Publikationen Wand, Wang (1996), Wang, Strong (1996), Pipino, Lee, Wang (2002), Batini u. a. (2009) und Ge, Helfert, Jannach (2011) zurückgegriffen, da sie grundlegende Aspekte zur Bewertung und Messung von Datenqualität beinhalten und darüber hinaus häufig von anderen Autoren zitiert werden. Mit Hilfe dieser fünf Publikationen werden die zu betrachtenden Datenqualitätsdimensionen extrahiert und definiert, um sie im späteren Verlauf auf mögliche Auswirkungen durch In-Memory-Datenbanken hin zu untersuchen. Daneben wurde zur Identifizierung von Ursachen für Datenqualitätsprobleme auf Lee u. a. (2006) zurückgegriffen. 1.4 Aufbau der Arbeit Im ersten Teil der Arbeit wird zunächst auf den Begriff der In-Memory-Datenbanken eingegangen. Dazu werden die Grundlagen von In-Memory-Datenbanken erläutert sowie für den späteren Verlauf der Arbeit relevante Eigenschaften dieser Datenbanktechnologie herausgestellt. Darüber hinaus erfolgt ein Vergleich von In- Memory-Datenbanken zu den bisher eingesetzten konventionellen Datenbanken. Im darauf folgenden Kapitel wird der Begriff Datenqualität eingeführt. Neben einer Begriffsdefinition wird der Frage nachgegangen, bei welchen Ursachen für Datenqualitätsprobleme ein möglicher Zusammenhang zur verwendeten Datenbanktechnologie besteht und ob der Einsatz einer In-Memory-Datenbank daher Auswirkungen auf die jeweilige Ursache besitzt. Anschließend wird der Begriff der Datenqualitätsdimension eingeführt und in der Literatur genannte Datenqualitätsdimensionen definiert. Im darauf folgenden Kapitel werden die Auswirkungen von In-Memory-Datenbanken auf die Systemlandschaft in Unternehmen untersucht. Dabei werden drei verschiedenen Nutzungsszenarien ( In-Memory- Datenbank für OLTP, In-Memory-Datenbank für OLAP, Integrierte In-Memory- Datenbank ) zum Einsatz von In-Memory-Datenbanken in Unternehmen unterschieden. Im anschließenden Kapitel werden für jedes dieser Nutzungsszenarien die möglichen Auswirkungen auf die einzelnen Datenqualitätsdimensionen untersucht und dabei Verbesserungen sowie Herausforderungen bezüglich der Datenqualität aufgezeigt. Im abschließenden Fazit wird u. a. aufgezeigt, in welchen Bereichen weiterer

5 Forschungsbedarf besteht. 2 In-Memory-Datenbanken 2.1 Begriffsdefinition Bei einer In-Memory-Datenbank handelt es sich um ein Datenbanksystem, dessen wesentliche Eigenschaft die dauerhafte Vorhaltung und Verarbeitung des gesamten Datenbestandes im Arbeitsspeicher (Primärspeicher) ist. 5 Zwar existiert bei In-Memory- Datenbanken neben der primären Kopie der Daten im Arbeitsspeicher noch eine weitere im Sekundärspeicher, jedoch wird auf diese ausschließlich zu Sicherungs- und Wiederherstellungszwecken im Falle eines Fehlers zugegriffen. 6 Im Gegensatz dazu basiert eine konventionelle Datenbank vollständig auf Sekundärspeicher. 7 Dabei kommt traditionell vor allem Festplattenspeicher zum Einsatz, wobei mittlerweile auch die deutlich schnelleren Solid State Drives (SSD) verwendet werden 8. Der Arbeitsspeicher hat bei konventionellen Datenbanken lediglich die Funktion eines Zwischenspeichers (Cache), weshalb bei dieser Datenbanktechnologie in der Regel ein Zugriff auf den Sekundärspeicher notwendig ist, um eine Datenbankabfrage beantworten zu können. Da der Zugriff auf den Sekundärspeicher jedoch um ein Vielfaches langsamer ist als der Zugriff auf den wesentlich schneller angebundenen Arbeitsspeicher, können In- Memory-Datenbanken deutliche Geschwindigkeitsvorteile gegenüber konventionellen Datenbanken realisieren. 9 Es ist wichtig noch einmal zu betonen, dass es sich bei In-Memory-Datenbanken nach der vorhergehenden Definition nicht lediglich um konventionelle Datenbanken handelt, die mit einem besonders großen Zwischenspeicher (Arbeitsspeicher) ausgestattet sind. 10 Stattdessen stellen In-Memory-Datenbanken eine eigenständige Datenbanktechnologie dar. Spielt bei der Entwicklung von konventionellen Datenbanken häufig die Vermeidung von Sekundärspeicherzugriffen eine große Rolle, so wird die Entwicklung 5 Vgl. Eich (1989), S. 252 253 sowie Garcia-Molina, Salem (1992), S. 509. 6 Vgl. Garcia-Molina, Salem (1992), S. 512. 7 Vgl. zu diesem und den folgenden beiden Sätzen Garcia-Molina, Salem (1992), S. 509. 8 Vgl. Polte, Simsa, Gibson (2008), S. 1 2. 9 Vgl. Gruenwald, Eich (1994), S. 151. 10 Vgl. Eich (1989), S. 252.

6 von In-Memory-Datenbanken von vornherein vollständig auf den Primärspeicher ausgerichtet. 11 Der Sekundärspeicher wird dagegen lediglich zur Sicherung und Wiederherstellung der In-Memory-Datenbank benötigt. Bei In-Memory-Datenbanken handelt es sich nicht um ein neuartiges Konzept, sondern die Grundlagen dieser Datenbanktechnologie wurden bereits Mitte der 1980er Jahre entwickelt. 12 Allerdings ermöglichte erst das Aufkommen moderner Computerarchitekturen, zu denen u. a. Mehrkernprozessoren, 64-Bit-Technologie und sehr große und günstige Arbeitsspeichermengen zu zählen sind, die sinnvolle Umsetzung dieses vormals eher theoretischen Konzepts. 13 Hervorzuheben ist insbesondere die 64-Bit-Technologie, durch die erst die Möglichkeit entstand, mehr als 2 32 Byte (= 4 GiB) Arbeitsspeicher direkt zu adressieren. 14 Dadurch können inzwischen auch sehr große In-Memory-Datenbanken mit Arbeitsspeicherkapazitäten, die im Terabyte-Bereich liegen, realisiert werden. 15 In der wissenschaftlichen Literatur finden sich synonym zum Begriff In-Memory- Datenbank häufig die Bezeichnungen Main Memory Database oder auch Memory- Resident Database 16. Dabei handelt es sich jedoch um das gleiche Konzept, das lediglich unter einem anderen Namen geführt wird. Um etwaigen Missverständnissen vorzubeugen, wird in dieser Arbeit einheitlich die Bezeichnung In-Memory-Datenbank verwendet. 2.2 Verwendete Literatur Neben Zeitschriftenartikeln und Konferenzbeiträgen werden auch zwei Bücher in die Literaturauswertung miteinbezogen. Dabei handelt es sich zum einen um Plattner, Zeier (2011), in dem detailliert ein Ansatz zur Implementierung einer In-Memory-Datenbank erläutert wird. Beim zweiten Buch Kemper, Eickler (2009) handelt es sich um ein 11 Vgl. zu diesem und dem folgenden Satz Lehman, Carey (1986a), S. 294. 12 Vgl. z. B. DeWitt u. a. (1984), Eich (1986), Hagmann (1986), Lehman, Carey (1986b) sowie Lehman, Carey (1987). 13 Vgl. Plattner, Zeier (2011), S. 11. 14 Vgl. Eich (1989), S. 257. 15 Vgl. Kemper, Neumann (2011), S. 196, Thiele, Lehner, Habich (2011), S. 60 sowie Funke, Kemper, Neumann (2012), S. 1424. 16 Vgl. z. B. DeWitt u. a. (1984), Garcia-Molina, Salem (1992) und Gruenwald, Eich (1994).

7 Grundlagenwerk, das sich intensiv mit dem Thema konventionelle Datenbanken auseinander setzt. Diese Publikation wird vor allem für den Vergleich von konventionellen Datenbanken mit In-Memory-Datenbanken in Kapitel 2.4 herangezogen. In Tabelle 2-1 wird eine Übersicht über die im Wesentlichen verwendete Literatur zum Thema In-Memory-Datenbanken gegeben. Dabei erfolgt eine Zuordnung der Publikationen zu den in diesem Kapitel erläuterten Eigenschaften von In-Memory- Datenbanken. Darüber hinaus wird die in der jeweiligen Publikation vorgeschlagene Nutzungsform für In-Memory-Datenbanken identifiziert und sofern möglich in die Kategorie OLTP, OLAP oder Hybrid eingeordnet. Die Nutzungsformen dienen Memory-Datenbanken in Unternehmen. Publikation DeWitt u. a. (1984) Eich (1986) Hagmann (1986) Lehman, Carey (1986b) Lehman, Carey (1987) Eich (1989) Garcia-Molina, Salem (1992) Levy, Silberschatz (1992) Huang, Gruenwald (1996) Lee, Kim, Cha (2001) Stonebraker u. a. (2007) X X X X X X X X X X als Grundlage für die in Kapitel 4 erläuterten Nutzungsszenarien zum Einsatz von In- Spaltenorientierung Kompressionsverfahren Recovery- Mechanismen Insert- Only- Verfahren Nutzungsform (X) X OLTP Plattner (2009) X X X Hybrid Krueger u. a. (2010) X X X Hybrid Kemper, Neumann (2011) X X Hybrid

8 Publikation Spaltenorientierung Kompressionsverfahren Recovery- Mechanismen Insert- Only- Verfahren Nutzungsform Krueger u. a. (2011a) X X X Hybrid Krueger u. a. (2011b) X X X Hybrid Plattner, Zeier (2011) X X X X Hybrid Thiele, Lehner, Habich (2011) Funke, Kemper, Neumann (2012) Tab. 2-1: Übersicht über die verwendete Literatur X X OLAP /Hybrid X X Hybrid 2.3 Ausgewählte Eigenschaften von In-Memory-Datenbanken 2.3.1 Verwendung des Primärspeichers Wie zuvor erwähnt ist die wesentliche Eigenschaft einer In-Memory-Datenbank die Verwendung des Arbeitsspeichers als primärer Ort zur dauerhaften Speicherung der Daten. Dies ist insofern zunächst verwunderlich, da es sich bei herkömmlichem Arbeitsspeicher, dem Dynamic Random-Access Memory (DRAM), um einen flüchtigen Speicher handelt. 17 DRAM muss demnach dauerhaft mit Strom versorgt werden, damit die in ihm abgelegten Daten erhalten bleiben. Wird daher ein auf DRAM basierendes System, das eine In-Memory-Datenbank ausführt, von der Stromversorgung getrennt, so gehen alle im Arbeitsspeicher abgelegten Daten verloren. 18 Zwar kann durch bestimmte Techniken (z. B. unterbrechungsfreie Stromversorgung (USV) oder spezieller nichtflüchtiger Arbeitsspeicher) der Datenverlust im Arbeitsspeicher bei Abbruch der Stromversorgung verhindert werden, jedoch bieten diese Techniken keinen Schutz vor Datenverlusten, die aufgrund von Betriebssystem- oder Hardwarefehlern hervorgerufen werden. 19 Zur permanenten Sicherung der Daten benötigen daher auch In-Memory- Datenbanken zwingend einen nicht-flüchtigen Sekundärspeicher, wobei hier vor allem Flash- oder Festplattenspeicher zu nennen sind. Somit ist gewährleistet, dass auch nach Störungen, die zum Verlust des Arbeitsspeicherinhalts führen, die Datenbank 17 Vgl. Boncz, Kersten, Manegold (2008), S. 78. 18 Vgl. Plattner, Zeier (2011), S. 11. 19 Vgl. zu diesem und dem folgenden Satz Lehman, Carey (1986b), S. 241, Lehman, Carey (1987), S. 104 sowie Garcia-Molina, Salem (1992), S. 510.

9 vollständig aus dem Sekundärspeicher wiederhergestellt und in den Arbeitsspeicher zurückgeladen werden kann. Die dabei verwendeten Recovery-Mechanismen werden im Kapitel 2.3.5 vorgestellt. Die Entwicklung der Hardwaretechnologie ist auch soweit fortgeschritten, dass die maximal verfügbaren Arbeitsspeichergrößen in Serversystemen bereits im Bereich von einigen Terabyte liegen und zukünftig noch weiter steigen werden. 20 Einige Autoren gehen sogar davon aus, dass die Arbeitsspeicherkapazitäten inzwischen einem schnelleren Wachstum unterliegen als die Datenmengen, die typischerweise im geschäftlichen Umfeld als operationale Daten anfallen. 21 Zwar wird es auch immer Anwendungsfälle geben, die noch größere Arbeitsspeicherkapazitäten erfordern und deshalb nicht mit In-Memory-Datenbanken realisiert werden können (z. B. Speicherung von unstrukturierten Daten), jedoch sollten die schon heute verfügbaren Arbeitsspeichergrößen für viele Unternehmensanwendungen (z. B. Verwaltung von Kunden- und Auftragsdaten) mehr als ausreichend dimensioniert sein. Zudem ist die Datenorganisation in In-Memory-Datenbanken wesentlich effizienter als in konventionellen Datenbanken, so dass in der Regel erheblich weniger Platz für die Speicherung der gleichen Datenmenge benötigt wird (siehe Kapitel 2.3.2). 22 20 Vgl. Plattner (2009), S. 5, Kemper, Neumann (2011), S. 196 sowie Thiele, Lehner, Habich (2011), S. 60. 21 Vgl. zu diesem und dem folgenden Satz Krueger u. a. (2010), S. 132 sowie Kemper, Neumann (2011), S. 196. 22 Vgl. Plattner (2009), S. 2.

10 Abb. 2-1: Speicherhierarchie mit Zugriffszeiten 23 Um die Auswirkungen der Verwendung des Arbeitsspeichers als primärer Ort für die Speicherung einer Datenbank aufzuzeigen, bietet sich zunächst die Betrachtung der Speicherhierarchie eines aktuellen Computersystems an. Die Darstellung in Abbildung 2-1 erfolgt in Form einer Pyramide, was die von oben nach unten zunehmende Speichergröße der Datenspeicher auf den einzelnen Ebenen symbolisieren soll. 24 Auf den einzelnen Ebenen sind neben den Datenspeichern auch die typischen Zugriffszeiten des Prozessors (CPU) auf diese angegeben. Auch bei den Zugriffszeiten ist ein Anstieg von oben nach unten entlang der Pyramidenform zu verzeichnen. An der Spitze der Speicherhierarchie stehen die direkt beim Prozessor angesiedelten CPU- Register. Diese können nur wenige Byte aufnehmen, besitzen dafür jedoch mit weniger als einer Nanosekunde (= 0,000000001 s) die schnellste Zugriffszeit aller CPU- Register CPU-Caches (L1, L2 & L3) > 1 ns Arbeitsspeicher (Hauptspeicher) ~ 100 ns Zugriffslücke 10³-10 5 Sekundärspeicher: Flash-Speicher (SSD) ~ 0,1 ms = 100.000 ns Festplattenspeicher (HDD) ~ 10 ms = 10.000.000 Archivspeicher: Magnetbänder > 1 s 23 Vgl. Polte, Simsa, Gibson (2008), S. 2, Kemper, Eickler (2009), S. 203 und Plattner, Zeier (2011), S. 47. 24 Vgl. zu diesem Absatz Kemper, Eickler (2009), S. 202 203.

11 Datenspeicher. Auf der Ebene unterhalb der CPU-Register folgen die CPU-Caches. Diese bilden eine eigene Hierarchie und werden nach ihrer Nähe zum Prozessor in mehrere Stufen, den so genannten Cache-Leveln, eingeteilt. 25 Dabei gilt, je näher der Cache an der CPU liegt, desto niedriger ist der Cache-Level. Typische Cache-Level heutiger Prozessoren sind Level-1 (L1), Level-2 (L2) und Level-3 (L3). Die Speichergröße der einzelnen CPU- Caches liegt im Bereich von mehreren Kilobyte bis wenigen Megabyte. Die Zugriffszeiten sind mit wenigen Nanosekunden geringfügig langsamer als bei den CPU- Registern. Allgemein gilt, je näher ein Cache an der CPU liegt, desto geringer ist seine Speicherkapazität sowie auch seine Zugriffszeit. 26 Die CPU-Caches sind erforderlich, damit moderne Prozessoren keine unnötigen Taktzyklen darauf verwenden, auf die benötigten Daten aus dem langsamer angebundenen Arbeitsspeicher (ca. 100 ns) zu warten. So werden beim Zugriff auf den Arbeitsspeicher nicht nur einzelne Zellen ausgelesen, sondern immer ganze zusammenhängende Datenbereiche als so genannte Cache-Line. Durch dieses Caching-Prinzip erhöht sich bei der Verarbeitung von Daten die Wahrscheinlichkeit dafür, dass die vom Prozessor benötigten Daten bereits in einem der CPU-Caches vorliegen und somit nicht erst aus dem langsamer angebundenen Arbeitsspeicher gelesen werden müssen. In einem einzelnen Computersystem können mittlerweile Arbeitsspeicherkapazitäten von mehreren Terabyte realisiert werden. 27 Die Ebene unterhalb des Arbeitsspeichers bildet der so genannte Sekundärspeicher, wobei hier vor allem die herkömmlichen, auf Magnetspeicher basierenden Festplatten 28 sowie die neueren, auf Flash-Speicher basierenden Solid State Drives (SSD) zu nennen sind. Im Unterschied zu den vorherigen Ebenen ist beim Zugriff der CPU auf den Sekundärspeicher ein vergleichsweise langsamer Input-/Output-Prozess notwendig, weswegen man in der Literatur auch von einer Zugriffslücke spricht. 29 Diese wird traditionell mit dem Faktor 10 5 angegebenen, wobei sich dieser Wert auf den Unterschied in der Zugriffszeit zwischen Arbeitsspeicher und Festplattenspeicher 25 Vgl. zu diesem und den folgenden drei Sätzen Boncz, Kersten, Manegold (2008), S. 78. 26 Vgl. zu diesem und den folgenden drei Sätzen Boncz, Kersten, Manegold (2008), S. 78. 27 Vgl. Kemper, Neumann (2011), S. 196 sowie Funke, Kemper, Neumann (2012), S. 1424. 28 Im Englischen als Hard Disk Drive (HDD) bezeichnet. 29 Vgl. zu diesem und dem folgenden Satz Kemper, Eickler (2009), S. 203.

12 bezieht. Mit dem Aufkommen der SSDs konnte diese Zugriffslücke ein Stück weit verringert werden. 30 Allerdings ist der Geschwindigkeitsvorteil des Arbeitsspeichers bei einer Zugriffszeit, die um den Faktor 10 3 schneller ist, auch gegenüber einem SSD noch immer beträchtlich. Im Hinblick auf die Kapazität können einzelne Festplatten oder SSDs bereits einige Terabyte Speicherplatz aufweisen. In einem Computersystem zusammengeschlossen sind daher problemlos Speicherkapazitäten von mehreren Hundert Terabyte und mehr möglich. Auf der untersten Ebene der Speicherhierarchie sind die Archivspeicher angesiedelt, wobei diese meist in Form von Magnetbändern bereitgestellt werden. 31 Da Magnetbänder nur sequentiell gelesen und beschrieben werden können, ist die Zugriffszeit vergleichsweise hoch. Die Speicherkapazität eines einzelnen Magnetbandes liegt auf einem ähnlichen Niveau wie bei einer Festplatte. 2.3.2 Spaltenorientierte Datenspeicherung Die Verwendung von Arbeitsspeicher zur primären Speicherung der Daten hat auch Einfluss auf die physische Datenorganisation, im Folgenden auch als Datenlayout bezeichnet, einer In-Memory-Datenbank. Tabelle 2-2 zeigt einen Ausschnitt aus einer beispielhaften Kundentabelle, wie sie typischerweise in Unternehmen zu finden ist. Bei konventionellen Datenbanken erfolgt die Speicherung derartiger Tabellen meist zeilenorientiert 32, wobei eine Zeile einem zusammenhängenden Datensatz (Tupel) entspricht, der aus mehreren Attributen (Spalten) besteht. 33 Die einzelnen Tupel werden demnach hintereinander gereiht auf dem Sekundärspeicher abgelegt (Abbildung 2-2) und belegen dort somit zusammenhängende Speicherbereiche. Dadurch wird eine schnelle Verarbeitung ganzer Tupel sichergestellt, da immer nur sequenzielle Lese-/Schreibvorgänge vom bzw. auf den Sekundärspeicher erforderlich sind. 34 Ein solches Zugriffsszenario findet sich typischerweise bei Systemen, die für die Verarbeitung von Transaktionsdaten (z. B. Kunden- und Auftragsdaten), auch als Online 30 Vgl. zu diesem und dem folgenden Satz Polte, Simsa, Gibson (2008), S. 1 2. 31 Vgl. zu diesem Absatz Kemper, Eickler (2009), S. 202 203. 32 Im Englischen als row store bezeichnet. 33 Vgl. zu diesem und dem folgenden Satz Kemper, Eickler (2009), S. 541. 34 Vgl. Kemper, Eickler (2009), S. 202.

13 Transaction Processing (OLTP) bezeichnet, zuständig sind. 35 Abfragen, die Berechnungen über ganze Spalten einer Tabelle erfordern und somit nur wenige Attribute vieler Tupel betreffen, können dagegen nur langsam ausgeführt werden, da hierbei in zufälliger Reihenfolge auf den Sekundärspeicher zugegriffen wird und somit die CPU-Caches nicht ausgenutzt werden können 36. 37 Derartige Abfragen kommen typischerweise beim Online Analytical Processing (OLAP) vor, wofür bisher auf speziell für diesen Zweck optimierte Datenbanken zurückgegriffen wird. 38 Dabei kommt meist eine spaltenorientierte Speicherung 39 der Datenbanktabellen zum Einsatz. Hierzu wird eine logische Datenbanktabelle spaltenweise zerlegt und die einzelnen Spalten als zusammengehörige Einheit im Sekundär- oder Arbeitsspeicher abgelegt (Abbildung 2-3). 40 Dies hat den Vorteil, dass die einzelnen Spalten sehr schnell durchlaufen werden können, da sie als zusammenhängende Einheiten in die CPU-Caches geladen werden. Dadurch können analytische Abfragen, die z. B. häufig die Berechnung von Summenoder Durchschnittswerten über ganze Spalten erfordern, sehr schnell ausgeführt werden. Dagegen ist der Zugriff auf viele Attribute eines einzelnen Tupels bei dieser Datenorganisation mit höheren Kosten verbunden, da hierzu das zerlegte Tupel zunächst rekonstruiert werden muss, wobei in zufälliger Reihenfolge auf den zugrundeliegenden Speicher zugegriffen wird. 41 Allerdings unterscheiden sich diese Kosten erheblich, je nachdem welche Speicherart eingesetzt wird. So ist das Lesen in zufälliger Reihenfolge bei Festplattenspeicher weitaus problematischer als bei Arbeitsspeicher, da letzterer als Random Access Memory auf zufällige Zugriffe ausgelegt ist. 42 Die spaltenorientierte Datenorganisation erscheint daher prädestiniert für den Einsatz in In-Memory- Datenbanken, da vor allem komplexe analytische Abfragen (OLAP), die häufig Aggregationen und Gruppierungen über ganze Spalten erfordern, durch die optimale 35 Vgl. Kemper, Eickler (2009), S. 511. 36 Aufgrund der zeilenorientierten Speicherung werden die CPU-Caches implizit auch mit den nicht angefragten Attributen eines Tupels belegt. 37 Vgl. Kemper, Eickler (2009), S. 541. 38 Vgl. Kemper, Eickler (2009), S. 517 518. 39 Im Englischen als column store bezeichnet. 40 Vgl. zu diesem und den folgenden beiden Sätzen Kemper, Eickler (2009), S. 541 542. 41 Vgl. Krueger u. a. (2010), S. 133. 42 Vgl. Plattner, Zeier (2011), S. 182.

14 Nutzung der CPU-Caches sehr schnell ausgeführt werden können. Daneben können auch für OLTP-Abfragen, die oft schreibend auf die Datenbank zugreifen und meist nur einzelne Tupel betreffen, bei einer spaltenorientierten Datenspeicherung hohe Transaktionsraten erzielt werden. 43 Allerdings werden in der Literatur auch alternative Ansätze zur Datenorganisation in In- Memory-Datenbanken vorgeschlagen, die u. a. auf eine noch höhere Performanz bei OLTP-Abfragen abzielen. So entwickeln Stonebraker u. a. (2007) eine zeilenorientierte In-Memory-Datenbank, die vollständig auf OLTP optimiert ist. 44 Dadurch können OLTP-Transaktionsraten erreicht werden, die um den Faktor 82 höher sind als bei einer konventionellen Datenbank. Dabei muss jedoch beachtet werden, dass eine derart spezialisierte In-Memory-Datenbank ausschließlich für ihren Einsatzzweck OLTP vorgesehen ist und daher nicht für komplexe analytische Abfragen verwendet werden kann. 45 Plattner, Zeier (2011) schlagen neben einem rein zeilen- oder spaltenorientierten Datenlayout auch eine Mischung aus beiden vor. 46 Dieses hybride Datenlayout basiert auf einer vertikalen Partitionierung der Datenbanktabellen. Anders als bei der spaltenorientierten Datenorganisation werden jedoch nicht die kompletten Datenbanktabellen spaltenweise zerlegt, sondern lediglich einzelne Spalten (Attribute) aus den Datenbanktabellen gelöst und als zusammenhängende Einheiten gespeichert. Die restlichen Attribute werden dagegen wie bei der zeilenorientierten Datenorganisation tupelweise auf dem Datenspeicher abgelegt. Mit dem hybriden Datenlayout wird versucht einen Kompromiss zwischen transaktionalen und analytischen Abfragen zu schaffen. Allerdings stellt die Frage, welche Attribute spaltenorientiert gespeichert werden sollen, eine neue Herausforderung dar. Diese Entscheidung kann mitunter auch erst während des operativen Einsatzes einer In- Memory-Datenbank getroffen werden, wenn Statistiken über die Nutzung der einzelnen Datenbanktabellen vorliegen. Allerdings ist dann eine aufwändige Neuorganisation der bereits gespeicherten Daten erforderlich. 43 Vgl. Kemper, Neumann (2011), S. 204. 44 Vgl. zu diesem und dem folgenden Satz Stonebraker u. a. (2007), S. 1151, 1154, 1157. 45 Vgl. Stonebraker u. a. (2007), S. 1151, 1153. 46 Vgl. zu diesem Absatz Plattner, Zeier (2011), S. 75 77.