Beschreibung und Einsatz von In-Memory-Computing

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Bremen
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Dipl.-Phys. Frank Guderwarning.png„Dipl.-Phys. Frank Guder“ gehört nicht zu den möglichen Werten dieses Attributs (Dipl-Inf._(FH)_Jörg_Muschiol, Dr._Vladimir_Stantchev, Prof._Dr._Ralf_Hötling, Prof._Dr._Uwe_Kern, Dipl-Inf._(FH)_Christian_Schäfer, Prof._Dr._Gregor_Sandhaus).
Typ: Fallstudienarbeit
Themengebiet:
Autor(en): Große Bley, Oliver, Nee, Mathias, Jungclaus, Lars
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS12
Studiensemester: 2
Bearbeitungsstatus: Bearbeitung abgeschlossen
Prüfungstermin: 27.7.2012
Abgabetermin: 13.7.2012


Inhaltsverzeichnis

1 Einleitung

Erzeugt von sozialen Netzen, einer stark wachsenden Anzahl von Mobilgeräten und der Digitalisierung des menschlichen Lebens bricht eine gewaltige Datenflut auf Unternehmen ein. Neudeutsch wird diese Datenflut auch als "Big-Data" bezeichnet. Um diese Informationen zu Verarbeiten und zu Nutzen reicht die bloße Vergrößerung der IT-Parameter - mehr Speicher, bessere Server etc. nicht aus. Stattdessen muss die gesamte IT-Infrastruktur neu betrachtet werden und neue Lösungen an die Anforderung gefunden werden.[1]


Von der Storage- und Netzwerktechnik über die Datenbanksoftware bis hin zur Optimierung der einzelnen Verarbeitungsprozesse.


Genau hier setzt die "In-Memory Technologie" ein um durch höhere Zugriffsgeschwindigkeiten die Datenverarbeitung signifikant zu beschleunigen.


Als Beispiel ist u.A. auch vor kurzen das Business-Netzwerk Xing diesen Trend gefolgt, da die wachsende Anzahl von Nutzer und Funktionsumfang das bisherige Datenbanksystem an seine Grenzen gebracht hat. Für weiter Information zum Xing-Portal[2]

1.1 Thema

Das Thema "In-Memory" zeichnen sich dadurch aus, dass primär der Arbeitsspeicher (RAM) eines Computers als Datenspeicher genutzt wird.

In-Memory-Technik gibt es bereits seit einigen Jahren, war aber bis dato eher ein Nischendasein. Vor allem Unternehmen, in denen es auf Echtzeit ankommt, setzen diese Technik ein, zum Beispiel Telekommunikationsanbieter, soziale Netzwerke und Handelsplattformen. Zu den bekanntesten In-Memory-Datenbanksystemen gehört u.A. das Produkt "HANA" vom Softwarehersteller SAP und TimesTen von Oracle.

1.2 Problemstellung

Durch die ständige und explosionsartige Ansammlung von vielen unstrukturierten Daten & Informationen werden immer größere Herausforderungen an die Verarbeitung, Analyse und Strukturierung gestellt. Dieses soll möglichst in Echtzeit ausgeben werden und zum Abruf zuverlässig zu Verfügung stehen. Dieses kann in naher Zukunft nicht mehr durch reguläre Speichersysteme oder Datenbanksysteme abgeleistet werden, da die Daten von den Plattensystemen zur CPU transportiert, dort verarbeitet und die Resultate wieder zurück in den Storage geschrieben werden. Bei Massendaten stößt dieses Verfahren an seine Grenzen, da diese Verarbeitung viel zu langsam abläuft und so zu "bottlenecks" führen kann.

1.3 Zielsetzung

In dieser Arbeit wird das Thema In-Memory-Computing, dessen Einsatzbereiche und die Technologie näher beschrieben.

1.4 Aufbau

Die Seminararbeit teilt sich in drei grundlegende Bereiche auf. Beginnend mit den Grundlagen zu Hard- und Software über die entsprechenden IN-Memory-Technologien bis hin zu den Einsatzmöglichkeiten sowie 2 praxisbezogenen Beispielen des Softwareproduktes HANA aus der Wirtschaft. Abgerundet wird die Arbeit mit eigens durchgeführten Benchmark-Test zwischen IN-Memory Datenbank und einer herkömmlichen festplattenbasierten Datenbankvariante.

2 Grundlagen

