Leistungsanalyse und Bewertung von Datenbankimplementierungen unterschiedlicher Workloads

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1 Motivation
1.2 AufbauderArbeit

2. Darstellung von Datenbank-Management-Systemen anhand von Speicherentwicklung und den zugrundeliegenden Benutzungsparadigmen
2.1 Darstellung traditioneller Datenbank-Management-Systeme und deren zugrunde liegenden Benutzungsparadigmen
2.2 Darstellung des In-Memory-Database-Managements mit Hilfe aktueller Speicherverwaltungssysteme

3. Darstellung verschiedener Speicherverwaltungssysteme und Performanz-Evaluation von In-Memory-Datenbanken
3.1 Darstellung verschiedener Speicherverwaltungssysteme
3.1.1 Darstellung der Speicherverwaltung von HDD-Magnetspeicher-Festplatten
3.1.2 Darstellung der Speicherverwaltung von SSD-Halbleiterlaufwerken
3.1.3 Darstellung derSpeicherverwaltung vonRAM-Arbeitsspeichern
3.2 Performanz-Evaluation von In-Memory-Datenbanken unter Berücksichtigung unterschiedlicher Workloads

4. Empirische Untersuchung zum Vergleich der Performanz von memSQL mit verschiedenen Speicherverwaltungssystemen in einer Amazon Elastic Compute Cloud
4.1 Untersuchungsaufbau zum Vergleich der Performanz von memSQL mit verschiedenen Speicherverwaltungssystemen in einer Amazon Elastic Compute Cloud
4.2 Betrachtung der Performanz von memSQL mit verschiedenen Speicherverwaltungssystemen
4.2.1 Betrachtung der Performanz von HDD-Magnetspeicher-Festplatten
4.2.2 Betrachtung der Performanz von SSD-Halbleiterlaufwerken
4.2.3 Betrachtung derPerformanz vonRAM-Arbeitsspeichern
4.3 Gesamtergebnisse sowie Bewertung der In-Memory-Datenbank-Performanz mit verschiedenen Speicherverwaltungssystemen

5. Schlussbetrachtung

Verzeichnis der Internetquellen

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abbildung 1: Entwicklung der konvergierenden Technologien

Abbildung 2: Verknüpfung von Relationen mit Hilfe von Primär- und Fremdschlüsseln

Abbildung 3: Datenorganisationsalternativen

Abbildung 4: Datenstruktur in einem OLAP-Hyperwürfel

Abbildung 5: ETL bei OLTP vs. OLAP

Abbildung 6: Speicherpreisentwicklung

Abbildung 7: Datenzugriff von OLTP- und OLAP-Anwendung bei Zeilen- und Spaltenorientierung

Abbildung 8: Die Speicherhierarchie mit typischen Zugriffszeiten und Kapazitätsgrößenordnungen derjeweiligen Speichermedien

Abbildung 9: NAND-Flash Architektur Leistungsunterschiede

Abbildung 10: Typische DRAM-Modulbauweisen

Abbildung 11: OLTP vs. OLAP Schemen

Abbildung 12: Schema des CH-benCHmark Exemplarischer Quelltext einerjson-Workload-Datei

Abbildung 14: Spezifikationen der Amazon EC2-Insatzen

Abbildung 15: Spezifikationen der ausgewählten Instanzen

Abbildung 16: Absolute Performanzergebnisse von OLTP unter HDD

Abbildung 17: Relative Performanzergebnisse von OLTP unter HDD

Abbildung 18: Absolute Performanzergebnisse von OLAP unter HDD

Abbildung 19: Relative Performanzergebnisse von OLAP unter HDD

Abbildung 20: Absolute Performanzergebnisse von Mix unter HDD

Abbildung 21: Relative Performanzergebnisse von Mix unter HDD

Abbildung 22: Absolute Performanzergebnisse von OLTP unter SSD

Abbildung 23: Relative Performanzergebnisse von OLTP unter SSD

Abbildung 24: Absolute Performanzergebnisse von OLAP unter SSD

Abbildung 25: Relative Performanzergebnisse von OLAP unter SSD Absolute Performanzergebnisse von Mix unter SSD

Abbildung 27: Relative Performanzergebnisse von Mix unter SSD

Abbildung 28: Absolute Performanzergebnisse von OLTP unter RAM

Abbildung 29: Relative Performanzergebnisse von OLTP unter RAM

Abbildung 30: Absolute Performanzergebnisse von OLAP unter RAM

Abbildung 31: Relative Performanzergebnisse von OLAP unter RAM

Abbildung 32: Absolute Performanzergebnisse von Mix unter RAM

Abbildung 33: Relative Performanzergebnisse von Mix unter RAM

Abbildung 34: Übersicht der erreichten QpS aller Workloads und Instanzen

Abbildung 35: Instanzleistungen in QpS im Verhältnis zu denjew. Betriebskosten in $/h

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1 Motivation

“Information is the oil of the 21st century, and analytics is the combustion engine.”^[1] Laut Sondergaard, Chefanalyst des weltweit tätigen Marktforschungs- und Beratungsunter­nehmens Gartner, stehen wir vor dem Beginn einer neuen Ära, einer vierten Industriellen Revolution. Dies begründet Sondergaard vor allem mit dem immer günstigeren und flä- chendeckenderen Einsatz von Rechenleistung. Waren 2009 noch 2,5 Milliarden Geräte mit einer eigenen IP-Adresse ausgestattet und mit dem Internet verbunden, sollen es bis 2020 bereits 30 Milliarden Geräte sein. Dabei werden neben Mobiltelefonen, Personal­computern und Tablets vor allem auch eigenständig kommunizierende Geräte das Inter­net gebrauchen. Dieses ,Internet der Dinge‘ wird riesige Datenmengen produzieren, ge­nauso wie Menschen und deren Aktivitäten. Intelligente Maschinen werden dabei Daten produzieren sowie konsumieren und Unternehmen diese nutzen um ihre Strukturen da­hingehend zu ändern, dass Prozesse weiter automatisiert und intelligenter gestaltet wer­den können.^[2] Die Vernetzung der physischen Welt der Dinge mit der digitalen Compu­terwelt ist in Deutschland als das äußerst prominent gewordene Konzept ,Industrie 4.0‘^[3] bekannt.^[4] Damit soll zum Ausdruck gebracht werden, dass es sich um die vierte Phase der industriellen Revolution handele.^[5]

Die Grundlage der Industrie 4.0 liegt aber nicht allein in der Entwicklung von physischen Objekten hin zu cyber-physischen Systemen. Das Internet der Dinge bedingt auch das Internet der Dienste und Daten. Die exponentiell zunehmende Entwicklungsgeschwin­digkeit von Speichergrößen, Rechenleistung und Netzkapazitäten sowie einer damit ver­bundenen gegenläufigen Kostendegression, förderte die Entwicklung von Zentralrech­nern hin zu Big Data, Cloud Computing und Smart Devices. Mit Hilfe von Cloud Com­puting ist es möglich kostengünstig und flächendeckend riesige Datenmengen zu spei­chern und mit intelligenten Algorithmen, auf Basis von Korrelationen und Wahrschein­lichkeitsberechnungen, zu analysieren: aus Big Data wird somit Smart Data.

Folglich liegt der Industrie 4.0 die Konvergenz verschiedenster Technologien zugrunde (Abb.l), welche so leistungsfähig und kostengünstig geworden sind, dass ihr flächende­ckender Einsatz möglich geworden ist.^[6]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung l: Entwicklung der konvergierenden Technologien (Quelle: Kagermann, H. (2014), S. 604).

Wachsende Datenströme und die damit verbundene Herausforderung einer effizienten Verwaltung deuten daraufhin, dass auch Datenbankmanagementsysteme (DBMS) vor einer Revolution stehen. „Tape is Dead, Disk is Tape, Flash is Disk, RAM Locality is King“^[7]. So beschrieb Gray, Informatiker und Wissenschaftler bei Microsoft Research, die zunehmende Verschiebung der Speicherhierarchie. Haben traditionelle DBMS noch Se­kundärspeicher unter entweder zeilen- oder spaltenorientierter Datenorganisation ver­wendet, gebrauchen In-Memory Datenbanken (IMDB) Hauptspeicher und eine primär spaltenorientierte Datenorganisation. Damit soll es in Echtzeit^[8] möglich sein zum einen große Datenmengen auswerten und zum anderen die Informationen zum Zeitpunkt des Entstehens verarbeiten zu können.^[9] Verhinderte in den Achtziger Jahren die starke Unzu­verlässigkeit des Hauptspeichers und das hohe Preisniveau die Etablierung von IMDB, so ist es heute möglich den Einsatz in Datenbanken ökonomisch zu legitimieren.^[10] Traditionelle DBMS sind physikalisch und logisch für entweder operativ-transaktionale oder entscheidungsnützlich-analytische Arbeitslasten optimiert. Dabei sind in Online­Transaction Processing (OLTP) Systemen die Daten auf viele performante Schreib- und

