IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

HANA auf non-SAP Pfaden?

Kategorie: Trend-Wende
Haben Sie auch schon über HANA als InMemory-Datenbank für ihre individuell entwickelten IT-Lösungen nachgedacht? Falls ja sind Sie nicht allein mit dieser Idee. Bei Capgemini diskutieren wir diese Option derzeit sehr intensiv und haben mit unseren Kunden auch bereits entsprechende Pilotprojekte durchgeführt. Diese „Proof of Concepts“ zeigten erstaunliche Ergebnisse hinsichtlich Performance und Speicherbedarf.

Während die zahllosen Kurzläufer-Queries im Schnitt leicht schneller ausgeführt wurden, liefen Langläufer in den meisten Fällen deutlich schneller. Der Speicherbedarf reduzierte sich nach unserer Erfahrung um mehr als 50%, insbesondere durch Kompressionstechniken und das Wegfallen von Indizes. Am Bemerkenswertesten aber ist das Potential, eine Menge Aufwand und damit Zeit und Geld zu sparen, der oft in das Tuning der IT-Lösung investiert wird.

Wann könnte es die richtige Entscheidung sein, in einer individuell entwickelten, mission-critical Nicht-SAP-Anwendung die relationale Datenbank durch eine SAP HANA In-memory-Datenbank zu ersetzen? Unsere bisherigen Erfahrungen zeigen, dass dies insbesondere dann eine Überlegung wert ist, wenn Ihre Applikation neben den typischen transaktionalen Funktionen (OLTP) auch viele eher analytische Funktionen (OLAP) aus einer Datenquelle offeriert und damit an ihre Grenzen kommt. Haben Sie zum Beispiel auch ein Kundenportal im B2B-Bereich, in dem sich ihre Kunden ihre eigenen Anfragen zusammenstellen können und sie somit keine Kontrolle über die abgesetzten Anfragen haben? Wenn das bislang ein Problem war, muss das mit „In Memory“ nicht so bleiben.

Wann ist eine Migration die richtige Entscheidung?

Mit der neuen HANA-Technologie wird das bisherige Paradigma der Trennung von OLTP und OLAP umgekehrt in eine Verschmelzung von OLTP- und OLAP-Services in eine einzige Applikation. Hier ist ein Umdenken gefordert und sicherlich sind bei so einem Paradigmenwechsel auch noch nicht alle Fragen beantwortet. Welche möglicherweise ungeklärte Frage kommt Ihnen dabei zum Beispiel sofort in den Sinn?

Ist es vielleicht auch eine Frage nach dem zweiten Paradigmenwechsel, den SAP mit HANA propagiert: Code to Data? Mit der XS-Engine wirbt SAP, in manchen Fällen auf die mittlere Schicht einer typischen Drei-Schichten-Architektur bestehend aus Client, Applikationsserver und Datenbankserver zu verzichten und die funktionale Logik vom Applikationsserver nach HANA zu verlagern. Wann entscheidet man sich in Zukunft also für eine 2-Schichtenarchitektur statt der klassischen 3-Schichtenarchitektur?

Sehen Sie die Zeit für einen Paradigmenwechsel auch in Ihrem Unternehmen gekommen? Ich freue mich mit Ihnen über dieses Thema auszutauschen. 

Über den Autor

Karl Prott

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.