Das Thema In-Memory-Computing stellt für die verschiedenen Anforderungen bestimmte Herausforderungen an die Hardware und Applikationen. Hier werden die Grundlagen näher Beschrieben und kurz erläutert, die in dem Bereich Technologien vertieft werden.

2.1 Hardware

Durch die ständige Weiterentwicklung der Hardwarehersteller und der rasanten Entwicklung der IT-Infrastruktur werden die entsprechenden Speichersysteme immer günstiger und bekommen immer höhere Kapazitäten. Somit ist es mittlerweile möglich, einen einzelnen Server durch große DRAM Module auf mehrere hundert GB Arbeitsspeicher aufzurüsten. Gleiches gilt in der CPU Entwicklung - in den aktuellsten Information der Multi-Core Entwicklung spricht man bei Intel von 10 Kernen innerhalb eines Prozessors.[3] SAP bietet sogar in Kooperation mit HP und Fujitsu aktuelle Server im "TByte RAM Bereich" mit mehreren CPUs und Kernen an.[4]

Durch die Nutzung und Kooperation von verschiedenen Speichersystemen in den Serversystemen werden für jede Anforderung und Vorhaltezeiten entsprechende Speicher verwendet. In der aktuellen und zeitkritischen Verarbeitung liegen die Daten direkt im RAM Speicher. Dieser ist der schnellste und bietet die beste Grundlage für analytische Echtzeitanwendungen. Für Daten die die Größe des RAMs übersteigen werden die Daten über eine PCIe-Flash/SSD Speicherkarte gecached und anschließend an die lokale Festplatte, die auf der SAS/SSD Technologie basiert abgespeichert. Anschließend wird über SAN-Technologie die Informationen im Storagesystem abgespeichert und für die Langzeitarchivierung abgelegt.


Die Tabelle verdeutlich In-Memory:

Anwendungsart Speicherart Geschwindigkeit[5]
Echtzeit RAM bis 38400 MB/s
Cache PCIe -Flash/SSD bis 509 MB/s
Speicherung lokal HDD - SAS/SSD bis 150 MB/s
Langzeitspeicherung / Archivierung Storage bis ~150 MB/s (eine HDD)

2.2 Software

In-Memory bringt für viele Software-Systeme einen Umbruch.


Informationen werden in Echtzeit erstellt, zu Verfügung gestellt und sollen schnell wieder abgerufen werden. In-Memory hat nicht nur was mit Hardware zu tun, was zwar die Grundlage für diese Technologie ist sondern bietet mit dem entsprechenden Softwaregegenstück ganze neue Möglichkeiten durch die unschlagbare Geschwindigkeit der Echtzeit-Auswertung von Big-Data.


Wenn wir hier von Big-Data sprechen benötigen wir auch eine Software die diese Daten verarbeiten kann. Somit gelangt man in den Bereich der Enterprise-Solutions. Durchs Web kreisen fast ausschließlich Datenbanken, die diese Technologie nutzen – bezeichnet auch als "In-Memory Datenbank".


Hierbei liegt der Fokus auf 4 verschiedene Produkte. 2 Produkte lassen sich bereits bei kleinen bis mittelständigen Unternehmen einsetzen, wobei zwei davon klar in den High-End Bereich zum Einsatz kommen.


TimesTen, ein Produkt vom Hersteller Oracle spielt aufgrund seiner umfangreichen Funktion und der höheren Preiskalkulation klar im High-End Bereich. Der Hersteller bietet das Produkt für Linux/Unix und auch Windows an.

Eine weitere Alternative in diesem Segment ist das Produkt SolidDB von IBM. Diese ist für die Plattform Linux, Windows und Solaris verfügbar.


In der Kategorien der mittelständigen und kleinen Unternehmen sind die Produkte HSQLDB und SQLite zu finden. Beide sind als OpenSource Variante verfügbar und daher sehr lukrative Datenbankprodukte. Im Gegensatz zu SQLite ist HSQLDB eine komplett in Java geschriebene Datenbank.


Die wohl bekannteste und größte Lösung ist eine All-in-One Lösung von Hersteller SAP mit dem Produkt HANA (High Performance Analytic Appliance). Hier liegt der Fokus klar auf Business-Analytics.

3 Technologien

Nachdem sie im vorrangegangen Abschnitt die Hardware und Software erläutert wurden. Geht es diesen Abschnitt um die Technologien, welche bei den In-Memory-Computing benutzt werden.

