In-MemoryComputing - zwischen IT-Beschleuniger und Nische

25.08.2011
Mit In-Memory-Computing und spaltenorientierter Datenbanktechnik will SAP ein neues IT-Zeitalter einläuten. Dabei sind die zugrunde liegenden Techniken nicht neu. Anwender wollen erst einmal prüfen, ob sich der IT-Beschleuniger auch rechnet.

Meilenstein" - "Paradigmenwechsel" - "eine neue Ära der Datenverarbeitung" - "real Realtime-Business" - SAPs Marketing-Strategen überschlagen sich derzeit geradezu mit Superlativen rund um das Thema "In-Memory-Computing" und die neue Appliance "HANA" (High Performance Analytical Appliance). Seit knapp einem Jahr lässt der größte deutsche Softwarekonzern 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.

Nun wird es ernst. Ende Juni hat das SAP-Management seine In-Memory-Appliance HANA offiziell am Markt vorgestellt und muss nun beweisen, ob es seine vollmundigen Versprechungen einlösen kann.

Bei HANA handelt es sich um eine Appliance, für die SAP Server-Hardware von Partnern wie Cisco, Dell, Fujitsu, Hewlett-Packard und IBM zertifiziert hat. Das Softwarepaket aus In-Memory-Datenbank und Business-Intelligence-Applikationen (BI) kommt aus Walldorf. SAPs Technikvorstand Vishal Sikka sprach von einem Meilenstein: "SAP HANA verändert grundlegend die Art und Weise, wie in Unternehmen gedacht, geplant und gearbeitet wird."

HANA soll Geschäftsabläufe in den Unternehmen quasi in Echtzeit analysieren können. Grundlage dafür bildet die Datenhaltung im Hauptspeicher der Rechner. Hier sollen Transaktions- und Analysedaten, die in herkömmlichen IT-Archtiketuren meist getrennt gehalten werden, in einem gemeinsamen Pool zusammenfließen. Anwender könnten damit - so die Vision der SAP - den eigenen Geschäftsablauf jederzeit auf Basis immer aktueller Daten auswerten, da das System kontinuierlich mit Informatio-nen aus den operativen Systemen wie beispielsweise dem ERP gefüttert werde. Große Datenmengen ließen sich so in Echtzeit bearbeiten und auswerten.

"Wir sehen in der In-Memory-Technik das Potenzial, ganze Geschäftsprozesse zu optimieren", bekräftigt Ingo Brenckmann, Program Director Data and Analytical Engines bei SAP. Klassische Techniken, Daten in einem Warehouse zu sammeln, im Rahmen von zeitaufwendigen Batch-Jobs in regelmäßigen Zeitabständen auf einen aktuellen Stand zu bringen und dann Analysen über längere Zeiträume von Stunden oder gar Tagen auf diesen Daten zu fahren, stießen derzeit an physische Rechengrenzen und reichten künftig nicht mehr aus.

Daten und Prozesse im RAM

Diese Grenzen will SAP mit seiner In-Memory-Technik und HANA überwinden. Dabei gehe es allerdings nicht nur um die Datenhaltung, erläutert Brenckmann. Würden Anwender nur die Daten in den Hauptspeicher verlagern, ohne die Anwendungen zu modifizieren, verschenkten sie Optimierungspotenzial, da sich auf diese Weise nur die Abfrage-Laufzeit beschleunigen lasse. SAPs In-Memory-Ansatz beinhaltet laut Brenckmann zusätzlich einen Computing-Teil. Dieser beschleunige nicht nur die Abfragen, sondern auch datenintensive Prozesse. Sie liefen künftig auch in-memory direkt auf der Datenbasis in HANA ab. Informationen müssten damit nicht mehr aus der Datenbank in die Applikationsschicht transportiert werden. "So gewinnen wir viel Zeit", sagt der SAP-Manager. "Wir bewegen nicht mehr Unmengen von Daten. Das ist sehr wichtig für das Echtzeit-Computing."

Zeile, Spalte oder beides

Den zweiten Eckpfeiler neben dem In-Memory-Computing bildet die Datenbank. SAP verwendet in HANA ein Hybridmodell, das eine zeilen- und spaltenorientierte Datenhaltung erlaubt.

Klassische relationale Datenbanken arbeiten zeilenorientiert. Hier werden beispielsweise Informationen zu Kundensätzen hintereinander geschrieben: Name, Ort, Land. Dann folgt der nächste Kunde. Spaltenorientierte Datenbanken sind anders aufgebaut. Sie schreiben zunächst alle Namen hintereinander, dann folgen die anderen Attribute wie Orte und Länder.

