Arbeiten im Arbeitsspeicher

Transkript

1

2 IT-STRATegIen In-Memory-Technologie Arbeiten im Arbeitsspeicher In-Memory-Datenbanken fristeten über lange Zeit ein Nischendasein als Cache für traditionelle relationale Datenbanken oder als spezielle Data-Warehouse-Lösungen. Erst mit SAP HANA trat die Technologie, bei der sämtliche Daten im Arbeitsspeicher gehalten werden, ins Rampenlicht und zwang die Platzhirsche im Datenbankmarkt zum Handeln. Peter Welker

3 Der Zugriff auf RAM-Speicher ist bis zu eine Million Mal schneller als bei herkömmlichen Festplatten und selbst beim Datendurchsatz ist es immerhin noch knapp Faktor 100. Die Preise für Arbeitsspeicher sinken pro Jahr durchschnittlich um 30 Prozent. Gleichzeitig werden die Prozessoren für fast alle Architekturen immer leistungsfähiger. Trotzdem sind die meisten Zugriffsverfahren in Datenbanken immer noch auf dem algorithmischen Stand der 80er- und 90er-Jahre: Sie sind auf ein möglichst effizientes Zusammenspiel von Festplatte und RAM ausgerichtet. Doch ist das noch zeitgemäß? Der Vorreiter: SAP HANA Um diese Altlasten abzuwerfen und natürlich um durch technischen Fortschritt den lukrativen Markt der Datenbankmanagementsysteme (DBMS) aufzurollen präsentierten Entwickler des Hasso Plattner Instituts und der Universität Stanford 2008 erstmals Beispiele ihrer relationalen In-Memory-Datenbank für Real-Time-Analysen. Zunächst noch ironisch unter dem Titel Hassos New Architecture geführt, entstand daraus zwei Jahre später SAP HANA, die High-Performance Analytic Appliance. Ziel war die Einsatzfähigkeit einer einzigen Plattform, ja sogar eines einzigen Datenbestandes sowohl für den Online-Einsatz (Online Transaction Processing, OLTP) als auch für analytische Zwecke (Online Analytical Processing, OLAP). Die Entwickler wollten die bisher harte und aufwendige Trennung zwischen operativen und Business-Intelligence- Aufgaben eliminieren und damit einen außerordentlichen Produktivitätsvorteil für den Einsatz dieser Appliance schaffen. Dennoch kam HANA 2011 zunächst nur für das SAP Business Warehouse auf den Markt. Seit Mitte 2013 war es dann auch für operative SAP-Module verfügbar. HANA ist konsequent darauf ausgelegt, alle Daten im Hauptspeicher zu halten. Die Datenbank nutzt dafür sehr intensiv CPU-Caches, organisiert die Daten vorwiegend spaltenorientiert statt wie bisher üblich in Zeilen. Zudem komprimiert sie die Daten im RAM und auf Festplatte und parallelisiert Datenoperationen innerhalb der CPU-Kerne bei Multicore-Systemen und sogar über mehrere Rechenknoten hinweg. Und plötzlich stellte man bestehende IT-Systeme infrage: Werden analy tische Abfragen jetzt auch eine Million Mal schneller und vielleicht sogar online verfügbar? Sollen wir uns jetzt von Data Warehouses und älteren DBMS trennen? Ist der durch SAP aufgebaute Vorsprung noch einholbar? Der Druck auf die traditionellen Datenbank-Anbieter wie IBM wuchs und schon bald bereicherten sie den Markt mit eigenen In-Memory- Lösungen. Bis heute gleicht natürlich kein Ansatz dem anderen und eignet sich gleichermaßen für unterschiedliche Einsatzzwecke. IBM DB2 BLU Acceleration Im April 2013 wurde das In-Memory- Funktionspaket BLU Acceleration als Teil der Advanced-Editions der IBM-Datenbank DB2 veröffentlicht. Im Prinzip kommen dabei dieselben Techniken wie bei HANA zum Einsatz. Allerdings integriert IBM diese einfach in die eigene Technik und erlaubt die Koexistenz herkömmlicher und In- Memory-optimierter Tabellen innerhalb derselben Datenbank. Diese Tabellen können von einem Format in das andere umgewandelt werden und sollen nach Aussage von IBM gut optimier bare Abfragen um den Faktor acht bis 40 beschleunigen. Darüber hinaus werden durch Komprimierung sowohl im RAM als auch auf Festplatte bis zu 90 Prozent Speicherplatz eingespart. Im Gegensatz zu HANA ist BLU Acceleration heute aber noch klar auf analytischen Workload ausgerichtet. Im Produktiveinsatz sollte OLTP also weiterhin auf zeilenorientierten Tabellen durchgeführt werden. Microsoft SQL Server In-Memory Database Features Auch Microsoft folgte mit seinem SQL Server dem Trend: Schon mit dem SQL Server Release 2012 konnten für komplexe Abfragen auf Tabellen spezielle spaltenorientierte, komprimierte In- Memory-Indizes erzeugt werden. Damit wurde es möglich, die Analytik spürbar zu beschleunigen. Die Indizes werden jedoch zusätzlich zur normalen Tabelle erstellt und müssen nach jeder Änderung manuell neu erstellt werden mit dem neuen SQL Server 2014 sind sie hingegen aktualisierbar. In Version 2014 kam mit In-Memory OLTP eine neue Lösung ausschließlich für die Beschleunigung von Transakti- Der autor Peter Welker Partner und Berater für Big Data und Data Warehousing bei trivadis. er verfügt über 25 Jahre It-Projekterfahrung als entwickler und Lösungsarchitekt. als autor verschiedener Fachbücher, referent und Keynote-Speaker auf Data-Warehouse- und Datenbank-Konferenzen ist er mit diesen themen seit Jahren bestens vertraut. Darüber hinaus ist Welker bei der Deutschen oracle-anwendergruppe (DoaG) für das thema Big Data verantwortlich. 31