Update-Vorgänge mit geringer Komplexität in typischerweise zeilenorientierter Daten­struktur optimiert. In Online Analytic Processing (OLAP) Systemen erfolgt die Optimie­rung hingegen auf wenige Leseanfragen hoher Komplexität in typischerweise spaltenori­entierter Datenstruktur. Die Zusammenführung und Synchronisation beider Systeme er­fordert dabei kostenintensive Extract-Transform-Load (ETL) Prozesse.^[11] Mit Hilfe eines entsprechend großen Hauptspeichers und der aktuellen 64-Bit-Multi-Core-Architektur könnenjedoch die Antwortzeiten eines Systems massiv verkürzt werden. Zusammen mit der spaltenorientierten Datenorganisation, angepassten Kompressionsalgorithmen und passender In-Memory-Softwareumgebung ist es dadurch möglich OLTP und OLAP mit­einander zu kombinieren. Durch das Schaffen eines ,Single Point of Truth‘^[12] entfallen kostenintensive ETL-Prozesse sowie Redundanzen durch vorgehaltene und vordefinierte Daten, sodass der Einsatz von Echtzeit-Analysen aktueller Daten ermöglicht wird.^[13] Die Quantifizierung dieses Leistungszuwachses gestaltet sich jedoch als schwierig. So hängt die Performanz einer Datenbank massiv von Design und Nutzungsparadigma ab. Dies betrifft sowohl rein transaktionale und analytische als auch gemischte Datenbank­nutzung. Die Untersuchung dieser Zusammenhänge hat insbesondere bei IMDB bisher keine große Beachtung gefunden.^[14]

Daher beschäftigt sich die vorliegende Arbeit mit den daraus abgeleiteten Fragen inwie­fern die Performanz einer IMDB unter verschiedenen Datenbankdesigns und Workloads zu bewerten ist. Zu diesem Zweck soll eine entsprechende Datenbank im Betrieb unter verschiedenen Speicherverwaltungssystemen bei OLTP-, OLAP- und gemischtem Workload betrieben und ihre Leistung gemessen werden. Hierfür muss zunächst geklärt werden welche Speicherverwaltungssysteme heute von Bedeutung sind, wie sie sich von­einander abgrenzen und wie sie im traditionellen sowie dem IM-Datenmanagement-Sys- tem zum Einsatz kommen. Des Weiteren müssen unterschiedliche sowie umfangreiche Workloads entwickelt und zur Untersuchung operationalisiert werden. Im Anschluss er­folgt die empirische Untersuchung der verschiedenen Datenbankimplementierungen, de­ren Ergebnisse miteinander vergleichend abgebildet und bewertet werden. Abschließend werden die daraus gewonnenen wesentlichen Erkenntnisse zusammenfassend dargestellt.

Die vorliegende Arbeit gliedert sich in fünf Kapitel. Hierbei erfolgt im nachfolgenden Kapitel 2 die inhaltliche Einführung durch die Darstellung traditioneller und In-Memory Datenbanksysteme. Anschließend erfolgen im Kapitel 3 die Darstellung von HDD-Mag- net-, SSD-Halbleiter- und RAM-Arbeitsspeicher sowie die Entwicklung eines geeigneten Workloadplans zur Performanzanalyse. Im Kapitel 4 wird die empirische Untersuchung, untergliedert in Aufbau, Durchführung und Ergebniserhebung, vorgenommen. Im ab­schließenden Kapitel 5 erfolgt die Schlussbetrachtung.

Für die empirische Untersuchung wird der Aufbau der IMDB memSQL innerhalb einer Amazon Elastic Cloud (EC2) gewählt. Die Installation innerhalb einer Amazon EC2 wird vorgenommen, da sie das schnelle und kostengünstige Anpassen der technischen Infra­struktur an den Untersuchungsgegenstand bietet. Die Wahl von memSQL als IMDB er­folgt aufgrund spezialisierten Ausrichtung auf die Verwendung von Hauptspeicher und der Aussage der Entwickler^[15] mit memSQL eine fast dreißig Mal schnellere Datenbank entwickelt zu haben, als eine, die auf konventionellem Sekundärspeicher basiert.

Hinsichtlich der theoretischen Grundlagen bezieht sich die vorliegende Arbeit auf die Werke von Scherr^[16] (1965), Ferrari^[17] (1986) und Risse^[18] (2006) zur Computer-Perfor- manzanalyse, Mayer^[19] (2013) und Hu/Gorton^[20] (1997) zur Performanz-Modellierung, Meyer et al.^[21] (2015) zum Performanzvergleich bei Datenbanken und Bog et al.^[22] (2011) sowie Krueger et al.^[23] (2010) zur Entwicklung eines Workloadplans. Der Datenbank- und Benchmarkaufbau erfolgt nach dem ,CH-benCHmark‘ nach Kemper/Neumann^[24] (2011) sowie dem TPC-C- und TPC-H-Benchmark des Transaction Processing Perfor­mance Council.^[25]

2. Darstellung von Datenbank-Management-Systemen anhand von Speicherentwicklung und den zugrundeliegenden Benutzungsparadigmen

Für den Einsatz von Datenbanken stellen Datenbankmanagementsysteme (DBMS) einen unverzichtbaren Bestandteil dar. Sie fungieren als Schnittstelle zwischen physischen Da­ten und denjeweiligen Anwendungsprogrammen. Durch den Einsatz von DBMS wird es mehreren Anwendern erst ermöglicht gleichzeitig die benötigten Daten zu manipulieren ohnejeweils eine redundante Kopie davon erstellen zu müssen.^[26] Ein DBMS ist folglich eine Unterstützungssoftware zur Datenverwaltung. Dabei sind wichtige Anforderungen die Sicherstellung von Mehrfachzugriff, Datenunabhängigkeit, Redundanzfreiheit, Da­tenintegrität sowie die Datensicherheit der zugrundeliegenden Daten.^[27] Häufig er­wünschte Eigenschaften von Transaktionen in DBMS beschreibt dabei das englische Ak­ronym ACID. So müssen DBMS Atomarität, Konsitenzerhaltung, Isolation und Dauer­haftigkeit gewährleisten. Das bedeutet, dass Transaktionen ganz oder gar nicht verarbei­tet, in einem konsistenten Datenzustand hinterlassend, von anderen Transaktionen abge­grenzt und abschließend garantiert dauerhaft gespeichert werden müssen.^[28]

Da es unterschiedliche DBMS gibt erfolgt eine Klassifizierung anhand verschiedener Kri­terien. Hierbei beschränkt sich diese Arbeit in den nachfolgenden Abschnitten allerdings auf das Kriterium des allgemeinen bzw. aufgabenspezifischen Aufbaus.^[29] Diese Be­schränkung wird gewählt, da der Aufbau im Kontext zur technologischen Entwicklung von Rechen- und Speichersystemen und den damit verbunden Benutzungsparadigmen betrachtet werden soll. Die angewandte Datenorganisation und -ablagestruktur bestimmt dann im Wesentlichen der Verwendungszweck.

Typischerweise existiert eine physische und aufgabenspezifische Trennung in transakti- onale und analytische Systeme. Diese Trennung zeigt sich u.a. bei schreiboptimierten Systemen mit zeilenbasierter Datenablage und leseoptimierten Systemen mit spaltenba­sierter Datenablage.^[30] Dieses Paradigma scheint allerdings durch die Entwicklung leis- tungs- und kostengünstigerer Speicher und dem damit verbundenen In-Memory-Data­base-Management-System (IMDBMS) fraglich.^[31]

2.1 Darstellung traditioneller Datenbank-Management-Systeme und deren zugrunde liegenden Benutzungsparadigmen

Basierend auf dem von E. F. Codd entwickeltem relationalen Modell^[32] sind die heute am häufigsten vertretenen Datenbanken mit einem relationalen Datenbank-Management­System (RDBMS) ausgestattet. Dabei besagt das zugrunde liegende Prinzip, dass sämtli­che Daten in Tabellen, sog. Relationen, abgelegt werden können.^[33] Die Daten werden hierbei innerhalb der Relationen nach Themenkreisen, sog. Entitäten, geordnet. So wer­den bei Strukturergänzungen neue Tabellen erzeugt oder bestehende erweitert.^[34] Um die Entitäten miteinander zu verknüpfen erfolgt die Definition eines Schlüssels welcher in den miteinander zu verknüpfenden Entitäten fürjeden Datensatz vermerkt wird^[35] (Abb.2). So wird eine hohe Flexibilität bezüglich Ergänzungen und Änderungen gewährleistet. Allerdings nimmt die Komplexität der Daten mitjeder neuen Entität zu und das Abfragen benötigt mehr Zeit, da das Ergebnis erst aus mehreren Tabellen zusammengeführt werden muss.^[36]

Abbildung in dieser Leseprobe nicht enthalten

Will man bspw. wissen aus welchem Ort der Kunde kommt, dessen Auftrag ein bestimm­ter Disponent bearbeitet hat, würde die Abfrage bereits drei Tabellen beinhalten. Die An­lage eines weiteren Kunden würde hingegen nur das Manipulieren einer einzigen Tabelle erfordern. Folglich ergeben sich im Wesentlichen zwei verschiedenen Benutzungspara­digma für relationale Datenbanken - OLTP und OLAP.