Beide Ansätze haben Vor- und Nachteile: Zeilenorientierte Datenhaltung erlaubt schnelle schreibende Zugriffe, während das Lesen der Daten länger dauert, da beispielsweise auf der Suche nach einem bestimmten Namen gesprungen werden muss. Das verzögert die Suche. Aufgrund dieser Voraussetzungen eignet sich dieser Datenbanktyp vor allem für OLTP-Systeme (Online Transactional Processing) wie beispielsweise das ERP, aus dem laufend viele Informationen in die Datenbank eingespeist werden. Mit diesem häufigen Schreiben kommen spaltenorientierte Datenbanken weniger gut zurecht, da beim Einfügen von Daten die Indizes neu organisiert werden müssten. Das dauert seine Zeit. Dagegen spielt dieser DB-Typ seine Vorteile bei lesenden Zugriffen aus. Wird zum Beispiel ein Name gesucht, liest die Datenbank einfach die entsprechende Spalte sequenziell ohne Sprünge aus. Das funktioniert extrem schnell. Daher werden spaltenorientierte Datenbanken meist in Olap-Systemen (Online Analytical Processing) wie Data Warehouses und anderen auf Auswertungen sowie Analysen spezialisierten Systemen eingesetzt. Ein weiterer Vorteil der Spaltenorganisation: Die so abgelegten Daten lassen sich stark komprimieren.

"Die Trennung zwischen OLTP- und Olap-Systemen löst sich allmählich auf", kommentiert SAP-Manager Brenckmann. Die Annahme, dass man für transaktionale Aufgaben zeilenbasierte und für analytische Zwecke spaltenbasierte Systeme verwenden sollte, lasse sich so nicht mehr aufrechterhalten. In HANA benutzt der Konzern eigenen Angaben zufolge eine Hybridform. Beide Techniken der Datenhaltung seien hier möglich und kombinierbar. Je nach Datenmodell und Nutzungsszenario ließen sich die Daten zeilen- oder spaltenbasiert organisieren.

Konfusion um Dimensionen

An diesem Punkt sieht Carsten Bange vom Business Application Research Center (Barc) jedoch einige Konfusion im Markt. Man müsse die einzelnen Techniken deshalb exakt voneinander trennen. Im Grunde stehen die verschiedenen Dimensionen In-Memory oder Hard-Disk sowie Zeilen oder Spalten nebeneinander. Dazu komme als dritte Dimension noch die Art der Bereitstellung als On-Premise-Software, im SaaS-Modell oder als Appliance: "Das sind aber voneinander unabhängige Themen." Demnach lasse sich eine klassische relatio-nale Datenbank so bauen, dass sie komplett im Hauptspeicher läuft und als Stück Software ausgeliefert wird. Ferner sei eine Appliance denkbar, in der eine Disk-basierte spaltenorientierte Datenbank ihren Dienst verrichtet. "Man findet für alle möglichen Kombinationen Beispiele", meint der Marktbeobachter.

Grundsätzlich gilt Bange zufolge die Trennung zwischen Zeilenorientierung für OLTP und Spaltenorientierung für Olap heute schon noch. Auf mittlere Sicht könne es jedoch durchaus sein, dass die Arten der Speicherindizierung allmählich verschwämmen. Es spreche nichts dagegen, die derzeit auch von SAP noch auf analytische Anforderungen ausgerichtete HANA-Datenbank in Zukunft auch für operative Aufgaben einzusetzen. Bis dahin müssten jedoch noch etliche Hausaufgaben erledigt werden. "Man steckt hier noch früh im Entwicklungsstadium", warnt der Experte vor überzogenen Erwartungen. "Es gibt sicher noch viele Dinge, die fehlen."

Anwender warten ab

Das sieht man auf Seiten der Anwender offenbar ähnlich. Die Konzepte rund um In-Memory-Computing seien grundsätzlich interessant und böten sicher auch Potenzial, konstatiert Marco Lenck, Vorstandsmitglied der Deutschsprachigen SAP-Anwendergruppe (DSAG). Allerdings müssten noch viele klassische Fragen geklärt werden. Dabei gehe es um Aspekte wie Betriebs-sicherheit und -konzepte sowie Wiederanlaufverhalten und Backup-Funktionen.

