SAPs In-Memory-Turbo könnte bald Speicherhierarchien integrieren

Alle Daten in den Hauptspeicher – so lautet SAPs Rezept für die IT-Beschleunigung. Teradata und Oracle kontern mit Speicherhierarchien. Analysten rechnen mittelfristig mit einer Konvergenz der Konzepte. (Ausgabe 10/2013)

Im Herbst 2009 hatte SAP-Mitbegründer und Aufsichtsratsvorsitzender Hasso Plattner die In-Memory-Technologie als IT-Paradigma formuliert. Daten werden demnach nicht mehr von der Festplatte gelesen, sondern ausschließlich im Hauptspeicher vorgehalten, dort verarbeitet und analysiert. Hauptvorteil dieses Ansatzes sei die dramatisch höhere Zugriffsgeschwindigkeit: „Disks are yesterday’s tapes. Künftig werden auch Großunternehmen wie Walmart nicht nur ihre Stammdaten, sondern auch sämtliche Bewegungsdaten im Hauptspeicher ablegen.“

„Künftig werden auch Großunternehmen wie Walmart nicht nur ihre Stammdaten, sondern auch sämtliche Bewegungsdaten im Hauptspeicher ablegen“, formuliert SAP-Mitgründer Hasso Plattner sein Paradigma.

„Künftig werden auch Großunternehmen wie Walmart nicht nur ihre Stammdaten, sondern auch sämtliche Bewegungsdaten im Hauptspeicher ablegen“, formuliert SAP-Mitgründer Hasso Plattner sein Paradigma.

SAP schiebt alle Daten in den Hauptspeicher

Praktisch genutzt hat SAP dieses Konzept erstmals im SAP BW Accelerator, einer Zusatzkomponente für SAP BW, die vor der Analyse sämtliche Daten in den Hauptspeicher lädt. 2011 kam der nächste Schritt: SAP ersetzte im Data Warehouse SAP BW die klassische Datenbank durch SAP HANA. Im Januar dieses Jahres schließlich stellten die Walldorfer SAP BW on HANA vor, eine komplette unternehmensweite Standardsoftware (ERP) auf Basis der In-Memory-Datenbank. Auf den ersten Blick hat sich damit Plattners Prognose erfüllt, nach der künftig sämtliche Daten im Hauptspeicher gehalten werden. Konkurrierende Hersteller kontern allerdings mit alternativen Konzepten: Teradata hatte 2011 das sogenannte Multitemperature Data Warehouse vorgestellt. Es handelt sich dabei um ein Data Warehouse, in dem Daten je nach ihrer Temperatur automatisch zwischen Solid State Disks (SSD) und klassischen Festplatten hin und hergeschoben werden. Daten, auf welche die Anwender häufig zugreifen, gelten als heiß und wandern auf eine schnelle SSD, während der Rest auf langsameren Festplatten lagert. Im Januar dieses Jahres hat Teradata das sogenannte Virtual Storage Konzept um eine In-Memory-Schicht erweitert. Die heißesten Daten lagern seitdem im Hauptspeicher.

Multitemperature Data Warehouse arbeitet mit Speicherhierarchien

Teradata Intelligent Memory stellt eine ins Data Warehouse integrierte Software-Schicht dar, die über einen Algorithmus die Daten anhand ihrer Nutzungshäufigkeit jeweils in den vom Preis-Leistungs-Verhältnis her am besten geeigneten Speicher verschiebt. Teradata Intelligent Memory sei eine Best-of-Breed-Lösung im Rahmen der übergeordneten Unified Data Architecture, die auf dem Zusammenspiel von Teradata, Teradata Aster und Apache Hadoop fußt. „Es wäre teuer und nicht zweckmäßig, sämtliche Daten im Arbeitsspeicher vorzuhalten“, argumentiert Hermann Wimmer, Vorstand International bei Teradata. „Intelligent Memory führt dazu, dass der Arbeitsspeicher nur die am häufigsten benötigten Daten enthält.“ Der Zugriff auf den Arbeitsspeicher ist laut Teradata um drei Zehnerpotenzen schneller als der auf Festplatten. Allerdings seien die Preise für Hauptspeicher auch deutlich höher als die für Solid State Disks oder Festplatten. Ähnlich argumentiert Oracle bei der im Juli dieses Jahres vorgestellten Oracle Database 12c. Hier überwacht eine sogenannte Heat Map, welche Daten wie oft genutzt werden. Anhand dieser Informationen können Administratoren Regeln festlegen, wie das System mit älteren Daten umgeht: „Es ist überhaupt nicht sinnvoll, den Hauptspeicher mit Daten zu füllen, die schon Monate nicht mehr gelesen oder geändert wurden“, erläutert Günter Stürner, Vice President Sales Consulting und Leiter der Business Unit Server Technologies bei Oracle Deutschland. „Bei Oracle DB 12c bildet die automatische Datenoptimierung den Lebenszyklus der Daten ab und komprimiert ältere Daten vollautomatisch oder verschiebt sie auf langsamere Speicher.“

