In-Memory-Computing: Chancen für Unternehmen und Marktanalyse

Transkript

1 In-Memory-Computing: Chancen für Unternehmen und Marktanalyse Abschlussarbeit Betreuer: Dipl.- Wirt.- Inf. (FH) Nikolai Kunz Verwaltungs- und Wirtschaftsakademie Frankfurt am Main Von Markus Schnabel Studienrichtung: Informatik-Betriebswirt (VWA) 6. Fachsemester Matrikelnummer: Abgabetermin: 18. Juli 2012 Steinbach, den 15. Juli 2012

2 II Inhaltsverzeichnis Abkürzungsverzeichnis... IV Abbildungsverzeichnis... V Tabellenverzeichnis... VI 1. Einleitung Datenbanken Datenbank Grundlagen Gründe für den Einsatz von Datenbanken Relationale Datenbanken Spaltenorientierte Datenbanken In-Memory-Datenbanken Bewährte In-Memory-Zusatzlösungen Reine In-Memory-Datenbanken Vorteile In-Memory-Computing Nachteile In-Memory-Computing Technischer Fortschritt als Katalysator Hauptspeicher Multi-Core-Prozessor Aktuelle Trends im Bereich In-Memory-Computing Ausblick auf den zweiten Teil In-Memory-Computing Marktanalyse In-Memory-Computing im Unternehmenseinsatz In welchen Bereichen sich ein Einsatz lohnt Chancen und Risiken aus Sicht des Business und der IT Beispiele erfolgreicher Einführungen Vergleich von drei In-Memory-Datenbanken Aufbau eines Kriterienkataloges... 30

3 III 6.2 Bewertung der Produkte anhand der Kriterien IBM soliddb Oracle TimesTen 11g SAP Sybase ASE Ergebnis des Produktvergleichs Fazit Literaturverzeichnis Eidesstattliche Versicherung... 48

4 IV Abkürzungsverzeichnis ASE APO BW BWA CPU DBMS DBS DD ETL HANA OLAP OLTP RAM SSD TCO Adaptive Server Enterprise Advanced Planner and Optimizer Business Warehouse Business Warehouse Accelerator central processing unit Datenbankmanagementsystem Datenbanksystem Data Dictionary Extract, Transform, Load High-Performance Analytic Appliance Online Analytical Processing Online Transaction Processing Random Access Memory Solid-State-Drive Total Cost of Ownership

5 V Abbildungsverzeichnis Abbildung 1: Information at the fingertips... 2 Abbildung 2: Bestandteile einer Datenbank... 4 Abbildung 3: Extract, Transform, Load... 5 Abbildung 4: Zeilen- und spaltenorientierter Datenzugriff Abbildung 5: SAP APO mit livecache Abbildung 6: Diskbasierte versus In-Memory-Datenbank Abbildung 7: Speicherhierarchie-Pyramide Abbildung 8: CPU als Flaschenhals im In-Memory-Computing Abbildung 9: Prozess der Datenwiederherstellung Abbildung 10: Hochverfügbarkeitstopologie von IBM soliddb Abbildung 11: Netzdiagramm In-Memory-Datenbanken... 41

6 VI Tabellenverzeichnis Tabelle 1: Speicherarten eines Datenbanksystems... 9 Tabelle 2: Datenbank-Performance mit BWA Tabelle 3: Chancen und Risiken von In-Memory-Computing Tabelle 4: Bedeutung Erfüllungswerte der Nutzwertanalyse Tabelle 5: Nutzwertanalyse In-Memory-Datenbaken... 39

7 1 1. Einleitung Wir leben in einer Welt, in der Unternehmen mehr und mehr im globalen Wettbewerb zueinander stehen. Das trifft heutzutage nicht nur auf die Global Player zu, auch mittelständische Unternehmen stehen im weltweiten Konkurrenzkampf. Um konkurrenzfähig zu bleiben, bedarf es dem Einsatz entsprechender Software, die die Geschäftsprozesse unterstützen beziehungsweise automatisieren. Unternehmen haben immer höhere Anforderungen an deren Informationssysteme. Prozesslaufzeiten im operationalen Geschäft sollen minimiert werden und im gleichen Schritt sollen die analytischen Daten zur Unterstützung der Entscheidungsfindung so aktuell und umfangreich wie nie zuvor sein. Dazu kommt der Anspruch der Unternehmensführung, die Kosten zu minimieren. Diese Forderungen gehen einher mit einem rasant wachsenden Datenvolumen und immer komplexer werdenden Anwendungen und Systemen. Das stark wachsende Datenvolumen, optimierte Prozesslaufzeiten sowie der Wunsch nach Reporting in Echtzeit stehen im Konflikt mit der heutigen Art der Datenhaltung für Unternehmensanwendungen. Der derzeitige Standard für die Datenhaltung von Unternehmensanwendungen ist ein relationales Datenbanksystem mit Festplattenspeicher, wobei der Festplattenspeicher der Flaschenhals der Datenbank und damit der Unternehmensanwendung ist. Optimierungspotential besteht durch den Einsatz von In-Memory-Computing 1. Dort werden die Daten im wesentlich schnelleren und prozessornahen Hauptspeicher eines Servers statt im langsamen Festplattenspeicher gespeichert. Technologiefortschritte im Bereich der Prozessoren (Multi-core) und des Hauptspeichers (Kapazitäten im Terabyte-Bereich je Server) haben es möglich gemacht, den Ansatz der klassischen, relationalen Datenbanken zu überdenken. Mit In-Memory-Computing soll ermöglicht werden, dass Teilnehmer einer Besprechung, die auf der ganzen Welt verteilt sein können, in Echtzeit durch dieselben Informationen navigieren und dadurch strategische Entscheidungen anhand aktuellster Daten treffen können. Bei den Global Playern ist es heute die Regel, dass das Aufbereiten der transaktionalen Daten zu den benötigten analytischen Reports mitunter Tage, wenn nicht sogar Wochen dauert. Damit sind die getroffenen Entscheidungen, die auf diesen 1 In der vorliegenden Arbeit werden die Begriffe In-Memory-Computing, In-Memory-Technologie, In-Memory-Datenbank, In-Memory-System und Hauptspeicherdatenbank synonym verwendet.

