KontaktAGBDatenschutzImpressumDruckversionSitemapHome
.
ANZEIGE

S@PPORT Online

.
.
.


Unternehmen & Personen

... Fortsetzung:

ERP-Software wird um Größenordnungen schneller

Zurück zur Seite | 1 |

Allerdings muss man dazu die bestehende Software – allen voran die Datenbankstrukturen, umschreiben. Applikationen gilt es von der Struktur her umzubauen. Erst dann kann man diese Geschwindigkeitsvorteile ausnutzen. Konkret bedeutet das: Die Datenstrukturen brauchen eine Art von „Cache-Bewusstsein“. Auf die Frage nach dem Aufwand, den diese Neuprogrammierung erfordert – bei SAP geht es immerhin um 400 Millionen Lines of Code, zitiert Sigg den Vordenker Hasso Plattner: Dann müsse man eben sofort anfangen.

Aber diese neue Technik darf man nicht mit dem traditionellen Disk-Caching verwechseln, bei dem die „Festplatten-Strukturen“ aus Geschwindigkeitsgründen in den Arbeitsspeicher verlagert – gechacht – wurden. Diese Strukturen werden direkt aus der Festplatte geladen und sind nicht für den Einsatz im Arbeitsspeicher optimiert. Damit muss hier auch kein Umschreiben der Applikation erfolgen. Das „echte“ In-Memory Computing agiert komplett anders: Alle verwendeten Strukturen und Programme sind auf den Einsatz im RAM hin neu geschrieben. Diese Strukturen werden dann zwar auch noch auf die Platte, also den nichtflüchtigen Speicher, geschrieben — allerdings nur, um die Informationen im Fehlerfall wieder vorrätig zu haben. Damit ist dann die Wiederherstellung einfach machbar.

„Derzeit ist es aber auch nötig, dass für das Ausnutzen des In-Memory Computing sehr viele Rechner parallel arbeiten“, erklärt Sigg. „Denn 1 TByte an Hauptspeicher reicht nicht aus. Es ist das 40- bis 100-fache an Hauptspeicher nötig. Das kann physisch gemacht werden aber auch über die Programmierlogik der Applikation unterstützt werden – wenn eben viel parallel abgehandelt wird.“

Eine weitere Technik, die hier positiv dazu beiträgt, ist die effiziente Speicherung der Daten im System. Bei Datenbankstrukturen hat das zur Folge, dass man die Daten nicht mehr in Rows (Reihen) ablegt, sondern in Columns (Spalten, siehe Abbildung 2). Wenn man die Daten auf diese Art speichert, kann man sie auch noch besser komprimieren.

Abbildung 2 – Datenstrukturen sind anzupassen: Der Übergang vom Row-basierten Konzept zum Column-basierten wird kommen (Quelle: SAP)


„Unsere Anwender haben zum Teil in Produktivumgebung Beschleunigungs-Produkte von SAP am Laufen, die auf einem System mit 64 Blades, also 64 Rechnern, zum Einsatz kommen. Wenn davon ein jeder mit 1 TByte Hauptspeicher ausgestattet ist und dann noch der Kompressionsfaktor von 10 mit ins Spiel kommt, ergeben sich 640 TByte – das macht für SAP-Systeme dann Sinn, hier In-Memory Computing zu machen“, skizziert Siggg ein mögliches Szenario.

Hasso Plattner möchte aber, so Sigg, mehr als nur eine Beschleunigung von Reports damit erzielen. Er will Transaktions- und Analytik-Processing zusammenführen und das mit der neuen Technologie. Denn es macht keinen Sinn, zwei Kopien derselben Daten vorrätig zu halten. Das war früher so und nicht anders zu machen. Doch mit einem neuen Integrationsansatz sei das nun machbar mit der In-Memory Technologie. (rh) @


Zurück zur Übersicht Artikel drucken










Weitere Links

Die Themen und Inhalte in
der aktuellen Druckausgabe
finden Sie hier…

Die Vorschau auf die nächste
Druckausgabe von S@PPORT
finden Sie hier…

Die Mediadaten und Themen-
übersicht für S@PPORT
finden Sie hier…

© CMS artmedic