Andrew Lacy 11. Februar 2015

SAP HANA oder Oracle – welcher Hersteller hat heute bei In-Memory-Systemen die Nase vorn?

Oracle beherrscht seit Jahren unangefochten den Markt der Datenbankhersteller. Hingegen gibt der größte Konkurrent des Softwareanbieters, die SAP, bei ERP-Systemen den Ton an [1]. Doch das Kräfteverhältnis scheint sich derzeit zu verändern.

Zahlreiche Produkte von SAP sind heute noch Oracle zertifiziert und laufen daher auf den Datenbanken des Wettbewerbers. Auf diese Installationen hatten es die Walldorfer abgesehen, als sie mit SAP HANA ein Komplettsystem mit In-Memory-Komponenten entwickelten, das die Oracle Datenbanken der Kunden zukünftig ersetzen kann. Die Rechnung scheint aufzugehen, denn die HANA erobert derzeit sehr erfolgreich den Markt.

Oracle hat echte Konkurrenz bekommen. © depositphotos.com / rbhavana

Was ist an dieser Datenbank so außergewöhnlich, und worin genau unterscheidet sie sich von den Oracle Systemen, die ebenfalls In-Memory-Technologien anbieten? In diesem Artikel vergleichen wir die SAP HANA im Detail mit Oracle Exalytics, Oracle Exadata und der In-Memory-Option des 12.1.0.2.0 Oracle Datenbank-Releases. Aber zunächst nehmen wir die In-Memory-Technologie an sich etwas genauer unter die Lupe.

Abb. 1: Die Marktverhältnisse bei RDMS und ERP (Quelle: Gartner Inc.)

Was ist unter In-Memory-Computing zu verstehen?

In-Memory-Computing ist dort relevant, wo es darum geht, die Daten in einer Datenbank zu analysieren. Diese Analyse dauert normalerweise sehr lange und so bemühen sich Administratoren, unnötige Abfragen an eine Datenbank zu vermeiden.

In-Memory-Technologien bringen jetzt eine neue Geschwindigkeit in die Systeme. Diese Technologie ist so schnell, dass eine Datenbank in die Lage versetzt wird, Ad-hoc-Abfragen in Sekundenbruchteilen zu beantworten. Die neuen Systeme können also ganze Abfrageketten in kürzester Zeit bearbeiten. Der Anwender stellt eine Frage an die Datenbank und formuliert mit den Erkenntnissen der Antwort bereits eine neue Frage. Ein Dialog in Echtzeit entsteht.

Die Technik dahinter

Eine normale Datenbank speichert ihre Daten im Row-Store-Format. Ähnlich wie ein Excel-Sheet werden die Daten hier in Reihen und Spalten abgelegt. Eine In-Memory-Computing-Datenbank speichert ihre Daten dagegen im Column-Store-Format. Dabei werden Daten, die gleiche Werte in den Spalten haben, zusammen gespeichert. Diese Methode ermöglicht eine hohe Komprimierung der Daten und verbessert die Performanz bei den Analysen. Wenn die Datenbank nur die Spalten liest, die notwendig sind, und nicht alle möglichen Spalten, dann nennt man dies Columnar Projection. Damit lässt sich viel Performanz gewinnen. Wenn die Datenbank Engine auch column-basiert ist, erreicht man dazu eine um den Faktor 100 erhöhte Performanz.

Die In-Memory-Technologie eignet sich aber nicht nur für Reporting und Business Analytics; sie kann auch mit OLTP (OnLine Transaction Processing) umgehen. In-Memory-Systeme beinhalten eine Datenbank für den Normalbetrieb und benutzen die gleiche Datenbank für Reporting und Business Analytics. Reporting und OLTP werden also in einem System vereint. Um so ein System handelt es sich bei der SAP HANA.

Unterschiedliche Klassen von In-Memory-Datenbanken

Am Markt sind viele In-Memory-Datenbanken erhältlich. Doch woran erkenne ich die Qualität einer solchen Datenbank? Diese Frage stellte sich Rob Klopp, Senior Director, Technology & Innovation für die SAP HANA bei SAP und Autor des Blogs Database Fog Blogs [2]. Um die neuen Datenbanken besser klassifizieren zu können, empfiehlt der Datenbankspezialist die folgende Einteilung:

Klasse 1 - „Hohe Komprimierung“: Hier werden Datenbanken eingeordnet, die Daten im Column-Format speichern. Die Oracle Exadata mit einer Datenbank-Version vor 12.1.0.2.0 mit Advanced-Compression-Option entspräche demnach dieser Klasse.

Klasse 2 - „Verbesserte Performance“: In diese Klasse gehören Datenbanken mit Columnar Projection, die also nur die Spalten lesen, die für eine Abfrage benötigt werden und nicht alle möglichen Spalten.

