Whitepaper SAP HANA versus Oracle In-Memory-Systeme im Vergleich
Was ist In-Memory Computing? 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. Welche Technik steckt 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ögliche Spalten, dann nennt man dies Columnar Projection. Damit lässt sich viel Performance 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. Klassifizierung In-Memory-DBs 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 [3]. Um die neuen Datenbanken besser klassifizieren zu können, empfielt 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ögliche Spalten. Klasse 3: Höchste Performance Engine Column-basierte Datenbanken ermöglichen einen Performanz- Zugewinn um Faktor 100. Zu Klasse 3 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 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 [2]. 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 Performance 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. Seite 3
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 berichtet 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 Performance-Ziele. SAP HANA vs. Oracle Exalytics Die Oracle Exalytics In-Memory Machine ist ein Produkt, das viele Parallelen zur SAP HANA aufweist. Es handelt sich um ein 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, in dem 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. SAP HANA vs. 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-Verbindungen 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, um Kapazitäten zu sparen. 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. SAP HANA vs. 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 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. 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. In Arbeitsspeicher hingegen nutzt das Oracle System wahlweise den Row-Store- oder den Column-Format. Oracle verspricht aber trotz dieses Overheads einen geringeren CPU Overhead bei Updates dieser beiden Stores. Seite 4
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. 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 andere 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. Die SAP HANA erlaubt zwar nur eine Datenbank in der Produktionsumgebung, aber für Test und Entwicklung können mehrere Datenbanken zum Einsatz kommen. Bei Oracle sind so viele DBs erlaubt, wie die Hardware zulässt. 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. Unterschiede in der Lizenzierung Beim Betrieb der SAP HANA müssen nur produktive Datenbanken lizenziert werden, Datenbanken für Test und Entwicklung sind lizenzfrei. Die SAP HANA wird entweder pro 64 GB RAM lizenziert oder als SAP Maintenance Base Value, einer Rundum-Lizenz, die sämtliche SAP Software-Produkte sowie weitere Produkte einschließt, die sich unter der Lizenz von SAP oder eines autorisierten Distributors befinden. Bei Oracle mussen nicht nur Produktivdatenbanken, sondern auch Test- und Entwicklungs-Datenbanken lizenziert werden. Oracle Datenbanken werden nicht anhand der Verwendung des Arbeitsspeichers sondern nach CPU Core in der Enterprise Edition lizenziert. Fazit 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 entscheidener Vorteil der SAP HANA gegenüber der Oracle Exalytics Machine besteht in ihrer Eignung für OLTP. Oracle hat hier echte Konkurrenz bekommen. Die Datenbank Version 12.1.0.2.0 mit In-Memory-Option verspricht nun allerdings eine echte Alternative für SAP Kunden, die bereits Oracle Systeme betreiben, denn sie haben nun keine Code-Änderungen mehr zu befürchten, wenn die auf Oracle 12.1.0.2.0 migrieren. Seite 5
Quellen [1] Gartner Inc. Market Share Analysis: ERP Software, Worldwide, 2012, https://www.gartner.com/doc/2477517/market-shareanalysis-erp-software Mark Fontecchio Oracle the clear in $24 billion RDBMS market, Blogbeitrag auf Tech Target Experts Community, 2012, Link: http://itknowledgeexchange.techtarget.com/eye-on-oracle/ oracle-the-clear-leader-in-24-billion-rdbms-market [2] SAP SE Newscenter SAP and Partners Set New Record for World s Largest Data Warehouse, 2014, Link: http://www.news-sap.com/ sap-and-partners-set-new-record-for-worlds-largest-datawarehouse/#sthash.ezphqmth.dpuflink: http://www.newssap.com/sap-and-partners-set-new-record-for-worlds-largestdata-warehouse/ [3] Data Base Fog Blog: https://robklopp.wordpress.com/author/ robklopp/ Über den Autor Unser Solution Architect Andrew Lacy verfügt über eine mehr als 20- jährige Erfahrung in der IT-Branche. Seit 1997 beschäftigt er sich beruflich mit Oracle Datenbanken. Seine besonderen Schwerpunkte liegen im Bereich Hochverfügbarkeitslösungen, Backup und Recovery, Lizenzierung und Monitoring. Über OPITZ CONSULTING OPITZ CONSULTING trägt als führender Projektspezialist für ganzheitliche IT-Lösungen zur Wertsteigerung von Unternehmen bei und bringt IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich die Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen. OPITZ CONSULTING wurde 1990 gegründet und beschäftigt heute an neun Standorten mehr als 400 Mitarbeiter. Zum Kundenkreis zählen ¾ der DAX30-Unternehmen sowie branchenübergreifend mehr als 600 bedeutende Mittelstandsunternehmen. Portfolio Das Portfolio von OPITZ CONSULTING umfasst die folgenden Leistungsschwerpunkte: IT-Beratung: Die IT-Experten unterstützen ihre Kunden dabei, die organisatorischen Grundlagen für eine verbesserte Wertschöpfung durch die Informationstechnologie zu schaffen. Transparente und effektive Strukturen im IT-Management sind hier grundlegend. Mit positiven Konsequenzen für das gesamte Unternehmen: bessere Kontrolle über aktuelle IT-Kosten, effektiverer Ressourceneinsatz, stabilere Planungsbasis für die Zukunft und zufriedene Anwender. Business-Lösungen: In enger Zusammenarbeit mit seinen Kunden entwickelt das Projekthaus innovative, differenzierende und individuelle Business-Lösungen. Hierbei unterstützen die Spezialisten den gesamten Plan-Build-Run-Zyklus. Auf Wunsch übernehmen sie die Verantwortung für Wartung und Weiterentwicklung der Lösungen über den gesamten Lebenszyklus, mittels Application Lifecycle Management, kurz: OC ALM. Managed Services: Unsere Teams für Managed Services Application (OC MSA ) und Managed Services Infrastructure (OC MSI ) kümmern sich rund um die Uhr, remote oder vor Ort um die Applikationen und Systeme ihrer Kunden. Dabei übernehmen sie die Wartung, die Weiterentwicklung und die Modernisierung von Applikationen, sowie die Administration, die Wartung und den Betrieb von IT -Infrastrukturen. Proaktiv werden die Kunden auf mögliche Risiken und Engpässe hingewiesen. Training und Coaching: Das Oracle University Schulungszentrum von OPITZ CONSULTING bietet ein umfangreiches Schulungsprogramm in den Bereichen Oracle, SOA, Java und Business Intelligence. Die Trainings werden flexibel auf Kunden oder Projekte zugeschnitten und auf Wunsch auch inhouse durchgeführt. Die Trainer kommen direkt aus der Praxis und verfügen neben fundiertem theoretischem Wissen über langjährige Projekterfahrung. Trends: Gemeinsam mit dem Kunden konzipieren und implementieren die IT-Experten innovative und differenzierende Lösungen. Hierzu beschäftigen sie sich permanent mit neuen Trends und evaluieren diese Hype-Themen hinsichtlich der möglichen Nutzung in den Kundenprojekten. Seite 6
Folgen Sie uns: youtube.com/opitzconsulting @OC_WIRE slideshare.net/opitzconsulting xing.com/net/opitzconsulting Weitere Infos auf www.opitz-consulting.com