8 2 Daten bzw. Informationen basieren, auch dementsprechend veraltet. Mit in Echtzeit vorliegenden Informationen kann demnach ein nicht zu unterschätzender Wettbewerbsvorteil resultieren. Die nachfolgende Abbildung 1 visualisiert die Vision von der Information at the fingertips!. Abbildung 1: Information at the fingertips 2 Die vorliegende Arbeit ist der erste von zwei Teilen. Der erste Teil schafft die theoretische Grundlage von traditionellen sowie In-Memory-Datenbanken, während im zweiten Teil eine Gegenüberstellung von drei In-Memory-Produkten mit ihren Vor- und Nachteilen in Bezug auf den Einsatz im Unternehmen erfolgt. Ziel der Gesamtarbeit ist es herauszufinden, ob eines der gegenübergestellten Produkte für Unternehmen als optimal anzusehen ist, um abschließend einen Ausblick geben zu können, welches der Produkte eingesetzt werden sollte. Der vorliegende Teil Arbeit gliedert sich in drei Kapitel. Im ersten Kapitel erfolgt eine Schilderung der Problemstellung. In Kapitel 2 werden die Grundlagen einer Datenbank erläutert und es erfolgt eine Betrachtung von relationalen, spaltenorientierten und In- Memory-Datenbanken. Auf In-Memory-Datenbanken wird ein besonderer Fokus gelegt und es erfolgt eine Betrachtung der Vor- und Nachteile. Weiterhin wird auf den technischen Fortschritt, der eine Grundvoraussetzung für eine In-Memory-Datenbank ist, eingegangen. In Kapitel 3 erfolgt ein kurzer Ausblick auf den zweiten Teil der Arbeit. 2 Plattner, H./Zeier, A. (2011), S. 9.

9 3 2. Datenbanken 2.1 Datenbank Grundlagen Mehr denn je leben wir heutzutage in einer Welt, in der Informationen eine immer wichtiger werdende Rolle spielen. Auch kleine und mittelständische Unternehmen können es sich nicht leisten, ohne eine Vielzahl von Informationen erfolgreich zu operieren, von den Großkonzernen ganz zu schweigen. Unternehmen sind abhängig von funktionierenden IT-Systemen. Hier kommen Datenbanksysteme 3 (DBS) ins Spiel, welche für die Verwaltung und Haltung der elektronischen Daten eines IT-Systems zuständig sind. Laut Faeskorn-Woyke sind sie dazu da, um [ ] in die zunehmende Informationsflut Ordnung und Struktur zu bringen. 4 Ein Datenbanksystem besteht aus folgenden zwei Teilen: Datenbankmanagementsystem (DBMS) Das Datenbankmanagementsystem ist die Software zur Verwaltung der Datenbasis. Es steuert die Prozesse der Datenbank und stellt unterschiedliche Dienstleistungen zur Verfügung. In einem vertikalen Schichtenmodell eines Datenbanksystems liegt es zwischen der Datenbasis und den Programmen. Datenbasis mit Data Dictionary (DD) Die Datenbasis besteht aus den eigentlichen Daten der Datenbank sowie dem Data Dictionary. Das Data Dictionary beschreibt die Datenbasis und die Beziehungen der Daten zueinander. 5 Die folgende Abbildung 2 zeigt grafisch die Bestandteile eines Datenbanksystems sowie die Schnittstelle mit den Anwendungen. 3 In der vorliegenden Arbeit werden die Begriffe Datenbank und Datenbanksystem synonym verwendet. 4 Faeskorn-Woyke, H. u. a. (2007), S Vgl. Faeskorn-Woyke, H. u. a. (2007), S. 22.

10 4 Abbildung 2: Bestandteile einer Datenbank 6 Datenbanksysteme können für viele verschiedene Anwendungen eingesetzt werden. Diese lassen sich in zwei Klassen unterscheiden. Zum einen gibt es transaktionale Anwendungen, diese kommen im operativen Tagesgeschäft zum Einsatz und realisieren selbiges in einem Unternehmen. Zum anderen gibt es analytische Anwendungen, welche die Grundlage für die strategische Unternehmensplanung bilden und vor allem vom Management genutzt werden. Im folgenden Abschnitt erfolgt eine Spezifikation der beiden Klassen. OLTP - Online Transaction Processing o Transaktionale Anwendungen o Häufige, schnelle und kurze Anfragen an die Datenbank mit wenigen Daten je Anfrage o Viele Änderungen (Update, Insert, Delete) in der Datenbasis o Operiert auf aktuellem Datenbestand (max. 1 Jahr) o Beispiel: Anlegen einer Kundenbestellung o Produktbeispiel: SAP Enterprise Resource Planning OLAP - Online Analytical Processing o Analytische Anwendungen o Wenige, langwierige Anfragen an die Datenbank mit vielen Daten je Anfrage o So gut wie keine Änderungen in der Datenbasis read only o Historische und aktuelle Daten (Unternehmensdaten der letzten Jahre) 6 Faeskorn-Woyke, H. u. a. (2007), S. 22.