Dabei zeigt sich im operationalen Tagesgeschäft das OLTP-Paradigma typischerweise als Hauptanwendung einer Datenbank. Abfragen mit der Structured Query Langue^[37] (SQL) gestalten sich dabei bspw. als INSERT-, UPDATE- oder DELETE-Befehle.^[38] OLTP-Da- tenbanken speichern demnach den aktuellen Datenbestand, welcher abgefragt oder mit Hilfe von Transaktionen aktualisierst wird. Das Augenmerk liegt folglich auf der gleich­zeitigen und direkten Transaktionsverarbeitung von Lese- und Schreiboperationen. Das bedeutet die Sicherstellung der Transaktionssicherheit bei parallelem Zugriff und die Mi­nimierung der Antwortzeiten bei maximalem Datendurchsatz.^[39]

Um dabei eine möglichst hohe Leistung zu gewährleisten wird eine zeilenbasierte Daten­organisation zu Grunde gelegt.^[40] In zeilenbasierten Datenbanken wird die Speicherung jeder Zeile als zusammenhängender Block abgelegt. Im Gegensatz dazu erfolgt in spal­tenbasierten Datenbanken die Speicherung der Attributwerte derjeweiligen Spalten nach­einander. Die zeilenbasierte Tabellenorganisation erhöht so den Zugriff durch schreibop­timierte Anfragen, da Blöcke einfach hinzugefugt oder entfernt werden können. Aller­dings muss fürjede Leseanfrage immer der komplette Datenbestand gelesen werden um ein bestimmtes Attribut einer Tabelle zu finden. Der Unterschied zwischen beiden Archi­tekturen ist in Abbildung 3 dargestellt. Die drei Datensätze zi, z2 und z3 enthalten dabei je drei Attribute si, s2 und s3.^[41] Die sich daraus ergebenden Einzeldaten vijsind dabei auf der rechten Seitejeweils zeilen- und spaltenorientiert angeordnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Datenorganisationsalternativen

(Quelle: Knabke, T., Olbrich, T. (2016) In-Memory-Datenbanken, S.i9i)

Die spaltenorientierte Architektur findet Verwendung im zweiten Benutzungsparadigma für Datenbanken - den leseoptimierten OLAP-Systemen. Anwendungen zu Analysezwe­cken und überwiegend mengenbasierten Leseoperationen verwenden nur wenige, ca. 10% aller vorkommenden Attribute einer Datentabelle. Hierfür stellt sich die zeilenori­entierte Speicherung als nachteilig heraus.

Werden die abzulegenden Daten in einer spaltenbasierten Datenstruktur organisiert, kann speziell auf die angeforderten bzw. relevanten Spalten und Datensätze zugegriffen wer­den. Weiterhin enthalten diejeweiligen Spalten immer gleiche Dateitypen mit ähnlichen Ausprägungen, was den Einsatz von Komprimierungsalgorithmen möglich macht. Diese beiden Zusammenhänge verbessern die Leseleistung unter gleichzeitiger Verringerung des Speicherverbrauchs.^[42] Der Leistungsunterschied kann eine Steigerung zwischen 10.000 und 100.000% ausmachen.^[43]

Das OLAP-Paradigma zeichnet sich durch vielfältige, schnelle und interaktive Zugriffe aus, um konsistente und relevante Informationen für Manager bzw. qualifizierte Mitar­beiter zu ermöglichen.^[44] SQL-Abfragen gestalten sich dabei häufig als Such- bzw. kom­plexe ,SELECT-FROM-WHERE‘-Befehle einer multidimensionalen Analyse eines be­stimmten Sachverhalts.^[45]

Wurden RDBMS für OLTP entwickelt und optimiert, werden OLAP Anwendungen mit­tels eines OLAP-Servers realisiert. Dieser Server wird dann in eine bestehende Datenbank eingegliedert, um sie um iterative Analysefunktionen zu erweitern. Im Gegensatz zu OLTP mit zweckorientierten Fragestellungen und zweidimensionaler Tabellen, werden die entscheidungsorientierten Analysen von OLAP-Anwendungen mittels mehrdimensi­onalen Strukturen, sog. OLAP-Würfeln, ermöglicht.^[46] In diesen Würfeln werden die zu analysierenden Sachverhalte ihren Dimensionen nach aufgespannt und mehrdimensional organsiert. Dabei sind OLAP-Würfel allerdings nicht nur auf drei Raumdimensionen be­schränkt, weshalb man in diesem Zusammenhang auch von ,Hyperwürfeln‘ spricht.^[47] Durch die Darstellung als Würfel wird der analytische Charakter von OLAP-Anwendun- gen bereits deutlich (Abb. 4).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Datenstruktur in einem OLAP-Hyperwürfel (Quelle: Totok, A. (2001), Modellierung, S.56.)

So wird bspw. die Fragestellung welchen Bruttoerlös der Artikel Natura in den ersten drei Quartalen erzielt hat, durch einfache Aggregation des Vektors Natura/Bruttoerlös in der grau unterlegten Zelle hinterlegt und beantwortet.^[48] Aber auch der Vorteil der spaltenori­entierten Datenorganisation wird deutlich, da aus der großen Datenmenge nur wenige Attribute der Zielspalten abgefragt werden müssen.^[49]

Bei solch komplexen OLAP-Anfragen an Hyperwürfel werden sehr große Datenmengen verarbeitet, indem typischerweise auf historische Daten aus heterogenen Datenquellen zugegriffen wird. Dabei ist es notwendig Daten aus den verschiedenen operativen Syste­men mittels eines ETL-Prozesses zu überführen. Dies hat eine Verlängerung der Analy­sezeit bzw. eine Erhöhung der Systemanforderungen zur Folge.^[50] Der Grund hierfür liegt in der eingangs beschriebenen unterschiedlichen Datenorganisation der beiden Systeme. So müssen die OLTP-schreiboptimal, zerteilten Daten in verschiedenen Tabellen zu OLAP-leseoptimalen, zusammenhängenden Sachverhaltsdaten umgewandelt werden.^[51] Die nachfolgend zusammengefassten Charakteristika von OLAP- und OLTP-Systemen zeigen die Schwierigkeiten der gleichzeitigen Anwendung auf einer gemeinsamen Da­tenbank und die Notwendigkeit von ETL-Prozessen auf.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: ETL bei OLTP vs. OLAP (Quelle: eigene Darstellung nach Roger, M. (2010), Konzeption, S.29)

Aufgrund der unterschiedlichen Art der Nutzung durch relativ kleine Datenmengen mit einer hohen Zahl von Zugriffen bei OLTP und relativ großen Datenmengen bei einer ge­ringen Zahl von Zugriffen bei OLAP ergeben sich gänzlich unterschiedliche Lastvertei­lungen.^[52] Die damit jeweils verbundene Art der Datenorganisation hat im Wesentlichen zur Optimierung von logisch und physisch getrennten Systemen geführt, welche mittels ETL-Prozess verbunden sind.^[53]

Als wesentliche Eigenschaft traditioneller DBMS kann mit der Entwicklung der In-Me- mory-Technologie allerdings auch die Datenvorhaltung auf Festplatten bzw. Sekundär­speichern benannt werden. Über mehrere Dekaden hinweg bestand in Sekundärspeichern die wirtschaftlichste und leistungsfähigste Losung Daten zu speichern. Auch wenn die Idee der Datenvorhaltung im Hauptspeicher bereits seit Mitte der achtziger Jahre besteht, sind erst in den letzten Jahren hauptspeicherbasierte Datenbanken aufgrund ihres expo­nentiell sinkenden Kostenleistungsverhältnis zunehmend in den Vordergrund gerückt.^[54] Daher erfolgt im nachfolgenden Abschnitt die nähere Betrachtung dieses Datenbanksys­tems und seiner zugrundeliegenden Datenorganisation.

2.2 Darstellung des In-Memory-Database-Managements mit Hilfe aktueller Speicherverwaltungssysteme

In-Memory-Datenbanken unterscheiden sich, ihrem Namen nach, gegenüber traditionel­len Datenbanken maßgeblich in der Verwendung von Haupt- anstelle des Sekundärspei­chers. Dadurch kann der typischerweise entstehende Engpass bei Ein- und Ausgabeope­rationen zwischen schnellem Arbeitsspeicher und langsamen Festplattenspeicher nahezu eliminiert und eine drastische Verkürzung der Zugriffszeiten erreicht werden.^[55] Wie im vorherigen Abschnitt bereits erwähnt, ist diese Idee allerdings nicht neu. Bereits 1984 untersuchte u.a. DeWitt dieses Konzept^[56], dessen Umsetzung früh wieder aufgege­ben wurde. Diejüngste Wiederaufnahme und Entwicklung von IMDB steht mit drei Fak­toren in engem Zusammenhang: dem Bedürfnis nach Echtzeitinformationen, der Ent­wicklung der Speicher- und Rechentechnologie sowie der Reduzierung bestimmter Kos­ten für Unternehmen.^[57]