Nur 5 bis 20 Prozent aller Daten sind wirklich heiß

Aus der Perspektive der mit SAP konkurrierenden Anbieter sieht es so aus, als sei das Konzept „alle Daten in den Hauptspeicher“ zumindest in Teilen schon wieder überholt. „Tatsächlich haben beide Ansätze ihre Berechtigung“, erläutert Carsten Bange, geschäftsführender Gesellschafter des Würzburger Business Application Research Center (BARC): „Hasso Plattner hatte bei der Entwicklung von SAP HANA die Vision eines ERP-Systems der nächsten Generation. Die Datenmenge in ERP-Systemen liegt häufig deutlich niedriger als in einem Data Warehouse. Das Volumen eines normalen ERP-Systems kann man heute oder in naher Zukunft problemlos im Hauptspeicher ablegen. Sehr große Data Warehouses hingegen erreichen Datenmengen, wo es wenig sinnvoll erscheint, alles In-Memory abzulegen.“ Neben die Begrenzung durch die hohen Kosten von Hauptspeicher trete die Nutzenabwägung: „Maximal 20 Prozent der Daten in einem Data Warehouse, wahrscheinlich sogar nur fünf Prozent oder weniger werden wirklich oft genutzt. Allein deshalb erscheint bei wirklich großen Datenmengen eine mehrschichtige Speicherarchitektur sinnvoll. “ Auch SAP selbst nutzt bei sehr großen Data Warehouses inzwischen ein Mischkonzept, bei dem lediglich die häufig genutzten Daten in SAP HANA liegen, der Rest hingegen beispielsweise in Sybase IQ. „Wenn es um sehr große Systeme geht, bietet die SAP das aktiv an, weil sie wissen, dass sie mit reinen In-Memory-Systemen gegenüber Mischsystemen der Konkurrenz preislich nicht mithalten können“, berichtet Bange. Auf lange Sicht könne ein derartiges Mischkonzept lediglich ein erster Schritt sein. „Die Walldorfer nutzen im Moment das, was sie haben, also eine Archivschnittstelle in den SAP-Applikationen, um damit eine externe Datenbank als Nearline Storage anzubinden. Das kann beispielsweise Sybase IQ oder Actian Vectorwise sein.“ Bei den Kunden dürften derartige Mischsysteme laut Bange auf Akzeptanz treffen. Es handle sich schließlich um eine seit Jahren erprobte Technologie, die bei großen Systemen im Vergleich zu einem reinen In-Memory-Konzept einen preislichen Vorteil aufweist.

Operatives Reporting läuft direkt im Transaktionssystem