11 5 o Beispiel: Umsatzentwicklung von Produkt xy in den letzten drei Jahren in Italien o Produktbeispiel: SAP Business Intelligence (Data Warehouse) 7 Wie in der obigen Aufstellung beschrieben, unterscheiden sich OLAP- und OLTP- Systeme in der Art der Nutzung. Auf Grund dieser unterschiedlichen Ausrichtung der beiden Systeme und der damit verbundenen vielfältigen und spezifischen Optimierungen [...] besteht mittlerweile weitgehender Konsens, dass man OLTP- und OLAP- Anwendungen nicht auf demselben Datenbestand (d. h. auf derselben physischen Datenbasis) ausführen sollte. 8 Diese Annahme der physischen Trennung des Datenbestands wird mit der Entwicklung von Hauptspeicherdatenbanken jedoch neu überdacht. Durch den Einsatz von zwei getrennten Datenbanken sind in einem OLAP-System initial keine Daten vorhanden. Die benötigten Daten werden aus den operationalen Datenbanken (OLTP) und anderen Datenquellen in ein Data Warehouse geladen. In zuvor bestimmten Zeitintervallen (z. B. täglich, wöchentlich) erfolgt eine Aktualisierung der Daten. Damit enthält das Data Warehouse auch historische Daten, auf denen die Unternehmensleitung wichtige, strategische Entscheidungen fällen kann. Dieser Vorgang wird Extract, Transform, Load (ETL) genannt und wird in der folgenden Abbildung 3 dargestellt. 9 Abbildung 3: Extract, Transform, Load 10 7 Vgl. Kemper, A./Eickler, A. (2011), S. 529 f. 8 Kemper, A./Eickler, A. (2011), S Vgl. Kemper, A./Eickler, A. (2011), S Kemper, A./Eickler, A. (2011), S. 531.

12 6 Die theoretische Grundlage einer Datenbank ist das Datenbankmodell. Es besagt, wie die Daten auf einer Datenbank gespeichert und bearbeitet werden. In den 1960er Jahren entstanden mit dem Hierarchischen und dem Netzwerkdatenbankmodell die ersten Datenbankmodelle. Sie ermöglichten den erstmaligen Einsatz von Datenbanken, spielen heutzutage aber keine große Rolle mehr. In den 1970er Jahren entstand das relationale Datenbankmodell, was heute das bekannteste und am weitesten verbreitete Modell ist. Zusätzlich gibt es noch zwei neuere Datenbankmodelle, das objektrelationale sowie das objektorientierte Datenbankmodell auf die der Autor auf Grund ihrer geringen Verbreitung nicht näher eingehen wird. Ein Großteil der Unternehmen setzt Datenbanksysteme von Oracle, IBM und Microsoft ein. Der bevorzugte Datenbankanbieter der SAP-Kunden ist mit großem Abstand die Firma Oracle (67%), gefolgt von Microsoft SQL Server (13%), IBM DB2 (12%) und SAP MaxDB (11%) Gründe für den Einsatz von Datenbanken Laut Kemper gibt es für Unternehmen für die Verarbeitung von Informationen keine Alternativen zum Einsatz eines DBMS. Folgende Probleme können durch den Einsatz eines einheitlichen, zentral genutzten DBMS zum größten Teil vermieden werden: Redundanz und Inkonsistenz Das DBMS verwaltet eine zentrale Datenbasis, die von mehreren Anwendungen benutzt werden kann. Datensätze müssen nur einmal angelegt oder geändert werden, was Redundanzen und Inkonsistenzen vermeidet. Mehrbenutzerbetrieb Das DBMS bietet eine Mehrbenutzerkontrolle, die einen kontrollierten Zugriff von mehreren Benutzern auf Daten gewährleistet und Gefahren wie das gleichzeitige editieren derselben Datei durch zwei oder mehrere Benutzer verhindern. Heutige Dateisysteme können keinen störungsfreien Mehrbenutzerbetrieb gewährleisten. Sicherheitsprobleme Mittels DBMS lassen sich Zugriffsrechte auf die zentral gespeicherten Daten sehr flexibel steuern. Je nach Benutzer oder Benutzergruppe greifen verschiede- 11 Vgl. (Abfragedatum: ).

