Wachsende Datenströme und die damit verbundene Herausforderung einer effizienten Verwaltung deuten darauf hin, dass auch Datenbankmanagementsysteme (DBMS) vor einer Revolution stehen. „Tape is Dead, Disk is Tape, Flash is Disk, RAM Locality is King“. So beschrieb Gray, Informatiker und Wissenschaftler bei Microsoft Research, die zunehmende Verschiebung der Speicherhierarchie. Haben traditionelle DBMS noch Sekundärspeicher unter entweder zeilen- oder spaltenorientierter Datenorganisation verwendet, gebrauchen In-Memory Datenbanken (IMDB) Hauptspeicher und eine primär spaltenorientierte Datenorganisation. Damit soll es in Echtzeit möglich sein zum einen große Datenmengen auswerten und zum anderen die Informationen zum Zeitpunkt des Entstehens verarbeiten zu können. Verhinderte in den Achtziger Jahren die starke Unzuverlässigkeit des Hauptspeichers und das hohe Preisniveau die Etablierung von IMDB, so ist es heute möglich den Einsatz in Datenbanken ökonomisch zu legitimieren.
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 Beratungsunternehmens 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, Personalcomputern und Tablets vor allem auch eigenständig kommunizierende Geräte das Internet gebrauchen. Dieses ,Internet der Dinge‘ wird riesige Datenmengen produzieren, genauso wie Menschen und deren Aktivitäten. Intelligente Maschinen werden dabei Daten produzieren sowie konsumieren und Unternehmen diese nutzen um ihre Strukturen dahingehend zu ändern, dass Prozesse weiter automatisiert und intelligenter gestaltet werden können.[2] Die Vernetzung der physischen Welt der Dinge mit der digitalen Computerwelt 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 Entwicklungsgeschwindigkeit von Speichergrößen, Rechenleistung und Netzkapazitäten sowie einer damit verbundenen gegenläufigen Kostendegression, förderte die Entwicklung von Zentralrechnern hin zu Big Data, Cloud Computing und Smart Devices. Mit Hilfe von Cloud Computing ist es möglich kostengünstig und flächendeckend riesige Datenmengen zu speichern und mit intelligenten Algorithmen, auf Basis von Korrelationen und Wahrscheinlichkeitsberechnungen, 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ächendeckender 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 Sekundärspeicher unter entweder zeilen- oder spaltenorientierter Datenorganisation verwendet, 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 Unzuverlä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 OnlineTransaction Processing (OLTP) Systemen die Daten auf viele performante Schreib- und
Update-Vorgänge mit geringer Komplexität in typischerweise zeilenorientierter Datenstruktur optimiert. In Online Analytic Processing (OLAP) Systemen erfolgt die Optimierung hingegen auf wenige Leseanfragen hoher Komplexität in typischerweise spaltenorientierter Datenstruktur. Die Zusammenführung und Synchronisation beider Systeme erfordert 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 miteinander 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 Datenbanknutzung. 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 inwiefern 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 voneinander 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 erfolgt die empirische Untersuchung der verschiedenen Datenbankimplementierungen, deren 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 abschließ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 Infrastruktur an den Untersuchungsgegenstand bietet. Die Wahl von memSQL als IMDB erfolgt 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 Performance 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 Daten 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, Datenintegrität sowie die Datensicherheit der zugrundeliegenden Daten.[27] Häufig erwünschte Eigenschaften von Transaktionen in DBMS beschreibt dabei das englische Akronym ACID. So müssen DBMS Atomarität, Konsitenzerhaltung, Isolation und Dauerhaftigkeit gewährleisten. Das bedeutet, dass Transaktionen ganz oder gar nicht verarbeitet, in einem konsistenten Datenzustand hinterlassend, von anderen Transaktionen abgegrenzt und abschließend garantiert dauerhaft gespeichert werden müssen.[28]
Da es unterschiedliche DBMS gibt erfolgt eine Klassifizierung anhand verschiedener Kriterien. Hierbei beschränkt sich diese Arbeit in den nachfolgenden Abschnitten allerdings auf das Kriterium des allgemeinen bzw. aufgabenspezifischen Aufbaus.[29] Diese Beschrä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 spaltenbasierter Datenablage.[30] Dieses Paradigma scheint allerdings durch die Entwicklung leis- tungs- und kostengünstigerer Speicher und dem damit verbundenen In-Memory-Database-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-ManagementSystem (RDBMS) ausgestattet. Dabei besagt das zugrunde liegende Prinzip, dass sämtliche Daten in Tabellen, sog. Relationen, abgelegt werden können.[33] Die Daten werden hierbei innerhalb der Relationen nach Themenkreisen, sog. Entitäten, geordnet. So werden 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 bestimmter Disponent bearbeitet hat, würde die Abfrage bereits drei Tabellen beinhalten. Die Anlage eines weiteren Kunden würde hingegen nur das Manipulieren einer einzigen Tabelle erfordern. Folglich ergeben sich im Wesentlichen zwei verschiedenen Benutzungsparadigma 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 gleichzeitigen und direkten Transaktionsverarbeitung von Lese- und Schreiboperationen. Das bedeutet die Sicherstellung der Transaktionssicherheit bei parallelem Zugriff und die Minimierung der Antwortzeiten bei maximalem Datendurchsatz.[39]
Um dabei eine möglichst hohe Leistung zu gewährleisten wird eine zeilenbasierte Datenorganisation zu Grunde gelegt.[40] In zeilenbasierten Datenbanken wird die Speicherung jeder Zeile als zusammenhängender Block abgelegt. Im Gegensatz dazu erfolgt in spaltenbasierten Datenbanken die Speicherung der Attributwerte derjeweiligen Spalten nacheinander. Die zeilenbasierte Tabellenorganisation erhöht so den Zugriff durch schreiboptimierte Anfragen, da Blöcke einfach hinzugefugt oder entfernt werden können. Allerdings muss fürjede Leseanfrage immer der komplette Datenbestand gelesen werden um ein bestimmtes Attribut einer Tabelle zu finden. Der Unterschied zwischen beiden Architekturen 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 Analysezwecken und überwiegend mengenbasierten Leseoperationen verwenden nur wenige, ca. 10% aller vorkommenden Attribute einer Datentabelle. Hierfür stellt sich die zeilenorientierte 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 werden. 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 Mitarbeiter zu ermöglichen.[44] SQL-Abfragen gestalten sich dabei häufig als Such- bzw. komplexe ,SELECT-FROM-WHERE‘-Befehle einer multidimensionalen Analyse eines bestimmten Sachverhalts.[45]
Wurden RDBMS für OLTP entwickelt und optimiert, werden OLAP Anwendungen mittels 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 mehrdimensionalen 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 beschrä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 spaltenorientierten 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 Systemen mittels eines ETL-Prozesses zu überführen. Dies hat eine Verlängerung der Analysezeit 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 Datenbank 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 geringen Zahl von Zugriffen bei OLAP ergeben sich gänzlich unterschiedliche Lastverteilungen.[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ärspeichern 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 exponentiell sinkenden Kostenleistungsverhältnis zunehmend in den Vordergrund gerückt.[54] Daher erfolgt im nachfolgenden Abschnitt die nähere Betrachtung dieses Datenbanksystems 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 traditionellen Datenbanken maßgeblich in der Verwendung von Haupt- anstelle des Sekundärspeichers. Dadurch kann der typischerweise entstehende Engpass bei Ein- und Ausgabeoperationen 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 aufgegeben wurde. Diejüngste Wiederaufnahme und Entwicklung von IMDB steht mit drei Faktoren in engem Zusammenhang: dem Bedürfnis nach Echtzeitinformationen, der Entwicklung der Speicher- und Rechentechnologie sowie der Reduzierung bestimmter Kosten für Unternehmen.[57]
Suchmaschinen zeigen heute auf, welches Potential bzw. Bedürfnis in der Echtzeitdatenverarbeitung 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 formulierte 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 Suchanfragen 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 Anfragen 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 Innovation. Für die Entstehung des IMDBMS kann hier die Entwicklung der MehrkernArchitektur und größerer sowie günstigerer Hauptspeicher als maßgeblich erachtet werden. 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 Datenvorhaltung im Hauptspeicher unter direktem Zugriff des Prozessors sinnvoll realisiert werden. Eine besondere Bedeutung kommt hierbei der spaltenorientierten Datenorganisation 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 Administration. Bei Datenbanksystemen mit klassischen Speichermedien und den damit verbundenen Kühleinrichtungen entsteht ein enormer Strombedarf. Dieser kann bei großen Datencentern zwischen 30% und 60% der TCO ausmachen. Größten Einfluss auf die Kostenstruktur der TCO haben allerdings die Administrationskosten. Diese umfassen sowohl das initiierende Aufbauen, Konfigurieren und Anpassen als auch das betriebliche Überwachen, Ausbauen und Erweitern.[69]
Werden nun die zu speichernden Daten im Haupt- statt dem Sekundärspeicher vorgehalten, erfährt das ganze System neben einer Leistungssteigerung auch große Änderungen in den zugrundeliegenden Kostenstrukturen. So steigen zwar aktuell die Anschaffungskosten, jedoch sinken Versorgungs- und Administrationskosten massiv.[70] Der bauartbedingte geringere Stromverbrauch von Hauptspeicher gegenüber Sekundärspeicher wird in den nachfolgenden Abschnitten des Kapitels 3 näher erläutert. Die Senkung der Administrationskosten ergibt sich durch den geänderten Aufbau von In-Memory-Systemen gegenü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 Redundanzen 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 Beschleunigung der Anwendungen wird auch die Zeit, welche fur kopieren, sichern und archivieren üblicherweise verwandt wird, reduziert. Somit entfallen viele der erwähnten administrativen Aufgaben und der dazugehörigen Kosten. Die einfachere Architektur mit weniger Bestandteilen wie z.B. Cache oder redundanten Datenansichten kann den zu verarbeitenden Programmcode um bis zu 75% verringern und neue Kapazitäten schaffen. Diese führen mit dem schnelleren Hauptspeicher dazu, dass die operationalen und analytischen 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 insbesondere Vorteile beim analysetypischen Lesen weniger Attribute. Bereits durch die Fokussierung auf relevante Spalten kann so ein Geschwindigkeitsvorteilt erreicht werden. Dem gegenüber stehenjedoch Mehrkosten beim Herstellen kompletter Relationen in vertikalen Partitionierungen, im Vergleich zu zeilenorientierten Strukturen. Bei festplattenbasierten 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‘-Funktionalitä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 Datenorganisation 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ämtlicher Anfragearten zu minimieren. Datenbanken mit Spaltenorientierung profitieren dabei von der geringen Kardinalität ihrerjeweiligen Werte einer Spalte. Dieser Zusammenhang sowie die Möglichkeit der separaten Spaltenverwaltung ermöglichen den Einsatz effektiver Komprimierung und die Erhöhung der Informationsdichte bei gleichbleibendem Speicherplatzbedarf. Dies istjedoch erst durch die Datenverarbeitung im Hauptspeicher effizient realisierbar, da Cache-Misses diesen Vorteil schnell wieder zunichtemachen.[75] Cache-Miss beschreibt den Vorgang, dass Daten einer Anfrage an den Sekundärspeicher im Pufferspeicher nicht vorrätig sind und erst mitVerzögerung aus dem Hauptspeicher geladen werden müssen.[76]
Die Verwendung effektiver Kompressionsalgorithmen resultiert auch aus der Nichtanwendbarkeit 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. Verlustfreie und einfache Kompressionen helfen allerdings diesen Flaschenhals zu vermindern. Sie erlauben es, die verfügbare Bandbreite besser auszunutzen, während der Mehraufwand 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 spaltenorientierten 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 besitzen typischerweise eine ähnliche Semantik. Daraus resultiert eine niedrige Entropie bzw. es gibt nur wenige Daten unterschiedlicher Werte. Dieser Zusammenhang ist insbesondere bei betriebswirtschaftlichen Datenbanken zu beobachten, da entsprechende Anwendungen 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 Kompressionsmethoden ,Dictonary‘- und ,Run-length-encoding‘. Beim ,Dictonary‘-Encoding wird, dem Namen 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 zweiten Schritt eine Bit-weise Komprimierung des Schlüssels erfolgen, um die Kompressionsrate weiter zu erhöhen. Ebenso erlaubt das Sortieren des Wörterbuchs weitere Vorteile, da diese keinen Einfluss auf die ursprüngliche Wertesortierung jedoch verkürzte Abfragezeiten zur Folge hat.[81] Beim ,Run-length-encoding‘ hingegen wirdjede Wiederholung innerhalb eines Wertes als Wertepaar aus Wert und Anzahl der Wiederholungen gespeichert. Diese Methode zeigtjedoch nur bei sortierten Spalten mit wenigen Attributen und geringer Varianz eine hohe Kompressionsrate.[82]
Mit Hilfe der Spaltenkomprimierung erhöht sich die Entropie so sehr, dass die gleichzeitige Verarbeitung relevanter Informationen und die Erhöhung der Bandbreitennutzung ermöglicht werden. Obwohl diese Technik auch in zeilenorientierten Datenorganisationen möglich ist, erlaubt erst die Kombination der spaltenorientierten Datenorganisation mit der Datenablage und -Verarbeitung im Hauptspeicher relevante Vorteile. Zu erwähnen 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 Operationen zu gewährleisten. Dabei werden in festgelegten Intervallen alle Änderungen des unkomprimierten Puffer- und komprimierten Hauptspeichers synchronisiert. Folglich stehen das Komprimierungsverhältnis und die Kosten der Dekomprimierung in einem Spannungsverhältnis zueinander. Daher wird generell das Ziel verfolgt so lange wie möglich Nutzen aus den komprimierten Werten zu ziehen und die Dekomprimierung wirklich notwendiger Daten möglichst lange hinauszuzögern.[83]
Abschließend erfolgt die Betrachtung der In-Memory-Datenpersistenz als wichtiges Unterscheidungsmerkmal zum traditionellen Datenbank-Management. Wie in Kapitel 2 eingangs erwähnt, werden an DBMS viele verschiedene Anforderungen gestellt. Um Daten gegen Programm- und Systemfehler sowie Hardwareausfälle zu sichern bzw. nach Störfällen den korrekten Zustand der Datenbank wiederherstellen zu können, wird eine persistente 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 Bedürfnis an kumulierten Daten das persistente Speichern häufig bedingt. In IMDB ist jedoch 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 subjektiven Sicherheitsbedürfnis in Vereinfachung der Datenhandhabung, Gesetze, Gover- nance-Bestimmungen und technische Einschränkungen gliedert. Eine persistente Speicherung zeigt sich häufig schon im Eingangsbereich der Datenbank, um nach erfolgreicher 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 Datenverfügbarkeit garantieren. Daten, die aufgrund ihrer Komplexität bzw. bestehenden Abhängigkeiten zu anderen Daten transformiert werden müssen, bedingen in vielen Fällen ebenfalls eine persistente Speicherung. Damit soll ein korrektes Durchlaufen bzw. keine wiederholte Transformation gewährleistet werden. Weitere Gründe entstehen aus veränderten Transformationsregeln, aufwendiger Datenwiederherstellung, dem Bedürfnis nach einer konstanten Datenbasis oder der Erhöhung der Datenzugriffsgeschwindigkeit.[87] Mit der sich entwickelnden ,Service Oriented Architecture4 (SOA) ist für sämtliche Unternehmenseinheiten die ,Single Source of Truth4 (SSOT) ihrer Daten immer wichtiger geworden.[88] Werden ohne spezielle Geschäftslogik transformierte Daten nach unternehmensweit gültigen Regeln persistent gespeichert, kann ein vergleichbarer und einheitlicher Datenbestand geschaffen werden, auf welchen die jeweiligen Anwendungen und Geschäftsbereiche zugreifen können.[89] Auch wenn mittlerweile auf Datenreplikation verzichtet 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 Analysezwecke abgeleiteten aggregierten oder verdichteten Daten könnten ,on-the-fly4 ermittelt und verfügbar gemacht werden. Dies gilt allerdings nur für wenige der oben gennannten Gründe. So muss aus Gründen der abhängigen Transformationen, veränderten Transformationsregeln, Datenverfügbarkeit, Corporate Governance sowie Gesetzen und Bestimmungen 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 wiederhergestellt werden können, wie bspw. komplex transformierte oder archivierte Daten. Hierbei ist der Begriff ,erheblich‘ sicherlich subjektiv und bedarf daher einer genaueren Betrachtung.
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, Konzeptionen der SSOT oder des ,Corporate Data Memory4 zeichnen sich durch die Notwendigkeit einer Datenpersistenz aus. Jedoch kann eine Entscheidung dafür oder dagegen erst erfolgen, 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-verpflichtend 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 aufgrund von komplexen Transformationen oder zur Herstellung einer konstanten Datenbasis 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 materialisierten 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 Unternehmen zwischen 15% und 20% bei sinkenden Beschaffungskosten von 30%. Diese Kosten resultieren aus dem immer größer werdenden Speicherbedarf einer immer mehr Daten produzierenden 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 Beschaffungskosten 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 wirtschaftlich 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 Speicherhierarchie (Abb. 8) entwickelt. Dabei wird versucht zu den Kosten des langsamsten die Zugriffszeiten 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 besser 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ärder, 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 Marktforschungsunternehmens 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 Marktanteil 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 Informationen 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 Speicherkapazitä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, interpretierbar 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 Winkelkoordinaten zu einem sogenannten Sektor gehören.[106]
Innerhalb eines aktuellen Computersystems gehört der HDD-Speicher zu den Bestandteilen mit den höchsten Zugriffszeiten. Diese Zugriffszeit setzt sich, bedingt durch die Konstruktion, aus mehreren Teilen zusammen. So umfasst sie im Wesentlichen die Spurwechselzeit, 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 Steuerungsmotor 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 Latenzzeit. 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übertragung. 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 Datentransferrate 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-Halbleiterspeichern. Daneben dauert der Festplattenstart bzw. das Andrehen der Scheiben auf ihre Betriebsgeschwindigkeit mit 2 bis 5s sehr lange, im Vergleich zum Halbleiterspeicher, welcher 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 Stromverbrauch von HDD- gegenüber SSD-Speichern nicht zu vernachlässigen.[110] Diese bauartbedingten Schwächen in Verbindung mit der Leistungssteigerung und Kostensenkung 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 nichtflü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 Formfaktor 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 signifikant 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 verschiedenen 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 speichert 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, wohingegen 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öschgeschwindigkeit. Jedoch sinken auch die Lebensdauer, die Wahrscheinlichkeit des Datenerhalts, 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 allerdings 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 Speichersysteme 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 Speicherarten exponentiell.[124] Dies änderte zwar nicht das Verhältnis der niedrigeren Anschaffungskosten 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.
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.