Beim In-Memory-Computing gibt es mehrere Technologien die eingesetzt werden, zum Beispiel In-Memory-Analytics und In-Memory-Datenbanken. In den nachfolgenden Punkten werde ich diese Technologien etwas genauer erläutert.


3.1 In-Memory-Analytics

Bei der In-Memory-Analytics geht es um die schnelle Verarbeitung großer Daten in der Business Intelligence (BI). Dabei ist es wichtig schnell diese Daten zur Verfügung zu stellen, damit man gegebenenfalls seine Unternehmens Strategie anpassen kann. Bei der In-Memory Variante werden die Lesezugriffe auf die Festplatte verringert bzw. gestoppt. Dieses bringt einen Performance-Gewinn, denn der Zugriff auf die Daten im RAM ist um den Faktor 10000 mal schneller als der Zugriff auf der Festplatte.[6] Denn bei RDBM's ist der Flaschenhals, des Zugriffs auf die Daten, die Lese-, Schreibe- und die Reaktionsgeschwindigkeit der Festplatte. Dieser kann auch mit SSD entgegengewirkt werden, aber diese SSD's haben nur eine begrenzte Anzahl an Schreibvorgängen. Wie schon vorher in der Ausarbeitung dargestellt ist auch die Größe der Datenbanken ein Problem. Bei den In-Memory-Analytics werden meistens auch In-Memory-Datenbanken benutzt, welche nun noch genauer Erklärt werden.

3.2 In-Memory-Datenbanken

Abbildung 1
Abbildung 1
Bei den meisten Firmen ist die Datenhaltung der Kundeninformationen die Aufgabe der relationalen Datenbank. Dort werden strukturierte Daten in Tabellen bzw. Datensätze in Feldern auf der Festplatte oder Server gespeichert. Werden Abfragen an die Datenbank gestellt müssen die Daten meist von der Festplatte gelesen werden.[7]

Eine wesentliche kürzere Antwortzeit sollen die In-Memory-Technologien bringen. Ihr Ansatz ist es die ganze Datenbank in den RAM zu laden und die Abfragen direkt aus dem Memory zu beantworten. Da die Daten in eine Memory Datenbank auch komprimiert werden, lässt sich die Größe der Datenbank zu ein Zehntel verringern.[7]

Bei klassischen Datenbanken werden für die BI oft OLAP (On-Line Analytical Process)-Lösungen angeboten. Diese sind meistens nötig, um zum Beispiel Auswertungen des Unternehmens zu machen. Da diese Abfragen die Datenbank sonst so beschäftigen würden, dass keine anderen Operationen mehr möglich wären. So etwas wird manchmal gemacht, wenn die Datenbanken nicht gut modelliert wurden. Bei der Fütterung dieser OLAP-Cubes werden viele Abfragen generiert und gespeichert, welches viel Zeit in Anspruch nehmen kann. Dieses ist der Flaschenhals dieser Anwendungen, natürlich werden diese Operationen nicht gebraucht wenn es sich um gut modellierte Datenbanken handelt. Diese Operationen werden nicht bei In-Memory-Datenbanken gebraucht, weil diese schneller die angeforderten Daten zurückliefern.[8]

Abbildung 2
Abbildung 2
Bei den IMDB gibt es einige Probleme, den der RAM ist nur ein flüchtiger Speicher. Wenn bei den Server die Spannungsversorgung ausfällt sind die Daten die im Memory waren verloren. Deswegen arbeiten große Datenbankhersteller mit zyklischen Speicherungen (Snapshots Images) auf der Festplatte. Außerdem werden Transaction-Logs auf die Festplatte geschrieben. In diesen Transaction-Logs werden Änderungen der Datenbank geschrieben, zum Beispiel Wert x auf y geändert. Meistens werden zwei Datenbank-Server, im Active-Standby-Cluster, für eine Datenbank eingesetzt, welche sich ein Storage-System teilen. Nachdem der eine Server die Stromversorgung verloren hat, ließt der zweite die Snapshots und Action-Logs auf der Festplatte und kann so die Daten von der vorher aktiven Server wieder herstellen. Die Daten die zum Zeitpunkt des Absturzes verarbeitet wurden lassen sich nicht wieder herstellen, wenn zum Beispiel bei den Verlust der Stromversorgung einen Update der Daten ausgeführt wurde. Deswegen werden auch Funktionen in die Applikation eingesetzt die dieses erkennen und gegebenenfalls die Anfrage erneut ausführen.[7]