Suchmaschinen zeigen heute auf, welches Potential bzw. Bedürfnis in der Echtzeitdaten­verarbeitung und -analyse von riesigen Datenmengen liegt. So führen millionenfache, gleichzeitige Anfragen der Nutzer zu nahezu sofortigen Antworten,^[58] und das bei einer ortsunabhängigen sowie ununterbrochenen Verfügbarkeit.^[59] Diese 1994 von Gates for­mulierte Vision der „Information at your fingertips“^[60] mit der Reaktionsgeschwindigkeit eines Gedankens^[61] ist heute in vielen Bereichen Wirklichkeit geworden.^[62] Die Übertragung in das Unternehmensumfeld mit Hilfe traditioneller DBMS gestaltet sich allerdings als schwierig. So interessieren, anders als bei indexgeleiteten Suchanfra­gen nicht nur die relevantesten Daten, sondern vielmehr die Sichtung und Beurteilung aller Daten, um daraus Relevanz für Berichte abzuleiten. Auch die Komplexität der An­fragen sowie die Datenvorverarbeitung aus teils verschiedenen Quellen stellen dabei große Herausforderungen dar.^[63]

Die Komplexität der Anfragen oder die Größe der Daten, wie sie bei heutigen OLTP bzw. OLAP-Systemen vorherrscht, kann zu teilweise stundenlangen Antwortzeiten führen. Diese Zeiten reduzieren sich jedoch, auch für komplexe Analyseanwendungen, mithilfe der IM-Technologie auf mitunter eine Sekunde.^[64]

Daneben zeigt sich moderne Hardware als Objekt kontinuierlichen Wandels und der In­novation. Für die Entstehung des IMDBMS kann hier die Entwicklung der Mehrkern­Architektur und größerer sowie günstigerer Hauptspeicher als maßgeblich erachtet wer­den. So entwickelten sich die HDD-Speicherpreise von 1970 mit 250 US-Dollar bis 2001 auf 0,01 US-Dollar pro MB (Abb. 6). In gleichem Maße sank auch der Preis/MB bei Hauptspeichern, allerdings mit vielfach höheren Leistungsdaten.^[65]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Speicherpreisentwicklung (Quelle: Plattner, H., Zeier, A. (2011), In-Memory Data Management, S.15)

Dabei zeichnet sich Hauptspeicher nicht nur durch gravierend kürzere Zugriffszeiten, sondern auch durch einfachere Zugriffsalgorithmen aus. In Verbindung mit der ab 2001 entstandenen Entwicklung von 64Bit-Mehrkernprozessoren konnte die permanente Da­tenvorhaltung im Hauptspeicher unter direktem Zugriff des Prozessors sinnvoll realisiert werden. Eine besondere Bedeutung kommt hierbei der spaltenorientierten Datenorgani­sation zu.^[66]

Schließlich haben auch Kostenfaktoren wie Betriebs- und Anschaffungskosten einen maßgeblichen Einfluss auf das Aufbauen und Betreiben von In-Memory-Systemen.^[67] In diesem Kontext wird fortführend auf Total Costs of Ownership (TCO) abgestellt, welche die Laufzeitkosten inkl. Beschaffung und Betrieb eines Systems umfassen.^[68]

Welche Hardware benötigt wird und welche Beschaffungskosten damit entstehen, hängt maßgeblich von den spezifischen Voraussetzungen der zu betreibenden Anwendungen ab. Grundsätzlich kannjedoch festgehalten werden, dass steigende Wettbewerbsfähigkeit häufig die Beschaffung teurer high-end Hardware impliziert. Determinierend für die TCO gestalten sich allerdings vielmehr die Kosten der Stromversorgung und der Administra­tion. Bei Datenbanksystemen mit klassischen Speichermedien und den damit verbunde­nen Kühleinrichtungen entsteht ein enormer Strombedarf. Dieser kann bei großen Daten­centern zwischen 30% und 60% der TCO ausmachen. Größten Einfluss auf die Kosten­struktur der TCO haben allerdings die Administrationskosten. Diese umfassen sowohl das initiierende Aufbauen, Konfigurieren und Anpassen als auch das betriebliche Über­wachen, Ausbauen und Erweitern.^[69]

Werden nun die zu speichernden Daten im Haupt- statt dem Sekundärspeicher vorgehal­ten, erfährt das ganze System neben einer Leistungssteigerung auch große Änderungen in den zugrundeliegenden Kostenstrukturen. So steigen zwar aktuell die Anschaffungs­kosten, jedoch sinken Versorgungs- und Administrationskosten massiv.^[70] Der bauartbe­dingte geringere Stromverbrauch von Hauptspeicher gegenüber Sekundärspeicher wird in den nachfolgenden Abschnitten des Kapitels 3 näher erläutert. Die Senkung der Admi­nistrationskosten ergibt sich durch den geänderten Aufbau von In-Memory-Systemen ge­genüber traditionellen Datenbanksystemen.^[71]

Wie im vorherigen Abschnitt dargestellt, sind OLTP- und OLAP-Systeme logisch wie physisch voneinander getrennt. Um die Reaktionszeit für analytische Systeme zu erhöhen werden mittels ETL-Prozessen redundante Daten erzeugt und aufbereitet. Diese Redun­danzen gehenjedoch mit einem hohen zeitlichen Mehraufwand einher.

Dieser Zusammenhang verliert an Bedeutung, wenn die Verbindung beider Systeme und dabei die deutlich schnellere Verarbeitung realisiert werden kann.^[72] In-Memory-Systeme beschleunigen die Verarbeitung von datenintensiven Anwendungen unter Ausnutzung sämtlicher Funktionalitäten einer gemeinsamen Datenbank. Dadurch ist die Notwendigkeit eines datenredundanten ETL-Prozess obsolet. Neben der Beschleu­nigung der Anwendungen wird auch die Zeit, welche fur kopieren, sichern und archivie­ren üblicherweise verwandt wird, reduziert. Somit entfallen viele der erwähnten admi­nistrativen Aufgaben und der dazugehörigen Kosten. Die einfachere Architektur mit we­niger Bestandteilen wie z.B. Cache oder redundanten Datenansichten kann den zu verar­beitenden Programmcode um bis zu 75% verringern und neue Kapazitäten schaffen. Diese führen mit dem schnelleren Hauptspeicher dazu, dass die operationalen und analy­tischen Anwendungen deutlich beschleunigt werden können.^[73]

Das physische Datenlayout hinsichtlich des tatsächlichen Zugriffs zu optimieren, statt durch vorgegebene OLTP- bzw. OLAP-Paradigma vorher zu definieren, liegt folglich im Fokus von In-Memory-Systemen. Die zunehmende Nachfrage nach Analysefunktionen für transaktionale Daten zeigt dabei eine besondere Bedeutung der OLAP-typischen Spaltenorientierung.

Wie im Abschnitt 2.1 dargestellt, bietet die spaltenorientierte Datenorganisation insbe­sondere Vorteile beim analysetypischen Lesen weniger Attribute. Bereits durch die Fo­kussierung auf relevante Spalten kann so ein Geschwindigkeitsvorteilt erreicht werden. Dem gegenüber stehenjedoch Mehrkosten beim Herstellen kompletter Relationen in ver­tikalen Partitionierungen, im Vergleich zu zeilenorientierten Strukturen. Bei festplatten­basierten Datenbanken muss so auf alle Daten zugegriffen und das sequentielle durch zufälliges und langsameres Lesen ersetzt werden. Diese Nachteile führten daher vor allem bei transaktionalem oder gemischtem Workload dazu, dass das spaltenorientierte Schema nicht zum Einsatz kommt. Erst die Kombination der schnellen ,random access‘-Funktio­nalität mit der Spaltenorientierung ermöglicht den Einsatz bei reinem OLTP-, OLAP- oder gemischtem Workload.^[74]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Datenzugriff von OLTP- und OLAP-Anwendung bei Zeilen- und Spaltenorientierung

(Quelle: Krueger, J. et al. (2010), Hauptspeicherdatenbanken, S.4)

Die konventionellen Zugriffsmuster im Zusammenhang mit physikalischer Datenorgani­sation zeigt die Abbildung 7. Es wird deutlich, dass die Kombination von OLTP und OLAP-Paradigmen eine Speicherablage benötigt, welche im Stande ist, die Kosten sämt­licher Anfragearten zu minimieren. Datenbanken mit Spaltenorientierung profitieren da­bei von der geringen Kardinalität ihrerjeweiligen Werte einer Spalte. Dieser Zusammen­hang sowie die Möglichkeit der separaten Spaltenverwaltung ermöglichen den Einsatz effektiver Komprimierung und die Erhöhung der Informationsdichte bei gleichbleiben­dem Speicherplatzbedarf. Dies istjedoch erst durch die Datenverarbeitung im Hauptspei­cher effizient realisierbar, da Cache-Misses diesen Vorteil schnell wieder zunichtema­chen.^[75] Cache-Miss beschreibt den Vorgang, dass Daten einer Anfrage an den Sekundär­speicher im Pufferspeicher nicht vorrätig sind und erst mitVerzögerung aus dem Haupt­speicher geladen werden müssen.^[76]