13 7 ne Regeln, die das Aufrufen, Editieren und Löschen der verschiedenen Informationen steuern. 12 Die Voraussetzung für eine sichere und konsistente Ausführung von Operationen auf der Datenbank trotz gleichzeitiger Aktivitäten unterschiedlicher Anwender ist das Einhalten der vier definierten ACID-Eigenschaften. Sie bestehen im Einzelnen aus: Atomicity (Atomarität): Unteilbarkeit von Transaktionen Besagt, dass entweder alle Änderungen der Transaktion in die Datenbank geschrieben werden oder gar keine. Consistency (Konsistenz): Konsistenter Datenbestand Nach Beendigung einer Transaktion muss die Datenbasis konsistent sein, andernfalls wird die Transaktion zurückgesetzt. Isolation: Transaktionen dürfen sich nicht beeinflussen Parallel ausgeführte Transaktionen dürfen sich nicht gegenseitig beeinflussen. Jede Transaktion wird, logisch betrachtet, einzeln auf dem Datenbanksystem ausgeführt. Durability (Dauerhaftigkeit): Transaktionsergebnis besteht dauerhaft Eine einmal erfolgreich abgeschlossene Transaktion muss dauerhaft in der Datenbasis erhalten bleiben. Selbst nach einem Hard- oder Softwarefehler muss das Resultat der Transaktion sichtbar sein Relationale Datenbanken Die relationale Datenbank ist der heutige Standard für den Unternehmenseinsatz. OLTP- und OLAP-Systeme setzen beide bis auf wenige, sehr fachspezifische Ausnahmen auf das relationale Datenbankmodell. Erstmals wurden Daten mitsamt ihrer Beziehung in Tabellen (Relationen) abgebildet. Hauptmerkmal der relationalen Datenbank sind die zweidimensionalen Tabellen, auch Relationen genannt. Daten werden in den Tabellen gespeichert und [ ] durch entsprechende Operatoren ausschließlich mengenorientiert verknüpft und verarbeitet. 14 Die grundlegenden Elemente einer Tabelle in einer relationalen Datenbank sind: 12 Vgl. Kemper, A./Eickler, A. (2011), S. 19 ff. 13 Vgl. Kemper, A./Eickler, A. (2011), S Kemper, A./Eickler, A. (2011), S. 71.

14 8 Attribut: Beschreibt die Objekte mit einem Namen und einem Wert. Tupel: Die Menge aller Attribute in einer Zeile, auch Datensatz genannt. Relation: Alle Tupel in einer Datenbank ergeben die Relation. Primärschlüssel: Dient zur eindeutigen Identifizierung der einzelnen Tupel. Er ist eindeutig und darf nicht leer sein. Mit ihm lassen sich verschiedene Tabellen eindeutig verknüpfen. 15 Hervorzuheben ist, dass die Daten bei einer traditionellen relationalen Datenbank zeilenorientiert auf der Festplatte gespeichert werden. Bei der physischen Datenstruktur einer relationalen Datenbank wird meist zwischen drei Stufen von Speichermedien unterschieden, die sehr oft gleichzeitig, aber für unterschiedliche Zwecke eingesetzt werden. Der Primärspeicher ist der Hauptspeicher des Rechners und übernimmt Pufferfunktionen im Datenbanksystem. Im Hauptspeicher werden alle Operationen durchgeführt, damit liegen die Daten, auf die aktiv zugegriffen wird, in selbigem. Der Sekundärspeicher ist die Festplatte. Hier werden die Daten gespeichert, die nicht im aktiven Gebrauch sind. Als Archivspeicher kommen in den meisten Fällen Magnetbänder zum Einsatz. Auf ihm werden zum Beispiel operativ nicht mehr benötigte Daten sowie Sicherheitskopien gespeichert. 16 Um die Daten verarbeiten zu können, müssen sie demzufolge zwischen dem Primärspeicher und dem Sekundärspeicher hin- und hergeschoben werden, da die Verarbeitung ausschließlich im größenmäßig limitierten Primärspeicher erfolgen kann. Die folgende Tabelle 1 stellt die verschiedenen Speicherarten eines Datenbanksystems gegenüber. 15 Vgl. Kannengiesser, C./Kannengiesser, M. (2007), S. 613 f. 16 Vgl. Kemper, A./Eickler, A. (2011), S. 203 ff.

15 9 Speicherstufe Primärspeicher Sekundärspeicher Archivspeicher Zugriffszeit Speicherkapazität Preis Vorteile Nachteile ~ 100 ns Gigabyte - Sehr schnell - Flüchtig bis - Feine Granularität - Sehr teuer Terabyte ~ 10 ms Terabyte - Nicht flüchtig - Relativ langsam - Direktzugriff - Mechanisch > 1 s Terabyte - Lagerbarkeit - Sehr langsam - Ausfallsicherheit - Verschleiß Tabelle 1: Speicherarten eines Datenbanksystems 17 Aus der obigen Tabelle 1 ist der immense Unterschied bei den Zugriffszeiten der einzelnen Speicherstufen hervorzuheben. Der Unterschied bei der Zugriffszeit zwischen dem Primär- und Sekundärspeicher beläuft sich auf den Faktor 10 5, was einem theoretisch mal schnelleren Zugriff entspricht. Dieser gewaltige Unterschied bei der Zugriffszeit macht deutlich, wieso es wichtig ist, einen vielen Gigabyte umfassenden Hauptspeicher in einem Datenbank-Server zu haben. Durch einen großen Hauptspeicher in einem Datenbank-Server wird das Auslagern von häufig verwendeten Daten von dem schnellen Primärspeicher in den langsamen Sekundärspeicher reduziert und eine verbesserte Performance des IT-Systems kann sichergestellt werden. Zusätzlich tragen die prozessornahen Caches (L1-L3) zu einer Steigerung der Performance bei. Anzumerken ist noch, dass die Festplatten oft mit eigenen Caches bestückt sind, um den Zugriff durch Zwischenspeicherung und andere Mechanismen zu beschleunigen. Die Geschwindigkeit des Hauptspeichers kann allerdings trotz des Festplatten-Caches nicht annährend erreicht werden. Die Datenbank-Server großer Konzerne sind beispielsweise mit bis zu 640 Gigabyte Hauptspeicher ausgestattet. Das ermöglicht dem Anwender und den zahlreichen Jobketten einen Zugriff mit so wenig Verzögerung wie möglich, da relativ viele Daten im Hauptspeicher gehalten werden können. Zusammenfassend lässt sich sagen, dass die Geschwindigkeit der Datenzugriffe eine der größten Limitierungen der festplattenbasierten, relationalen Datenbanken und damit der 17 Vgl. Kemper, A./Eickler, A. (2011), S. 203 ff.