Es gibt bei den auf den Markt befindlichen IMDB viele Gemeinsamkeiten was das Prinzip betrifft:

  1. Datenhaltung: Beim Starten werden alle Daten in den RAM gelesen um keine Daten nachladen zu müssen
  2. Checkpoint Files/Snapshot Images: Geänderte Daten werden in regelmäßigen Abständen mit der Festplatte abgeglichen.
  3. Transaction-Logs: Zwischen den einzelnen Checkpoint Files werden laufende Änderungen in diese Logs geschrieben um nach einen Crash einen Rollforward nachdem zu können.
  4. ACID-Prinzip: Wie herkömmliche RDBMS können auch IMDB sämtliche Daten nach dem ACID-Prinzip (Atomarität (Abgeschlossenheit), Konsistenzerhaltung, Isolation (Abgrenzung), Dauerhaftigkeit) verarbeiten.
  5. Hochverfügbarkeit: Es werden meistens mehrere Datenbank-Server für eine Datenbank benutzt, um Datenreplikationen sicherzustellen.
  6. Direct-Connect: Die Applikation kann direkt die In-Memory-Datenbank in ihren Adressbereich laden, um jeglichen Overhead zu vermeiden.


Zum Abschluss dieses Kapitels noch eine kurzen Vergleich der Datenbanksysteme In-Memory und On-Disk:

In-Memory On Disk
Applikation und In Memory auf gleichem Server, verbunden mit "Direct Connect". Verschiedene Server für Applikation und Datenbank.
Keine blockierenden Disk-I/O-Operationen beim Schreibvorgang in die Datenbank (Commit), da Verarbeitung im Hauptspeicher. Blockierende I/O-Operation beim Commit, da der Log Buffer auf die HDD geschrieben wird.
Verlust von "Committed"-Daten möglich, da nur im Hauptspeicher (Log Buffer). AKID (Atomarität, Konsistenz, Isoliertheit und Dauerhaftigkeit) garantiert.
Wenig Backup-Features, Datenverlust beim Server-Crash möglich. Umfangreiche Backup-Features, Restore/Recover ohne Datenverlust.
Wenige Analyse-Tools bei Performance Problemen (keine SQL Elapsed Time). Umfangreiche Tools und Reporting Möglichkeiten.
Keine parallelen Abfragen (Parallel Query). Parallel Query vorhanden/möglich.
Bisher wenig Wissen vorhanden. Viel Wissen vorhanden.

4 Einsatz von In-Memory-Computing

In-Memory-Computing bietet zwar verschiedene Technologien, die bedeutendste ist aber mit Abstand die In-Memory-Datenbank (im Folgenden IMDB genannt), für die im Folgenden auf dem Markt verfügbare Software sowie deren Einsatz betrachtet wird.

4.1 In-Memory Datenbank Software

Bereits seit 1984 gibt es In-Memory-Datenbanken, eines der ersten verfügbaren Produkte war die IBM TM1 - OLAP Datenbank. Doch führten Einschränkungen im Betriebssystem und verfügbarer Hardware dazu, dass diese Systeme Ihre Vorteile nicht nutzen konnten. In den letzten Jahren wurden diese Einschränkungen allmählich aufgehoben und es waren verschiedene IMDB Lösungen der großen Anbieter am Markt erhältlich.

IBM stellt 2008 SolidDB als IMDB vor, die die Datenintegrität durch zwei separate aber dauerhaft synchronisierte Datenbankkopien sowie durch permanentes Logging auf den Festplatten. Im Falle von Datenverlust kann die komplette Datenbank innerhalb weniger Sekunden ohne Datenverlust wiederhergestellt werden.[9]

Oracle hat TimesTen in 2009 als IMDB vorgestellt, die als Cache für die traditionale RDBMS oder als Standalone Datenbank genutzt werden kann. TimesTen nutzt Transaktions-Logging und Datenbank-Prüfpunkte als Maßnahmen zur Datenintegrität.[10]

2010 stellte SAP HANA als Datenbanktechnologie vor, bei der es sich um eine High Performance Analytic Appliance handelt und die in Kapitel 4.2 genauer betrachtet wird.

SQLite ist eine Programmbibliothek, die ein relationales Datenbanksystem enthält und auf Grund vieler Datenbankschnittstellen die am meisten verwendete SQL Datenbank der Welt ist.[11] Um SQLite Datenbanken im Hauptspeicher zu nutzen kann man in der Datenbankverbindung die ":memory"-Option verwenden. Sobald man die Datenbankverbindung schließt wird die Datenbank auf die Festplatte geschrieben.[12]