4 IT-STRATegIen In-Memory-Technologie Die HANA-Plattform von SAP orga nisiert die Daten vorwiegend spalten orientiert statt wie bisher üblich in Zeilen. onen in operativen Systemen wie ERP oder CRM hinzu. Tabellen dieser Art müssen dabei komplett im Hauptspeicher gehalten werden. Sie ermöglichen für transaktionsintensive Anwendungsfälle dabei deutliche Performance-Zuwächse nach Angaben von Microsoft je nach Anwendungsfall um den Faktor 100 oder sogar noch mehr. Auch hier existieren natürlich In- Memory-Tabellen friedlich neben herkömmlichen Tabellen in der gleichen Datenbank und können fast beliebig miteinander kombiniert werden. Damit hat Microsoft zwei getrennte Lösungen für OLTP und Analysen im Programm. Oracle Database In-Memory-Option Im Juli 2014 zog endlich auch Oracle nach und stattete seine 12c-Datenbank mit einer kostenpflichtigen In-Memory-Zusatzoption aus. Diese besteht im Wesentlichen aus einem In-Memory Column-Store zur Beschleunigung analytischer Abfragen, ist aber aufgrund ihrer Bauart teilweise auch für OLTP- Anwendungsfälle einsetzbar. Die Oracle-Datenbank funktioniert ähnlich wie IBM BLU Acceleration und soll je nach Anwendungsfall Performance-Steigerungen von Faktor 10 bis 100 erreichen. Im Gegensatz zu anderen Lösungen schreibt die Oracle-Datenbank jedoch keinerlei In- Memory-Daten auf die Festplatte. Spalten orientierte Datenhaltung, automatische Indizierung, Kompression sämtliche Operationen laufen ausschließlich im Hauptspeicher ab. Alle festplattenrelevanten Operationen werden dabei mit den althergebrachten Mitteln durchgeführt und redundant, aber konsistent für die In- Memory-Strukturen mitgezogen. Daraus ergeben sich einerseits Nachteile wegen der redundanten Ressourcenbelastung sowie der fehlenden Kompression auf der Festplatte. Andererseits gibt es aber auch einen besonderen Vorteil dieser Vorgehensweise: In-Memory ist bei Oracle lediglich ein Schalter, mit dem sich online Tabellen oder auch nur Teile von Tabellen In-Memory optimieren lassen. Es müssen also keine Daten migriert werden, um von den neuen Möglichkeiten zu profitieren. Dies macht einen Test also besonders einfach. Gemeinsamkeiten und Unterschiede Die Stoßrichtung der Großen Drei ist klar: Der Wechsel auf eine andere, separate In-Memory-Plattform wie HANA soll künftig nicht mehr nötig sein. Im einfachsten Fall braucht der Administrator in bestehenden Datenbanken nur einen Schalter umzulegen, um alle Applikationen damit um ein Vielfaches zu beschleunigen. Aber ist das wirklich realistisch? Es fällt schnell auf, dass alle neuen In-Memory-Datenbanken ähnliche Mechanismen nutzen. Dazu gehören die spaltenorientierte Datenhaltung, automatisch erzeugte und hauptspeicheroptimierte Datenstrukturen sowie eine intensive Nutzung von CPU-Features und die Komprimierung von Daten im Hauptspeicher und/oder auf der Festplatte. Es gibt aber auch erkennbare Unterschiede bei den einzelnen Lösungen. Da ist zunächst die Frage einer Limitierung der Datenbankgröße durch den verfügbaren Hauptspeicher. SAP HANA und die SQL-Server-OLTP-Lösung müssen In-Memory-Daten spätestens bei der ersten Abfrage vollständig in den Hauptspeicher laden, während Oracle und IBM DB2 dies nicht erfordern und somit die Arbeit mit größeren Datenmengen vereinfachen. Hinzu kommt, dass bei Oracle komprimierte Daten nicht in komprimierter Form auf Storage-Datenträger geschrieben werden. Sie müssen nach einem Restart der Datenbank wieder neu aufgebaut werden. Dieser Ansatz bietet zwar mehr Flexibilität bei Administration und ein breiteres Einsatzspektrum, spart aber keinen Platz auf Datenträgern und erzeugt Redundanzen in der Verarbeitung. Und dann ist da noch die Art der nutzbaren Applikationsarten: Microsoft offeriert spezielle, OLTP-optimierte Tabel- 32 Business&IT