Auch in Sachen neuer Datenbanktechnik sieht der Anwendervertreter noch Fragezeichen. "Die Datenbanken in den Unternehmen sind wie Wasser aus dem Wasserhahn - den dreht man auf, und dann muss es fließen." Daher sei die klassische relatio-nale Datenbank im Grunde gesetzt. Gerade hinsichtlich der Betriebssicherheit sei die Technik etabliert und ausgereift. "Das werden die Anwender nicht von heute auf morgen aufgeben", sagt Lenck.

Allerdings, so schränkt der DSAG-Vorstand ein, gebe es auch Zeiten für Paradigmenwechsel und Innovationsschübe. Damit müssten sich die Anwenderunternehmen beschäftigen und überlegen, ob sie an der einen oder anderen Stelle nicht einen neuen Weg einschlagen sollten. Gerade angesichts der wachsenden Anforderungen im analytischen Bereich sieht Lenck durchaus Chancen für die neue Technik. Um die Herausforderungen zu meistern, müssten Anwender die bestehende relationale Technik immer wieder erweitern und ergänzen.

BI-Anforderungen steigen

"Gerade im BI-Umfeld steigen die Ansprüche", bestätigt Barc-Experte Bange. Die zu verarbeitenden Datenmengen würden immer größer, die Abfragen und Analysen immer komplexer. Gleichzeitig forderten die Nutzer jedoch eine möglichst hohe und gute Performance der Systeme: "Es drückt von allen Seiten."

Die Lösung ist aus Banges Sicht nicht einfach: "Es ist mühsam, aufwendig und teuer, die herkömmliche relationale Datenbanktechnik dahin zu bringen, dass sie die geforderte Leistung auch liefert." Ein auf Anwenderseite beliebtes Mittel sei es, die Hardware hochzurüsten, um Defizite in der Datenbanktechnik auszugleichen. Doch irgendwann gehe es Bange zufolge ins Geld, immer größere Rechenkapazitäten bereitzustellen. Eine andere Methode sei das Datenbank-Tuning, beispielsweise bestimmte Sichten auf die Daten zu entwickeln beziehungsweise entsprechende Aggregatstabellen zu bauen. Das habe jedoch zur Folge, dass die Administration und Weiterentwicklung der eigenen Datenbank-Infrastruktur komplexer wird, gibt der Barc-Experte zu bedenken.

"In-Memory hat eine Chance"

Gelänge es mit In-Memory, diese Aufwände und die damit verbundene Komplexität zu reduzieren, hätte die Technik durchaus eine Chance, meint DSAG-Vorstand Lenck. Doch die sei derzeit nur theoretischer Natur: "Das sind Denkmodelle." In-Memory könne zwar durchaus ein Kandidat dafür sein, relationale Datenbanktechnik abzulösen. "Doch da sind wir heute definitiv noch nicht, und wir reden an dieser Stelle nicht von diesem und auch nicht vom nächsten Jahr." Der Anwendervertreter fordert belastbare Anwendungsszenarien, die auch einen Business Case rechtfertigten. Diese Use- und Proof-Cases gebe es indes noch nicht. Die Unternehmen könnten mit HANA erste Erfahrungen in diesem Technikfeld sammeln. Allerdings sei dies ein teures Vorhaben, das man mit Geschäftsprozessnutzen erst einmal unterlegen müsse, so Lenck.

"Hier müssen die Firmen Investitionen wagen", fordert indes Gerd Stangneth, Managing Consultant OnDevice bei Capgemini. Allerdings sieht auch er die Problematik: Berechnungen des Return on Investment (RoI) nur innerhalb der IT seien heute meist Daumenpeilungen. Konkrete Aussagen, wie viele Lizenzen oder Server sich einsparen ließen, seien kaum möglich. Im Gegenteil: Die Unternehmen müssten erst einmal in zusätzliche IT investieren, um im Business einen Mehrwert zu schaffen. Dementsprechend lasse sich der RoI nicht allein in der IT rechnen. Vielmehr müsse das in enger Abstimmung mit den Fachabteilungen geschehen: "Die Herausforderung liegt darin, dass man erst einmal eine bestimmte Summe möglichst intelligent investieren muss, um sich überhaupt vorstellen zu können, was man mit der neuen Technik erreichen kann."

Anwender fürchten die Kosten

Doch mit diesen Investitionen tun sich die Anwender offenbar noch schwer. Momentan sei die Zahl der Nutzer und konkreter Projekte überschaubar, berichtet Lenck. Zwar sei Interesse da. Einige beobachteten den Markt, ohne sich jedoch schon festlegen oder gar konkrete Investitionsentscheidungen treffen zu wollen. "Viele schrecken vor den hohen Kosten zurück."