16 10 Anwendungen (OLAP / OLTP) darstellt. Nach Schätzungen verdoppelt sich der Datenbestand in Unternehmen ca. alle 5 Jahre, was das Problem des langsamen Datenzugriffs zunehmend verschärft. Zumal das Datenvolumen schneller als die Leistung relationaler Datenbanken wächst. Dieses Problem soll durch In-Memory-Datenbanken reduziert und bestenfalls vollständig behoben werden. 2.4 Spaltenorientierte Datenbanken Erste Vorläufer von spaltenorientierten Datenbanken gibt es bereits seit den 1970er Jahren. Daten werden hier spaltenweise statt, wie normalerweise, zeilenweise abgespeichert. Mit dieser Art der Datenhaltung können verbesserte Zugriffszeiten bei OLAP- Anwendungen erreicht werden. Der Grund dafür ist, dass bei OLAP-Anwendungen häufig nur sehr wenige Spalten, aber viele Zeilen eines Datensatzes abgefragt werden. Zum Beispiel müssen für die Abfrage des Umsatzes aller Filialen einer Handelskette in Deutschland in 2011 bei einer spaltenorientierten Datenbank nur die Spalten Land, Jahr und Umsatz gelesen werden. Die anderen gespeicherten Informationen wie Mitarbeiteranzahl oder Filialleiter sind bei dieser analytischen Abfrage nicht von Bedeutung. Würden die Daten in einer konventionellen relationalen Datenbank zeilenweise gespeichert sein, müsste jeder Datensatz gelesen werden, da die benötigten Informationen auf alle Datensätze verteilt sind. Abbildung 4 zeigt den Unterschied zwischen zeilen- und spaltenorientiertem Datenzugriff bei OLAP- bzw. OLTP-Anwendungen. Sie verdeutlicht weiterhin, dass eine spaltenorientierte Speicherung für transaktionale Anwendungen (OLTP) oft nicht sinnvoll ist, da auf viele Spalten eines Datensatzes zugegriffen wird (z. B. Mitarbeiter-Stammdaten). Abbildung 4: Zeilen- und spaltenorientierter Datenzugriff Krueger, J. u. a. (2010), S. 4.

17 11 Mit spaltenorientierten Datenbanken kann weiterhin eine höhere Kompressionsrate als bei zeilenorientierten Datenbanken erreicht werden. Das liegt unter anderem daran, dass alle Werte in einer Spalte vom gleichen Datentyp sind (z. B. string, integer). Außerdem sind Unternehmensanwendungen dazu konzipiert, wiederholende Prozesse abzuarbeiten. Dadurch gibt es oftmals nur wenige unterschiedliche Werte in einer Spalte. All das führt zu einer guten Komprimierung mit dem Effekt, dass mehr Informationen auf der gleichen Menge an Speicher liegen und dadurch weniger Speicherplatz benötigt wird. 19 Spaltenorientierte Datenbanken eignen sich also im Besonderen für analytische Anwendungen, wohingegen die zeilenorientierte Datenbank für transaktionelle Anwendungen eingesetzt werden sollte. Es gibt auch Überlegungen, spalten- und zeilenorientierte Datenbanken in einer hybriden Datenbank zu kombinieren, um die Vorteile beider Techniken nutzen zu können. 2.5 In-Memory-Datenbanken In-Memory-Datenbanken sind keine neuen Lösungen oder neue Produkte, auch wenn der derzeitige Boom und das mediale Interesse in der IT-Fachwelt darauf schließen lassen. Es existieren bereits seit einigen Jahren In-Memory-Lösungen, die sich als stabil und extrem nützlich für Unternehmen erwiesen haben Bewährte In-Memory-Zusatzlösungen In der Vergangenheit wurden die immer größer werdenden Wünsche und Ansprüche an IT-Systeme unter anderem mit Hilfe kostspieliger Zusatzlösungen und redundanter Datenspeicherung (z. B. Data Warehouse) zu Lasten der Flexibilität und Kosten weitestgehend erfüllt. 20 Die nachfolgend vorgestellten Produkte sind In-Memory-Datenbanken, die als Beschleuniger für traditionelle Datenbanken bzw. Anwendungen dienen. Sie sind ohne das jeweilige Hauptsystem nutzlos. Im SAP-Bereich sind als Beispiel für In-Memory-Zusatzlösungen der SAP Advanced Planner and Optimizer (APO) livecache und der SAP Business Warehouse Accelerator (BWA) zu nennen. Der SAP APO livecache basiert auf der SAP-eigenen Datenbank MaxDB, liegt komplett im Hauptspeicher und ist als zusätzliche, zweite Datenbank innerhalb eines SAP 19 Vgl. Krueger, J. u. a. (2010), S. 4 f. 20 Vgl. Krueger, J. u. a. (2010), S. 2.

