19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Entdecken Sie im vorliegenden Praxishandbuch, welche Möglichkeiten die SAP-HANA-Plattform für eine moderne, cloudbasierte Softwareentwicklung bietet. Neben Technologieaspekten und Konzepten wie »Cloud-native«-Softwareentwicklung oder Microservices-basierte Architekturen werden Sie die relevanten Programmiersprachen, Prozesse und Tools im SAP-Kontext kennenlernen.
In unterschiedlichen Anwendungsszenarien veranschaulicht der Autor die Bedeutung der auf der Cloud Foundry basierten Platform-as-a-Service-(PaaS-)Lösung und zeigt Strategien auf, wie die XSA-Architektur in Unternehmen zu etablieren ist. Grundlage für die Entwicklung bilden neben dem XSA-Programmiermodell die Multi-Target Applications (MTA). Anhand eines übergreifenden MTA-Projekts mit mehreren Modulen werden Ihnen die beschriebenen Programmiersprachen und Technologien gegliedert in die Bereiche »Oberflächen«, »Prozesse« und »Datenbank«, nähergebracht.
Der Autor hat in diesem Buch Erfahrungen aus diversen Entwicklungsprojekten auf Basis der SAP-HANA-Plattform verarbeitet. Er richtet sich damit insbesondere an Software-Architekten mit einem technischen Grundverständnis und Interesse an moderner Entwicklung im SAP-Umfeld. Die aufgeführten Beispiele der jeweiligen Programmiersprachen werden über ein öffentliches GitHub-Repository zur Verfügung gestellt, um die Technologien direkt ausprobieren zu können.
- Einstieg in die cloudbasierte Softwareentwicklung
- SAP-HANA-XSA-Plattform für eigene Softwareprojekte verwenden
- Entwickeln mit HANA CDS, Java, Node.js, Python und SAPUI5
- inklusive vollständiger MTA-Beispielanwendung
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 175
Veröffentlichungsjahr: 2021
Ähnliche
Eik Sunke
Cloud-Entwicklung in SAP HANA®
Eik SunkeCloud-Entwicklung in SAP HANA®
ISBN:978-3-96012-044-5 (E-Book)
Lektorat:Anja Achilles
Korrektorat:Bernhard Edlmann Verlagsdienstleistungen, Raubling
Coverdesign:Philip Esch
Coverfoto:© dimazel | Nr. 272511511 – stock.adobe.com
Satz & Layout (E-Book):Johann-Christian Hanke
1. Auflage 2021
© Espresso Tutorials GmbH, Gleichen 2021
URL: www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch die Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Sebastian Abshoff:
Mobile Apps mit den SAP
®
Cloud Platform Mobile Services
Dr. Boris Rubarth:
Schnittstellenprogrammierung in SAP
®
ABAP
Johannes Gerbershagen:
Qualitätsmanagement in der ABAP-Entwicklung unter SAP
®
Johannes Gerbershagen:
SAP
®
-Praxishandbuch ABAP Core Data Services (CDS)
Tobias Steckenborn:
Schnelleinstieg in SAP
®
Cloud Platform Workflow
Jörg Böke:
Schnelleinstieg in SQLScript für SAP HANA
Vorwort
Die SAP hat vor einigen Jahren mit der Einführung des eigenen Datenbanksystems SAP HANA bei allen Unternehmen, die SAP-Software einsetzen, einen erheblichen Architekturwandel eingeleitet. Dies liegt in der Tatsache begründet, dass der Softwarekonzern seine Innovationen zukünftig ausschließlich auf Basis dieser Datenbanktechnologie veröffentlichen wird. Dementsprechend müssen SAP-Kunden das Themengebiet »HANA« für sich analysieren und ggf. Einführungs- oder Migrationsprojekte durchführen.
Als Lösungsarchitekt arbeite ich seit mehreren Jahren in Projekten verschiedener Kunden, die die Datenbankplattform nicht nur als Grundlage für ihre ERP- und BW-Systeme, sondern auch für Eigenentwicklungen verwenden.
Genau um diesen Aspekt geht es im vorliegenden Buch.
Ich gebe Ihnen einen umfassenden Einblick in die neuen Möglichkeiten, die sich aus dem Einsatz der SAP-HANA-Plattform ergeben. Gerade wenn Sie aktuell noch Entwicklungen für Ihre On-Premise-Landschaft durchführen, die Sie zukünftig in die Cloud umziehen möchten, kann die SAP-HANA-Plattform ein wichtiger Bestandteil Ihres Technologiemix sein.
Ich richte mich mit diesem Buch an interessierte Leser aus dem Bereich der Informationstechnologie, die mehr über die Potenziale der HANA-Plattform für die Softwareentwicklung erfahren möchten. SAP geht mit dieser Plattform auch architektonisch neue Wege und verbindet die klassische SAP-Welt mit Technologien, die bislang eher außerhalb des SAP-Universums verwendet wurden.
Nach einer Einführung in das Thema »Softwareentwicklung auf der HANA-Plattform« beschreibe ich in Kapitel 2 die zugrunde liegende Architektur und erkläre generelle Technologieaspekte dieser Plattform. Als Ausgangspunkt für die weiteren Kapitel erhalten Sie in Kapitel 3 Erläuterungen zu Konzepten wie »Cloud Native«-Softwareentwicklung und Microservices-basierte Architekturen. Basierend darauf stelle ich in Kapitel 4 die für die Softwareentwicklung relevanten Programmiersprachen, Prozesse und Tools vor. Gerade diese unterscheiden sich von den »altbekannten« SAP-Vorgehensmodellen.
In Kapitel 5 zeige ich Ihnen anhand diverser Beispiele, wie die Softwareentwicklung in den einzelnen Bereichen (Oberflächen, Prozesslogik und Datenbank) mithilfe unterschiedlicher Programmiersprachen durchgeführt wird. Diese Beispiele führen gemeinsam zu einer lauffähigen HANA-Anwendung, die Sie nach Belieben erweitern und anpassen können.
Abschließend erhalten Sie einen Ausblick, welche weiteren Technologien von der SAP zukünftig für die Entwicklung von Software ausgebaut werden.
Quellcode-Beispiele
Dieses Buch enthält viele Quellcode-Beispiele. Um die Lesbarkeit in Ihrem E-Book-Lesegerät zu verbessern und den Zeilenumbruch korrekt darzustellen, empfehlen wir, den Quellcode im Querformat zu betrachten oder die Schriftgröße kleiner zu zoomen.
Quellcode der Beispiele
Wenn Sie möchten, können Sie die in diesem Buch gegebenen Beispiele auch in Eigenregie ausführen. Den benötigten Quellcode stelle ich Ihnen über zwei öffentliche GitHub-Repositorys zur Verfügung.
Quellcode der Beispielanwendung:https://github.com/esunke/espresso-cnj-hana-xsaWeiterer Quellcode für die Softwaregenerierung:https://github.com/esunke/espresso-docker-build-xsaIn den Text sind Kästen eingefügt, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen Personen weiblichen und diversen Geschlechts.
Hinweis zum Urheberrecht
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Einleitung
Lassen Sie uns mit einem Blick zurück in die Vergangenheit beginnen. Ich möchte Ihnen darstellen, wie die SAP in den letzten zehn Jahren den Weg zu einer modernen Datenbank- und Entwicklungsplattform verfolgt hat und warum es für Sie und Ihr Unternehmen von Vorteil sein kann, das aktuelle SAP-Datenbanksystem für Ihre Softwareprojekte zu nutzen.
Meine Rückschau startet mit dem Veröffentlichungszeitpunkt der SAP-eigenen In-Memory-Datenbank HANA. Basierend darauf stelle ich Ihnen den leichtgewichtigen Applikationsserver mit dem Namen »Extended Application Services Classic« (XSC bzw. XS, wie er früher genannt wurde) vor, um mich abschließend dem Hauptfokus dieses Buches zu widmen: der auf modernen Cloud-Technologien basierenden Plattform »Extended Application Services Advanced« (XSA).
1.1 HANA im Rückblick
Als die SAP im Jahr 2011 die erste Version der HANA-Datenbank veröffentlichte (Kundenfreigabe am 05.09.2011), wurde dem Produkt viel Aufmerksamkeit gewidmet. Die SAP versprach erhebliche Performancegewinne für die auf HANA aufsetzenden SAP-Anwendungen.
Bei öffentlichen Veranstaltungen, wie beispielsweise der SAP TechEd, wurde von deutlich verbesserten Abläufen in Kundenumgebungen berichtet – Abläufe, die mit der HANA-Technologie 100.000-mal schneller seien als ohne. Der Kreis der Kunden, die solche Performancegewinne erzielten, wurde von der SAP medienwirksam inszeniert. Man sprach von dem »100k-Club«.
Diese sehr plakativen und eher marketinglastigen Aussagen über die Potenziale der HANA-Technologie konnten allerdings in verschiedenen Kundenprojekten tatsächlich realisiert werden.
Um die Vorteile besser zu verstehen und vor allem auch für eigene Softwareprojekte nutzen zu können, ist es wichtig, Details der HANA-Technologie zu betrachten. Darauf werde ich im Abschnitt 2.1 zu sprechen kommen. Dabei werde ich auf weitere Besonderheiten der HANA-Architektur eingehen und Ihnen einen Überblick über die HANA Processing Services (z.B. Search, Spatial, Predictive & Planning, Machine Learning) geben, mit denen spezifische Logiken direkt innerhalb der Datenbank umgesetzt werden. Diese Processing Services erweitern das Datenbanksystem um zusätzliche Funktionen und ermöglichen spezielle, integrierte Anwendungsszenarien.
Abbildung 1.1 stellt das Produkt SAP HANA unter Berücksichtigung der Processing Services und Entwicklungsaspekte dar.
Abbildung 1.1: SAP HANA – Business Data Platform
Im Zentrum der Grafik sehen Sie die einzelnen Funktionen der HANA-Datenbank, auf der linken Seite die Möglichkeit, externe Daten zu integrieren, und auf der rechten Seite das Thema Anwendungsentwicklung, zu dem auch die XSA-Umgebung gehört, um die es in diesem Buch primär geht.
Ein weiterer wichtiger Aspekt bei der Markteinführung der HANA-Datenbank war die Aussage der SAP, dass HANA die alleinige Datenbanktechnologie für moderne SAP-Systeme (S/4HANA, BW/4HANA etc.) sei. Innovationen werde man ausschließlich auf Basis der HANA-Technologie ausrollen. Dies bedeutet für alle SAP-Kunden, dass sie mittel- bis langfristig mit dem Thema HANA in Berührung kommen werden.
Ergänzend ermöglicht die SAP ihren Kunden die Nutzung der HANA-Technologie für Eigenentwicklungen außerhalb des ABAP-Stack oder anderer SAP-Produkte. Zu diesem Zweck stellt sie ein eigenes Lizensierungsmodell zur Verfügung.
HANA-Lizenzen
SAP unterscheidet bei der HANA-Datenbank zwischen folgenden Lizenzmodellen:
Runtime-Lizenz: Sie wird benötigt, um HANA für SAP-Produkte zu verwenden (z.B. bei der Business Suite). Platform-Lizenz: Sie ist für Eigenentwicklungen auf HANA erforderlich. Bei diesem Modell wird zusätzlich der jeweils zur Verfügung stehende Funktionsumfang lizensiert.1.2 Extended Application Services
Damit auch vollständige Anwendungen (also inklusive Anwendungslogik und Oberflächen) auf der Datenbankplattform entwickelt werden können, hat die SAP neben der Datenbank die sogenannten Extended Application Services(XS) eingeführt. Die Idee dahinter ist eine Plattform zur Entwicklung kundeneigener Anwendungen, die die Funktionen der HANA-Datenbank vollumfänglich nutzen können. Auch die SAP selbst erweitert über die XS den Funktionsumfang der SAP-HANA-Plattform insgesamt.
Zunächst wurde der mittlerweile als Extended Application Services Classic (XSC) benannte Ansatz angeboten. Die Technologie erwies sich allerdings als sehr proprietär und zeigte architektonische Schwachstellen. Beispielsweise konnte die XSC-Umgebung nicht unabhängig von der HANA-Instanz skaliert werden. Des Weiteren war die Laufzeitumgebung an einen HANA-Prozess gekoppelt, was insbesondere aus Stabilitätsgründen problematisch ist.
Basierend auf den Erfahrungen mit XSC hat die SAP eine komplette Neuausrichtung des Themas »Extended Application Services« in die Wege geleitet. Mit SAP HANA 1.0 SP11 wurden den Kunden erstmalig die Extended Application Services Advanced (XSA) zur Verfügung gestellt. An dieser Stelle möchte ich darauf hinweisen, dass die Nähe der XSA zur XSC fast ausschließlich über den Namen (Classic und Advanced) gegeben ist. Bei der XSA handelt es sich um einen cloudbasierten Ansatz, der auf offenen Standards aufbaut. Weitere Details und vor allem die wichtigsten Unterschiede zwischen den Umgebungen XSC und XSA schildere ich im Abschnitt 2.2. Auf die XSA-Architektur gehe ich in Abschnitt 2.3.4 genauer ein.
Nachdem wir bisher fast ausschließlich die Vergangenheit betrachtet haben, möchte ich Ihnen einen weiteren wichtigen Aspekt der aktuellen HANA-Datenbank und im Besonderen der XSA-Umgebung aufzeigen, an dem sich zeigt, dass bei der XSA entscheidende Aspekte anders als in der Vergangenheit gehandhabt werden.
1.3 Eigenentwicklungen der SAP
Wenn man das Thema »Softwareentwicklung im SAP-Umfeld« betrachtet, handelt es sich in den meisten Fällen um proprietäre Technologien. In einem SAP-System wird mit der Programmiersprache ABAP entwickelt. Diese wurde speziell von der SAP entworfen, um SAP-Anwendungen wie das ERP bzw. die Business Suite zu realisieren. Bei der Fragestellung, wie Software durch die verschiedenen Systemumgebungen wie Entwicklung, Test und Produktion transportiert werden kann, setzt die SAP auf das Transport Management System (TMS), auf Erweiterungen wie das Enhanced Change and Transport System (CTS+) und auf das SAP Change Request Management (ChaRM) – alle ebenfalls Eigenentwicklungen der SAP.
Neben der Programmiersprache und den zu verwendenden Werkzeugen unterscheidet sich bei diesen Lösungen das Vorgehen während des Entwicklungsprozesses. So wird in ABAP beispielsweise der gesamte Quellcode im Laufzeitsystem (also dem Entwicklungssystem) vorgehalten. Möchte der Entwickler seinen Quellcode ausführen, muss er ihn zunächst auf diesem System aktivieren. Eine zentrale Quellcode-Verwaltung, in der mehrere Entwickler an unterschiedlichen Versionen und Strängen der Software arbeiten, ist nicht vorgesehen.
Die Entwicklung eigener Tools unter Verwendung proprietärer Technologien hat in vielen Fällen ihre Daseinsberechtigung, denn für spezielle Anforderungen werden besondere Werkzeuge benötigt. Das Beispiel von ABAP und dem ABAP-Stack zeigt sogar, dass der Erfolg eines Produkts durch Einsatz einer solchen Technologie klar begünstigt werden kann. Das SAP-ERP-System wäre vermutlich nicht so erfolgreich geworden, hätte man es nicht mit ABAP, sondern mit einer anderen Programmiersprache entwickelt. Gerade die konsequente Ausrichtung der Sprache auf die Anforderungen eines ERP-Systems waren und sind der Schlüssel zum Gelingen. Auch die für den Entwicklungsprozess dargestellten Werkzeuge weisen erhebliche Vorteile auf und zeigen, dass eine Eigenentwicklung der SAP die SAP-Systeme bestmöglich unterstützt.
Auf der anderen Seite kann der Einsatz eigener Technologien insofern problematisch sein, als der Kreis derer, die sich damit auskennen, eher begrenzt ist. Zudem kann bei Fragen oder Problemen nicht auf große, bereits vorhandene Communitys zurückgegriffen werden. ABAP ist keine Programmiersprache, die etwa in den Universitäten oder anderen Ausbildungsstätten zum Standard für angehende IT-Experten gehört.
Ich möchte an dieser Stelle ein Beispiel für eine aus meiner Sicht weniger erfolgreiche Umsetzung einer SAP-Eigenentwicklung anführen: Java von SAP.
SAP hatte geplant, Java-Entwickler, die noch keine Berührungspunkte mit dem SAP-Universum hatten, für SAP-Entwicklungen zu gewinnen. Verständlicherweise, denn der Markt ist riesig, da Java eine der beliebtesten Programmiersprachen mit einer sehr ausgeprägten Community ist.
Um dieses Ziel zu erreichen, wurde der SAP Web Application Server (SAP WebAS, später NetWeaver AS) in zwei Varianten – als ABAP-Stack und als Java-Stack – bereitgestellt. Neue Produkte wurden entweder für den ABAP-Stack (z.B. ERP) oder für den Java-Stack (z.B. Portal) entwickelt. Einige basierten sogar auf beiden Stacks, wie der Solution Manager. Der eigene Applikationsserver im Java-Umfeld (SAP NetWeaver AS Java) wird nicht mehr weiterentwickelt und aller Wahrscheinlichkeit nach mit der aktuellen Version 7.5 auslaufen. Ebenso erging es dem Thema »Software-Logistik im Java-Umfeld« mit der Eigenentwicklung SAP NetWeaver Development Infrastructure (NWDI). Auch diese wurde nur mit mäßigem Erfolg vom Markt akzeptiert.
Java-Entwickler konnten jedenfalls nur ganz begrenzt für die SAP-Plattformen gewonnen werden. Ein Grund dafür ist meines Erachtens, dass sich viele der Java-Entwickler nicht auf die SAP-Besonderheiten einlassen wollten. Allzu häufig unterschied sich die SAP-eigene Java-Entwicklung von der allgemein bekannten, und zwar sowohl in der Programmierung als auch in dem Werkzeugkasten, der für die Entwicklung verwendet werden musste (z.B. die erwähnte SAP NWDI).
Anhand der genannten Beispiele stellt sich die Frage, welche Erkenntnisse die SAP aus den Erfahrungen mit der eigenen Java-Umgebung gezogen hat. Genau an dieser Stelle komme ich zum Thema XSA zurück, denn in der XSA-Umgebung lässt sich Software auch mittels Java entwickeln. Im Unterschied zum Ansatz des NetWeaver AS Java kann in der XSA Standard-Java-Code entwickelt werden. Es gibt fast keine Einschränkungen, wie die Sprache zu verwenden ist. Als Entwickler können Sie damit genauso entwickeln, wie Sie es außerhalb der SAP-Welt tun würden. Gerade für Programmierer, die bis dato noch keine Berührungspunkte mit SAP-Systemen hatten, ist dies ein erheblicher Vorteil.
1.4 Cloud als Strategie
Neben der Möglichkeit, eine SAP-fremde Programmiersprache wie beispielsweise Java zu verwenden, ist noch ein weiterer Aspekt wichtig, der die XSA-Umgebung als moderne Entwicklungsplattform ausweist.
Mittlerweile sind Begriffe wie »cloud native« und »cloud first« auf dem Vormarsch. Gerade bei Eigenentwicklungen ist es inzwischen maßgeblich, ob Software auch in einer Cloud-Umgebung lauffähig ist oder nicht. Aktuell drängen sowohl Softwarehersteller als auch Kunden in die Cloud und erwarten die »Cloudfähigkeit« natürlich ebenso von einer modernen Entwicklungsplattform.
Genau bei diesem Thema kann die XSA überzeugen. Die Art und Weise, wie mit der XSA-Umgebung Software entwickelt wird, basiert auf Cloud-Konzepten. Eine Anwendung, die in der XSA läuft, kann demnach auch in einer Cloud-Umgebung bereitgestellt werden.
Weitere Details zum Themenschwerpunkt »Cloud« gebe ich in Kapitel 3.
2 HANA-Plattform
In diesem Kapitel werde ich Ihnen die Architektur und die wichtigsten Funktionen der HANA-Plattform aufzeigen. Diese Grundlagen werden Ihnen helfen, die Plattform für Ihre eigenen Softwareprojekte optimal zu nutzen.
2.1 SAP HANA
Die SAP-Strategie, ausschließlich HANA als Datenbank für aktuelle SAP-Systeme zuzulassen und Produktinnovationen nur noch für HANA-basierte Systeme zur Verfügung zu stellen, hat den Vorteil, dass die Software nicht mehr wie früher eine Vielzahl von Datenbanksystemen unterstützen muss.
In den älteren SAP-Systemen – bis SAP ERP Central Component (ECC) 6.0 – hat der NetWeaver AS die Datenbankkommunikation gekapselt. Die Anwendung selbst brauchte die Unterschiede der Datenbanksysteme nicht zu berücksichtigen. Von der Nutzung spezieller Funktionen der einzelnen Datenbanken wurde aus technischer Sicht abgeraten, da sie bei Anpassungen des Datenbanksystems ggf. nicht mehr funktioniert hätten.
Durch die alleinige Nutzung von HANA als Datenbank können die spezifischen HANA-Funktionen aus den Anwendungen heraus vollumfänglich zum Einsatz kommen. Des Weiteren können bei der Entwicklung von Anwendungen sogar einige Teilfunktionen komplett in die HANA-Datenbank ausgelagert werden. In diesem Fall wird von einer nativen HANA-Entwicklung gesprochen.
2.1.1 In-Memory-Datenbank-Technologie
Ein weiterer Vorteil der HANA-Datenbank ist, dass sie alle relevanten Daten im Hauptspeicher, also »In-Memory«, hält. Kritiker sagen, dass dies auch andere Datenbanksysteme können. Diese Aussage stimmt natürlich, denn andere Hersteller von Datenbanken bieten ebenfalls eine In-Memory-Technologie für ihre Produkte.
Stark vereinfacht, geht es bei allen In-Memory-Datenbanken darum, die Zugriffszeiten auf die Daten zu optimieren. Auf Daten im Hauptspeicher kann deutlich schneller zugegriffen werden als auf Daten, die erst zeitintensiv von der Festplatte gelesen werden müssen.
Dauerhafte Speicherung der Daten
Auch bei In-Memory-Datenbanken werden die Daten im Arbeitsspeicher für eine dauerhafte Speicherung zusätzlich in das angebundene Dateisystem gespeichert. Dies ist notwendig, falls das System neu gestartet und dabei der Arbeitsspeicher geleert wird. Beim Systemstart der HANA werden die Daten dann wieder in den Arbeitsspeicher geladen. Dieser Prozess läuft vollautomatisch ab.
Die Stärken von SAP HANA sind allerdings nicht nur in der Datenbanktechnologie selbst zu suchen. Dass die Datenbank und die Anwendungen vom selben Hersteller stammen, bietet einen erheblichen Vorteil. Seit dem Beschluss, dass HANA zukünftig als alleinige Datenbank für SAP-Systeme verwendet werden soll, optimiert die SAP ihre Anwendungen Schritt für Schritt für eine Nutzung mit dieser Datenbanktechnologie. Dabei ist sie nicht mehr von den Funktionsangeboten anderer Datenbankanbieter abhängig.
Bei der von der SAP verfolgten HANA-optimierten Entwicklung spricht man vom Code Pushdown. Dessen Ziel ist es, Datenoperationen nicht mehr in einem Anwendungsserver durchzuführen, sondern direkt in der Datenbank. Die Programmlogik wird also in die Datenbank verlagert bzw. »gepushed«. Abbildung 2.1 stellt die Logik des Code Pushdown exemplarisch dar.
Abbildung 2.1: Anwendungen mit und ohne »Code Pushdown«
Anwendung 1 lädt die Datensätze 1 und 2 aus der Datenbank und führt die programmierte Logik auf diesen Daten aus. Gerade bei großen Datenmengen kann das Laden der Daten in den Applikationsserver einige Zeit in Anspruch nehmen.
Im Gegensatz dazu basiert Anwendung 2 auf dem Prinzip des Code Pushdown. Hier wird die Logik in der Datenbank selbst ausgeführt. Da dort alle Daten im Hauptspeicher gehalten werden, kann die Datenbank das Ergebnis schnell an die Anwendung zurückliefern.
Dieses Prinzip wird in allen modernen SAP-Produkten eingesetzt, um Datenoperationen zu optimieren.
2.1.2 Spalten- und zeilenorientierte Datenspeicherung
Neben der In-Memory-Technologie ist für Ihre Projekte noch ein weiterer Aspekt relevant, der dem besseren Verständnis für eine Nutzung der HANA-Datenbank-Technologie dient. Dies ist die Verwendung der spaltenorientierten (Column Store) oder zeilenorientierten Ablage (Row Store) der Tabellendaten.
Weitere spaltenorientierte Datenbanksysteme
Auch andere Hersteller, wie z.B. Oracle (12c mit In-Memory-Option) und Microsoft (SQL-Server 2012 mit dem Column Store Index Feature), bieten in ihren Produkten verschiedene Ablageoptionen. Die Technologie ist also nicht SAP- oder HANA-spezifisch.
Nachfolgend werde ich diese beiden Technologien kurz beschreiben und Ihnen die jeweiligen Vor- und Nachteile aufzeigen.
In der Vergangenheit haben die gängigsten Datenbanksysteme die Daten der Tabellen zeilenorientiert behandelt. Dabei erfolgen sowohl die Datenablage als auch der Zugriff auf die Daten zeilenweise. Im Gegensatz dazu steht die spaltenorientierte Organisation der abgelegten Daten. In der HANA-Datenbank kann sich der Entwickler je Tabelle entscheiden, welche der beiden Ablagemöglichkeiten er verwenden möchte; beide Verfahren werden unterstützt.
Um den Unterschied zwischen beiden Varianten zu verstehen, nehmen wir eine einfache Tabelle zu Hilfe. Diese betrachten wir zunächst als logische Struktur (Abbildung 2.2), wie wir sie beispielsweise aus Excel oder anderen Tabellenkalkulationstools kennen.
Abbildung 2.2: HANA-Tabelle – logische Struktur
Die Daten zur Einwohnerzahl rechts in der Tabelle sind vom Dezember 2019 [1]. Für unser Beispiel sind allerdings nicht die Daten an sich von Interesse, sondern die Art und Weise, wie diese in der Datenbank abgelegt werden. Die logische Struktur ist zweidimensional, die Ablage muss aber in eindimensionaler Form erfolgen.
Stellen wir uns die physikalische Ablage der Tabelleninhalte als eine Aneinanderreihung von Blöcken vor, bei dem jeder Block den Wert von genau einer Zelle aufnehmen kann.
Die oben gezeigte Tabelle wird bei einer zeilenorientierten Ablage wie in Abbildung 2.3 aussehen: Die Werte werden Zeile für Zeile untereinandergeschrieben.
Abbildung 2.3: HANA-Tabelle – zeilenorientierte Ablage (Row Store)
Im Gegensatz dazu speichert die spaltenorientierte Ablage jede Spalte als eigene physische Tabelle. In unserem Beispiel wären das die Tabellen Stadt, Bundesland und Einwohner.
Anschließend werden diese einzelnen Tabellen sowohl komprimiert als auch sortiert. Bei der Komprimierung werden Duplikate entfernt. In unserem Beispiel können bei den Bundesländern Blöcke eingespart werden, da NRW mehrfach vorkommt. Dies reduziert den für die Daten benötigten Speicher.
Durch die Sortierung der einzelnen Werte kann später schneller auf die Daten zugegriffen werden. Beide Schritte sehen Sie zusammengefasst in Abbildung 2.4.
Abbildung 2.4: HANA-Tabelle – spaltenorientierte Ablage (Column Store)
Tabelle 2.1: Vergleich zeilen- und spaltenorientierte Speicherung
Basierend auf dem gegebenen Beispiel, möchte ich die Vor- und Nachteile beider Speichervarianten exemplarisch zusammenfassen (siehe auch Tabelle 2.1).
Um zu entscheiden, welche Variante besser für ein gegebenes Szenario passt, sind zwei Kriterien wichtig:
die Struktur der erwarteten Daten sowie
deren spätere Verwendung.