SAP selbst gibt sich bezüglich Nutzerzahlen und Prognosen einsilbig. Man mache gute Fortschritte, wolle aber zum gegenwärtigen Zeitpunkt nicht konkreter werden, sagt SAP-Manager Brenckmann. Grundsätzlich scheint SAP jedoch aus den Fehlern der Vergangenheit gelernt zu haben. In Walldorf gibt man sich bemüht, Brüche zu vermeiden und die Anwender möglichst behutsam an das In-Memory-Thema heranzuführen. So könnten Unternehmen bestehende und neue Technik parallel betreiben.

Aus Sicht des Capgemini-Experten Stangneth hat SAP damit eine "charmante" Strategie gefunden, die Technik parallel zu stellen. Dies erlaube es Anwendern, erste Vorteile zu nutzen, ohne gleich einen kompletten Umstieg zu wagen. Barc-Analyst Bange warnt die Unternehmen jedoch davor, einen Umstieg auf die leichte Schulter zu nehmen. Gerade ein Umbau der Datenbank sei alles andere als trivial. Anpassungen, die mittels möglicherweise herstellerspezifischer SQL-Scripts in die Datenbank eingebaut wurden, ließen sich nicht ohne Weiteres migrieren und in die neue In-Memory-Welt mitnehmen.

Anwendungen umschreiben

Lenck von der DSAG findet trotz möglicher Hürden SAPs Weg, In-Memory zusätzlich anzubieten, durchaus sinnvoll. Anwender könnten so ihre bestehenden Applikationen zunächst einmal eins zu eins weiternutzen. Richtig profitieren würden die Anwendungen allerdings erst dann, wenn sie In-Memory nativ unterstützten, schränkt er ein. "Doch dazu muss man die Software umschreiben." Es gebe allerdings nur Sinn, die Performance-kritischen Applikationen anzupassen: "Kein Mensch wird die Funktion ‚ÄöEinen Auftrag anlegen` umprogrammieren." Die entscheidende Frage, die sich die Anwender an dieser Stelle selbst beantworten müssten, laute: "Wie viel bin ich zu zahlen bereit, damit diese oder jene Funktion schneller läuft?" Das werde die Gretchenfrage sein.

SAP-Anwendungen für In-Memory

Auch SAP ist bei der Beantwortung dieser Frage gefordert. Doch davon scheint sich der Softwarekonzern nicht irritieren zu lassen. HANA und In-Memory werden einen großen Einfluss auf die künftige Produktentwicklung der SAP haben, heißt es in Walldorf. "HANA wird die Grundlage sämtlicher Neuentwicklungen rund um unser Produkt- und Technologieportfolio sein", kündigte SAP-Vorstand Sikka an. Bis Ende des Jahres werde das SAP BW als erste Abap-basierende Anwendung auf HANA laufen und dort seine Daten ablegen sowie verarbeiten, präzisiert Brenckmann die Vorgabe seines Technikchefs. Darüber hinaus will SAP weitere Anwendungen für In-Memory fit machen. Dar-unter bestehende Applikationen, die künftig die neue Technik nutzen könnten, aber auch komplett neue Softwarebausteine, die das SAP-Portfolio ergänzen sollen und von vornherein ausschließlich auf die Nutzung von In-Memory ausgelegt sind. Brenckmann nennt als Beispiel die Anwendung "Strategic Workforce Planning", die bei komplexen Analysen in der Personalentwicklung eines Unternehmens von den Performance-Vorteilen in HANA profitieren soll. Diese Software verwende dediziert die SAP-Appliance als Datenspeicher, kündigt der SAP-Manager an. So soll ein Anwendungsszenario nach dem anderen für In-Memory und HANA angepasst werden, beschreibt Brenckmann die Idee des Softwareherstellers. Langfristig gesehen könnte damit das Thema Datenbank marginal werden. Mit In-Memory als zentraler Technik sei eine relationale Datenbank nicht mehr so wichtig, prognostiziert der SAP-Manager: "Diese kann letztlich nicht die erforderliche Leistung bringen."

Das sieht man bei der Konkurrenz, wie nicht anders zu erwarten, etwas differenzierter. In bestimmten Situationen mögen Systeme wie HANA Sinn geben und eine In-Memory-Datenbank notwendig machen, meint Günther Stürner, Vice President für den Bereich Server Technologies bei Oracle in Deutschland. Das seien jedoch sehr spezifische Anwendungen: "Es ist im Grunde immer eine Art Nische".