Die Verwendung effektiver Kompressionsalgorithmen resultiert auch aus der Nichtan­wendbarkeit des Moor’schen Gesetzes^[77]. Dieses sagt seit über 40 Jahren verhältnismäßig zuverlässig voraus, dass die Leistung von Prozessoren alle 18 Monate verdoppelt werden kann. Ein solcher Zusammenhang ist für Primär- oder Sekundärspeicherjedoch nicht zu beobachten. Der dadurch immer größer werdende Leistungsabstand zwischen Prozessor und Speicher resultiert in zunehmend größer werdenden Ein-/Ausgabe-Verzögerungen. Für die Mehrheit aller Datenbankanfragen stellt das heute den größten Engpass dar. Ver­lustfreie und einfache Kompressionen helfen allerdings diesen Flaschenhals zu vermin­dern. Sie erlauben es, die verfügbare Bandbreite besser auszunutzen, während der Mehr­aufwand der Dekompression durch die schnellere Prozessorleistung eliminiert werden kann. Für eine effektive Kompression nutzen entsprechende Verfahren Wissen über die jeweilige Datendomäne und Redundanzen innerhalb der Daten. Dies zeigt sich bei spal­tenorientierten Datenbanken als besonders effizient.^[78] Dafür wird im Folgenden auf das Konzept der Entropie als Maß des mittleren Informationsgehalts abgestellt.^[79]

Daten innerhalb derjeweiligen Spalten weisen häufig denselben Datentyp auf und besit­zen typischerweise eine ähnliche Semantik. Daraus resultiert eine niedrige Entropie bzw. es gibt nur wenige Daten unterschiedlicher Werte. Dieser Zusammenhang ist insbeson­dere bei betriebswirtschaftlichen Datenbanken zu beobachten, da entsprechende Anwen­dungen vor allem sich wiederholende Prozesse abarbeiten bzw. festhalten. Folglich wird der Wertebereich derjeweiligen Datentypen kaum ausgenutzt.^[80]

Dieser Zusammenhang erlaubt den Einsatz der häufig eingesetzten Kompressionsmetho­den ,Dictonary‘- und ,Run-length-encoding‘. Beim ,Dictonary‘-Encoding wird, dem Na­men nach, ein Wörterbuch von häufig erscheinenden Werten angelegt, auf welche nur noch mit Hilfe signifikant kürzerer Schlüssel verwiesen wird. Dabei kann in einem zwei­ten Schritt eine Bit-weise Komprimierung des Schlüssels erfolgen, um die Kompressi­onsrate weiter zu erhöhen. Ebenso erlaubt das Sortieren des Wörterbuchs weitere Vor­teile, da diese keinen Einfluss auf die ursprüngliche Wertesortierung jedoch verkürzte Abfragezeiten zur Folge hat.^[81] Beim ,Run-length-encoding‘ hingegen wirdjede Wieder­holung innerhalb eines Wertes als Wertepaar aus Wert und Anzahl der Wiederholungen gespeichert. Diese Methode zeigtjedoch nur bei sortierten Spalten mit wenigen Attribu­ten und geringer Varianz eine hohe Kompressionsrate.^[82]

Mit Hilfe der Spaltenkomprimierung erhöht sich die Entropie so sehr, dass die gleichzei­tige Verarbeitung relevanter Informationen und die Erhöhung der Bandbreitennutzung ermöglicht werden. Obwohl diese Technik auch in zeilenorientierten Datenorganisatio­nen möglich ist, erlaubt erst die Kombination der spaltenorientierten Datenorganisation mit der Datenablage und -Verarbeitung im Hauptspeicher relevante Vorteile. Zu erwäh­nen bleibt allerdings, dass die Modifikation der Daten eine erneute Komprimierung durch die verschiedenen Algorithmen benötigt. Der dadurch entstehende Mehraufwand muss in einem Pufferspeicher unkomprimiert vorgehalten werden um weiterhin schnelle Operati­onen zu gewährleisten. Dabei werden in festgelegten Intervallen alle Änderungen des un­komprimierten Puffer- und komprimierten Hauptspeichers synchronisiert. Folglich ste­hen das Komprimierungsverhältnis und die Kosten der Dekomprimierung in einem Span­nungsverhältnis zueinander. Daher wird generell das Ziel verfolgt so lange wie möglich Nutzen aus den komprimierten Werten zu ziehen und die Dekomprimierung wirklich not­wendiger Daten möglichst lange hinauszuzögern.^[83]

Abschließend erfolgt die Betrachtung der In-Memory-Datenpersistenz als wichtiges Un­terscheidungsmerkmal zum traditionellen Datenbank-Management. Wie in Kapitel 2 ein­gangs erwähnt, werden an DBMS viele verschiedene Anforderungen gestellt. Um Daten gegen Programm- und Systemfehler sowie Hardwareausfälle zu sichern bzw. nach Stör­fällen den korrekten Zustand der Datenbank wiederherstellen zu können, wird eine per­sistente Datenhaltung benötigt. Diese unter die Datensicherheit fallende Anforderung an DBMS gestaltet sich bei der Verwendung von flüchtigen Hauptspeichern jedoch als schwierig.^[84]

Eine Entscheidung für oder gegen eine persistente Datenspeicherung ist in traditionellen DBMS weniger ausgeprägt, da die geringere Leistung und das daraus resultierende Be­dürfnis an kumulierten Daten das persistente Speichern häufig bedingt. In IMDB ist je­doch die flüchtige Haltung der kompletten Daten mit bis zu 50 TB^[85] möglich und folglich die Entscheidung für oder gegen eine persistente Speicherung deutlich relevanter.^[86]

Es zeigen sich vielzählige Gründe für eine Datenpersistenz, welche sich neben dem sub­jektiven Sicherheitsbedürfnis in Vereinfachung der Datenhandhabung, Gesetze, Gover- nance-Bestimmungen und technische Einschränkungen gliedert. Eine persistente Spei­cherung zeigt sich häufig schon im Eingangsbereich der Datenbank, um nach erfolgrei­cher Extraktion das Quellsystem zu entlasten. Dabei sind Daten häufig nicht lange oder nur in veränderten Zuständen verfügbar, sei es aus regelmäßiger Überschreibung oder Problemen mit dem Netzwerk. Die persistente Speicherung kann allerdings die Datenver­fügbarkeit garantieren. Daten, die aufgrund ihrer Komplexität bzw. bestehenden Abhän­gigkeiten zu anderen Daten transformiert werden müssen, bedingen in vielen Fällen eben­falls eine persistente Speicherung. Damit soll ein korrektes Durchlaufen bzw. keine wie­derholte Transformation gewährleistet werden. Weitere Gründe entstehen aus veränder­ten Transformationsregeln, aufwendiger Datenwiederherstellung, dem Bedürfnis nach ei­ner konstanten Datenbasis oder der Erhöhung der Datenzugriffsgeschwindigkeit.^[87] Mit der sich entwickelnden ,Service Oriented Architecture4 (SOA) ist für sämtliche Un­ternehmenseinheiten die ,Single Source of Truth4 (SSOT) ihrer Daten immer wichtiger geworden.^[88] Werden ohne spezielle Geschäftslogik transformierte Daten nach unterneh­mensweit gültigen Regeln persistent gespeichert, kann ein vergleichbarer und einheitli­cher Datenbestand geschaffen werden, auf welchen die jeweiligen Anwendungen und Geschäftsbereiche zugreifen können.^[89] Auch wenn mittlerweile auf Datenreplikation ver­zichtet werden kann, ist mit der Erschaffung einer SSOT die Datenpersistenz eine der wichtigsten Prämissen.^[90]

Die In-Memory-Technologie suggeriert hingegen, dass nun keine Daten mehr zusätzlich zu den Ursprungsdaten persistent gespeichert werden müssten. Insbesondere die für Ana­lysezwecke abgeleiteten aggregierten oder verdichteten Daten könnten ,on-the-fly4 ermit­telt und verfügbar gemacht werden. Dies gilt allerdings nur für wenige der oben gennann­ten Gründe. So muss aus Gründen der abhängigen Transformationen, veränderten Trans­formationsregeln, Datenverfügbarkeit, Corporate Governance sowie Gesetzen und Best­immungen weiterhin verpflichtend persistent gespeichert werden.^[91]

Daneben besteht in vielen Bereichen eine Notwendigkeit ihr eine Datenpersistenz. Diese können zum einen Daten sein, welche nur mit einem erheblichen Aufwand wiederherge­stellt werden können, wie bspw. komplex transformierte oder archivierte Daten. Hierbei ist der Begriff ,erheblich‘ sicherlich subjektiv und bedarf daher einer genaueren Betrach­tung.

Zum anderen werden Daten, die den Betrieb der Datenbank oder einzelner Anwendungen vereinfachen, bspw. Data-Marts mit besonderen Berechtigungen oder speziell abgelegte Plandaten, persistent gespeichert. Auch Aspekte der Sicherheit, Performanz, Konzeptio­nen der SSOT oder des ,Corporate Data Memory4 zeichnen sich durch die Notwendigkeit einer Datenpersistenz aus. Jedoch kann eine Entscheidung dafür oder dagegen erst erfol­gen, sobald die unscharfen und subjektiven Begriffen wie ,aufwendig‘, ,häufig‘ oder ,komplex‘ fürjeden Bereich individuell spezifiziert wurden.^[92]