Klasse 3 - „Höchste Performanz“: Engine column-basierte Datenbanken ermöglichen einen Performanz-Zugewinn um Faktor 100.
Zu dieser Klasse zählen diese Datenbanken:

SAP HANA
IBM DB2 Blu
Hekaton (MSSQL 2014)
Oracle 12.1.0.2.0 mit In-Memory-Option
Andere (z. B. HP Vertica, SAP Sybase IQ, Actian Paraccel)

SAP HANA im Detail

SAP HANA ist eine „Appliance“, also ein System, in dem Hardware und Software kombiniert sind. Die Software darin stammt von SAP selbst, die Hardware hingegen von zehn unterschiedlichen Herstellern: IBM, Dell, HP, Fujitsu, Cisco, Hitachi, Lenovo, NEC, Huawei und VCE. Das System ist erhältlich als 2-CPU, 2 TB Single Server oder als Scale-Out Cluster mit 2 bis 56 Server Clustern. Cluster mit noch mehr Servern befinden sich in der Testphase. Das größte Data Warehouse der Welt mit 12 Petabyte läuft auf einer SAP HANA mit 111 Servern [3].

Die SAP HANA kann Daten sowohl im Row-Format als auch im Column-Store-Format ablegen. So ist es beispielsweise besser, Reporting- und Analyse-Daten im Column-Store-Format zu speichern, OLTP-Daten dagegen sind im Row-Store-Format besser aufgehoben. Das Produkt gibt es seit November 2011. Seitdem kam alle sechs Monate eine neue Software-Version heraus. Damit verspricht SAP eine schnelle Weiterentwicklung dieser Datenbank.

SAP Lösungen sind immer konfiguriert. Diese Konfiguration erfolgte in der Vergangenheit oft mithilfe der herstellereigenen Programmiersprache ABAP. 98% des ABAP-Codes funktionieren auf der SAP HANA. Das bedeutet, dass immerhin 2% nicht funktionieren und angepasst werden müssen. Der Hersteller stellt Tools zur Verfügung, um dysfunktionalen ABAP-Code zu finden.

Bis jetzt war es beim SAP Stack relativ egal, welche Datenbank für die Applikationen benutzt wurde. Die Business-Logik befand sich in der Applikationsschicht, die Datenbank wurde nur benutzt, um Daten zu speichern. Bei der SAP HANA ist das nun anders. Um ein Maximum an Performanz zu erreichen, muss man die Applikationslogik in die Datenbankschicht bringen. D.h. der Anwender muss das System auf eine angepasste Version der Applikation migrieren oder es mit eigenen Applikationen oder Konfigurationen anpassen.

So kommt es, dass man die SAP HANA nicht per „Plug and Play“ migrieren kann, sondern ihre Applikation nach der Überführung noch im Detail anpassen muss. Bei einem SAP Training in Walldorf berichtete mir ein Coach, der auch als Consultant tätig ist, von der Migration einer SAP ERP Datenbank auf SAP HANA, die er vor Kurzem vorgenommen hatte. Nach der Migration sei ein Drittel der Funktionalität sofort schneller, ein weiteres Drittel gleich und ein Drittel sogar langsamer gewesen als vorher. Erst nach einem mehrwöchigen Tuning-Prozess erreichte der Spezialist die eigentlichen Performanz-Ziele.

Vergleich SAP HANA und Oracle Exalytics

Die Oracle Exalytics In-Memory-Machine ist ein Produkt, das viele Parallelen zur SAP HANA aufweist. Es handelt sich um eine Appliance, die ebenfalls eine In-Memory-Datenbank beinhaltet: die Oracle TimesTen Datenbank. Wie SAP HANA eignet sich Oracle Exalytics für den Einsatz im Business-Intelligence-Umfeld. Obwohl Oracle Exalytics schon fast so lange am Markt ist wie das SAP System – sie kam im Februar 2012 – kennen nur wenige diese Oracle Variante.

Wie bei SAP HANA muss auch bei Oracle Exalytics die ganze Datenbank in den Arbeitsspeicher passen. Die Größe der Datenbank ist dadurch stark eingeschränkt. Bei SAP HANA kann der Anwender diese Grenze umgehen, indem er ein SAP HANA Cluster aufbaut. Bei Oracle Exalytics gibt es diese Möglichkeit nicht, deshalb ist hier nur ein Teil des Data Warehouse
analysierbar.

Exalytics gibt es in zwei Versionen: der Linux-basierten Version X3-4 mit 2 TB RAM und der Solaris-basierten Variante T5-8 mit 4 TB RAM. Ein typisches kleines Data Warehouse ist vielleicht 10 TB groß. Klar ist, dass so ein Server nicht das ganze Data Warehouse im Arbeitsspeicher halten kann. Nur ein Subset der Daten passt in dieses System. Es gibt aber Tools, mit denen sich genau dieses Daten-Subset identifizieren lässt. Als Workaround für die 2-TB-Grenze gibt es bei der SAP HANA die Multi-Server-Lösung Scale-Out. Für die Exalytics hat Oracle keine vergleichbare Lösung vorzuweisen.