In-Memory-Datenbanken werden immer populärer und finden Ihren Einsatz hauptsächlich in den Bereichen Zeitkritische Anwendungen, Echtzeit-Datenausgabe sowie Analyse von großen Datenmengen. So verwenden z.B. Google, Twitter und Facebook alle angepasste In-Memory-Datenbanken um schnelle Antwortzeiten bei immer weiter ansteigenden Datenmengen zu gewährleisten.[13]

4.2 SAP HANA

SAP HANA ist eine Datenbanktechnologie von SAP, bei der es sich um eine flexible, für verschiedene Zwecke geeignete und datenquellenagnostische In-Memory-Appliance handelt, bei der SAP-Softwarekomponenten von führenden SAP-Hardwarepartnern auf optimierter Hardware bereitgestellt und ausgeliefert werden.

Hana wurde von SAP 2010 vorgestellt und im direkten Praxiseinsatz mit Kunden wie z.B. Coca Cola Hellenic, der Future Group und Hilti entwickelt, um sehr große Datenmengen in Millisekunden verarbeiten und analysieren zu können.

Bei HANA kommen verschiedene Techniken im Bereich von Hard- und Software zum Einsatz. So wird auf der Software-Seite ein Hybrid aus In-Memory-Datenbanken eingesetzt, dass Zeilen-basierte, Spalten-basierte und Objekt-basierte Datenbanktechnologien miteinander kombiniert. Die IMDB wurde auf Parallelprozesse und den Nutzen moderner Mehrkern-CPUs optimiert. Auf der Hardwareseite wird möglichst viel Festplattenspeicher durch CPU-Cache und Hauptspeicher ersetzt, um schnellere Zugriffszeiten zu erhalten.[14]

SAP HANA ist seit knapp über einem Jahr auf den Markt und wird inzwischen bei 354 Kunden mit 150 erfolgten Implementierungen eingesetzt. 16 Kunden konnten dabei Ihre Leistung im Gegensatz zu vorherigen Festplatten-basierten Datenbanken um das 10.000fache steigern. Inzwischen nutzen 64000 Endanwender SAP HANA, es gibt 2000 Instanzen für Amazon Web Services und 1791 ausgebildete Consultants.

Beim Einsatz von SAP HANA wird eine 20fache Datenkompression erreicht, sodass Abfragen aus dem Business Warehaus in 300-500 Millisekunden möglich sind und Ad-hoc Abfragen 800 Millisekunden bis 2 Sekunden benötigen. Es wird eine Einspielrate von 770.000 Datensätzen pro Sekunde erreicht und um diese Datenmengen zu speichern, kann SAP HANA bis auf 500TB Hauptspeicher skaliert werden.[15]

Um die Verarbeitung von Big Data in Echtzeit zu ermöglichen, benötigt die Appliance sehr gute Hardware, wie die von SAP empfohlenen Hardwarekomponenten zeigen:

  • CPU: Intel Westmere-EX E7 mit 2, 4 oder 8 CPUs (20, 40 oder 80 Kerne)
  • RAM: 128 GB pro verwendeter CPU
  • Festplatte: Entweder SAS oder NAS, je nach Konfiguration

Eine mittlere Appliance sollte laut SAP 4 CPUs mit 40 Kernen und 512 GB RAM haben.[16]

4.2.1 SAP HANA Beispiel 1 - Hana Oncolyzer

Abbildung 3
Abbildung 3

Bei der Forschungsinitiative HANA Oncolyzer handelt es sich um eine interdisziplinäre Kooperation zwischen der Berliner Charité, dem SAP Innovation Center in Potsdam und dem Hasso Plattner Institut.

Um bessere Behandlungsmöglichkeiten für Krebs zu entwickeln, analysieren die Tumorforscher an der Berliner Charité Zellkulturen aus Tumorgewebe, um herauszufinden, welche Therapie bei einem Patienten helfen könnte. Dabei fallen enorme Datenmengen an; alleine bei der patientenspezifischen Genomanalyse fallen Daten im mehrstelligen Terrabytebereich an. Um diese Datenmengen zu analysieren, brauchte ein Onkologe etwa 3-4 Tage, mit dem Einsatz von des HANA Oncolyzer geht das in Sekunden. Das Frontend des HANA Oncolyzer ist eine iPad-Software, die während des Patientenbesuchs eine Echtzeitanalyse aller Patientendaten ermöglicht.[17]

4.2.2 SAP HANA Beispiel 2 - Reporting bei Hilti