18 12 APO-Systems (OLTP) integriert. Die APO-Funktionalitäten sind im Gegensatz zu anderen ERP-Modulen wesentlich umfangreicher und machen daher auch eine erhöhte Zugriffshäufigkeit auf die Datenbank erforderlich. Eine schnelle Antwortzeit der Datenbank auf Anfragen ist gerade bei der Verfügbarkeitsprüfung (Global Available-To- Promise) von sehr hoher Wichtigkeit. Der In-Memory livecache sorgt für die benötigte schnelle Antwortzeit der Verfügbarkeitsprüfung, der Produktionsfeinplanung und der Bedarfsplanung. Laut Nüßer werden bei den oben beschriebenen datenbankintensiven Anwendungen Geschwindigkeitsvorteile im Faktor 1000 möglich. 21 Die nachfolgende Abbildung 5 zeigt die Architektur eines SAP APO-Systems. Es wird deutlich, dass weiterhin eine relationale, festplattenbasierte Datenbank eingesetzt wird, zusätzlich kommt der hauptspeicherbasierte livecache zum Einsatz. Abbildung 5: SAP APO mit livecache 22 Bei dem SAP BWA handelt es sich um eine spaltenorientierte Hauptspeicherdatenbank. Diese wird an die auf einer relationalen Datenbank basierenden OLAP-Anwendung SAP Business Warehouse (BW) gekoppelt. Damit werden erheblich schnellere Antwortzeiten auf immer umfangreichere Anfragen ermöglicht. Der SAP BWA kommt speziell in großen Unternehmen mit einer hohen Menge an auszuwertenden Daten zum Einsatz. Kleinere Firmen sehen in der Regel auf Grund der überschaubaren Datenmenge im Unternehmen und der zusätzlichen Kosten für Hardware und Lizenzen von einem Einsatz ab. Die folgende Tabelle 2 zeigt eine mögliche Performancesteigerung mit dem 21 Vgl. Nüßer, W. u. a. (2006), S. 416 f. 22 Nüßer, W. u. a. (2006), S. 416.

19 13 Einsatz von BWA. Es wird deutlich, dass sich die Antwortzeit der in dem BWA indizierten Abfragen signifikant verbessert. Abfrage Ohne BWA Mit BWA Retail Masterquery dynamisch 69,1 Sekunden 2,2 Sekunden Global Risk Report 8,7 Sekunden 1,4 Sekunden Tabelle 2: Datenbank-Performance mit BWA 23 Mit den beschriebenen In-Memory-Lösungen lässt sich die Anwendungs-Performance für die Benutzer verbessern. Der Hauptteil der Daten befindet sich jedoch nach wie vor auf langsamen Festplatten. Es werden lediglich wichtige Bereiche in den Hauptspeicher ausgelagert, um business-kritische Transaktionen oder Analysen zu beschleunigen. Diese beiden Produkte machen deutlich, dass bisherige In-Memory-Datenbanken [ ] entweder für den OLTP-Anwendungsbereich (also für die effiziente Transaktionsverarbeitung) oder für den OLAP-Bereich (also für die effiziente Anfrageauswertung) konzipiert 24 wurden. Mittlerweile findet jedoch ein Umdenken statt, wobei die starre Trennung der beiden Anwendungstypen aufgehoben werden soll. Es befinden sich bereits hybride In-Memory-Datenbanken in der Entwicklung, die OLTP- und OLAP- Anwendungen auf einer Datenbasis vereinen. Weiterhin sind diese Datenbanken nicht mehr diskbasiert, sondern liegen komplett im Hauptspeicher Reine In-Memory-Datenbanken Bei In-Memory-Datenbanken handelt es sich um Datenbanken, die komplett im Hauptspeicher gehalten werden. Der größte Unterschied der Architektur eines In-Memory- Systems zu einem diskbasierten System besteht in der Art der Datenhaltung. Bei diskbasierten Systemen werden die benötigten Daten erst bei Bedarf von der Platte in den hauptspeicherbasierten Buffer Pool (Pufferspeicher) geladen. Das Laden der Daten von dem Sekundär- in den Primärspeicher verursacht zeitaufwendige Kommunikation (Input/Output). Bei einem In-Memory-System werden dagegen beim Start der Datenbank alle Daten aus einem Festspeicher in den Hauptspeicher geladen. Auf diese Weise kann auf alle Daten der Datenbank direkt zugegriffen werden, ohne dass ein zeitaufwendiges 23 Vgl. Löscher, N. (2010), S. 14: (Abfragedatum: 13. November 2011). 24 Kemper, A./Eickler, A. (2011), S. 668.

20 14 Nachladen aus dem Festspeicher nötig ist. Der direkte Zugriff auf die Daten sorgt außerdem für einen extrem vereinfachten Zugriffsalgorithmus bei In-Memory- Datenbanken, wie in Abbildung 6 anhand eines diskbasierten Systems und der Oracle In-Memory Datenbank TimesTen dargestellt wird. 25 Abbildung 6: Diskbasierte versus In-Memory-Datenbank 26 Nachfolgend werden einige wesentliche Elemente von In-Memory Datenbanken erläutert: Abfragesprache So gut wie alle untersuchten Datenbanken unterstützen die Datenbanksprache SQL. Flüchtige Daten Der in Hauptspeichern verwendete Speicher ist Random Access Memory (RAM). Sobald die Energieversorgung unterbrochen wird, gehen die Daten verloren. Daher werden regelmäßig Checkpoint-Files in den persistenten Speicher (Festplatte) geschrieben. 25 Vgl. Stirnimann, R./Ott, J. (2011), S Stirnimann, R./Ott, J. (2011), S. 7.