SAP ERP on HANA koppelt Transaktionen und Analysen. Das klassische Data-Warehouse-Konzept, nach dem Transaktionen und Analysen  in separaten Systemen laufen, wird dadurch laut Bange zumindest teilweise aufgeweicht: „Alles, was operative BI betrifft, prozessnahe Auswertungen, Analyse und Reporting, das bilden viele Unternehmen heute in SAP BW ab. Wenn sie so etwas schnell und funktionsreich direkt aus dem ERP-System bekommen, gibt es wenige Gründe, das nicht dort zu tun.“ Die Grundkonzepte eines Data Warehouse, etwa die physische Integration und die Harmonisierung von Daten, seien damit aber keineswegs außer Kraft gesetzt. „Nicht nur angesichts des Trends zur verstärkten Anbindung externer Datenquellen wäre es völlig utopisch zu glauben, dass ein Unternehmen jemals sämtliche relevanten Daten in einem einzigen System verwalten kann. Die physische Integration von Daten bleibt weiter relevant, ebenso die semantische Integration, also die inhaltliche Harmonisierung von Informationen aus verschiedenen Quellen. Damit werden auch die klassischen Data Warehouses bestehen bleiben.“ Ein weiterer Grund für die Trennung von Transaktions- und Analysesystem sind laut Bange die Schemata der Daten: „Im ERP-System ist das Datenschema relativ streng limitiert. Die einzige Flexibilität besteht darin, Daten in Form von Views in ein Schema zu legen, das jeweils eine bestimmte Ausprägung oder Sicht repräsentiert. Für Business Intelligence müssen Daten oftmals stark harmonisiert werden, und dafür bestehen in einem Data Warehouse deutlich mehr Freiheitsgrade.“ SAP HANA biete – unter anderem durch seine hohe Geschwindigkeit – die Möglichkeit, über die Transaktionsdaten eine weitere logische Sicht zu legen, die dann zur Laufzeit berechnet wird. Liefen allerdings Transaktionen und Analysen parallel auf dem gleichen System, dann addierten sich Lastspitzen – und das wiederum sei nicht immer gewünscht. „Mit SAP HANA lassen sich in einem physikalischen Datenbankmanagement-System mehrere Schemata logisch verwalten“, erläutert Bange. „Manche Unternehmen entscheiden sich allerdings aus Betriebsaspekten dafür, die Datenbanken für Transaktionen und Analysen physikalisch zu trennen.“ Auch die Systemverfügbarkeit ist laut Bange ein Grund, der eher für getrennte Datenbankmanagementsysteme spricht. ERP-Systeme machen viele Unternehmen mit einem sehr großen Aufwand hochverfügbar, so dass beispielsweise in einem Katastrophenfall in Sekunden ein Spiegelsystem den Betrieb übernimmt. Data Warehouses würden zwar auch für den Betrieb immer wichtiger, doch reiche es hier häufig immer noch aus, wenn das System nach einigen Stunden wieder verfügbar ist.

Prozessorregister, RAM, Festplatten und Grafikspeicher

Insgesamt geht Bange davon aus, dass sich künftigen Datenbankmanagement-Systemen nicht eine einzelne Technologie wie etwa In-Memory durchsetzen wird, sondern dass sämtliche heute verfügbaren Beschleunigungstechnologien gemeinsam genutzt werden. „Ein Beispiel hierfür sind die fortgeschrittenen Datenbankmanagement-Systeme von Teradata, Oracle oder IBM, die vier Speicherhierarchien nutzen: Register in den Prozessoren, den Hauptspeicher, Solid State Disks und klassische Festplatten. In diese Richtung dürfte sich künftig auch SAP HANA entwickeln.” Neben der In-Memory-Datenhaltung gibt es auf der Hardware-Ebene eine weitere Beschleunigungstechnologie, nämlich das Verlagern der Rechenleistung auf High-End-Grafikkarten, in denen 250 und mehr Rechenkerne parallel arbeiten. „Ein Video-Hauptspeicher hat etwa die achtfache Lesegeschwindigkeit des klassischen Intel-RAMs“, erklärt Jedox-CEO Kristian Raue. „Wegen der massiv parallelen Befehlsverarbeitung von Grafikkarten erzielen wir Performance-Steigerungen, die durchschnittlich um den Faktor 50, in Einzelfällen sogar um den Faktor 400 höher liegen als bei einer In-Memory-Datenverarbeitung.“ Die Hürde bei dieser Beschleunigungstechnologie liege laut Bange darin, dass bislang die Graphic Processing Unit (GPU) und die Central Processing Unit (CPU) separat betrieben werden mussten, so dass ein Datentransfer zwischen CPU und GPU nötig war. „Künftig wird hier eine engere Integration stattfinden“, erläutert Bange. „Dann kann die CPU die Daten mitverwalten, welche die GPU verarbeitet. Dann wird es einfacher für die Datenbankmanagement-Systeme, die GPU-Rechenleistung mit auszunutzen. Bisher waren hier aufwändige Anpassungen notwendig.“ jf

Die Experten

„Künftig dürften In-Memory, Speicherhierarchien und Analysen im Grafikspeicher konvergieren“, prognostiziert Carsten Bange, geschäftsführender Gesellschafter von BARC.

„Künftig dürften In-Memory, Speicherhierarchien und Analysen im Grafikspeicher konvergieren“, prognostiziert Carsten Bange, geschäftsführender Gesellschafter von BARC.

„Sämtliche Daten im Hauptspeicher zu lagern ist wirtschaftlich nicht sinnvoll, da RAM die teuerste Speicherart ist“, kontert Hermann Wimmer, Vorstand International von Teradata.

„Sämtliche Daten im Hauptspeicher zu lagern ist wirtschaftlich nicht sinnvoll, da RAM die teuerste Speicherart ist“, kontert Hermann Wimmer, Vorstand International von Teradata.

 

Kommentare sind deaktiviert