Ein deutlicher Unterschied zu den traditionellen DBMS ergibt sich bei allen nicht-ver­pflichtend persistent gespeicherten Daten. Hierbei spielt Redundanz eine zentrale Rolle um bspw. Suchprozesse innerhalb der Datenbank zu beschleunigen.^[93] Neben Daten zur Verbesserung der Zugriffsperformanz betrifft dies insbesondere redundante Daten auf­grund von komplexen Transformationen oder zur Herstellung einer konstanten Datenba­sis für Planungsabläufe. Hierbei zeigt sich, dass in einem In-Memory-System viele Daten nicht gespeichert werden müssen, sondern bei Bedarf ,on-the-fly‘ flüchtig erzeugt werden können. Dies zeigt sich insbesondere für Daten mit einfacher Transformationslogik wie ,Joins‘ und Aggregationen. Folglich äußert sich die Persistenz bei IMDB in vielen mate­rialisierten Schichten nur noch als virtuelle Schichten.^[94]

3 Darstellung verschiedener Speicherverwaltungssysteme und Performanz- Evaluation von In-Memory-Datenbanken

3.1 Darstellung verschiedener Speicherverwaltungssysteme

Laut Kanakamedala und Kaplan steigen jährlich die Datenspeicherungskosten in Unterneh­men zwischen 15% und 20% bei sinkenden Beschaffungskosten von 30%. Diese Kosten re­sultieren aus dem immer größer werdenden Speicherbedarf einer immer mehr Daten produ­zierenden und verarbeitenden Gesellschaft. Die steigenden Kosten der Speicherung, bedingt durch Administration, Sicherung, Spiegelung sowie steigenden rechtlichen Anforderungen an die Datenhaltung, stehen in einem Spannungsverhältnis zu den sinkenden Beschaffungs­kosten für Speicher, die immer mehr Kapazität und geringere Zugriffszeiten anbieten.^[95] Die Speicherkosten mit kürzeren Zugriffszeiten steigen daneben so hoch an, dass eine wirtschaft­lich vertretbare Verwendung hoher Speicherkapazitäten nur mit vergleichsweise langsamen Speichern möglich ist. Um nun dennoch die Speicherkosten zu senken, ohne dabei signifikant auf kürzere Zugriffszeiten zu verzichten, hat sich die bewährte Architektur der Speicherhie­rarchie (Abb. 8) entwickelt. Dabei wird versucht zu den Kosten des langsamsten die Zugriffs­zeiten des schnellsten Speichers zu erreichen. Daten mit hohen Zugriffswahrscheinlichkeiten werden so in den schnellen, kleinen und teuren Speichern gehalten, während die anderen auf den langsameren, größeren und günstigeren Speichern gehalten werden.^[96] Die in den nachfolgenden Abschnitten näher betrachteten Speichersysteme können somit bes­ser in ihrer Leistung und technisch/betriebswirtschaftlichen Relevanz eingeordnet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Die Speicherhierarchie mit typischen Zugriffszeiten und Kapazitätsgrößenordnungen der jeweili­ gen Speichermedien (Quelle: eigene Darstellung nach Häberlein, T. (2011), Saake, G. (2011), Här­der, T., Rahm, E. (2001), Rahm, E. (1993))^[97]

3.1.1 Darstellung der Speicherverwaltung von HDD-Magnetspeicher-Festplatten

In sechs Dekaden entwickelte sich der ,Hard-Disk-Drive‘- (HDD) Speicher, mit anfangs noch 24 Inch Disk-Durchmesser und einer Speicherkapazität von 5MB zum kompakten und hochkapazitiven Rückgrat der digitalen Gesellschaft.^[98] Nach Analysen des Marktfor­schungsunternehmens IHS Inc. ist der weltweite prognostizierte Absatz von HDD-Spei- chern im Jahr 2016 mit knapp 400 Millionen Stück immer noch der mit Abstand größte nach Halbleiter-Speichern mit ca. 200 Millionen Stück.^[99] Bis 2019 solljedoch der Markt­anteil von Halbleiter-Speichern im Notebook-Sektor den von HDDs überstiegen haben.^[100]

Die HDD-Magnetspeicher-Festplatte bezieht sich mit ihrem Namen auf ihre technische Funktionsweise und Bauart. Herzstück des Speichers ist eine magnetisierbare rotierende Aluminium- oder Glasscheibe, welche mit Hilfe eines Lese- und Schreibkopfes Informa­tionen speichern, wiedergeben und überschreiben kann. Die Rotationsgeschwindigkeit kann bis zu 10.000 Umdrehungen pro Minute betragen. Heute typische Abmessungen für HDD-Scheiben, Form Faktor genannt, betragen im Durchmesser für den Desktop- und Serverbereich 3,5 Inch und für den Mobilbereich 2,5 Inch.^[101] Hinsichtlich der Speicher­kapazität erreicht die im Jahr 2015 vorgestellte ,Ultrastar He10‘ den bisher höchsten^[102] Wert von 10TB mit 7.200 Umdrehungen pro Minute unter den 3,5-Inch-Festplatten.^[103]

Die Datenanordnung auf den magnetisierbaren Disks erfolgt mit Hilfe eines ,thin film inductive head‘ durch Polarisation der Oberfläche. Diese polarisierten Bereiche, interpre­tierbar als Bits, bilden über die Oberfläche hinweg konzentrische Kreise, genannt Spuren. Ein Bit stellt die kleinste speicherbare Information auf einem Medium dar und enthält die binäre Information Null oder Eins. Pro Disk befinden sich ca. 70.000 bis 100.000 Spuren auf der Oberfläche, welche auf mehreren Ebenen magnetisiert einen Zylinder ergeben.^[104] Spuren unterteilen sich dabei in weitere Einheiten, sogenannte Blöcke. Blöcke habe eine Länge von typischerweise 512 Byte^[105], wobei verschiedene Blöcke mit den gleichen Win­kelkoordinaten zu einem sogenannten Sektor gehören.^[106]

Innerhalb eines aktuellen Computersystems gehört der HDD-Speicher zu den Bestandtei­len mit den höchsten Zugriffszeiten. Diese Zugriffszeit setzt sich, bedingt durch die Kon­struktion, aus mehreren Teilen zusammen. So umfasst sie im Wesentlichen die Spurwech­selzeit, Latenzzeit und der Datentransferzeit.^[107]

Die Spurwechselzeit beschreibt die Zeit, die benötigt wird um den Lese-/Schreibkopf zu einer bestimmten Position zu bewegen und wird hauptsächlich durch den Steuerungsmo­tor determiniert. Hierfür typische Zeiten befinden sich zwischen 2 und 15ms und haben einen durchschnittlichen Wert von 9ms. Aus der Rotation der Scheibe resultiert die La­tenzzeit. Sie beschreibt die Wartezeit des Schreib-/Lesekopfs auf die passende Stelle der rotierenden Scheibe und beträgt bei 7.200 Umdrehungen/Minuten durchschnittlich 4,17ms. Schließlich beschreibt die Datentransferzeit die Zeit der eigentlichen Datenüber­tragung. Sie ergibt sich aus der zu bearbeitenden Dateigröße und der Datentransferrate, gemessen in MB/s. Bei einer bspw. 2MB großen Datei und einer Festplatte mit 7.200 Umdrehungen/Minute sowie 125 Sektoren zu 512 Byte/Sektor ergibt sich das eine Da­tentransferrate von 125 Sektoren x 512 Byte x (7200 rpm / 60 s) = 7,68 MB/s und einer Datentransferzeit von 2MB / 7,68 MB/s = 260ms.^[108]

Die Such- und Rotationslatenz stellt sich als Flaschenhals mechanischer HDD-Speicher dar. Die Latenzzeit dominiert dabei die Zugriffszeit und ist mit mehreren Millisekunden deutlich höher als die Zugriffszeit von max. 100 Mikrosekunden bei Flash-Halbleiterspei­chern. Daneben dauert der Festplattenstart bzw. das Andrehen der Scheiben auf ihre Be­triebsgeschwindigkeit mit 2 bis 5s sehr lange, im Vergleich zum Halbleiterspeicher, wel­cher de facto sofort betriebsbereit ist. Auch die hohe Schock- bzw. Störanfälligkeit und die damit verbundene geringe ,Mean Time Between Failures4 sind gravierende Schwä­chen gegenüber Halbleiterspeichern.^[109] Schließlich ist auch der 290% höhere Stromver­brauch von HDD- gegenüber SSD-Speichern nicht zu vernachlässigen.^[110] Diese bauartbedingten Schwächen in Verbindung mit der Leistungssteigerung und Kos­tensenkung von Halbleiterspeichern, konstituieren diesen als Nachfolgetechnologie.^[111] Im nachfolgenden Abschnitt erfolgt dahingehend eine detaillierte Betrachtung von SSD- Halbleiterlaufwerken.

3.1.2 Darstellung der Speicherverwaltung von SSD-Halbleiterlaufwerken

Bei einem ,Solid-State-Drive‘- (SSD) Halbleiterlaufwerk handelt es sich um einen nicht­flüchtigen Flash-Speicher der als HDD-Laufwerk emuliert wird. Dabei bezieht sich ,So- lid-State‘, englisch für Festkörper, auf den in der Elektronik verwendeten Zusammenhang keine mechanischen Teile und stattdessen Halbleitertechnik zu verwenden.^[112] Durch die Emulation als HDD-Laufwerk können die gleichen Host-Schnittstellen und Protokolle wie ,Parallel-ATA‘, ,Serial-ATA‘ oder ,SCSI‘ verwendet werden. Der typische Form­faktor ist dabei 2,5 Inch bzw. Bauformenkompatibel zu Mobil-, ,USB‘- und ,PCIe‘- Schnittstellen.