21 15 Datenwiederherstellung Nach einem Datenbank-Crash oder einer Unterbrechung der Energiezufuhr können die Daten durch das letzte Checkpoint-File und die geschriebenen Transaction Logs wiederhergestellt werden ACID-Eigenschaften Alle ACID-Eigenschaften bis auf Durability (Dauerhaftigkeit) werden standardmäßig unterstützt. Durch die Art des gewählten Speichers sind die Daten bei einem Systemabsturz nicht dauerhaft. Der Großteil verfügbarer In-Memory- Datenbanken deckt die Dauerhaftigkeit allerdings über Checkpoint-Files, Transaction Logs und Hochverfügbarkeitslösungen wie Replikation und Failover ab. Hochverfügbarkeit Zur schnellen Wiederherstellung der Services gibt es Replikationslösungen, wobei die Daten dauerhaft auf eine zweite Datenbank repliziert werden. Bei einem Ausfall der primären Datenbank kann die Standby-Datenbank innerhalb weniger Minuten mit den aktuellen Daten gestartet und von den Anwendern benutzt werden Vorteile In-Memory-Computing Nachfolgend werden zwei technische Vorteile und die daraus resultierenden Vorteile für Unternehmen betrachtet. Da diese Vorteile gleichzeitig Nachteile der diskbasierten Systeme darstellen, werden einige Unterschiede beider Systeme hervorgehoben. Bessere Performance Da alle Daten garantiert im Hauptspeicher gehalten werden, ist kein Festplattenzugriff nötig, um Daten zu lesen, zu schreiben oder zu ändern. Weiterhin können optimierte, Cache-effiziente Indexstrukturen verwendet werden. Technischer Vorteil: Minimierung der Zugriffszeit auf die Daten und vereinfachte Zugriffsalgorithmen. Vorteil für Unternehmen: Schnellere Abwicklung von Geschäftsprozessen (OLTP) und kürzere Laufzeit für das Erstellen von Reports (OLAP). Unternehmen können eine Vorreiterrolle einnehmen und sich von der Konkurrenz absetzen. 27 Vgl. Stirnimann, R./Ott, J. (2011), S. 6.

22 16 Vereinfachte IT-Landschaft und geringere Kosten Trotz der vergleichsweise hohen Anschaffungskosten durch den teuren Hauptspeicher wird erwartet, dass durch In-Memory-Computing die Total Cost of Ownership (TCO), also die Kosten für den gesamten Lebenszyklus eines IT- Systems reduziert werden können. Dies wird durch die vereinfachte System- Landschaft und den daraus resultierenden Kosteneinsparungspotentialen (z. B. weniger Administration, Wartung) erreicht. 28 Technischer Vorteil: Geringere Komplexität und dadurch weniger Systemausfälle. Vorteil für Unternehmen: Das gesparte Geld durch die reduzierten Kosten für den Betrieb der IT-Systeme kann entweder als Rücklage dienen oder es kann in die IT reinvestiert werden, um einen Wettbewerbsvorteil vor Konkurrenten zu erreichen. Eine höhere Systemverfügbarkeit bedeutet einen reibungsloseren Ablauf der Geschäftsprozesse für Unternehmen Nachteile In-Memory-Computing Nachfolgend werden zwei technische Nachteile und die daraus resultierenden Nachteile für Unternehmen betrachtet. Hohes Risiko bei der Einführung In-Memory ist bei weitem nicht so verbreitet bei Unternehmen wie diskbasierte Systeme. Damit ist vergleichsweise sehr wenig Wissen über die Technologie vorhanden. Außerdem gibt es sehr wenige Experten und Tools zur Problemanalyse. Die folgenden Fragen können auf Grund eines unzureichenden Einsatzes in der Praxis nicht hinreichend beantwortet werden: Wie bewährt sich ein solches System im day-to-day Betrieb, speziell unter Volllast? Wie reagiert es im Falle eines Desasters? Technischer Nachteil: Für die meisten Systemadministratoren ist das Gebiet Neuland. Damit steigt die Gefahr einer falschen Implementierung oder unsachgemäßer Administration, was im schlimmsten Fall einen Systemausfall und einen damit einhergehenden Datenverlust mit sich zieht. Nachteil für Unternehmen: Ein nicht oder nur schlecht laufendes IT-System wirkt sich in der heutigen Welt fast immer auf das Kerngeschäft der Unterneh- 28 Vgl. Plattner, H./Zeier, A. (2011), S. 22.