Relationale Systeme haben Zukunft

Prognosen von SAP, das Ende der Disk-basierenden relationalen Datenbanksys-teme sei abzusehen, hält der Oracle-Manager für reichlich übertrieben. Stürner verweist auf Caching-Techniken, die auch für traditionelle Datenbanken genügend Leis-tungsreserven böten. Es gebe Cache im Hauptspeicher, Solid-State-Drives (SSDs) mit erweiterten Caches, Flash-Caches und Result-Caches, in denen Ergebnisse eines SQL-Befehls für ähnliche Abfragen vorgehalten würden. "Ein gut eingeschwungenes Datenbanksystem hat eine Trefferrate von 90 bis 95 Prozent", sagt Stürner. "Das heißt, die Systeme greifen sowieso auf den Hauptspeicher zu."

Es sei zu einfach, zu behaupten, alle Probleme seien gelöst, indem man alles

einfach in den Hauptspeicher lade, merkt Stürner an. An dieser Stelle müssten noch einige Fragen beantwortet werden, beispielsweise, ob der hier zur Verfügung stehende SQL-Sprachumfang auch für hochkomplexe Abfragen geeignet sei oder die auch hier notwendigen Optimizer gut funktionierten.

Die Grundproblematik, die SAP mit HANA aufgreift, sieht allerdings auch der Oracle-Manager. Data Warehouses müssten heute zunehmend Realtime-orientierter arbeiten: "Was sich ändert, ist die Frequenz der Updates." Habe es in der Vergangenheit definierte Ladestrecken beispielsweise am Wochenende gegeben, gelte es heute, die Veränderungen aus den OLTP-Systemen stündlich, minütlich oder sogar realtime im Data Warehouse zu aggregieren: "Ein Warehouse muss heute gleichzeitig auch transaktionsorientiert arbeiten können." Die Herausforderung, dass sich die ständigen Updates und die gleichzeitigen Lesezugriffe nicht stören dürften, habe Oracle längst gelöst.

Trennung OLTP - Olap gibt Sinn

Grundsätzlich hält Stürner die Trennung von OLTP und Olap für sinnvoll. Es möge aus seiner Sicht zwar Anwendungen geben, für die Hybridsysteme passten. Demgegenüber eigneten sich spezielle Auswertungen jedoch nur für eine optimierte Datenstruktur in Olap-Systemen. Außerdem hätten Anwender meist unterschiedliche Anforderungen an die Systeme. Für ein Business-kritisches OLTP-System herrschten beispielsweise andere Verfügbarkeitskriterien als für ein Warehouse, das sich im Grunde jederzeit wieder aus dem OLTP-System aufbauen lässt. "Schwarz-weiß wird es deshalb nicht geben", lautet sein Fazit.

Auch die Konkurrenz hat deshalb spezielle Lösungen im Programm. Oracle bietet mit "Times Ten" eine zeilenbasierende In-Memory-Datenbank an und positioniert im DW-Umfeld "Exadata" als Highend-Appliance für OLTP und Olap. Auch IBM offeriert verschiedene In-Memory-Lösungen in diesem Umfeld: "Solid DB" für das OLTP-Umfeld, "TM1" für Multidimensionales Olap (Molap) und den Informix Warehouse Accelerator für relationales Olap (Rolap).

Allerdings sieht auch Andreas Weininger, BI- und Datenbankspezialist von IBM, In-Memory nicht als alleinige Lösung für alle Probleme. Gerade für großvolumige Warehouses im Petabyte-Bereich seien die Disk-basierenden relationalen DB-Systeme weiterhin gesetzt. Trotz sinkender Memory-Preise würden die Anwender ab einer bestimmten Kapazität eine Kostengrenze ziehen.

Grundsätzlich verweist aber auch der IBM-Manager auf die Veränderungen im Data-Warehouse-Umfeld. "Haben die Anwender vor 15 Jahren ihr DW einmal im Monat geladen, gibt es heute kaum mehr einen Kunden, der das nicht täglich tut." Der Wunsch nach mehr Echtzeitfähigkeit sei nicht zu verkennen. Gleichzeitig ständen geringerer Tuning- und Administrationsaufwand sowie bessere Performance auf der Prioritätenliste der Anwender weit oben. Dafür sei In-Memory eine interessante Option. Zwar lasse sich auch in traditionellen Datenbanksystemen im Grunde vieles In-Memory cachen. Dennoch seien die Lösungen darauf ausgelegt, die Daten blockweise von einer Festplatte zu holen. Dagegen kämen im Zuge von In-Memory-Datenbanken Algorithmen zum Einsatz, die speziell für diese Technik ausgelegt seien und Leistungsvorteile böten. Hier verschiebe sich die Speicherhierarchie, erläutert Weininger: "Was früher Disk war, ist jetzt der Hauptspeicher, und was früher RAM war, ist heute der CPU-Cache."