Während in den letzten 20 Jahren die Magnetspeicher-Leistung um ca. 30% gestiegen ist, stieg zeitgleich die Rechenleistung um ca. 3.000%. Dies machte die Entwicklung des sig­nifikant schnelleren SSD-Speichers notwendig, um die physikalischen Begrenzungen der HDD-Technologie aufzuheben. Dabei bietet der Flash-Speicher geringere Zugriffszeiten und die Erhöhung der Systemleistung mit Hilfe aktueller Rechenleistung.^[113] SSD-Spei- cher haben mit 15,36TB die bisher höchste Speicherkapazität und damit bereits knapp 50% mehr^[114] als der bisher größte HDD-Speicher erreicht.^[115]

Die SSD-Architektur umfasst im Wesentlichen die Host-Schnittstelle, einen Controller- und mehrere Flash-Chips, angeordnet und fest miteinander verlötet auf einer Leiterplatte. Dabei bilden mehrere parallel geschaltete Flash-Chips einen Flash-Channel. Die ver­schiedenen Flash-Channel sind wiederum parallel an den Controller-Chip angebunden, welcher über die Host-Schnittstelle mit dem Host kommuniziert. Die Datenanordnung erfolgt in Flash-Zellen, welche sich als Arrays in den Flash-Chips befinden. Jede Zelle besteht dabei aus zwei Transistoren, die bei angelegter Spannung Elektronen einfangen und halten können. Die verschiedenen Spannungsniveaus speichern den Ladungszustand, interpretierbar als Bit. Anders als bei flüchtigen Halbleiterspeichern wie Arbeitsspeichern ist das Halten der Elektronen auch bei ausgeschalteten Speicher-Chips und fehlender Spannung möglich und erlaubt somit die permanente Datenspeicherung.^[116]

Das Halten eines einzelnen Ladungszustands bzw. Bits stellt dabei eine ,Single-Level- Cell‘ (SLC) dar. Durch halten mehrerer Ladungszustände, in einer sog. ,Multi-Level- Cell‘ (MLC), ist es möglich mehrere Bits pro Zelle zu speichern.^[117] Die Ladezustände ,Aus/An‘ bzw. ,Null/Eins‘ der SLC-Architektur werden bei der MLC-Architektur mit mindestens zwei weiteren Ladezuständen auf ,Null/Null‘, ,Null/Eins‘, ,Eins/Null‘ sowie ,Eins/Eins‘ und somit auf 2 Bit erweitert. Eine Layer-Cell mit 8 Ladungsschichten spei­chert demnach bereits 3 Bit und eine mit 16 Schichten 4 Bit.^[118]

Neben der ,SLC/MLC‘-Architektur ist ein weiterer logischer und physischer Aufbau von Flash-Speichern zu unterscheiden. Flash-Speicher können zum einen mit einer ,Not-Or‘- (NOR) oder einer ,Not-And‘- (NAND) Struktur aufgebaut sein. Primär zeichnet sich NOR-Flash durch kürzere Zugriffszeiten mit einer geringeren Lebensdauer und NAND- Flash durch eine höhere Datendichte mit einer höheren Lebensdauer aus. Daher wird NOR-Flash überwiegend zur Speicherung von Code auf OnBoard-Chips verwendet, wo­hingegen NAND-Flash in SSD-Speichern Verwendung findet.^[119] Da dieser Abschnitt den Fokus auf SSD-Speicher hat wird folglich auf eine detailliertere Betrachtung der NAND/NOR-Architektur verzichtet.

Die SSD-Speicherleistung wird demnach maßgeblich durch die SLC/MLC-Architektur determiniert. Steigt die Levelanzahl pro Zelle, so steigen die Datendichte und Löschge­schwindigkeit. Jedoch sinken auch die Lebensdauer, die Wahrscheinlichkeit des Daten­erhalts, Schreib- und Lesegeschwindigkeit sowie die Anschaffungskosten^[120] (Abb. 9).

Abbildung in dieser Leseprobe nicht enthalten

Nach einer kürzlich beendeten sechsjährigen Studie von Schroeder et al. scheint aller­dings der Zusammenhang im Punkt der Zuverlässigkeit nicht mehr aktuell zu sein. So stellte sich die SLC- im Vergleich zur MLC-Architektur im Rahmen von zehn getesteten SSD-Modellen als nicht signifikant zuverlässiger dar.^[121]

Insgesamt zeigen SSD-Speicher eine deutlich höhere Leistung im Vergleich zu HDD- Speichern. Setzt man die Eingabe-/Ausgabeoperationen pro Zeiteinheit beider Speicher­systeme ins Verhältnis zu ihrem Stromverbrauch, zeigt sich ein weiterer Vorteil: Steigt die Belastung pro Zeiteinheit, so erhöht sich der Stromverbrauch von HDD-Speichern schneller als der von SSD-Speichern. Unter geringer Last zeigt ein SSD-Speicher diesen Zusammenhang allerdings nicht, was den Einsatz in leistungsfordernden Anwendungen z.B. in Mobilgeräten attraktiv macht.^[122]

Durch die Verwendung von SSD-Speichern entstehen aber auch Vorteile durch sinkende Opportunitätskosten bei Ausfall. So geht aus einer Untersuchung von Intel hervor, dass sich bei Einsatz von SSDs statt HDDs die jährliche Ausfallrate um 90% reduziert. Dadurch reduzieren sich die jährlichen Ausfallzeiten der Personenstunden um ebenfalls 90%. Die verwendete Zeit zur Instandsetzung der Systeme reduziert sich sogar um 96%. Dabei machen neben der höheren Leistung, den sinkenden Opportunitätskosten und den Produktivitätsvorteilen vor allem die sinkenden Einsatzkosten die Verwendung von SSD- Speichern zunehmend attraktiver.^[123]

So sank über die letzten Dekaden das Verhältnis von Kosten zu Kapazität bei allen Spei­cherarten exponentiell.^[124] Dies änderte zwar nicht das Verhältnis der niedrigeren An­schaffungskosten von HDD- zu SSD-Speichern, jedoch erlaubten insgesamt geringere TCO den ökonomisch legitimierten Einsatz von SSD- anstelle von HDD-Speichern. Die niedrigen SSD-TCO ergeben sich aus drastisch geringeren Energiekosten sowie deutlich geringeren Kosten bei Verwendung von Speicher-Arrays. Die etwas geringeren HDD- Anschaffungskosten können so ausgeglichen werden.^[125]

Um die Zusammenhänge zwischen Speicherleistung und -kosten weiter herauszuarbeiten betrachtet diese Arbeit im nachfolgenden Abschnitt das RAM-Speichersystem.

[...]

---

^[1] Sondergaard, P. (2011): History, Rede vor dem Gartner Symposium/ITxo.

^[2] Vgl. Sondergaard, P. (2013): Beginning, Rede vor dem Gartner Symposium/ITxo.

^[3] Vgl. Barner, A. et al. (2013): Perspektivenpapier, S.10.

^[4] Vgl. Hirsch-Kreinsen, H. (2014): Industrie 4.0, S.3.

^[5] Vgl. Ganschar, O. et al. (2013): Produktionsarbeit, S.23.

^[6] Vgl. Kagermann, H. (2014): Chancen, S.604-606.

^[7] Gray, J. (2006): Tape, Präsentation auf der CIDR2007 Gong Show.

^[8] Vgl. Straßburger, F.-X. (1990): ISDN, S.59.

^[9] Vgl. Wessel, P. et al. (2013): Auswirkungen, S.1781-1784.

^[10] Vgl. Wessel, P. etal. (2013): Auswirkungen, S.1782.

^[11] Vgl. Lorenz, M. (2013): Combining, S.5-7.

^[12] Vgl. Bachmann, R. et al: (2014): Big Data, S.180.

^[13] Vgl. Lorenz, M. (2013): Combining, S.7-28.

^[14] Vgl. Bog, A. etal. (2011): Benchmarking, S.417f.

^[15] Vgl. Ewbank, K. (2012): MemSQL.

^[16] Vgl. Scherr, A. L. (1965): Analysis, S.1-115.

^[17] Vgl. Ferrari, D. (1986): Considerations, S.3.

^[18] Vgl. Risse, T. (2006): Processing, S.18.

^[19] Vgl. Mayer, M. (2013): Performance, S.30.

^[20] Vgl. Hu, L., Gorton, I. (1997): Performance, S.3.

^[21] Vgl. Meyer, R. etal. (2015): Suitability, S.78-89.

^[22] Vgl. Bog, A. et al. (2011): Normalization, S.5f.

^[23] Vgl. Krueger, J. etal. (2010): Hauptspeicherdatenbanken, S.8f.

^[24] Vgl. Technische Universität München (2016): CH-benCHmark, Internetpräsenz TUM.

^[25] Vgl. TPC (2016): Active, Internetpräsenz TPC.

^[26] Vgl. Laudon, K. C. (2009): Wirtschaftsinformatik, S.6.