23 17 men aus. Das heißt im Klartext, dass bei einem Produktionsbetrieb die Fließbänder still stehen. Flüchtiger Speicher Durch den Einsatz von flüchtigem Speicher gehen die Daten bei Stromausfall verloren, was bedeutet, dass das ACID-Paradigma standardmäßig nicht gewährleistet wird. Es bedarf zusätzlicher Sicherungsmechanismen, wie das regelmäßige speichern der Daten auf persistentem Speicher (Festplatte) sowie das Loggen aller Transaktionen. Technischer Nachteil: Bei Stromausfall sind alle Daten verloren, die Implementierung zusätzlicher Sicherungsmechanismen verursacht Kosten und steigert die Komplexität der Systemumgebung. Nachteil für Unternehmen: Ein totaler Datenverlust der produktiven, transaktionalen Datenbank hat verheerende wirtschaftliche Auswirkungen für Unternehmen. Bei nicht ordnungsgemäßer Implementierung der notwendigen Sicherungen können wichtige Aufträge oder andere relevante Daten verloren gehen Technischer Fortschritt als Katalysator Das Thema In-Memory-Computing wird zurzeit sehr intensiv in der Fachwelt und den Unternehmen diskutiert. Laut Färber hat der technologische Fortschritt einen großen Anteil, dass es zu einem Überdenken der traditionellen Datenbankarchitekturen kommt. Er weist auf die Verfügbarkeit neuer Technologien wie große Hauptspeicherkapazitäten (Datenbank-Server mit einer Hauptspeicher-Kapazität von mehr als einem Terabyte) und Multi-Core-Prozessoren für eine echte parallele Verarbeitung von Transaktionen hin. 29 Die auf dem Markt verfügbare Hauptspeicher-Kapazität genügt, um selbst die transaktionalen Daten großer Unternehmen im Hauptspeicher speichern zu können. Hinzu kommt, dass die vorgenannten Technologien in diesem Ausmaß mittlerweile auch für mittelständische Unternehmen bezahlbar sind, was vor einigen Jahren noch nicht der Fall war Hauptspeicher Wie im Vorfeld bereits geschrieben und wie der Name In-Memory verrät, dient der Hauptspeicher als zentraler Datenspeicher für In-Memory-Datenbanken. Festplatten 29 Vgl. Färber, F. u. a. (2010), S. 81.

24 18 spielen demnach, wenn überhaupt, nur noch als Archivspeicher eine Rolle. Solid-State- Drives (SSD) werden immer günstiger und bieten eine bessere Performance als Festplatten. Große Anbieter von Storage-Lösungen wie Hitachi Data Systems haben bereits Storage-Systeme im Programm, die ausschließlich SSDs als Speicher verwenden. Die traditionelle, magnetische Festplatte läuft also Gefahr in nicht allzu ferner Zukunft ein Nischendasein zu fristen. Möglich und Interessant für viele Unternehmen wird der Einsatz der In-Memory-Technologie jedoch erst durch den starken Preisverfall von Hauptspeicher in den letzten Jahren. Während ein Megabyte Hauptspeicher im Jahr 2000 noch 1 US $ gekostet hat, liegt der durchschnittliche Preis heute bei 0,01 US $. In der Einführungsphase des relationalen Datenbankmodells im Jahr 1975 lag der Preis für Hauptspeicher bei US $ pro Megabyte. Der Preis für Festplatten ist in den letzten Jahren ähnlich exponentiell gefallen. 30 Hinzu kommt, dass sich die Größe des maximalen Arbeitsspeichers je Server in den letzten Jahren exponentiell erhöht hat. Es ist heutzutage ohne Probleme möglich, Server mit vier Terabyte Hauptspeicher zu beziehen (z. B. IBM POWER 770). Sollte die Menge nicht ausreichen, lässt sich der Hauptspeicher durch das Koppeln mehrerer Server nahezu beliebig erweitern. 31 Voraussetzung ist jedoch das Partitionieren und Verteilen der Daten auf den verschiedenen Servern. Die folgende Abbildung 7 visualisiert den Geschwindigkeitsvorteil des Hauptspeichers anhand der Speicherhierarchie-Pyramide und wirft auch einen Blick auf die Register der central processing unit (CPU) und die CPU-Caches. Abbildung 7: Speicherhierarchie-Pyramide Vgl. Plattner, H./Zeier, A. (2011), S Vgl. (Abfragedatum: 13. November 2011) (Abfragedatum: 25. November 2011).

25 19 Als Faustregel gilt: Je näher ein Speicher der CPU ist (Spitze der Pyramide), desto schneller aber auch kleiner ist der Speicher. Der Grund dafür ist der Preis. Zur Erweiterung der schnellen L1- und L2-Caches des Prozessors wird teures Silizium benötigt, was den Preis der CPU rapide steigen lässt Multi-Core-Prozessor Mit der Verwendung einer hauptspeicherbasierten Datenbank ist laut Krüger [ ] der Flaschenhals nicht mehr der Durchsatz und die Geschwindigkeit der Festplatte, sondern die Geschwindigkeit des Prozessors und wie schnell dieser Daten aus dem Arbeitsspeicher lesen kann. 33 Verdeutlicht wird diese Aussage in der Abbildung 8, die den neuen und alten Flaschenhals bei Datenbanken grafisch darstellt. Abbildung 8: CPU als Flaschenhals im In-Memory-Computing 34 Diesem drohenden neuen Flaschenhals steht die rasante Entwicklung von Multi-Core- Prozessoren entgegen. Dabei handelt es sich um Prozessoren, die mehrere Hauptprozessoren (Kerne) auf einem Chip haben. Prozessoren mit acht Kernen gelten heutzutage als Standard. Allerdings befinden sich in der Forschung bereits Prozessoren mit einem Vielfachen von acht Kernen. Jeder der Kerne hat in der Regel seinen eigenen L1- und L2-Cache. Damit ist ein echtes, paralleles Verarbeiten von Daten, beispielsweise die Verarbeitung mehrerer Transaktionen unterschiedlicher Benutzer, möglich. Ein aktueller Server der Firma IBM vom Typ POWER 770 für mittlere bis große Datenbankanwendungen kann z. B. mit bis zu acht Prozessoren mit 3,3 GHz mit je acht Prozessor- 33 Krueger, J. u. a. (2010), S Groth, H./Forster, A. (2011), S. 10.