Bei Hilti, Hersteller von Befestigungstechnik und Bohrhammern, erstreckt sich das Reporting über die gesamte Wertschöpfungskette vom Verkauf über Logistik bis hin zu Finanzen und Personalplanung. Die Gesamtgröße der Datenbank umfasst 53 Millionen Einträge, davon beinhaltet die Kundendatenbank alleine 9 Millionen Einträge. Bislang dauerten Extraktion, Transformation und Auswertung auf einer relationalen Datenbank zwei bis drei Stunden. Durch den Einsatz von SAP HANA kann der gesamte Prozess innerhalb von zwei bis drei Sekunden durchgeführt werden. Durch den Geschwindigkeitszuwachs stehen allen Vertretern detaillierte Kunden-Reports auf Ihren mobilen Geräten jetzt jederzeit und in Echtzeit zur Verfügung. Im Bereich der Geschäftskennzahlenanalyse stieß die bisherige Datenbank an ihre Grenzen, durch den Einsatz von SAP HANA können die Daten jetzt noch schneller und detaillierter analysiert werden.[18]

4.3 Benchmarks / Vergleiche

Im Nachfolgenden soll die Leistungsfähigkeit von IMDB mit denen relationaler festplattenbasierten Datenbanksysteme verglichen werden. Ziel des Experimentes ist es, festzustellen, ob und in welchen Fällen IMDB die Geschwindigkeit von RDBMS übertreffen kann.

Um die Leistungsfähigkeit der Systeme unter realistischen Bedingungen testen zu können, wurde die Northwind Access-Datenbank, die mit dem Microsoft SQL-Server ausgeliefert wird, herangezogen. Diese Datenbank enthält sehr praxisnahe warenwirtschafliche Daten eines fiktiven Unternehmes.

Um die original Northwind-Datenbank, die nur knapp 850 Zeilen enthält, an realistischen Bedingungen anzupassen, wurde die „Order“-Tabelle knapp 1150 mal in eine neue Tabelle „BigOrders“ kopiert.

Nach dieser Anpassung enthält die für das Experiment wichtige Tabelle nun knapp 1.000.000 Datensätze und ist knapp 800 MB groß. Als Hardwaregrundlage wurde ein IBM Blade-Server mit einer 4-Kern Intel Xeon CPU, 2 GB RAM und 4 SCSI-Platten genutzt.

Um die verschiedenen Datenbanktechnologien vergleichen zu können, wurde zum einen mySQL als klassisches RDBMS On-Disc, eine dateibasierte SQLite Datenbank On-Disk und eine SQLite Datenbank In-Memory mit der jeweils identischen angepassten Northwind-Datenbank eingesetzt.

Für jede Art von SQL-Anweisung wurde in dem Experiment eine eigene Statistik mit jeweils unterschiedlichen Anzahl an betroffenen Datensätzen durchgeführt. Die Anzahl der betroffenen Datensätze begann mit 10 und wurde um den Faktor 10 bis zu einem Endwert von 1.000.000 erhöht. Alle drei Datenbanksysteme wurde mit der Standardkonfiguration verwendet und vor jedem Testdurchlauf wurden alle Caches gelöscht.

4.3.1 SQL-Anweisungen und Ergebnisse

Bei einem SQL-Select ohne WHERE-Bedingung zeigte sich, dass die SQLite In-Memory Datenbank um den Faktor 10 schneller ist, als das gleiche System auf einer Festplatte und bei 1.000.000 Datensätzen um den Faktor 8000 schneller ist, als eine festplattenbasierte mySQL-Datenbank. Weiterhin zeigte sich, dass mit zunehmender Anzahl an Datensätzen die Antwortzeit unter 1 Millisekunde blieb, wobei eine mySQL-Datenbank bei 1.000.000 Datensätzen erst nach 5,8 Sekunden Ergebnisse zurücklieferte. Das dateibasierte SQLite On-Disc zeigte durchgehend kaum veränderte Werte, sodass hier davon auszugehen ist, dass die Anzahl der Datensätze nur geringe Auswirkungen auf die Antwortzeiten haben.

Bei einem SQL-Select mit WHERE-Bedingung bei der temporäre Tabellen erzeugt werden müssen, ist die SQLite In-Memory bis zu einem Datenvolumen von 1000 Datensätzen schneller, wird jedoch ab dort von der dateibasierten SQLite On-Disc eingeholt. Die Antwortzeiten von mySQL und SQLite steigen mit der Anzahl der Datensätze proportinal an.