^[27] Vgl. Leimeister, J. M. (2015): Wirtschaftsinformatik, S.86-87.

^[28] Vgl. Haldar, S. (2015): SQLite, S.20.

^[29] Vgl. Elmasri, R. A., Navathe, S. (2009): Datenbanksystemen, S.53.

^[30] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.191.

^[31] Vgl. Simon, T., Merz, M. (2012): Paradigmenwechsel, S.1-3.

^[32] Vgl. Codd, E. F. (1970): Relational, S.377-387.

^[33] Vgl. Kleinschmidt, P., Rank, C. (2005): Datenbanksysteme, S.7.

^[34] Vgl. Steiner, R. (2014): Datenbanken, S.11.

^[35] Vgl. Unland, R., Pernul, G. (2015): Modellbildung, S.304.

^[36] Vgl. Steiner, R. (2014): Datenbanken, S.12.

^[37] Vgl. Kleinschmidt, P., Rank, C. (2005): Datenbanksysteme, S.22.

^[38] Vgl. Dasgupta, P. K. (2009): Database Management, S.76.

^[39] Vgl. Gabriel, R. et al. (2009): Data Warehouse, S.ii.

^[40] Vgl. Stonebraker, M. etal. (2005): Column-oriented, S.553.

^[41] Vgl. Knabke, T., Olbrich, T. (20i6): In-Memory-Datenbanken, S.i9if.

^[42] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.191-192.

^[43] Vgl. Plattner, H. (2009): Approach, S.2.

^[44] Vgl. Gabriel, R. et al. (2009): Data Warehouse, S.11.

^[45] Vgl. Martin, W. M. (2006): Implementing, S.1-5.

^[46] Vgl. Cvija, A. (2003): OLAP, S.20-22.

^[47] Vgl. Totok, A. (2001): Modellierung, S.56.

^[48] Vgl. Totok, A. (2001): Modellierung, S.56.

^[49] Vgl. Schmitz, U. (2015): Nutzung, S.239f.

^[50] Vgl. Röger, M. (2010): Konzeption, S.29.

^[51] Vgl. Kannowski, O. (1999): Projektierung, S.37.

^[52] Vgl. Kannowski, O. (1999): Projektierung, S.37-38.

^[53] Vgl. Gronwald, K.-D. (2015): Business-Informationssysteme, S.52.

^[54] Vgl. Koppen, V. et al. (2014): Data Warehouse, S. 185-186.

^[55] Vgl. Loos, P. et al. (2011): In-Memory Datenmanagement, S.383.

^[56] Vgl. DeWitt, D. J. et al. (1984): Implementation, S.1-20. sowie Eich, M. H. (1987): Classification, S.332-339.

^[57] Vgl. Plattner, H., Zeier, A. (2011): Inflection, S.7-23.

^[58] Vgl. Wessel, P. et al. (2013): Auswirkungen, S.1782. sowie Plattner, H., Zeier, A. (2011): Inflection, S.7.

^[59] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.188.

^[60] Gates, B. (1994): Fingertips 2005 Präsentation, Comdex Las Vegas.

^[61] Vgl. Plattner, H., Zeier, A. (2011): Inflection, S.9.

^[62] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.188.

^[63] Vgl. Wessel, P. etal. (2013): Auswirkungen, S.1782.

^[64] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.188.

^[65] Vgl. Plattner, H., Zeier, A. (2011): Inflection, S.15.

^[66] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.190. sowie Plattner, H., Zeier, A. (2011): Inflection, S.15.

^[67] Vgl. Plattner, H., Zeier, A. (2011): Inflection, S.21.

^[68] Vgl. Schwan, R. (2014): Ownership, S.1-13.

^[69] Vgl. Plattner, H., Zeier, A. (2011): Inflection, S.21-22.

^[70] Vgl. Plattner, H., Zeier, A. (2012): Technology, S.18.

^[71] Vgl. Plattner, H., Zeier, A. (2011): Inflection, S.22.

^[72] Vgl. Plattner, H., Zeier, A. (2012): Technology, S.18.

^[73] Vgl. Plattner, H., Zeier, A. (201l): Inflection, S.22-23.

^[74] Vgl. Krueger, J. etal. (2010): Hauptspeicherdatenbanken, S.4.

^[75] Vgl. Krueger, J. et al. (2010): Hauptspeicherdatenbanken, S.4f.

^[76] Vgl. Manegold, S. et al. (2002): Hierarchical, S.2.

^[77] Vgl. Moore, G. E. (1965): Cramming, S.114-117.

^[78] Vgl. Krueger, J. et al. (2010): Hauptspeicherdatenbanken, S.4f.

^[79] Vgl. Schöning, U. (2008): Modelle, S.209.

^[80] Vgl. Krueger, J. etal. (2010): Hauptspeicherdatenbanken, S.5.

^[81] Vgl. Saake, G. etal. (2011): Implementierungstechniken, S.90.

^[82] Vgl. Salomon, D. (2007): Data Compression, S.22f.

^[83] Vgl. Krueger, J. etal. (2010): Hauptspeicherdatenbanken, S.5f.

^[84] Vgl. Leimeister, J. M. (2015): Wirtschaftsinformatik, S.87.

^[85] Vgl. Plattner, H. (2009): In-Memory, S.5.

^[86] Vgl. Winsemann, T., Köppen, V. (2011): Datenpersistenz, S.99

^[87] Vgl. Winsemann, T., Köppen, V. (2011): Datenpersistenz, S.98f.

^[88] Vgl. Pang, C., Szafron, D. (2014): SSOT for SOA, S.575.

^[89] Vgl. Winsemann, T., Köppen, V. (2011): Datenpersistenz, S.98f.

^[90] Vgl. Pang, C., Szafron, D. (2014): SSOT for SOA, S.575.

^[91] Vgl. Winsemann, T., Köppen, V. (2011): Datenpersistenz, S.100.

^[92] Vgl. Winsemann, T., Köppen, V. (2011): Datenpersistenz, S.lOOf.

^[93] Vgl. Jarosch, H. (2016): Datenbankentwurf, S.56.

^[94] Vgl. Winsemann, T., Köppen, V. (2011): Datenpersistenz, S.101.

^[95] Vgl. Heinrich, L. J. (2014): Informationsmanagement, S.298f.

^[96] Vgl. Rahm, E. (1993): Transaktionssysteme. S.110.

^[97] Vgl. Häberlein, T. (2011): Informatik, S.184, Saake, G. (2011): Datenbanken, S.47, Härder, T., Rahm, E. (2001): Datenbanksysteme, S.65, Rahm, E. (1993): Transaktionssysteme, S.110f.

^[98] Vgl. Al Mamun, A. et al. (2007): Hard Disk Drive, S.5.

^[99] Vgl. IHS (2013): SSDs, Pressemitteilung IHS 2013.

^[100] Vgl. Don, J. (2015): SSDs, Internetpräsenz Trendfocus.

^[101] Vgl. Al Mamun, A. et al. (2007): Hard Disk Drive, S. 3-8.

^[102] Vgl. Sauter, M. (2015): Helium-Festplatte, Internetpräsenz golem.

^[103] Vgl. HGST (2015): Ultrastar, technisches Datenblatt Ultrastar He10 des Herstellers HGST.

^[104] Vgl. Al Mamun, A. et al. (2007): Hard Disk Drive, S. 10-17.

^[105] Ausnahme hiervon bilden Advanced Format Drives mit 4kB-Sektoren vom Branchenverband IDEMA.

^[106] Vgl. Hering, E. et al. (1995): Informatik, S.111.

^[107] Vgl. Grotegut, M. (2011): Unternehmensnetzen, S.258.

^[108] Vgl. Kamthane, A. N. (2012): Computer, S.34.

^[109] Vgl. Micheloni, R. et al. (2010): NAND, S.163.

^[110] Vgl. Song, H.-J., Lee Y.-H. (2011): I/O Performance, S.195.

^[111] Vgl. Micheloni, R. etal. (2010): NAND, S.163.

^[112] Vgl. Bruni, P. et al. (2010): DB2 10, S.590.

^[113] Vgl. Wong, R. (2013): Market, S.2.

^[114] Die Angabe bezieht sich auf das in Abschnitt 3.1.1 erwähnte Modell He10.

^[115] Vgl. Samsung (2016): Introduces, Pressemitteilung Samsung 2016.

^[116] Vgl. Eshghi, K., Micheloni, R. (2013): SSD, S.21f.

^[117] Vgl. Eshghi, K., Micheloni, R. (2013): SSD, S.22-24.

^[118] Vgl. Siemers, C. (2014): Handbuch, S.332.

^[119] Vgl. Beug, M.F. (2013): NAND, S.79.

^[120] Vgl. Micheloni, R. et al. (2010): NAND, S.9

^[121] Vgl. Schroeder, B. etal. (2016): Reliability S.67-80.

^[122] Vgl. Song, H.-J., Lee, Y.-H. (2011): Performance, S.195.

^[123] Vgl. Wong, R. (2013): Market, S.7.

^[124] Vgl. Knabke, T., Olbrich, T. (2016): In-Memory-Datenbanken, S.190.

^[125] Vgl. Wong, R. (2013): Market, S.11f.