5 lentypen, IBM hingegen Tabellentypen für rein analytischen Workload. SAP HANA unterscheidet mitunter nach Bedarf zwischen zeilen- und spaltenorientierter Datenhaltung und unterstützt beide Arten von Workload. Oracle platziert seine Lösung hauptsächlich für den analytischen Bereich, verspricht aber auch Verbesserungen für OLTP- Applikationen, weil weniger Indizes auf Tabellen nötig sind und somit der DML-Durchsatz verbessert werden soll. Welcher Ansatz ist der richtige? Für Unternehmen stellen sich im Grunde zwei Fragen: Welcher In-Memory- Ansatz ist der richtige und welche Lösung soll ich kaufen? Mögliche Antworten darauf lassen sich jedoch nicht verallgemeinern, sondern sind von individuellen Einsatzszenarien abhängig. Unternehmen sollten in jedem Fall alle technischen, organisatorischen und kostenrelevanten Besonderheiten differenziert betrachten sowohl für eine Neuentwicklung als auch bei einer Anwendungsmigration. Sie sollten wissen, dass nur wenige Anwendungsfälle ohne weitere Anpassungen profitieren werden und sie in entsprechende Leistungen investieren müssen. Darüber hinaus werden die Performance-Vorteile nicht bei allen Anwendungen möglich sein und können diese sogar verlangsamen. In einigen Fällen wird man auch mit funktionalen Einschränkungen leben müssen. Vor der Einführung einer In-Memory- Datenbank sollte eine gründliche Evaluation stattfinden sowohl beim Wechsel auf eine neue Plattform als auch bei einer geplanten Migration. Auch im Falle einer vermeintlich einfachen Umstellung auf die In-Memory-Technik innerhalb des vertrauten DBMS ist es ratsam, die jeweils geeigneten Daten zu identifizieren und alle Anwendungsfälle ausführlich zu überprüfen. Dies kann entweder mit eigenen Teams oder durch einen externen Dienstleister geschehen. Fazit: Lohnt sich die In-Memory-Technologie? Für IT-Entscheider stellt sich am Ende die Frage, ob sich ein Umstieg auf die In-Memory-Technologie lohnt auch oder gerade wenn es sich in manchen Fällen nur um ein Upgrade bestehender Systeme handelt. Fakt ist, dass die Lösungen in bestimmten Anwendungsszenarien sowohl im OLTP als auch im analytischen Bereich deutlich schneller und effizienter arbeiten als bisher übliche Techniken. Allerdings lassen sich nur sehr abgegrenzte Prozesse um die oben erwähnten Faktoren beschleunigen im Durchschnitt wird der Performance-Gewinn deutlich geringer ausfallen. Doch durch die In-Memory-Technologie lassen sich in vielen Fällen Kosten für Hardware und Lizenzen einsparen. Diese Kostensenkungen werden jedoch erst nach der Umsetzung sichtbar, denn der Umstieg auf die neue Technologie ist fast immer mit Applikationsanpassungen verbunden, die in die Gesamtkostenrechnung einfließen müssen. In-Memory-Datenbanken sind eine echte Bereicherung der Datenbankwelt. Aber sie eignen sich nicht für jeden Anwendungsfall und sollten vor der sprichwörtlichen Bindung an eine neue Technologie umfassend geprüft werden. [ rm ] Der Zugriff auf den Arbeitsspeicher erfolgt deutlich schneller als auf normale Festplatten. 33