IN RAM we trust!
Werbung
BI & Big Data 2015 IN RAM we trust! In-­‐Memory-­‐Datenbanken In-Memory-Datenbanken fristeten über lange Zeit ein Nischendasein als Cache traditioneller relationaler Datenbanken oder als spezielle Data-Warehouse-Lösungen. Erst mit SAP HANA trat das Thema ins Rampenlicht – und zwang IBM, Oracle und Microsoft zum Handeln. Der Zugriff auf RAM-Speicher ist bis zu eine Million Mal schneller als bei herkömmlichen Festplatten und selbst beim Datendurchsatz sind es immerhin noch knapp Faktor 100. Die Preise für Arbeitsspeicher sinken pro Jahr durchschnittlich 30 Prozent. Gleichzeitig werden die Prozessoren für fast alle Architekturen immer leistungsfähiger. Trotzdem sind die meisten Zugriffsverfahren in Datenbanken 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äß? eBook 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 www.it-daily.net, Juli 2015 Seite 56 BI & Big Data 2015 HANA ist konsequent darauf ausgelegt, alle Daten im Hauptspeicher zu halten. Die Datenbank nutzt dafür sehr intensiv CP- Caches, organisiert die Daten vorwiegend spaltenorientiert – statt wie bisher üblich in Zeilen. 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 BusinessIntelligence-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-Cores bei Multicore-Systemen und sogar über mehrere Rechenknoten hinweg. Und plötzlich stellte man bestehende IT- Systeme infrage: Werden analytische 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 mit eigenen In-Memory-Lösungen den Markt. IBM DB2 BLU Acceleration Im April 2013 uwrde das In- Memory-Funktionspaket „BLU Acceleration“ als Teil der Advanced Editions der IBM DB2 Datenbank veröffentlicht. Im Prinzip kommen dabei die selben Techniken wie bei HANA zum Einsatz. Allerdings eBook integriert IBM diese einfach in die eigene Technik und erlaubt die Koexistenz herkömmlicher und Memoryoptimierter Tabellen innerhalb derselben Datenbank. Diese Tabellen können von einem Format in das andere umgewandelt werden und sollen nach Aussage von IBM gut optimierbare Abfragen um den Faktor 8-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 der Microsoft SQL-Server folgte dem Trend: Schon mit dem SQL-Server Release 2012 konnten für komplexe Abfragen auf Tabellen spezielle spaltenorientierte, komprimierte In-Memory-Indizes erzeugtw erden. 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 Transaktionen auf operativen Systemen wie ERPs oder CRMs hinzu. Tabellen dieser Art müssen dabei komplett im Hauptspeicher gehalten werden. Sie ermöglichen für transaktionsintensive Anwendungsfälle dabei deutliche Performancezuwächse – nach Angaben von Microsoft je nach Anwendungsfall um 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. www.it-daily.net, Juli 2015 Seite 57 BI & Big Data 2015 Die Oracle-Datenbank funktioniert ähnlich wie IBM BLU Acceleration und soll je nach Anwendungsfall Performancesteigerungen von Faktor 10 bis 100 erreichen. „In Memory“ ist bei Oracle lediglich ein Schalter. 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 InMemory-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 Performancesteigerungen von Faktor 10 bis 100 erreichen. Im Gegensatz zu anderen Lösungen schreibt die Oracle-Datenbank jedoch keinerlei In-Memory-Daten auf Festplatte. Spaltenorientierte Datenhaltung, automatische Indexierung, 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-MemoryStrukturen mitgezogen. Daraus ergeben sich einerseits Nachteile wegen redundanter Ressourcenbelastung sowie der fehlenden Kompression auf Festplatte. Andererseits gibt 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. eBook www.it-daily.net, Juli 2015 Seite 58 BI & Big Data 2015 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. 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 umlegen, um alle Applikationen damit um ein Vielfaches zu beschleunigen. Aber ist das wirklich realistisch? Es fällt schnell auf, dass alle neuen In-MemoryDatenbanken ä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 Festplatte. Es gibt aber auch erkennbare Unterschiede bei den einzenen 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 B2 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, OLTPoptimierte Tabellentypen, IBM hingegen Tabellentypen für rein analytischen Workload. SAP HANA unterscheidet mitunter nach Bedarf zwischen zeilen- und spaltenorientierter eBook 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 Indexe auf Tabellen nötig sind und somit der DML Durchsatz verbessert werden soll. Welcher In-­‐Memory-­‐Ansatz ist der Richtige? Für Unternehmen stellen sich im Grunde zwei Fragen: Welcher In Memory Ansatz ist der richtige und auf welche Lösung soll ich setzen? 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 Performancevorteile 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 RDBMS 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. www.it-daily.net, Juli 2015 Seite 59 BI & Big Data 2015 Durch die In-Memory-Technologie lassen sich in vielen Fällen Kosten für Hardware und Lizenzen einsparen. Lohnt sich die In-­‐Memory-­‐Technologie? Für IT-Entscheider stellt sich am Ended ie Frage, ob sich ein Umstieg auf In-Memory-Technologie lohnt, auch oder gerade wenn es sich in manchen Fällen nur um ein Upgrade der bestehenden Systeme handelt. Fakt ist, dass die Lösungen in bestimmten Anwendungsszenarien so wohl 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 Performancegewinn 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 werden. 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. Peter Welker www.trivadis.de Weitere Informationen: • Webinar HANA: https://wind-soft.de/de/webinarnext-generation-bi-sap-hana-plattform • Video Oracle (4 Teile): https://www.youtube.com/watch?v=kJ_6L8Sd098 • Video IBM DB2 und Oracle: https://www.youtube.com/watch?v=TqKyokfzXb4 Peter Welker „Nach wie vor sind die meisten Zugriffsverfahren in Daten-­‐ banken 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äß?“ eBook www.it-daily.net, Juli 2015 Seite 60
