In-Memory-Computing: Chancen für Unternehmen und Marktanalyse
Werbung
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: 238329 Abgabetermin: 18. Juli 2012 Steinbach, den 15. Juli 2012 II Inhaltsverzeichnis Abkürzungsverzeichnis ................................................................................................... IV Abbildungsverzeichnis ..................................................................................................... V Tabellenverzeichnis......................................................................................................... VI 1. Einleitung .............................................................................................................. 1 2. Datenbanken .......................................................................................................... 3 2.1 Datenbank Grundlagen ................................................................................... 3 2.2 Gründe für den Einsatz von Datenbanken ...................................................... 6 2.3 Relationale Datenbanken ................................................................................ 7 2.4 Spaltenorientierte Datenbanken .................................................................... 10 2.5 In-Memory-Datenbanken.............................................................................. 11 2.5.1 Bewährte In-Memory-Zusatzlösungen .................................................. 11 2.5.2 Reine In-Memory-Datenbanken ............................................................ 13 2.5.3 Vorteile In-Memory-Computing ........................................................... 15 2.5.4 Nachteile In-Memory-Computing ......................................................... 16 2.5.5 Technischer Fortschritt als Katalysator ................................................. 17 2.5.5.1 Hauptspeicher ................................................................................... 17 2.5.5.2 Multi-Core-Prozessor ....................................................................... 19 2.6 Aktuelle Trends im Bereich In-Memory-Computing ................................... 20 3. Ausblick auf den zweiten Teil............................................................................. 20 4. In-Memory-Computing Marktanalyse ................................................................ 21 5. In-Memory-Computing im Unternehmenseinsatz .............................................. 23 6. 5.1 In welchen Bereichen sich ein Einsatz lohnt ................................................ 24 5.2 Chancen und Risiken aus Sicht des Business und der IT ............................. 26 5.3 Beispiele erfolgreicher Einführungen ........................................................... 27 Vergleich von drei In-Memory-Datenbanken ..................................................... 29 6.1 Aufbau eines Kriterienkataloges ................................................................... 30 III 6.2 6.2.1 IBM solidDB 7.0 ................................................................................... 33 6.2.2 Oracle TimesTen 11g ............................................................................ 35 6.2.3 SAP Sybase ASE 15.7 ........................................................................... 37 6.3 7. Bewertung der Produkte anhand der Kriterien ............................................. 33 Ergebnis des Produktvergleichs .................................................................... 38 Fazit ..................................................................................................................... 42 Literaturverzeichnis..................................................................................................... 44 Eidesstattliche Versicherung ....................................................................................... 48 IV Abkürzungsverzeichnis ASE Adaptive Server Enterprise APO Advanced Planner and Optimizer BW Business Warehouse BWA Business Warehouse Accelerator CPU central processing unit DBMS Datenbankmanagementsystem DBS Datenbanksystem DD Data Dictionary ETL Extract, Transform, Load HANA High-Performance Analytic Appliance OLAP Online Analytical Processing OLTP Online Transaction Processing RAM Random Access Memory SSD Solid-State-Drive TCO Total Cost of Ownership 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 ............................................ 10 Abbildung 5: SAP APO mit liveCache ........................................................................... 12 Abbildung 6: Diskbasierte versus In-Memory-Datenbank ............................................. 14 Abbildung 7: Speicherhierarchie-Pyramide .................................................................... 18 Abbildung 8: CPU als Flaschenhals im In-Memory-Computing.................................... 19 Abbildung 9: Prozess der Datenwiederherstellung ......................................................... 32 Abbildung 10: Hochverfügbarkeitstopologie von IBM solidDB .................................... 34 Abbildung 11: Netzdiagramm In-Memory-Datenbanken ............................................... 41 VI Tabellenverzeichnis Tabelle 1: Speicherarten eines Datenbanksystems ........................................................... 9 Tabelle 2: Datenbank-Performance mit BWA ................................................................ 13 Tabelle 3: Chancen und Risiken von In-Memory-Computing........................................ 26 Tabelle 4: Bedeutung Erfüllungswerte der Nutzwertanalyse.......................................... 39 Tabelle 5: Nutzwertanalyse In-Memory-Datenbaken ..................................................... 39 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-Computing1. 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. 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 fingertips2 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 InMemory-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. 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 Datenbanksysteme3 (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. 19. 5 Vgl. Faeskorn-Woyke, H. u. a. (2007), S. 22. 4 Abbildung 2: Bestandteile einer Datenbank6 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. 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 OLTPSysteme 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 OLAPAnwendungen 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, Load10 7 Vgl. Kemper, A./Eickler, A. (2011), S. 529 f. Kemper, A./Eickler, A. (2011), S. 530. 9 Vgl. Kemper, A./Eickler, A. (2011), S. 530. 10 Kemper, A./Eickler, A. (2011), S. 531. 8 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%).11 2.2 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. http://www.computerwoche.de/software/software-infrastruktur (Abfragedatum: 27.12.2011). 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.13 2.3 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. Vgl. Kemper, A./Eickler, A. (2011), S. 289. 14 Kemper, A./Eickler, A. (2011), S. 71. 13 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 16 Vgl. Kannengiesser, C./Kannengiesser, M. (2007), S. 613 f. Vgl. Kemper, A./Eickler, A. (2011), S. 203 ff. 9 Speicher- Zu- stufe griffszeit kapazität Primärspei- ~ 100 ns cher Speicher- Preis Vorteile Nachteile Gigabyte - Sehr schnell - Flüchtig bis - Feine Granularität - Sehr teuer Terabyte Sekundär- ~ 10 ms Terabyte speicher Archivspei- >1s Terabyte cher - Nicht flüchtig - Relativ langsam - Direktzugriff - Mechanisch - Lagerbarkeit - Sehr langsam - Ausfallsicherheit - Verschleiß Tabelle 1: Speicherarten eines Datenbanksystems17 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 105, was einem theoretisch 100.000-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. 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 OLAPAnwendungen 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 Datenzugriff18 18 Krueger, J. u. a. (2010), S. 4. 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. 2.5.1 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 20 Vgl. Krueger, J. u. a. (2010), S. 4 f. Vgl. Krueger, J. u. a. (2010), S. 2. 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-ToPromise) 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 liveCache22 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 22 Vgl. Nüßer, W. u. a. (2006), S. 416 f. Nüßer, W. u. a. (2006), S. 416. 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 BWA23 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 Tren- nung der beiden Anwendungstypen aufgehoben werden soll. Es befinden sich bereits hybride In-Memory-Datenbanken in der Entwicklung, die OLTP- und OLAPAnwendungen auf einer Datenbasis vereinen. Weiterhin sind diese Datenbanken nicht mehr diskbasiert, sondern liegen komplett im Hauptspeicher. 2.5.2 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-MemorySystems 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: http://www.sap.com/austria/about/events (Abfragedatum: 13. November 2011). 24 Kemper, A./Eickler, A. (2011), S. 668. 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-MemoryDatenbanken, wie in Abbildung 6 anhand eines diskbasierten Systems und der Oracle In-Memory Datenbank TimesTen dargestellt wird.25 Abbildung 6: Diskbasierte versus In-Memory-Datenbank26 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 26 Vgl. Stirnimann, R./Ott, J. (2011), S. 6. Stirnimann, R./Ott, J. (2011), S. 7. 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-MemoryDatenbanken 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.27 2.5.3 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. 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 ITSystems reduziert werden können. Dies wird durch die vereinfachte SystemLandschaft 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. 2.5.4 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. 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. 2.5.5 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. 2.5.5.1 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. 18 spielen demnach, wenn überhaupt, nur noch als Archivspeicher eine Rolle. Solid-StateDrives (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 50.000 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-Pyramide32 30 Vgl. Plattner, H./Zeier, A. (2011), S. 15. Vgl. http://www.isreport.de/news-events/news (Abfragedatum: 13. November 2011). 32 http://openbook.galileocomputing.de/linux (Abfragedatum: 25. November 2011). 31 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. 2.5.5.2 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-Computing34 Diesem drohenden neuen Flaschenhals steht die rasante Entwicklung von Multi-CoreProzessoren 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 34 Krueger, J. u. a. (2010), S. 7. Groth, H./Forster, A. (2011), S. 10. 20 kernen konfiguriert werden. Bei einer gewählten Einstellung von bis zu vier Threads pro Prozessorkern entspricht dies 256 echt parallel laufenden Threads.35 2.6 Aktuelle Trends im Bereich In-Memory-Computing Im Fokus der Entwicklung im In-Memory-Computing stehen sowohl transaktionale Datenbanken (OLTP) als auch analytische Datenbanken (OLAP). In den letzten Jahrzenten wurde sich auf die Optimierung der Trennung beider Arten fokussiert. Auf Grund des erwähnten technischen Fortschritts und der damit einhergehenden Möglichkeit, komplexe Anfragen in sekundenbruchteilen durchführen zu können, stellt sich jedoch zunehmend „[…] die Frage, ob die künstlich eingeführte Trennung von OLTP und OLAP aufgehoben werden kann und sämtliche Anfragen auf einem vereinfachten Datenbestand arbeiten können.“36 Der große Treiber auf diesem Gebiet ist zurzeit die SAP AG mit dem Produkt „High-Performance Analytic Appliance“ (HANA). Die Entwicklung von HANA begann 2007 und im Februar 2010 wurde das Produkt erstmals der Öffentlichkeit vorgestellt. Es sieht sich als Nachfolger des klassischen, relationalen Datenbankmanagementsystems. HANA sieht vor, OLTP- und OLAP-Systeme von zwei getrennten, festplattenbasierten Datenbanken, in eine gemeinsame Hauptspeicherdatenbank zu integrieren. Getrieben wird dieser Wunsch dadurch, dass analytische Auswertungen sich mehr und mehr als Treiber des operationalen Geschäfts herauskristallisieren und zum festen Bestandteil eines operativen Geschäftsprozesses werden. Auch soll HANA, je nach Bedürfnis, zeilen- und spaltenbasiertes Speichern von Daten unterstützen. Die neueste SAP HANA Version unterstützt bereits die aktuelle SAP Data-WarehouseLösung SAP BW (OLAP) und fungiert dort als zentrale Datenbank. Für OLTP-Systeme befindet sich HANA allerdings noch in der Entwicklung. Aber auch andere Firmen wie IBM, Oracle und diverse Open Source Anbieter springen auf den In-Memory-Zug und entwickeln neue Produkte. 3. Ausblick auf den zweiten Teil Nachdem im ersten Teil der Arbeit die theoretischen Grundlagen von Datenbanken und im Speziellen von In-Memory-Datenbanken betrachtet wurden, erfolgen im zweiten 35 36 Vgl. http://www.ibm.com/common/ssi (Abfragedatum: 10. Januar 2012). Krueger, J. u. a. (2010), S. 1. 21 Teil eine eingehende Marktanalyse und ein Produktvergleich von Hauptspeicherdatenbanken. Im vierten Kapitel erfolgt eine Marktanalyse zum Thema In-MemoryComputing. In Kapitel 5 wird ein Einsatz der Technologie im Unternehmen betrachtet. Es wird erörtert, für welche Branchen und Unternehmen eine Einführung lohnend ist. Weiterhin werden die Chancen und Risiken, die ein Einsatz mit sich bringt, aus Sicht des Business und der IT betrachtet. Im Weiteren wird auf erfolgreiche Einführungen in der Praxis dreier unterschiedlicher Produkte eingegangen. In Kapitel 6 erfolgt ein Vergleich von drei auf dem Markt etablierten Produkten im Enterprise Sektor. Mit Hilfe eines Kriterienkataloges werden die Produkte einzeln beschrieben. Abschließend werden die Ergebnisse des Produktvergleichs besprochen und mit Hilfe einer Nutzwertanalyse veranschaulicht und bewertet. In Kapitel 7 erfolgt das Fazit der Arbeit und es wird überprüft, ob eines der gegenübergestellten Produkte optimal für den Unternehmenseinsatz ist. Weiterhin wird ein Ausblick gegeben, welches der Produkte für den Unternehmenseinsatz geeignet scheint. 4. In-Memory-Computing Marktanalyse In-Memory-Datenbanken fristen auf dem globalen Markt derzeit noch ein absolutes Nischendasein. Festplattenbasierte Datenbanken sind nach wie vor die von Unternehmen favorisierte Datenbanklösung. Diese haben sich im Alltag bewährt und das erforderliche Know-how zur Einrichtung und Administration ist vorhanden. Allerdings stoßen traditionelle Datenbanken an ihre technischen Grenzen, da in Unternehmen die Anforderungen an die IT steigen. Beispielsweise werden immer mehr Daten gespeichert, die immer schneller verarbeitet werden sollen. Der dafür benötigte Festplattenspeicher stößt dabei an seine physikalische Grenze in Bezug auf die Verarbeitungsgeschwindigkeit. Um die steigenden Anforderungen von Unternehmen zu befriedigen, konstruieren Datenbankanbieter neue Datenbankmodelle und -architekturen. Es gibt mittlerweile weit über 20 reine In-Memory-Datenbanken auf dem Markt, die sich unter anderem im Funktionsumfang sowie den Integrations- und Administrationsmöglichkeiten unterscheiden. Eine andere Differenzierung erfolgt anhand der darüber liegenden Anwen- 22 dung.37 Es gibt spezielle In-Memory-Lösungen für transaktionale sowie für analytische Anwendungen. Andere Produkte sind für beide Anwendungsarten einsetzbar.38 Viele große relationale Datenbankhersteller sind im In-Memory-Sektor mit unterschiedlichen Lösungen vertreten und machen dieses auch seit mehreren Jahren mit einer umfangreichen Vermarktungsstrategie publik. So hat IBM (Relationale Datenbank: DB2) die In-Memory-Datenbank solidDB in ihrem Portfolio. Oracle (Relationale Datenbank: Oracle Datenbank) hat unter anderem TimesTen im Programm. Microsoft (Relationale Datenbank: SQL Server), dritter im Bunde der großen Datenbankanbieter, hält sich dagegen bisher noch sehr bedeckt zu dem Thema. Es gibt momentan keine bestätigten Informationen, wann und wie Microsoft eine eigene In-Memory-Lösung auf den Markt bringt. Gerüchte besagen jedoch, dass es eine Eigenentwicklung sein wird und in einer zukünftigen Version von Microsoft SQL Server zu sehen ist - allerdings nicht in naher Zukunft.39 Der vierte, große Anbieter von Enterprise-Datenbanklösungen ist SAP (Relationale Datenbank: MaxDB), die mit der In-Memory-Lösung HANA seit rund zwei Jahren mit mehreren großen Kampagnen für ein großes mediales Aufsehen sorgt. Mit der Übernahme des Datenbankspezialisten Sybase im Jahr 2010 wurde nicht nur der Zugang zu neuen Kunden geschaffen, sondern es wurden auch vielversprechende, hochentwickelte Produkte (unter anderem Sybase Adaptive Server Enterprise (ASE)) und die entsprechende Expertise, mit der die Entwicklung von HANA vorangetrieben werden kann, ins Unternehmen geholt. Die Übernahme von Sybase und die exzessiven Marketingaktivitäten der SAP sind als eine Kampfansage an die führenden Datenbankanbieter Oracle, Microsoft und IBM zu sehen. SAP plant bis zum Jahr 2015 eine Führungsposition auf dem Datenbankmarkt einzunehmen. Diese kommerziellen Produkte eignen sich auf Grund ihrer umfangreichen Features und der relativ hohen Kosten für Lizenzen und Support hauptsächlich für große Konzerne mit einer großen IT-Umgebung. Für kleine und mittelständische Unternehmen gibt es jedoch auch diverse In-Memory-Lösungen. Als Beispiele seien hier die komplett kostenlosen Produkte HSQLDB sowie SQLite genannt. Aktuellen Einschätzungen, Erfahrungen und Analysen aus Forschung und Praxis zufolge befindet sich die In-Memory-Technologie bereits in einer Phase in der davon ausge- 37 Vgl. Ott, J./Stirnimann, R. (2012), S. 1. Vgl. Kapitel 2 dieser Arbeit. 39 Vgl. Foley, M.-J. (2012) (Abfragedatum: 28. April 2012). 38 23 gangen werden kann, dass sie in den nächsten 10 Jahren traditionelle Datenbanksysteme größtenteils ablösen und ein neues Zeitalter in der Informationstechnologie einleiten kann.40 5. In-Memory-Computing im Unternehmenseinsatz Wie bei jedem anderen Produkt oder jeder anderen Technologie muss auch bei der InMemory-Technologie genau geprüft werden, ob ein Einsatz Sinn macht. Als größten Nutzen stellen die Anbieter immer wieder die um eine vielfach verbesserte Performance der Anwendungen dar, mit der Unternehmen sich einen deutlichen Wettbewerbsvorteil schaffen können. Eine verbesserte Performance ist aber nicht für jedes Unternehmen und jeden Geschäftsprozess von hoher Bedeutung, daher sollte im Rahmen des Projektmanagements genau geprüft werden, ob eine Einführung einen Nutzen für das Unternehmen hat. Dies kann beispielsweise im Rahmen eines Proof of Concept durchgeführt werden. Als größte Showstopper einer Einführung sind die folgenden Faktoren zu nennen: Anwendungen sind (noch) nicht In-Memory-fähig Sehr hohe Einführungskosten (hoher Preis für Arbeitsspeicher) Fehlendes Fachwissen in der IT-Abteilung und von externen Beratern Kaum Erfahrungswerte im Tagesbetrieb (was passiert wirklich, wenn der Strom ausfällt?) Bevor es allerdings zu einem Projekt mit dem Ziel der Einführung von In-MemoryComputing kommt, sollten einige allgemeine Faktoren betrachtet werden. Zum einen spielt die Branche eine wichtige Rolle. Branchen, in denen die Geschwindigkeit der ausgeführten Transaktionen eine große Rolle spielt, wie zum Beispiel im E-Commerce oder bei Finanzdienstleistern, profitieren im Allgemeinen weitaus mehr von dieser Technologie als andere Branchen. Durch die möglich werdende extrem schnelle Antwortzeit können die vereinbarten Service Level Agreements (SLA) gehalten beziehungsweise optimiert werden. Zum anderen hängt es von dem betrachteten Unternehmen selbst ab, ob eine Einführung in Erwägung gezogen werden sollte. Eine kleine Finanzagentur mit einer Kundendatenbank von 1000 Datensätzen hat in der Regel keinen nennenswerten Vorteil durch eine Umstellung auf eine In-Memory-Datenbank. Ganz 40 Vgl. Plattner, H. (2009), S. 6 f. 24 anders könnte das bei einem großen, global tätigen Finanzdienstleister sein. Die dort eingesetzten Anwendungen werden von tausenden Mitarbeitern auf der ganzen Welt gleichzeitig bedient und die darunter liegenden Datenbanken haben nicht selten Tabellen mit mehreren hundert Millionen Datensätzen. Hier kann der Einsatz von In-Memory unter Umständen einen wichtigen Wettbewerbsvorteil schaffen. Die oben aufgeführten Faktoren mit ihren Beispielen bilden nur einen Bruchteil dessen ab, was das Projektmanagement bei einer in Frage kommenden Einführung prüfen muss. Der Autor Ott sieht unter anderem die folgenden, allgemeinen Anforderungen und Rahmenparameter als Argumente für den Einsatz einer In-Memory-Datenbank: Ein regelmäßig hoch frequentierter Lese- und Schreibzugriff auf die plattenbasierte Datenbank, was durch viele gleichzeitig operierende Benutzer und eine hohe Anzahl an Transaktionen verursacht wird. Dieser Effekt kann auch durch Jobketten entstehen. Der Datenbank-Server leidet unter einer hohen Auslastung (u.a. durch die vorher beschriebenen Faktoren) und ist oder entwickelt sich zum Flaschenhals für die Anwendung. Es werden größtenteils einfache und kurze SQL-Statements auf der Datenbank ausgeführt (z. B. INSERT INTO kunde (knr, name, vorname) VALUES (1, 'Doe', ‘John’). Ein erhöhtes Risiko von Datenverlust, durch den flüchtigen Speicher, wird in Kauf genommen.41 5.1 In welchen Bereichen sich ein Einsatz lohnt Das Potenzial des In-Memory-Computing kann nicht in jedem Bereich so ausgeschöpft werden, dass es für das Unternehmen profitabel ist. Es muss von Fall zu Fall abgewogen werden, welche Vorteile der Einsatz dieser neuen Technologie erzielen kann. Die folgenden Bereiche können besonders von In-Memory profitieren: Business Warehouse Reports und -Analysen, welche je nach Datenvolumen und Komplexität bis zu mehreren Tagen benötigen, um generiert zu werden. Beispiel: Im Bereich der Personaleinsatzplanung kann das Unternehmen direkt erkennen, wie sich Veränderungen der Organisation auf das Geschäft auswirken. 41 Vgl. Ott, J./Stirnimann, R. (2012), S. 3. 25 Bei Akquisitionen wäre das Unternehmen in der Lage zu simulieren, wie die Belegschaft nach einem geplanten Zukauf angepasst werden muss. Diese Möglichkeit unterstützt den Prozess des Personalwesens. In-Memory-Computing ermöglicht es, Mitarbeiter und Entscheidungsträger mit detaillierten und aktuelleren Daten zu versorgen. Damit können Geschäftsprozesse schneller abgewickelt, Entscheidungen präziser getroffen sowie Trends erkannt werden. Beispiel: In Echtzeit zur Verfügung stehende Absatzzahlen aller Filialen einer Einzelhandelskette ermöglichen es dem Unternehmen direkt zu sehen, welche Produkte sich gut und welche sich schlecht verkaufen, welche Promotion erfolgreich ist und welche der Filialen am effektivsten ist. Im Endeffekt erhält das Unternehmen dadurch einen Live-Einblick in das Kaufverhalten der Kunden und sieht dadurch umgehend und sehr präzise, wie sich unter anderem Änderungen am Sortiment, an den Preisen und am Personal auf die Einkäufe bemerkbar machen. Wenn mit einem hohen Risiko behaftet Entscheidungen schnell getroffen werden müssen, kann In-Memory helfen, das Risiko eines eventuell aus der Entscheidung resultierenden Schaden zu minimieren. Die schnelle Datenbank ermöglicht die Simulation sehr vieler Szenarien binnen einer sehr kurzen Zeit und maximiert somit das Verhältnis von Potenzial und Risiko.42 Die Verfügbarkeitsprüfung (Global Available-To-Promise) ist eine wichtige Funktion in einem SAP ERP-System. Gibt ein Mitarbeiter eine Bestellung in das SAP-System ein, wird automatisch im Hintergrund geprüft, ob das gewünschte Produkt in der gewünschten Menge und zum gewünschten Liefertermin dem Kunden zugesagt werden kann. Ohne diese Prüfung sollte demnach keine Bestellung aufgenommen werden. Mit In-Memory lässt sich nicht nur die Verfügbarkeitsprüfung schneller durchführen, sondern es sind auch unterschiedliche Echtzeit-Analysen möglich, wie zum Beispiel eine Übersicht von Produkten, die auf Grund von fehlendem Bestand nicht verkauft werden konnten. Mit Hilfe dieses Reports kann nachgeforscht werden, in welchem Teil der Lieferkette die Ursache gelegen hat. Ist die Ursache gefunden, können entsprechende Vorkehrun- 42 Vgl. Stangneth, H. (2011) (Abfragedatum: 5. Mai 2012). 26 gen oder Verbesserungen getroffen werden, um zukünftige Nicht-Lieferungen zu minimieren. 5.2 Chancen und Risiken aus Sicht des Business und der IT Eine geplante Integration einer In-Memory-Lösung in die vorhandene IT-Landschaft eines Unternehmens birgt zum einen große Chancen, sie bringt aber auch nicht zu verachtende Risiken mit sich. Dies gilt sowohl für das Business als auch die für die Einführung und anschließende Administration im Tagesbetrieb verantwortliche ITOrganisation. Die Risiken sind vor allem darauf zurückzuführen, dass es sich bei dem Thema In-Memory um eine relativ neue und damit im Verhältnis zu festplattenbasierten Datenbanken wenig erprobte Technologie handelt. Die nachfolgende Tabelle 3 stellt die Chancen und Risiken von In-Memory-Computing dar. Abteilung Business & Management Chancen Risiken IT-Abteilung Analysen in Echtzeit Neue Analysemöglichkeiten Beschleunigung von Geschäftsprozessen Wettbewerbsvorteil Bessere Entscheidungsmöglichkeiten in Fachabteilungen Bereitstellung von neuen ITLösungen für das Business Hohe Zufriedenheit der Fachabteilungen mit der IT Optimale CPU-Ausnutzung Schlankere IT-Umgebung durch den Wegfall von Disks Reduzierte IT-Kosten (TCO) Erhöhte Ausfallzeiten vor allem zu Beginn Erhöhtes Risiko von Datenverlust Einführung bringt nicht die erhoffte Performance-Verbesserung Vorhandene Geschäftsprozesse müssen angepasst werden Erwartungen werden nicht erfüllt Fehlendes Know-how Hohe Einführungskosten durch neue Hardware & Lizenzen Applikationen müssen angepasst werden Kein umfangreiches Monitoring Versuchsobjekt von DB-Anbietern Tabelle 3: Chancen und Risiken von In-Memory-Computing43 Wie in der obigen Tabelle 3 dargestellt, gibt es auf beiden Seiten eine Vielzahl von Chancen und Risiken, die vor der Entscheidung einer möglichen Einführung genauestens abgewogen werden müssen. Zusammenfassend ist festzustellen, dass auf der Seite des Business die Chancen in neuen Analysemöglichkeiten und schneller abgewickelten Geschäftsprozessen liegen. Daraus resultieren verbesserte Entscheidungsmöglichkeiten der Fachabteilungen, was im Endeffekt einen Vorsprung vor Wettbewerbern und damit 43 Vgl. EXASOL - Vorteile - Das Richtige für alle im Unternehmen (Abfragedatum: 6. Mai 2012). 27 einen höheren Absatz möglich macht. Die Risiken für das Business liegen darin, dass die neue Technologie noch nicht ausgereift ist und das Risiko von erhöhten Ausfallzeiten und Datenverlust vor allem anfangs relativ hoch sein kann. Außerdem wird oft erst im Tagesgeschäft deutlich, ob die Einführung die versprochenen Geschwindigkeitszuwachse hält. Auf Seiten der IT kann mit einer erfolgreichen Einführung das Vertrauen des Business in die IT massiv gesteigert werden. Durch In-Memory können die Fachabteilungen bisher nicht für möglich geglaubte Operationen in Echtzeit durchführen. Weiterhin wird durch den Wegfall der Platten in den Systemen die Architektur vereinfacht, was langfristig verringerte Administrations- und Hardwarekosten zur Folge hat. Die Risiken liegen in dem momentan noch fehlendem Know-how der IT-Abteilungen, in fehlenden Analyse- und Monitoring-Tools für In-Memory-Datenbanken und der Tatsache, dass man eventuell als Versuchsobjekt für die Datenbank-Anbieter dient. Hohe Einführungskosten sowie eine notwendige Anpassung des Programmcodes der Anwendungen erweitern die Risiken für die IT-Abteilung. Es ist davon auszugehen, dass sich die Chancen und Risiken in den nächsten Jahren durch einen vermehrten Einsatz von In-Memory-Datenbanken massiv verändern werden. Gute Erkenntnisse können vor allem dann gewonnen werden, sobald Großkonzerne ihre Systeme umstellen. 5.3 Beispiele erfolgreicher Einführungen In Laufe der letzten Jahre haben bereits einige Unternehmen ihre IT-Systeme ganz oder teilweise auf speicherbasierte Datenbanken umgestellt. Im folgenden Abschnitt werden anhand drei reeller Beispiele die Möglichkeiten mit In-Memory-Computing praxisnah dargestellt. Unternehmen: Charité Berlin Branche: Gesundheitswesen Eingeführtes Produkt: SAP HANA Problemstellung: Das Krankenhaus hat mit einem rapide wachsenden Datenbestand zu kämpfen. Neben einer höher werdenden Anzahl an Patienten und Behandlungen tragen auch der Fortschritt in Technik und Forschung dazu bei, dass immer mehr Daten verarbeitet werden müssen. Im klinischen Bereich gibt es 28 Tabellen mit 300 Millionen Zeilen, die für das vorhandene, diskbasierte ERPSystem nicht in einer angemessen Art und Weise nutzbar waren. Lösung: Mit der Einführung von SAP HANA sind Einblicke in Patientendaten in Echtzeit möglich. Mit dieser direkt möglichen Auswertung lassen sich beispielsweise Therapien optimieren in dem der Erfolg der Therapie in Echtzeit überprüft und falls nötig angepasst werden kann.44 Unternehmen: Sihua Technologies Branche: Technologie Eingeführtes Produkt: Oracle TimesTen Problemstellung: Sihua Technologies bietet Streaming-Lösungen (Webradio und Web-TV) für seine Kunden aus den Media- und Fernsehanstalten an, die dann den Endkunden mit Musik, Videos und Fernsehsendern über die Streaming-Technologie versorgen. Eine wachsende Anzahl an Konsumenten sowie verbesserte Auflösungen (High Definition) machen eine Optimierung der unterliegenden Datenbank notwendig. Lösung: Mit der Einführung diverser Oracle-Datenbankprodukte inklusive der In-Memory-Datenbank TimesTen wurde die Performance so verbessert, dass die Anzahl der gleichzeitig verbundenen Benutzer von 1.500 auf 4.000 erhöht werden konnte. Weiterhin erfolgte eine Optimierung der Zugriffsgeschwindigkeit auf die angebotenen Medien.45 Unternehmen: Universidad Autónoma Metropolitana Branche: Bildung Eingeführtes Produkt: SAP Sybase Adaptive Server Enterprise (ASE) Problemstellung: Die Universität hatte mit einer immer schlechter werdenden Reaktionszeit des IT-Systems zu kämpfen. Verursacht wurde dies durch eine wachsende Anzahl von Benutzern (Studenten, Dozenten, Verwaltung) sowie eine Steigerung der gespeicherten Daten. Lösung: Mit der Umstellung auf die In-Memory-Datenbank Sybase ASE konnte die Universität die im Vorfeld vereinbarten Service Level Agreements einhalten und die Anwender haben nun einen einfacheren und schnelleren Zugriff auf die benötigten Informationen. Die durchschnittliche Reaktionszeit konnte um bis zu 40 % gesteigert werden und für vereinzelte Transaktionen ist die Bearbeitungs- 44 45 Vgl. SAP_Charite Berlin_Erfolgsgeschichte (Abfragedatum: 6. Mai 2012). Vgl. Oracle_Shanghai Sihua_Erfolgsgeschichte (Abfragedatum: 7. Mai 2012). 29 zeit von 18 Stunden auf 30 Minuten gesunken. Weiterhin konnte die Nutzung der Hardware-Ressourcen optimiert werden sowie die TCO der IT reduziert werden.46 Die oben aufgeführten erfolgreichen Einführungen machen deutlich, welche Optimierungsmöglichkeiten mit dem Einsatz der In-Memory-Technologie möglich sind. Das Einsatzgebiet ist, wie an den unterschiedlichen Wirtschafszweigen ersichtlich, relativ weit gestreut. Da öffentlich publizierte Erfolgsgeschichten sehr allgemein gehalten sind, müssen diese allerdings mit Vorsicht betrachtet werden. Die teilweise kennzahlengestützten Erfolgskriterien lassen sich nicht beliebig auf jedes andere Unternehmen kopieren. Weitere Faktoren wie die unterliegende Infrastruktur (Netzwerk), eingesetzte Hochverfügbarkeitslösungen (Datenreplikation), verwendete Hardware und das Datenbankvolumen können das Ergebnis erheblich beeinflussen, zum Negativen sowie zum Positiven. 6. Vergleich von drei In-Memory-Datenbanken Mit den Jahren hat sich die Anzahl der auf dem Markt verfügbaren In-MemoryDatenbanken gesteigert. Dies hängt zum einen mit den neuen technischen Möglichkeiten sowie dem Preisverfall der Hardware zusammen. Zum anderen gibt es einen wachsenden Bedarf nach hochperformanten Datenbanken in den Unternehmen. In den letzten Jahren wurde die In-Memory-Technologie stetig verbessert, entweder durch eine kontinuierliche interne Weiterentwicklung oder durch den Zukauf von anderen Datenbankanbietern und dadurch entstehenden neuen Möglichkeiten für das kaufende Unternehmen in Hinsicht auf nutzbare Patente, vorhandene Technologien und das Fachwissen der Mitarbeiter. Die Auswahl der in diesem Kapitel vorgestellten In-Memory-Datenbanken zielt auf Enterprise-Lösungen für IT-Umgebungen in Großkonzernen ab. Produkte für den vorwiegenden Einsatz in kleinen oder mittelgroßen IT-Umgebungen werden nicht betrachtet, sind auf dem Markt aber ebenso vertreten. Die Wahl der zu vergleichenden Produkte fiel nach eingehender Recherche auf Lösungen der Firmen IBM, Oracle und SAP Sybase. Diese Auswahl wird dadurch begründet, dass die nachfolgend diskutierten Produkte im direkten Wettbewerb zueinander stehen und für ähnliche Einsatzzwecke entwickelt wurden. Dadurch wird eine gute Vergleichsmöglichkeit geschaffen. Ganz be46 Vgl. Sybase_Universität_Erfolgsgeschichte (Abfragedatum: 7. Mai 2012). 30 wusst fiel die Wahl nicht auf SAP HANA. Es handelt sich bei HANA zum einen um eine Appliance (Kombination aus Hardware und Software) und zum anderen befindet sich ein großer Teil der Appliance noch in der Entwicklung und ist somit noch nicht vollständig auf dem Markt verfügbar. Das macht einen Vergleich mit anderen Produkten nahezu unmöglich. Die Wahl fiel auf die folgenden Produkte: IBM solidDB 7.0 Oracle TimesTen 11g SAP Sybase ASE 15.7 Hervorzuheben ist, dass alle vorgenannten Produkte von den Weltkonzernen IBM, Oracle und SAP in den letzten 6 Jahren aufgekauft worden sind. Bei den übernommenen Firmen handelt es sich um Anbieter von High-Performance-Datenbanken. Oracle hat im Jahr 2006 den Anfang gemacht und die Firma TimesTen übernommen. Der Rivale IBM hat im Jahr 2008 nachgezogen und die Firma Solid aufgekauft, während die SAP sich im Jahr 2010 mit dem langjährigen Kooperationspartner Sybase zusammengeschlossen hat.47 6.1 Aufbau eines Kriterienkataloges Um die drei In-Memory-Datenbanken möglichst standardisiert und objektiv beschreiben und vergleichen zu können, erfolgte eine intensive Recherche mit dem Ziel der Erstellung eines geeigneten Kriterienkataloges. In diesem Kapitel erfolgt zunächst eine Beschreibung der Kriterien, mit der im weiteren Verlauf dieser Arbeit dann die einzelnen Produkte beschrieben, bewertet und schließlich mit Hilfe einer Nutzwertanalyse miteinander verglichen werden. Es erfolgt eine Unterteilung in unterstützte Plattformen, Hochverfügbarkeit, Datenwiederherstellung (Checkpoint-Files & Transaction Logs), Performance und Skalierbarkeit. Unterstützte Plattformen Eine In-Memory-Datenbank wird in der Regel in eine bereits bestehende IT-Landschaft integriert. Bei großen Konzernen ist es eher die Regel als die Ausnahme, dass verschiedene Betriebssysteme serverseitig eingesetzt werden. Beispiele sind Windows Server, diverse Linux-Distributionen, IBM AIX und UNIX. Daher ist es von großer Bedeutung, dass das ausgewählte Produkt mit möglichst allen im Unternehmen eingesetzten Platt47 Vgl. Jackson, J. (2010) (Abfragedatum: 12. Mai 2012). 31 formen kompatibel ist. Eine Nicht-Kompatibilität mit der bestehenden IT-Landschaft führt entweder zu einem Ausschluss des Produktes oder erfordert eine, wenn möglich, entsprechende Anpassung der bestehenden IT-Landschaft auf die In-MemoryDatenbank. Hochverfügbarkeit Vor allem kritische Unternehmensanwendungen, die beispielsweise Teil des Order-toCash-Prozesses sind, sollten dem Anwender uneingeschränkt zur Verfügung stehen. Störfälle sind aber trotz des Einsatzes redundanter Komponenten, wie zwei Netzwerkkarten und zwei Netzteile je Server, nicht auszuschließen. Daher ist es bei kritischen Produktivsystemen oft notwendig, den gesamten Server redundant zu halten. Fällt der primäre Server durch einen unerwarteten Störfall aus, kann die Anwendung samt Datenbank innerhalb kurzer Zeit auf den Standby-Server umgeschaltet werden. Die Realisierung erfolgt meistens durch eine Datenbankreplikation. Hier werden die Daten der primären Datenbank ununterbrochen auf die Standby-Datenbank geschrieben. Kritisch zu betrachten ist, dass die andauernde Replikation zu Leistungsbeeinträchtigungen der primären Datenbank führen kann. Datenwiederherstellung Daten sind ein wichtiges Gut eines Unternehmens. Daher ist es notwendig, dass die eingesetzte Datenbanklösung über entsprechende Mechanismen verfügt, um nach einem Datenbank-Crash oder bei einer Stromunterbrechung keinen Datenverlust zu erleiden. Vor allem bei In-Memory-Datenbanken kann es auf Grund des ausschließlich flüchtigen Speichers schneller als bei festplattenbasierten Datenbanken zu Datenverlusten kommen. Für eine effektive Datenwiederherstellung gibt es Checkpoint-Files und Transaction Logs. Checkpoint-Files Ein Checkpoint-File ist eine Momentaufnahme der Datenbank, die in regelmäßigen zeitlichen Abständen auf einen persistenten Speicher geschrieben wird. In der Regel werden in dem Checkpoint-File nur die Änderungen seit dem letzten Checkpoint gespeichert. Bei einem Datenbank-Crash oder bei Datenkorruption kann keine gültige Verbindung mehr zu der Datenbank hergestellt werden. In solch einem Fall wird das letzte gültige Checkpoint-File in den Speicher der Datenbank gelesen und damit stehen die Daten wieder zur Verfügung. Transaktionen, die nach dem letzten gültigen Checkpoint-File 32 bestätigt wurden, sind dementsprechend mit dem Checkpoint-File nicht mehr wiederherstellbar. Transaction Logs Daten, die nach einem Checkpoint-File bestätigt wurden, werden in der sogenannten Roll-forward-Phase wiederhergestellt. Dabei werden alle bestätigten Transaktionen mittels der fortwährend auf einem persistenten Speichermedium gespeicherten Transaction Logs zurück in die Datenbank geschrieben. Somit lassen sich auch jene Daten wiederherstellen, die nicht durch das geplante Checkpoint gespeichert wurden.48 Die folgende Abbildung 9 verdeutlicht den kompletten Prozess der Datenwiederherstellung. Die Checkpoints und die Transaction Logs werden auf einem nicht-flüchtigen Speichermedium gespeichert, in der Regel auf einer Festplatte oder einer SSD. Abbildung 9: Prozess der Datenwiederherstellung Performance Die Performance von Datenbanken wird vor allem an der durchschnittlichen Antwortzeit von Transaktionen gemessen. Hinzu müssen Faktoren, wie die Größe der Datenbank, Komplexität der SQL-Statements und gleichzeitig angemeldete Benutzer in Betracht gezogen werden. Auch äußere Faktoren wie das Netzwerk und verwendete Hardware spielen eine Rolle. Einen weiteren Einfluss auf die Performance hat die für viele Hochverfügbarkeitslösungen notwendige Replikation zwischen primärer und sekundärer Datenbank. Gerade In-Memory-Datenbanken werben mit einer extrem verbesserten Leistung der Datenbank durch den Einsatz von Hauptspeicher anstelle von Festplatten. 48 Vgl. Oracle Data Availability and Integrity (Abfragedatum: 18. Juni 2012). 33 Skalierbarkeit Schon vor der Einführung einer In-Memory-Datenbank sollte geprüft werden, wie sich die Datenbank skalieren lässt, um in Zukunft mehr Zugriffe und einen wachsenden Datenbestand verarbeiten zu können und steigenden Anforderungen der Benutzer und des Managements gerecht zu werden. Bei der Skalierung wird zwischen Scale-Up und Scale-Out unterschieden. Scale-up steht für eine vertikale Skalierung. Hier wird beispielsweise ein bestehender Datenbank-Server mit mehr Speicher und CPU aufgerüstet oder der Server wird durch einen neuen, leistungsfähigeren Server ersetzt. Beim Scale-Out (horizontale Skalierung) werden neue Server zu dem bestehenden Server hinzugefügt, auch bekannt unter Blade- oder Grid Computing. 6.2 Bewertung der Produkte anhand der Kriterien 6.2.1 IBM solidDB 7.0 Unterstützte Plattformen SolidDB ist mit den folgenden Plattformen kompatibel: HP-UX, Microsoft Windows Server, Linux, Solaris sowie IBM AIX. Es ist davon auszugehen, dass IBM solidDB besonders für die IBM-eigene POWER7-Prozessorgeneration optimiert ist, die auf dem IBM-Betriebssystem AIX operiert. Hochverfügbarkeit Bei solidDB kommt eine Konfiguration aus zwei unabhängigen Servern als Hochverfügbarkeitslösung zum Einsatz. Diese Lösung läuft bei IBM unter dem Namen HotStandby. Die sekundäre Datenbank läuft parallel zu der aktiven Datenbank und hält den aktuellen Datenbestand der primären Datenbank vor. Bei einem Ausfall der primären Datenbank schlägt ein Überwachungsprogramm Alarm und es erfolgt, je nach Konfiguration, ein automatischer Failover auf die sekundäre Datenbank in weniger als einer Sekunde. Abbildung 10 veranschaulicht die Hochverfügbarkeitstopologie von solidDB. 34 Abbildung 10: Hochverfügbarkeitstopologie von IBM solidDB 49 Datenwiederherstellung (Checkpoint-Files & Transaction Logs) Die Datenbank unterstützt das automatische und manuelle Erstellen von CheckpointFiles aus dem Speicher auf eine Festplatte. Um bei einer notwendigen Wiederherstellung der Datenbank einen konsistenten Zustand zu erhalten, werden bei jedem ausgeführten Checkpoint nur die bestätigten Transaktionen auf die Festplatte geschrieben. Das Intervall der Checkpoints lässt sich mit Hilfe von zwei Parametern flexibel gestalten. Zum einen kann es in einem bestimmten zeitlichen Abstand ausgeführt werden, zum anderen nach der Anzahl der geschriebenen log files. Die richtige Frequenz richtet sich nach den individuellen Bedürfnissen des Unternehmens. Während der Erstellung eines Checkpoint-Files wird die Performance der Datenbank beeinträchtigt, was sich unter Umständen für den Anwender in Form von einer verzögerten Reaktionsgeschwindigkeit bemerkbar macht. Eine hohe Frequenz hat jedoch den Vorteil, dass die Datenwiederherstellungszeit erheblich verkürzt wird, da weniger Transaktionen auf der Datenbank zwischen den einzelnen Checkpoints durchgeführt wurden und somit das Rollforward der Transaction Logs zügig durchlaufen kann. Bei solidDB ist das Schreiben der Operationen in Transaction Logs auf einen Festspeicher standardmäßig aktiviert. Dadurch wird eine vollständige Wiederherstellung bis zu dem Zeit des Störfalls gewährleistet. Andernfalls ist eine Wiederherstellung nur bis zu dem letzten Checkpoint-File möglich. Das Schreiben der Logdateien kann entweder synchron oder asynchron erfolgen, je nach den individuellen Performance- und Sicherheitsanforderungen. Performance SolidDB kann sowohl für speicherbasierte als auch für plattenbasierte Datenbanken genutzt werden. Häufig verwendete Tabellen sollten demnach in den Hauptspeicher gelegt werden, um die Zugriffsgeschwindigkeit zu verbessern. Bei ausreichend vorhandenem Speicher kann auch der gesamte Datensatz im Speicher vorgehalten werden, es handelt sich dann um eine reine In-Memory-Datenbank, als welche solidDB hier auch betrachtet wird. Wenn die IBM-Hochverfügbarkeitslösung HotStandby zum Einsatz kommt, kann der sekundäre Datenbankserver von den Anwendern mitgenutzt werden. Um die Konsistenz 49 IBM solidDB 7.0 Information Center (Abfragedatum: 26. Mai 2012). 35 zu gewährleisten, sind allerdings nur read only Operationen möglich, die vor allem bei dem Generieren von Reports zustande kommen. Weiterhin können Datenbank-Backups von der sekundären Datenbank erstellt werden. Durch die beiden vorgenannten Faktoren kann die primäre Datenbank mit vorhandenen Mitteln (Hochverfügbarkeitslösung) erheblich entlastet werden. Weitere Performanceverbesserungen sind zum Beispiel durch eine individuelle Bestimmung, wann der Sever die Transaktionsdaten in das Transaction Log schreibt, möglich. Die Einstellung „relaxed“ (asynchron) bedeutet, dass der Server die Daten nicht direkt nachdem er sie bestätigt hat in das log file schreiben muss. Der Server wartet bis er weniger stark ausgelastet ist, um dann gleichzeitig mehrere Daten in das log file zu schreiben. Diese Einstellung erhöht die Performance, aber auch das Risiko, das aktuelle Daten bei einem Crash der primären Datenbank verloren gehen können, da die Daten unter Umständen noch nicht in ein log file geschrieben wurden. Weder die sekundäre noch die primäre Datenbank haben dann die Möglichkeit diese Daten wiederherzustellen.50 Zusätzlich stehen weitere Parameter zur Verfügung, die von DatenbankAdministratoren zur Optimierung der Performance angepasst werden können. Skalierbarkeit Wie jede andere auf dem Markt erhältliche In-Memory-Datenbank lässt sich IBMs InMemory-Datenbank skalieren, um ein wachsendes Datenvolumen und mehr Benutzer zu absorbieren. Eine vertikale Skalierbarkeit wird ermöglicht, da die neuesten Technologien (64-bit, multi-core, u.w.) unterstützt werden und neue, leistungsstärkere Server eingesetzt werden können. Weiterhin lässt sich solidDB auf zwei verschiedene Arten horizontal skalieren. Zum einen kann derselbe Datenbestand auf mehreren Datenbankinstanzen gespiegelt und damit die Last und die Anwender auf mehrere physikalische Server verteilt werden. Zum anderen können sehr große Tabellen auf mehrere physikalische Server aufgeteilt werden. Mit den beiden vorgenannten Skalierungsmöglichkeiten lässt sich die Reaktionszeit einer Datenbank unter Umständen bemerkbar verbessern.51 6.2.2 Oracle TimesTen 11g Unterstützte Plattformen 50 51 Vgl. IBM solidDB 7.0 Information Center (Abfragedatum: 26. Mai 2012). Vgl. IBM SolidDB data sheet (Abfragedatum: 26. Mai 2012). 36 TimesTen unterstützt laut Herstellerangaben die folgenden Plattformen: Microsoft Windows Server, Linux, Solaris und IBM AIX. Hochverfügbarkeit Als Hochverfügbarkeitslösung von Oracle TimesTen kommt zusätzlich zur aktiven Datenbank eine Standby-Datenbank zum Einsatz. Nur die primäre Datenbank kann direkt aktualisiert werden, die Standby-Datenbank erhält die Updates über die primäre Datenbank und kann bei einem Störfall auf der primären Datenbank den aktiven Part übernehmen. Das Umschalten von der aktiven auf die Standby-Datenbank kann mittels Oracle Clusterware automatisiert werden. Oracle Clusterware entdeckt Fehler und leitet Benutzer auf die Standby-Datenbank um und startet den Datenwiederherstellungsprozess auf der primären Datenbank. TimesTen bietet nahezu die gleichen Konfigurationsmöglichkeiten wie IBM solidDB bezüglich der Replikation zwischen primärer und sekundärer Datenbank, je nach individuellem Fokus auf Performance und Hochverfügbarkeit des Unternehmens. Datenwiederherstellung (Checkpoint-Files & Transaction Logs) Die bei TimesTen ausgeführten Checkpoints sichern nur die Daten, die sich seit dem letzten Checkpoint verändert haben. Neue oder veränderte Daten werden im Checkpoint-File aktualisiert, während nicht mehr benötigte Daten in dem Checkpoint gelöscht werden. TimesTen bietet zwei verschiedene Typen von Checkpoints an: Nonblocking Checkpoints: Diese werden standardmäßig und automatisch im Hintergrund der aktiven Datenbank nach beliebiger Frequenz erstellt. Während der Ausführung müssen keine Tabellen auf der Datenbank gesperrt werden und andere Transaktionen können parallel ausgeführt werden. Die Datenbank kann ohne Unterbrechung von den Applikationen bzw. den Anwendern während eines Checkpoints genutzt werden. Blocking Checkpoints: Diese können nur manuell erstellt werden. Im Unterschied zu den Nonblocking Checkpoints werden hier alle anderen Transaktionen pausiert und erst dann wieder gestartet, wenn das Checkpoint-File fertig gestellt wurde. Dies kann zur Folge haben, dass von Anwendern ausgeführte Operationen sich verzögern, hat aber den Vorteil, dass das Checkpoint konsistent ist. Log files können je nach gewünschter Sicherheit vor Datenverlust und Performance auf verschiedene Weise auf die Festplatte geschrieben werden. Wird der Parameter Durab- 37 leCommit auf „1“ gesetzt, wird die Transaktion erst ausgeführt, wenn das log file auf die Festplatte geschrieben und selbiges bestätigt wurde. Die Transaktion ist damit garantiert dauerhaft und kann bei einem Fehler der Datenbank wiederhergestellt werden. Wird der Parameter auf „0“ gesetzt, verbessert sich die Performance der Datenbank, aber es besteht die Gefahr, dass kürzlich ausgeführte Transaktionen, die noch nicht auf die Festplatte geschrieben wurden, bei einem Problem auf der Datenbank verloren gehen. Performance Auch bei TimesTen kann bestimmt werden, wann Transaktionen in das Transaction Log geschrieben werden. Weiterhin kann die sekundäre Datenbank für read onlyTransaktionen mitgenutzt werden. Zusätzlich stehen weitere Parameter zur Verfügung, die von Datenbank-Administratoren zur Optimierung der Performance angepasst werden können.52 Skalierbarkeit TimesTen selbst lässt sich nur vertikal, durch zusätzlichen Speicher und CPUs oder einen neuen Server, skalieren. Eine horizontale Skalierung wird in der betrachteten Version nicht unterstützt. Über Umwege lässt sich jedoch auch eine horizontale Skalierung erreichen. Dies wird ermöglicht, in dem TimesTen nur als Datenbank-Cache für eine festplattenbasierte Oracle-Datenbank eingesetzt wird. TimesTen arbeitet in diesem Fall nur als Beschleuniger einer plattenbasierten Datenbank, nicht aber als die Hauptdatenbank. Da bei diesem Produktvergleich nur reine In-Memory-Datenbanken verglichen werden sollen, wird auf eine nähere Erläuterung verzichtet. 6.2.3 SAP Sybase ASE 15.7 Unterstützte Plattformen Die Sybase ASE Datenbank ist mit den folgenden Server-Plattformen kompatibel: Microsoft Windows Server, Linux, Solaris, IBM AIX und HP-UX. Hervorzuheben ist, dass alle Microsoft Windows Server Versionen die In-Memory-Version von Sybase ASE nicht unterstützen.53 Hochverfügbarkeit 52 53 Vgl. Oracle TimesTen In-Memory Database Documentation (Abfragedatum: 23. Juni 2012). Vgl. Sybase ASE 15.7 Features (Abfragedatum: 23. Juni 2012). 38 Sybase ASE unterstützt in der vorgestellten Version keine reinen In-MemoryDatenbanken. Es gibt keine Möglichkeit die primäre In-Memory-Datenbank mit einer sekundären In-Memory-Datenbank zu replizieren und dadurch eine Hochverfügbarkeitslösung zu schaffen. Datenwiederherstellung (Checkpoint-Files & Transaction Logs) Sybase ASE bietet als reine In-Memory-Datenbank keine Möglichkeit zur Datenwiederherstellung. Der Parameter, der die Dauerhaftigkeit der Datenbank bestimmt, muss bei einer Nutzung als reine In-Memory-Datenbank auf „no_recovery“ gesetzt werden. Nach einem geplanten Neustart oder ungeplanten Störfall der Datenbank sind alle Daten verloren. Transaction Logs werden weiterhin geschrieben, jedoch nicht auf einen persistenten Festspeicher, sondern nur in den Hauptspeicher, um beispielsweise fehlerhafte Transkationen rückgängig machen zu können. Performance Sybase ASE ermöglicht weder eine Replikation zu einer Standby-Datenbank noch das Ausführen von Checkpoints in seiner In-Memory-Version. Weiterhin werden die Transaction Logs auf keinen Festspeicher geschrieben. Diese Faktoren machen die Datenbank hochperformant, mit der Kehrseite der dadurch nicht mehr gewährleisteten Dauerhaftigkeit der Daten. Skalierbarkeit Wie auch die beiden anderen vorgestellten Datenbanken lässt sich die In-MemoryVersion von Sybase ASE vertikal skalieren. Ob sich die Datenbank auch horizontal skalieren lässt, konnte trotz eines eingehenden Studiums der Benutzerdokumentation nicht abschließend herausgefunden werden.54 6.3 Ergebnis des Produktvergleichs In den Kapiteln 6.2.1 bis 6.2.3 wurden die Funktionalitäten der drei In-MemoryDatenbanken anhand der Kriterien aus dem Kriterienkatalog betrachtet. In diesem Kapitel werden diese Informationen herangezogen und in eine Nutzwerttabelle übertragen, wobei das Produkt mit dem höchsten Nutzwert als das Optimale anzusehen ist. Die Kriterien der Nutzwertanalyse werden unterschiedlich gewichtet und geben in der Summe 100. Das Kriterium Performance wird mit 40 Punkten am stärksten gewichtet, 54 Vgl. SAP Sybase ASE Documentation (Abfragedatum: 23. Juni 2012). 39 da es das Hauptkriterium für den Einsatz einer In-Memory-Datenbank ist. Die restlichen 60 Punkte verteilen sich auf die unterstützten Plattformen, Hochverfügbarkeit, Datenwiederherstellung und Skalierbarkeit, wobei die Kriterien unterstützte Plattformen und Skalierbarkeit die geringste Gewichtung mit jeweils 10 Punkten erhalten. Der Erfüllungsgrad gibt an, wie gut ein Produkt das jeweilige Kriterium erfüllt. Die hier benutzte Skala reicht von 1-5 und hat die in Tabelle 4 gezeigten Bedeutungen. Wert Erfüllungsgrad 1 nicht erfüllt 2 teilweise erfüllt 3 erfüllt 4 gut erfüllt 5 sehr gut erfüllt Tabelle 4: Bedeutung Erfüllungswerte der Nutzwertanalyse Die Gewichtung mit der Erfüllung multipliziert ergibt den Nutzwert. Die Summe der einzelnen Nutzwerte eines Produktes ergibt das Ergebnis und zeigt auf, welches der drei Produkte die Anforderungen am besten erfüllt. Die Nutzwertanalyse für die drei verglichenen In-Memory-Datenbanken ist in Tabelle 5 ersichtlich. Nach der Nutzwertanalyse erfolgt eine Erläuterung für die eingetragenen Erfüllungswerte je Kriterium und Datenbank. Kriterien Gewichtung Unterstützte Plattformen Hochverfügbarkeit Datenwiederherstellung Performance Skalierbarkeit Gesamt 10 20 20 40 10 100 IBM solidDB 7.0 Oracle TimesTen 11g Sybase ASE 15.7 Erfüllung Nutzwert Erfüllung Nutzwert Erfüllung Nutzwert 5 50 4 40 4 40 4 80 5 100 1 20 4 80 4 80 1 20 3 120 3 120 5 200 4 40 2 20 2 20 370 360 300 Tabelle 5: Nutzwertanalyse In-Memory-Datenbaken Unterstützte Plattformen Alle drei Produkte sind im Wesentlichen mit den wichtigsten Betriebssystemen kompatibel. IBM solidDB unterstützt alle wichtigen Server-Plattformen und erreicht die höchste Punktzahl. Oracle TimesTen und Sybase ASE werden von jeweils einer Plattform nicht unterstützt und erhalten Abzüge. 40 Hochverfügbarkeit Die Hochverfügbarkeitslösungen von IBM und Oracle werden mittels Replikation auf eine Standby-Datenbank realisiert. Die jeweiligen Lösungen beinhalten auch ein Überwachungsprogramm, das Fehler erkennt und, wenn nötig, einen automatischen Failover von der primären auf die Standby-Datenbank durchführt. Beide Anbieter erfüllen die gestellten Anforderungen, wobei Oracle mehr Konfigurationsmöglichkeiten mit dem Fokus auf Performance und Datensicherheit bietet und daher die Höchstpunktzahl erhält. Die In-Memory-Version von Sybase ASE bietet in der untersuchten Version keine Hochverfügbarkeitslösung, die Anforderung ist damit nicht erfüllt. Datenwiederherstellung (Checkpoint-Files & Transaction Logs) TimesTen und solidDB erfüllen alle gestellten Anforderungen an die Datenwiederherstellung. Checkpoint-Files werden inkrementell erstellt, das heißt es werden nur veränderte Daten gesichert. Weiterhin werden log files auf einen Festspeicher geschrieben. Beide Hersteller bieten vielfältige Konfigurationsmöglichkeiten und erfüllen die Anforderungen damit gut. Sybase unterstützt als In-Memory-Datenbank keine Datenwiederherstellung und muss bei einem Störfall von neuem aufgesetzt werden. Die Daten der Datenbank gehen bei diesem Prozess verloren. Performance Es ist davon auszugehen, dass alle drei Produkte ihre diskbasierten Konkurrenten in Bezug auf die Performance um ein Vielfaches übertreffen. Hervorzuheben ist das Produkt von Sybase, welches komplett auf Performance ausgelegt ist. Dieses wird durch die nicht vorhandene Hochverfügbarkeitslösung und die fehlende Möglichkeit der Datenwiederherstellung ersichtlich. Die Sicherungsmechanismen bremsen auch eine InMemory-Datenbank aus, wenn beispielsweise das notwendige Schreiben von Transaction Logs auf den Festspeicher betrachtet wird. Auf Grund des nach wie vor notwendigen Schreibens auf einen Festspeicher erhalten die Produkte von IBM und Oracle zwei Punkte Abzug. Durch das Fehlen dieser Schutzmechanismen ist Sybase ASE rein von den technischen Daten her die In-Memory-Datenbank mit der besten Performance. Skalierbarkeit Alle drei Datenbanken lassen sich vertikal skalieren. Eine horizontale Skalierung wird laut dem Kenntnisstand des Autors nur von solidDB unterstützt, womit solidDB diesen Vergleich für sich entscheidet. TimesTen lässt sich nur als Cache genutzt horizontal 41 skalieren. Zu den horizontalen Skalierungsmöglichkeiten von Sybase ASE konnte der Autor keine Informationen ausfindig machen. Das Ergebnis der Nutzwertanalyse zeigt, dass die Produkte von IBM und Oracle einen erheblichen Vorteil gegenüber der Datenbank von Sybase haben, wobei IBM mit 370 Punkten noch einen kleinen Vorsprung gegenüber Oracle mit 360 Punkten aufweist. Der Gewinner der Nutzwertanalyse ist damit IBM solidDB, zusätzlich erfüllt es als einziges Produkt alle fünf gestellten Kriterien. Sybase dagegen liegt mit lediglich 300 Punkten deutlich hinter den beiden anderen Produkten. Diese In-Memory-Datenbank besticht lediglich durch die sehr gute Performance. Die Kriterien Hochverfügbarkeit, Datenwiederherstellung und Skalierbarkeit werden nicht oder nur teilweise unterstützt. Die folgende Abbildung 11 zeigt anhand eines Netzdiagramms die Stärken und Schwächen der drei verglichenen In-Memory-Datenbanken und verstärkt die im vorigen Absatz getätigten Aussagen. Die Gewichtung findet hier keine Beachtung. SolidDB und TimesTen sind starke Allrounder, mit leichten Schwächen bei der Performance, während Sybase ASE ihre eindeutige Stärke in der Performance hat, bei den meisten anderen Kriterien aber nur mäßig abschneidet. Abbildung 11: Netzdiagramm In-Memory-Datenbanken 42 7. Fazit Global agierenden Unternehmen bleibt oft nichts anderes übrig, als sich einem immer stärker werdenden Wettbewerb zu stellen. Nischenmärkte werden mit der zunehmenden Globalisierung zur Seltenheit und so müssen sich Unternehmen von ihrer Konkurrenz absetzen. Die angebotenen Güter und Dienstleistungen müssen hinsichtlich der Qualität, der Vielfalt und des Preises konkurrenzfähig sein. Die IT kann bei diesem Unterfangen als Unterstützer und sogar als Wegbereiter dienen - die richtigen Prozesse, Technologien und Mitarbeiter vorausgesetzt. Durch den Einsatz von In-Memory-Computing können sich Unternehmen von der Konkurrenz absetzen und optimierte Güter und Dienstleistungen zu einem niedrigeren Preis anbieten, in dem Daten beispielsweise schneller prozessiert (z.B. Aufträge) und analysiert (z.B. Kaufverhalten) werden. Während das Erstellen eines kritischen Statusreports zum Kaufverhalten bei Unternehmen A beispielsweise zwei Tage dauert, kann das Konkurrenzunternehmen B, bei dem eine In-Memory-Datenbank zum Einsatz kommt, bereits nach einer Stunde auf den gleichen Report zugreifen. Das gibt dem Unternehmen B zwei Tage Vorsprung, um beispielsweise auf ein verändertes Kaufverhalten eingehen zu können und es kann damit letztendlich dem Unternehmen A Marktanteile abnehmen. Auf Basis der Nutzwertanalyse kann angenommen werden, dass die IBM In-MemoryDatenbank solidDB als optimal angesehen wird, da hier alle vorgenannten Kriterien erfüllt werden. Dagegen wird bei den anderen Produkten mindestens ein Kriterium nicht oder nur teilweise erfüllt. In der Praxis kann jedoch nicht pauschal gesagt werden, dass diese Lösung für alle Unternehmen optimal ist. Es muss hier je nach Unternehmen eine genaue Analyse erfolgen, welche Kriterien für das jeweilige Unternehmen wichtig sind. Es müssen alle Stärken und Schwächen der einzelnen Produkte betrachtet und dann anhand der individuellen Bedürfnisse eine Entscheidung getroffen werden. Selbst die in der Nutzwertanalyse schlecht abgeschnittene Datenbank Sybase ASE kann für den Einsatz bestimmter Anwendungen Sinn machen. Für Unternehmen, die Anwendungen einsetzen, welche Daten nur für einen kurzen Zeitraum benötigen und damit nicht dauerhaft sein müssen, kann diese Datenbank auf Grund der herausragenden Performance die beste Lösung sein. Als Beispiel kann der Warenkorb bei einem Online-Shop genannt werden. Nach einem Check-Out zum Bezahlvorgang wird der Warenkorb nicht mehr 43 benötigt. Es ist davon auszugehen, dass die Entwicklung von In-Memory-Datenbanken in den nächsten Jahren verstärkt vorangetrieben wird. Mit einem gleichzeitig vermehrten Praxiseinsatz sind vielfältige Neuerungen und Verbesserungen in diesem Bereich zu erwarten. Abschließend kann gesagt werden, dass jedes Unternehmen für sich entscheiden muss, welche der hier verglichenen bzw. auf dem Markt verfügbaren In-MemoryDatenbanken für einen Einsatz in Frage kommt. Es kann durchaus möglich sein, dass ein Einsatz für Unternehmen zu dem jetzigen Zeitpunkt oder generell keinen Sinn macht. Soll die vorhandene IT-Landschaft dennoch aufgewertet werden, kommt alternativ ein Upgrade der vorhanden IT-Landschaft (hardware- und softwareseitig) in Frage, um der steigenden Informationsflut und den stetig wachsenden Anforderungen des Business gerecht zu werden. Allerdings bleibt der Einsatz von In-Memory-Datenbanken eine zukünftige Option für Unternehmen, wenn auf mehr Erfahrungen zurückgegriffen werden kann. 44 Literaturverzeichnis Faeskorn-Woyke, H./Bertelsmeier, B./Riemer, P./Bauer, E. (2007): Datenbanksysteme: Theorie und Praxis mit SQL2003, Oracle und MySQL, München, S. 19, S. 22. Färber, F./Jäcksch, B./Lemke, C./Große, P./Lehner, W. (2010): Hybride Datenbankarchitekturen am Beispiel der neuen SAP In-Memory-Technologie, entnommen aus: Datenbank-Spektrum: Zeitschrift für Datenbanktechnologie und Information Retrieval, Band 10, Heft 2, Berlin-Heidelberg, S. 81. Groth, H./Forster, A. (2011): SAP In-Memory: Decision Making at the Speed of Thought (siehe: SAP In-Memory - Decision Making at the Speed of Thought.pdf, S. 10). Kannengiesser, C./Kannengiesser, M. (2007): PHP 5/MySQL 5, 2. Auflage, Poing, S. 613 f. Kemper, A./Eickler, A. (2011): Datenbanksysteme: Eine Einführung, 8. Auflage, München, S. 19 ff, S. 71, S. 203 ff, S. 289, S. 529 ff, S. 668. Krueger, J./Grund, M./Tinnefeld, C./Eckart, B./Zeier, A./Plattner, H. (2010): Hauptspeicherdatenbanken für Unternehmensanwendungen: Datenmanagement für Unternehmensanwendungen im Kontext heutiger Anforderungen und Trends, entnommen aus: Datenbank-Spektrum: Zeitschrift für Datenbanktechnologie und Information Retrieval, Band 10, Heft 3, Berlin-Heidelberg, S. 1 f, S. 4 f, S. 7. Nüßer, W./Stein, M./Hass, A./Kugelberg, T./Kley, F. (2006): SAP on Linux: Architektur, Implementierung, Konfiguration, Administration, Berlin-Heidelberg, S. 36 f, S. 399 f, S. 409 f. Ott, J./Stirnimann, R. (2012): In-Memory-Datenbanken im Vergleich, entnommen aus: Computerwoche 3/12 (siehe: In-Memory-Datenbanken im Vergleich.pdf, S. 1, 3, 4). Plattner, H. (2009): A Common Database Approach for OLTP and OLAP Using an InMemory Column Database (siehe: A Common DB Approach for OLTP and OLAP Using an In-Memory Column DB.pdf, S. 6 f). 45 Plattner, H./Zeier, A. (2011): In-Memory Data Management: An Inflection Point for Enterprise Applications, Berlin-Heidelberg, S. 9, S. 15, S. 22. Stirnimann, R./Ott, J. (2011): In-Memory Datenbanken auf den Zahn gefühlt! (siehe: In-Memory Datenbanken auf den Zahn gefühlt.pdf, S. 6 f). 46 Sonstige Quellen http://www.computerwoche.de/software/software-infrastruktur/2369870 (Abfragedatum: 27. Dezember 2011, siehe: Oracle dominiert - Datenbankeinsatz im SAPUmfeld.pdf). Stangneth, H. (2011): http://www.de.capgemini.com/it-trends-blog/2011/07/5- bereiche-denen-echtzeit-echte-vorteile-verschafft (Abfragedatum: 5. Mai 2012, siehe: 5 Bereiche, in denen Echtzeit echte Vorteile verschafft - IT-Trends-Blog - Capgemini.pdf). http://docs.oracle.com/cd/E11882_01/timesten.112/e21631/availability.htm (Abfragedatum: 18. Juni 2012, siehe: Oracle Data Availability and Integrity.pdf). http://docs.oracle.com/cd/E21901_01/welcome.html (Abfragedatum: 23. Juni 2012, siehe: Oracle TimesTen In-Memory Database Documentation.pdf). http://www.exasol.com/exasolution/vorteile.html (Abfragedatum: 6. Mai 2012, siehe: EXASOL - Vorteile - Das Richtige für alle im Unternehmen.pdf). http://www.isreport.de/news-events/news/archiv/2010/08/05/article/sap-appliancesoll-erp-datenbank-abloesen.html (Abfragedatum: 13. November 2011, siehe: SAPAppliance soll ERP-Datenbank ablösen.pdf). http://www.ibm.com/common/ssi/cgibin/ssialias?infotype=PM&subtype=SP&htmlfid=POD03031DEDE&attachment= POD03031DEDE.PDF&appname=STGE_PO_PO_DEDE_SP (Abfragedatum: 10. Januar 2012, siehe: IBM Power 770 Server Datenblatt.pdf). Jackson, J. (2010): http://www.infoworld.com/d/data-management/sybase-releasesits-first-in-memory-database-827 (Abfragedatum: 12. Mai 2012, siehe: Sybase releases its first in-memory database.pdf). http://infocenter.sybase.com/help/index.jsp?docset=/com.sybase.infocenter.help.ase .15.7/title.htm&docSetID=1797 (Abfragedatum: 23. Juni 2012, siehe: SAP Sybase ASE Documentation.pdf). 47 http://www.oracle.com/us/corporate/customers/customersearch/shanghai-sihua-1berkeley-db-ss-488833.html (Abfragedatum: 7. Mai 2012, siehe: Oracle_Shanghai Sihua_Erfolgsgeschichte.pdf). http://openbook.galileocomputing.de/linux/linux_05_001.htm#mj5498e5c72106a7b 330c22ded68392cc2 (Abfragedatum: 25. November 2011, siehe: Linux - Das umfassende Handbuch - Galileo Openbook.pdf). http://pic.dhe.ibm.com/infocenter/soliddb/v7r0/index.jsp (Abfragedatum: 26. Mai 2012, siehe: IBM solidDB 7.0 Information Center.pdf). http://public.dhe.ibm.com/common/ssi/ecm/en/imb14128usen/IMB14128USEN.PD F (Abfragedatum: 26. Mai 2012, siehe: IBM SolidDB data sheet.pdf). http://www.sap.com/austria/about/events/worldtour10/assets/2010/A_3_OMV_BW A_SAP%20World%20Tour%202010.pdf (Abfragedatum: 13. November 2011, siehe: A_3_OMV_BWA_SAP World Tour 2010.pdf). http://www.sap-kunden.de/erfolge/wp-content/uploads/CSS_Charite_de.pdf (Ab- fragedatum: 6. Mai 2012, siehe: SAP_Charite Berlin_Erfolgsgeschichte.pdf). http://www.sybase.com/files/Success_Stories/UAM-Customer-CS.pdf (Abfrageda- tum: 7. Mai 2012, siehe: Sybase_Universität_Erfolgsgeschichte.pdf). http://www.sybase.com/files/Data_Sheets/Sybase_ASE_15.7_Features_DS.pdf (Abfragedatum: 23. Juni 2012, siehe: Sybase ASE 15.7 Features.pdf). Foley, M.-J. (2012): http://www.zdnet.com/blog/microsoft/microsoft-hey-were-anin-memory-database-player-too/12393 (Abfragedatum: 28. April 2012, siehe: Microsoft Hey, we're an in-memory database player, too.pdf). 48 Eidesstattliche Versicherung Hiermit versichere ich, dass die vorliegende Arbeit von mir selbstständig und ohne unerlaubte Hilfe angefertigt worden ist, insbesondere dass ich alle Stellen, die wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen sind, durch Zitate als solche gekennzeichnet habe. Ich versichere auch, dass die von mir eingereichte schriftliche Version mit der digitalen Version übereinstimmt. Weiterhin erkläre ich, dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat. Ich erkläre mich damit nicht einverstanden, dass die Arbeit der Öffentlichkeit zugänglich gemacht wird. Ich erkläre mich damit einverstanden, dass die Digitalversion dieser Arbeit zwecks Plagiatsprüfung auf die Server externer Anbieter hochgeladen werden darf. Die Plagiatsprüfung stellt keine Zurverfügungstellung für die Öffentlichkeit dar. Steinbach, den 15. Juli 2012 ____________________