Bei der Oracle Exalytics Machine stammen sowohl die Software als auch die Hardware von Oracle; es handelt sich also um eine reine Oracle Appliance. Das ist ein Vorteil gegenüber der SAP HANA, bei der nur die Software von SAP ist. Im Fehlerfall hat man hier mit diversen Hardware- und Software-Firmen zu tun.

Die Oracle TimesTen Datenbank ist zwar eine ideale Lösung für Business-Intelligence-Vorhaben, sie kann aber kein OLTP. Hier haben die Nutzer der SAP HANA die Nase vorn, weil diese mit OLTP und OLAP beide Technologien anbietet.

Vergleich SAP HANA und Oracle Exadata

Oracle Exadata ist eine High-end-Datenbank-Appliance mit höchster Performance-Leistung. Die Exadata besitzt eine 44 TB Flash Disk, bei Komprimierung steigt das Speichervolumen auf über 80 TB. Netzwerk-Verbin-dungen gehen über Infiniband mit einer Geschwindigkeit von 40 Gb/s. Doch die Oracle Exadata verfügt nicht nur über eine Performance-optimierte Hardware-Zusammenstellung, sie enthält auch eine ganz clevere Lösung auf der Storage-Ebene. Mithilfe von Smart Scan merkt sich das System beispielsweise, welche Werte in einem Block gespeichert sind. Somit kann die Exadata auf der Storage-Ebene irrelevante Blöcke einfach weglassen, gibt diese Blöcke nicht an den Datenbank Server zurück und spart dadurch viele I/O Ressourcen.

SAP Kunden die momentan Oracle Datenbanken verwenden, können ohne Applikationsänderung sofort auf Oracle Exadata migrieren. Bei SAP HANA ist das nicht der Fall.

Die Datenbank muss bei der Oracle Exadata nicht komplett im Arbeitsspeicher residieren, wie es bei der SAP HANA Datenbank der Fall ist. Die Oracle Exadata verwendet Platte, Flash Disk und Arbeitsspeicher.

Bei der Oracle Exadata handelt es sich immer um einen RAC (Real Application Cluster), also nicht um einen Single Server, sondern um einen mehrere Server umfassenden Cluster. Zwar ist auch bei der SAP HANA Datenbank ein Cluster möglich, aber die Daten sind dort nur einem Server zugeordnet. Bei Oracle Exadata hingegen sind die Daten für alle Server verfügbar. Diese Differenz macht sich bei der Performanz der Datenbank bemerkbar, da alle Server eine Abfrage gleichzeitig abarbeiten können.

Vergleich: SAP HANA und Oracle 12.1.0.2.0

Die Oracle Datenbank Version 12.1.0.2.0 bietet als Zusatzoption
In-Memory-Funktionalitäten an. Sie beinhaltet die Enterprise Edition nebst einer In-Memory-Option. Die In-Memory-Option gibt es nicht für die Standard Edition und die Standard Edition One.

Bei der SAP HANA muss man für jede Tabelle entscheiden, ob diese Daten im Row-Store- oder im Column-Store-Format gespeichert werden sollen. Bei der Oracle 12.1.0.2.0 In-Memory-Option sind die Daten immer in Row-Store und optional auch in Column-Store gespeichert. Für OLTP zahlt sich das besonders aus.

Die SAP HANA unterscheidet bei den Speicherformaten nicht danach, ob die Daten im Arbeitsspeicher oder auf Disc vorgehalten werden. Die Oracle 12.1.0.2.0 In-Memory-Option speichert die Daten auf Disc immer im Row-Store-Format. Im Arbeitsspeicher bei Oracle sind die Daten immer im Row-Store-Format gehalten, wahlweise auch im Column-Format. Oracle verspricht aber trotz dieses Overheads einen geringeren CPU Overhead bei Updates dieser beiden Stores.

Beim Oracle Real Application Cluster (RAC) der 12.1.0.2.0 Datenbank-Version sind die Daten im Row-Format auf der Platte gespeichert. Die Column Stores existieren nur im Arbeitsspeicher. Bei einem Neustart der Server muss der Column Store neu aufgebaut werden. Bei der SAP HANA müssen die Daten dagegen nur in den Arbeitsspeicher geladen und nicht umgewandelt werden.

Hochverfügbarkeit: Die SAP HANA schließt eine Standby-Lösung mit ein, bei der ein zweiter Server alle Änderungen spiegelt und im Disaster-Fall übernehmen kann. Oracle hat seine Standby-Lösungen schon länger im Betrieb und stellt darüber hinaus auch noch einige Funktionalitäten mehr bereit.