Bei einem SQL-Insert ist die SQLite In-Memory Datenbank durchgehend schneller als die SQLite On-Disc und die mySQL On-Disc. Bei 1.000.000 Datensätzen beträgt der Faktor knapp 4.

Bei einem SQL-Update mit WHERE-Bedingung antwortet die SQLite In-Memory Datenbank deutlich schneller als die beiden anderen Systen. Updates werden mindestens mit dem Faktor 166, maximal ein Faktor größer 10000 ausgeführt.

Bei einem SQL-Delete mit WHERE-Bedingung arbeitet die SQLite In-Memory Datenbank ebenfalls deutlich schneller. Hier wird mindestens der Faktor 180, maximal ein Faktor größer 10000 erreicht.

Ergebnis

Das Experiment hat gezeigt, dass eine IMDB nicht generell schneller ist als ein RDBMS oder eine dateibasierte Datenbank, sondern nur in speziellen Einsatzbereichen. Eine IMDB ist schneller als On-Disc basierte Datenbanken, wenn Daten modifiziert werden:

  • SQL-Insert: Daten werden eingefügt mit dem Faktor 4
  • SQL-Update: Daten werden verändert mit mindestens einem von Faktor 166
  • SQL-Delete: Daten werden gelöscht mit mindestens einem Faktor von 180

Abbildung 4 Abbildung 5 Abbildung 6 Abbildung 7 Abbildung 8

5 Fazit

In Bezug auf das Thema In-Memory-Computing sprechen IT-Experten von einem "Paradigmenwechsel", "einer neuen Ära der Datenverarbeitung" oder "real Realtime-Business". Seit knapp einem Jahr lässt der größte deutsche Softwarekonzern SAP keine Gelegenheit aus, darzulegen, welche Vorteile die Anwender künftig aus der neuen Technik ziehen könnten. Die Rede ist von völlig neuen Analyse- und Geschäftsanwendungen sowie einer deutlich vereinfachten und kostengünstigeren IT-Infrastruktur.

Dass diese Aussagen sich nicht so verallgemeinern lassen, konnte während bei der Durchführung der Recherche und Experimente nachgewiesen werden.

Der produktive Einsatz von In-Memory-Computing bringt im Bereich der Big Data und Echtzeitanalysen völlig neue Möglichkeiten, doch die Umstellungs- bzw. Anschaffungskosten sowohl im Bereich der Hard- als auch Software sind momentan noch sehr hoch, sodass eine Implementierung bis jetzt nur in großen Konzernen durchgeführt worden ist.

In weniger komplexen Bereichen, wie z.B. Unit-Tests in der Softwareentwicklung werden heute schon mehrfach In-Memory-Datenbanken auch in kleinen und mittelständischen Unternehmen eingesetzt.

Die Technologien des In-Memory-Computing werden in naher Zukunft auf Grund stetig wachsender Datenmengen und sinkender Hardwarepreise weiter an Wichtigkeit gewinnen.

6 Literatur- und Quellenverzeichnis

Internet-Quellen

o.V. : Artikel "Präse Slideshare", http://www.slideshare.net/SAP_Nederland/the-next-generation-architecture-inmemory-computing-massimo-pezzini 04.07.2012, 01:15

o.V.: Artikel "In Memory Cimputing", http://www.computerwoche.de/software/bi-ecm/2494293/ 04.07.2012, 01:16

o.V.: Artikel "Big Data im Griff", http://www.cio.de/dynamicit/management_strategie/2308070/ 04.07.2012 01:17

o.V.: Artikel "SAP IN-MEMORY COMPUTING", http://www.sap.com/germany/plattform/in-memory-computing/index.epx 04.07.2012 01:18

o.V: Artikel "In-Memory Datenbanken auf den Zahn gefühlt!" http://www.trivadis.com/uploads/tx_cabagdownloadarea/Trivadis_CW_Artikel_In-Memory_DB_2011.pdf 05.07.2012 00:14

7 Abkürzungsverzeichnis

AbkürzungBedeutung
BIBuisness Intelligence (Deutsche Bedeutung: Gewerbeerkundung oder Geschäftsaufklärung)
CPUCentral Processing Unit (Deutsche Bedeutung: Hauptprozessor)
HANAHigh Performance Analytic Appliance von SAP
IMDBIn-Memory Database (Deutsch: Hauptspeicherresidente Datenbank)
PCIePeripheral Component Interconnect Expres (Deutsche Bedeutung: PCI Express Schnittstelle)
RAMRandom-Access-Memory
RDBMSRelational Database Management System (Deutsch: relationales Datenbankmanagementsystem)
SASSerial Attached SCSI (Deutsche Bedeutung: SCSI-Schnittstelle)
SSDSolid-State-Drive (Deutsche Bedeutung: Flash-Speicher)