"Die klassischen DB-Anbieter achten jedoch eher darauf, ihr bestehendes Geschäft mit herkömmlichen Systemen zu schützen", meint Tristan Werner, Experte für das Thema In-Memory bei Accenture. Ob diese Hersteller dem aus Walldorf forcierten Hype folgen, könne man derzeit schwer beurteilen. Aus SAP-Sicht sei es jedoch nur konsequent, an dieser Stelle eigene Technik zu pushen. Schließlich laufe der Großteil der SAP-Installationen auf Datenbanken von Oracle und IBM. Mittelfris-tig sei es sicher das Ziel, Datenbanken durch In-Memory-Technik zu ersetzen. Werner rechnet mit völlig neuen Möglichkeiten der Softwarenutzung und in der Folge auch mit einer neuen Generation der Business Suite.

Polarisierung bringt nichts

Bis es so weit ist, plädiert Capgemini-Manager Stangneth dafür, das neue Thema möglichst unvoreingenommen zu behandeln. Aus seiner Sicht müssten sich die Firmen klug mit In-Memory beschäftigen, um vorbereitet zu sein, wenn die Technik kommt. Daran zweifelt der Experte indes nicht. Deshalb sei es auch wichtig, in der Diskussion nicht zu stark zu polarisieren: "In Memory ist nicht der Heilsbringer, aber auch kein kompletter Unfug."

von Martin Bayer

Aus Sicht der Barc-Experten gibt es verschiedene Dimensionen, die die Strukturen analytischer Datenbanken beeinflussen. Dabei sind viele Kombinationen denkbar.
Aus Sicht der Barc-Experten gibt es verschiedene Dimensionen, die die Strukturen analytischer Datenbanken beeinflussen. Dabei sind viele Kombinationen denkbar.
Foto: Barc
Welches Potenzial sehen Sie für Ihr Unternehmen in der In-Memory-Technologie?
Welches Potenzial sehen Sie für Ihr Unternehmen in der In-Memory-Technologie?
Foto: RAAD Research
Inwieweit spielt In-Memory bei den Planungen für 2011 eine Rolle?
Inwieweit spielt In-Memory bei den Planungen für 2011 eine Rolle?
Foto: RAAD Research
Zwei Drittel aller SAP-Anwender setzen auf Datenbanken von Oracle.
Zwei Drittel aller SAP-Anwender setzen auf Datenbanken von Oracle.
Foto: RAAD Research
Eine Befragung von 500 Firmen-Managern im März 2011 hat ergeben, dass die Unternehmen angesichts der schnellen Business-Veränderungen mehr Echtzeitsysteme benötigen.
Eine Befragung von 500 Firmen-Managern im März 2011 hat ergeben, dass die Unternehmen angesichts der schnellen Business-Veränderungen mehr Echtzeitsysteme benötigen.
Foto: Oxford Economics

Was heißt In-Memory?

In-Memory-Datenbanken zeichnen sich dadurch aus, dass sie primär den Arbeitsspeicher (Random Access Memory = RAM) eines Computers als Datenspeicher nutzen. Aufgrund der höheren Zugriffsgeschwindigkeiten lässt sich die Datenverarbeitung signifikant beschleunigen. Um die Daten im flüchtigen Arbeitsspeicher zu sichern, setzen Hersteller Techniken wie Snapshots, Transaction Logs und Replikationen ein. Die Daten werden dann bei Bedarf etwa auf herkömmliche Festplattensysteme geschrieben. In-Memory-Technik gibt es bereits seit einigen Jahren, sie fristet aber bis dato eher ein Nischendasein. Vor allem Unternehmen, in denen es auf Echtzeit ankommt, setzen diese Technik ein, zum Beispiel Telekommunikationsanbieter, soziale Netze und Handelsplattformen. Zu den bekanntesten In-Memory-Datenbanksystemen gehören Times Ten (Oracle), Solid DB (IBM), ASE 15.5 (Sybase/SAP), Qlikview (Qliktech) und Gemstone (VMware).