Dataguard Delayed Apply: Eines dieser zusätzlichen Features ist das Oracle Dataguard Delayed Apply. Dieses Tool kommt zum Tragen, wenn ein Benutzer versehentlich Daten löscht. Es sorgt dafür, dass die Daten schnell und ohne ein aufwändiges Datenbank-Restore wieder verfügbar sind. Die SAP HANA hat keine vergleichbare Funktion in ihrem Leistungsumfang.

Synchronous Apply: Ein weiteres Feature der Oracle Datenbank ist Synchronous Apply, bei dem das System nicht erst auf ein Log Switch wartet, sondern die Daten sofort auf das Standby-System schickt. Der Datenverlust bei einem Server Crash kann so auf ein Minimum reduziert werden.

Maximum Protection: Maximum Protection ist ein exklusives Feature bei Oracle, mit dessen Hilfe ein Commit nur endet, wenn die Änderungen auch auf der Standby-Maschine appliziert sind. Die Verwendung bietet sich allerdings nur an, wenn man mehr als einen Standby Server betreiben möchte. Hierdurch ist ein Zero Data Loss garantiert.

Active Data Guard: Beim Active Data Guard von Oracle ist der Standby Server auch dann fürs Reporting verfügbar, wenn gerade Änderungen erfolgen. SAP HANA hat diese Funktionalität nicht.

Cluster Datenbank: Bei der SAP HANA verteilen sich die Daten über alle Knoten in einem Cluster. Wenn sich die Last auf bestimmte Datenbereiche konzentriert, liegt sie also unter Umständen auf nur wenigen Knoten. Beim Absturz eines Cluster-Knotens ist ein Teil der Daten dann möglicherweise nicht verfügbar, bis dieser Knoten wieder hochfährt. Wenn man bei der SAP HANA noch einen Knoten im Cluster hinzufügen will, bedeutet das eine Downtime für den ganzen Cluster. Beim Oracle RAC hingegen sind alle Daten jederzeit verfügbar.

Weitere technische Aspekte

Security auf der Datenbank-Ebene garantiert sichere Daten, egal ob der Anwender mit den BI-Tools einer Java-Anwendung oder mit der Command Line auf die Datenbank zugreift. Werkzeuge für diesen Zweck, wie Data Masking oder DBA Vault, gibt es nur bei Oracle. Data Masking erlaubt nur bestimmten Benutzern den Zugriff auf alle Daten. So sehen alle anderen User z. B. nur die letzten vier Ziffern einer Kreditkartennummer. DBA Vault verhindert Zugriffe der Datenbankadministratoren auf die Daten.

Bei der SAP HANA bedeutet Backup immer ein Voll-Backup. Hier gibt es kein Incremental Backup. Wenn ein Backup- oder ein Produktiv-System auf einem 8-Knoten-Cluster basiert, dann kann auch ein Restore nur auf einem ebensolchen 8-Knoten-Cluster erfolgen und z. B. nicht auf einem 4-Knoten-Testsystem.

Vergleich Lizenzierung

Bei SAP HANA müssen nur produktive Datenbanken lizenziert werden. Die Lizenzen für Test- und Entwicklungsdatenbanken sind in der Lizenz der produktiven Datenbanken enthalten.

Die SAP HANA wird je nach Einsatzzweck beispielsweise pro 64GB RAM lizenziert oder als bestimmter Prozentsatz der SAP Maintenance Base Value (SMBV). SMBV ist die Summe alle Lizenzen, die sämtliche SAP Software-Produkte sowie weitere Produkte einschließt, die sich unter der Lizenz von SAP oder eines autorisierten Distributors befinden.

Oracle Enterprise Edition Datenbanken werden nicht anhand der Verwendung des Arbeitsspeichers sondern nach CPU Core oder nach Einzelbenutzer lizenziert. Es sind alle Server oder Cluster zu lizenzieren, auf denen die Datenbank installiert ist und/oder läuft.

Zusammenfassung

SAP HANA ist zwar aufgrund der notwendigen Anpassungen in ABAP-Code und Applikation keine Plug-and-Play-Datenbank, bei der die Applikationslogik in die Datenbank verlegt wurde. Aber entsprechend getuned ist sie extrem performant und schafft mit ihrer Geschwindigkeit neue Möglichkeiten für den BI-Bereich. Der entscheidende Vorteil der SAP HANA gegenüber der Oracle Exalytics Machine besteht in ihrer Eignung für OLTP. Oracle hat hier Konkurrenz bekommen.

Die Datenbank Version 12.1.0.2.0 mit In-Memory-Option verspricht nun allerdings eine Alternative für SAP-Kunden, die bereits Oracle Systeme betreiben, denn sie haben nun keine Code-Änderungen mehr zu befürchten, wenn sie auf Oracle 12.1.0.2.0 migrieren.