8 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1RMDB versus IMDB
2Funktionsweise In-Memory-Datenbanken
3SAP HANA Oncolyzer auf dem Apple iPad
4Vergleich Dauer Selects in Bezug Anzahl Records
5Vergleich Dauer Selects in Bezug Anzahl Records
6Vergleich Dauer Inserts in Bezug Anzahl Records
7Vergleich Dauer Updates in Bezug Anzahl Records
8Vergleich Dauer Deletes in Bezug Anzahl Records

8.1 Fußnoten

  1. Vgl. Artikel "Big Data im Griff", http://www.cio.de/dynamicit/management_strategie/2308070, 01.07.2012, 19:45
  2. Vgl. Artikel "Xing analysiert seine Community in-Memory", http://www.computerwoche.de/software/bi-ecm/2494322, 01.07.2012, 19:45
  3. Vgl. Datenblatt "Intel Xeon CPU E7-8870", http://ark.intel.com/de/products/53580/Intel-Xeon-Processor-E7-8870-(30M-Cache-2_40-GHz-6_40-GTs-Intel-QPI, 01.07.2012, 19:45
  4. Vgl. Artikel "SAP Partner Hardware", http://www.sap.com/solutions/technology/in-memory-computing-platform/hana/overview/platform/partners.epx, 01.07.2012, 19:45
  5. Vgl. Artikel "Wikipedia SSD", http://de.wikipedia.org/wiki/Solid-State-Drive, 01.07.2012, 19:45
  6. Vgl. Artikel "In-memory analytics", http://it.toolbox.com/wiki/index.php/In-memory_analytics, 01.07.2012, 20:30
  7. 7,0 7,1 7,2 Vgl. Whitepapers "Performance & Technologie - In-Memory", http://whitepaper.central-it.de/index.cfm?event=channel.index&CID=59&searchterm=in-memory&category=0&pubid=12&order=desc&ordercol=downloaddate&page=1&maxrows=10&type=all, 01.07.2012, 20:30
  8. Vgl. Manuel Sevilla "OLAP databases are being killed by In-Memory solutions", http://www.capgemini.com/technology-blog/2011/09/olap-db-killed-by-inmemory/, 05.07.2012, 20:15
  9. Vgl. Artikel "IBM solidDB-Fastest Data Delivery", http://www-01.ibm.com/software/data/soliddb/, 01.07.2012, 16:45
  10. Vgl. Artikel "Oracle TimesTen Software Downloads", http://www.oracle.com/technetwork/products/timesten/downloads/index.html, 01.07.2012, 16:51
  11. Vgl. Artikel "Most Widely Deployed SQL Database Engine", http://www.sqlite.org/mostdeployed.html, 01.07.2012, 16:58
  12. Vgl. Artikel "About SQLite", http://www.sqlite.org/about.html, 01.07.2012, 16:59
  13. Vgl. Artikel "Data in Memory — DatabaseJournal.com", http://www.databasejournal.com/features/db2/article.php/3922046/Data-in-Memory.htm, 01.07.2012, 17:16
  14. Vgl. Artikel "SAP HANA – Wikipedia", http://de.wikipedia.org/wiki/SAP_HANA, 01.07.2012, 17:51
  15. Vgl. Artikel "SAP Deutschland - SAP feiert einjährigen Geburtstag von SAP HANA", http://www.sap.com/germany/about/press/press.epx?pressid=19149, 01.07.2012, 18:21
  16. Vgl. Artikel "The SAP HANA Hardware FAQ | Bluefin Solutions", http://www.bluefinsolutions.com/insights/blog/the_sap_hana_hardware_faq/, 01.07.2012, 18:34
  17. Vgl. Video "SAP TV - In-Memory in der Krebstherapie", http://www.sap-tv.com/video/#/7611/in-memory-in-der-krebstherapie, 01.07.2012, 19:45
  18. Vgl. Video "SAP TV", http://www.sap-tv.com/#/topic/6/video/7040, 01.07.2012, 19:45

9 Präsentation

Bild:Praesentation IMC.pdf

Persönliche Werkzeuge