In-Memory-Techniken im Vergleich
Werbung
Speicherung in Zeilen Block „100“ Speicherung in Spalten Block „2000“ Block „2001“ Block „2002“ ProductID OrderDate Cost 310 20010701 2‘171.29 ProductID OrderDate Cost 311 20010701 1‘912.15 310 20010701 2‘171.29 312 20010701 2‘171.29 311 20010702 1‘912.15 Block „101“ ProductID OrderDate Cost 313 20010701 4‘171.20 314 20010702 1‘812.25 315 20010702 1‘171.30 313 2‘171.29 314 4‘171.20 315 1‘812.25 312 1‘171.30 Spalte statt Zeile Die spaltenorientierte Ablage von Daten in einer entsprechend organisierten Datenbank erlaubt höhere Kompressionsraten und eine schnellere Abfrage von Daten – vor allem im Hauptspeicher. Quelle: Trivadis In-Memory-Techniken im Vergleich: Alles hängt vom Einsatzszenario ab Lange fristeten In-Memory-Datenbanken ein Nischendasein. Doch neue Techniken und sinkende Speicherpreise machten das Thema wieder populär. Nachdem SAP mit HANA eine eigene In-Memory-Datenbank entwickelt hatte, zogen IBM, Microsoft und Oracle nach und rüsteten ihre Datenbanken mit entsprechenden Funktionen aus. Doch die Ansätze unterscheiden sich. Von Peter Welker, Partner und Berater für Big Data und Data Warehousing bei Trivadis und verantwortlich für Big Data bei der DOAG D er Zugriff auf den Arbeitsspeicher eines Rechners (Random Access Memory = RAM) erfolgt bis zu eine Million Mal schneller als bei herkömmlichen Festplatten. Beim Datendurchsatz liegt der Geschwindigkeitsvorteil immerhin noch knapp um den Faktor 100 höher. Dazu kommt, dass die Preise für Arbeitsspeicher pro Jahr um durchschnittlich 30 Prozent sinken. Gleichzeitig werden die Prozessoren für fast alle Architekturen immer leistungsfähiger. Trotz dieser Entwicklungen im Markt 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. Da dies nicht mehr zeitgemäß ist, haben verschiedene Anbieter in den zurückliegenden Jahren ihre Entwicklungsabteilungen auf das Thema angesetzt und neue In-MemoryPlattformen auf den Markt gebracht. SAP HANA Angetreten mit dem Ziel, Altlasten abzuschütteln und den lukrativen Markt der DatenbankManagement-Systeme (DBMS) aufzurollen, präsentierten Entwickler des Hasso-PlattnerInstituts (HPI) und der Universität Stanford 2008 erstmals Beispiele einer relationalen In-Memory-Datenbank für Realtime-Analysen. Zunächst noch ironisch unter dem Titel „Hassos New Architecture“ geführt – eine Anspielung auf SAP-Gründer Hasso Plattner, der die Entwicklungen persönlich massiv vorangetrieben hatte –, entstand daraus zwei Jahre später „SAP HANA“, die „High-Performance Analytic Appliance“. Damit zielte der größte deutsche Softwarekonzern darauf ab, verschiedene Datenbankanforderungen in einer einzigen Plattform, ja sogar in einem einzigen Datenbestand abzubilden – sowohl für den transaktionalen Einsatz 2015 – 13 Technik (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-IntelligenceAufgaben aufheben und damit einen 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. Heute zeichnet sich ab, dass die In-Memory-Datenbank als Basis unter sämtliche SAP-Software gelegt werden soll. HANA ist konsequent darauf ausgelegt, alle Daten im Hauptspeicher zu halten. Die Datenbank nutzt dafür intensiv CPU-Caches und organisiert die Daten vorwiegend spaltenorientiert – statt, wie bisher in klassischen Relationalen Datenbank-ManagementSystemen (RDBMS) üblich, in Zeilen. Zudem komprimiert HANA die Daten im RAM sowie auf Festplatte und parallelisiert Datenoperationen innerhalb der CPU-Cores bei Multicore-Systemen und sogar über mehrere Rechenknoten hinweg. Mit HANA sorgte SAP für frischen Wind in der weltweiten Datenbankszene. Mit einem Mal wurden bestehende IT-Systeme infrage gestellt: Werden analytische Abfragen jetzt auch eine Million Mal schneller und vielleicht sogar online verfügbar? Sollen wir uns von Data Warehouses und älteren DBMS trennen? Ist der von SAP aufgebaute Vorsprung noch einholbar? Der Druck auf die traditionellen Datenbankanbieter wuchs, und schon bald zogen diese mit eigenen In-Memory-Lösungen nach. Allerdings unterscheiden sich die Ansätze voneinander. IBM DB2 BLU Acceleration Im April 2013 hat IBM das In-Memory-Funktionspaket „BLU Acceleration“ als Teil seiner Advanced Editions der DB2-Datenbank vorge- stellt. Im Prinzip kommen dabei dieselben Techniken wie bei HANA zum Einsatz. Allerdings integriert IBM diese einfach in die eigene Technik und erlaubt damit die Koexistenz herkömmlicher und Memory-optimierter Tabellen innerhalb ein und derselben Datenbank. Diese Tabellen lassen sich zudem von einem Format in das andere umwandeln und sollen nach Angaben von IBM gut optimierbare Abfragen um den Faktor acht bis 40 beschleunigen können. Darüber hinaus würden 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 analytische Workloads ausgerichtet. Im Produktiveinsatz sollte OLTP also weiterhin auf zeilenorientierten Tabellen betrieben werden. Microsoft SQL Server In-Memory Database Auch Microsoft folgte mit seinem SQL Server dem Trend: Schon mit Release 2012 konnten Anwender für komplexe Abfragen auf Tabellen spezielle spaltenorientierte, komprimierte In-Memory-Indizes erzeugen. Damit wurde es möglich, die Analytik spürbar zu beschleunigen. Die Indizes werden jedoch zusätzlich zur normalen Tabelle aufgebaut und müssen nach jeder Änderung manuell neu erstellt werden. Mit dem neuen SQL Server 2014 sind sie hingegen aktualisierbar. In Version 2014 der Microsoft-Datenbank kam mit „In-Memory OLTP“ eine neue Lösung ausschließlich für die Beschleunigung von Transaktionen auf operativen Systemen wie ERP- und CRM-Anwendungen hinzu. Tabellen dieser Art müssen dabei komplett im Hauptspeicher gehalten werden. Sie ermöglichen für transaktionsintensive Anwendungsfälle deutliche Performance-Zuwächse. Nach Angaben von Microsoft liegen diese je nach Anwendungsfall bei Faktor 100 oder sogar noch höher. Auch hier existieren die In-Memory- neben den herkömmlichen Tabellen in der gleichen Datenbank und können fast In-Memory-Datenbanken – Technik und Lösungen Eine In-Memory-Datenbank (IMDB) lädt sämtliche Daten in den Hauptspeicher des Rechners, vor allem um kürzere Antwortzeiten zu erreichen. Der Arbeitsspeicher eines Rechners bietet wesentlich höhere Zugriffsgeschwindigkeiten als Festplattenlaufwerke, und die Algorithmen für den Zugriff sind einfacher. Allerdings ist RAM ein flüchtiger Speicher. Um die Daten bei einem Systemabsturz gegen Verlust zu sichern und einen möglichst hohen Grad an Persistenz sicherzustellen, müssen die Anbieter von IMDB spezielle Techniken mit Snapshots, Replikation und Failover-Techniken in ihre Systeme einbauen. Grundsätzlich lässt sich eine In-Memory-Lösung wie eine herkömmliche relationale Datenbank ansprechen. Allerdings sind dafür die betreffenden Applikationen an die Funktionen der Datenbank anzupassen. Der bloße Einsatz der In-MemoryTechnik garantiert also noch lange keine zuverlässigen Performance-Vorteile. Neben den Anpassungen ihrer klassischen Datenbanksysteme haben gerade die großen Anbieter dedizierte In-Memory-Lösungen im Portfolio. Oracle hat beispielsweise im Jahr 2005 den Anbieter Times Ten übernommen und dessen gleichnamiges InMemory-System seitdem kontinuierlich weiterentwickelt. IBM hat zwei orignäre In-Memory-Produkte im Softwareprogramm: Das mit dem Cognos-Kauf 2008 übernommene System „TM1“ ist einer der ältesten In-Memory-Ansätze der Industrie. Applix, das 2007 von Cognos geschuckt worden war, hatte die Lösung bereits 1984 entwickelt. Außerdem hatte IBM im Jahr 2007 bereits mit „Solid DB“ eine In-MemoryLösung zugekauft. 27 Fazit Eine Antwort auf die Frage, welcher In-Memory-Ansatz der richtige ist, hängt von den individuellen Einsatzszenarien ab. Unternehmen sollten in jedem Fall alle technischen, organisatorischen und kostenrelevanten Besonderheiten differenziert betrachten – für eine Neuentwicklung wie auch bei einer Anwendungsmigration. Nur wenige Anwendungsfälle profitieren ohne weitere Anpassungen von In-Memory-Technik. Zudem werden Performance-Vorteile nicht bei allen Anwendungen möglich sein, manchmal kommt es sogar zu Leistungseinbußen. In einigen Fällen muss man auch mit funktionalen Einschränkungen leben. Vor der Einführung einer In-Memory-Datenbank sollte also eine gründliche Evaluation stattfinden. Auch im Falle einer vermeintlich einfachen Umstellung auf 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. Fakt ist, dass die Lösungen in bestimmten Anwendungsszenarien sowohl im OLTP- als auch im OLAP-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 geringer ausfallen. Doch durch die In-MemoryTechnik lassen sich in vielen Fällen Kosten für Hardware und Lizenzen einsparen. Diese Kostensenkungen werden aber erst nach der Umsetzung sichtbar. Denn der Umstieg ist fast immer mit Applikationsanpassungen verbunden –der damit verbundene Aufwand muss in die Gesamtkostenrechnung einfließen. In-Memory-Datenbanken sind eine Bereicherung der Datenbankwelt. Aber sie eignen sich nicht für jeden Anwendungsfall und sollten vor dem Einsatz umfassend geprüft werden. 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 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 der 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 zehn bis 100 erreichen. Anders als andere 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 Festplatten-relevanten Operationen werden mit den althergebrachten Mitteln abgewickelt und redundant, aber konsistent für die In-Memory-Strukturen mitgezogen. Daraus ergeben sich einerseits Nachteile wegen redundanter Ressourcenbelastung sowie der fehlenden Kompression auf Festplatte. Andererseits gibt es aber auch einen besonderen Vorteil dieser Vorgehensweise: „In-Memory“ ist bei Oracle lediglich ein Schalter, mit dem sich Tabellen oder auch nur Teile von Tabellen für In-Memory-Verarbeitung optimieren lassen. Es müssen also keine Daten migriert werden, um von den neuen Möglichkeiten zu profitieren. Gemeinsamkeiten und Unterschiede Die Stoßrichtung der klassischen großen Datenbankanbieter ist klar: Der Wechsel auf eine andere, separate In-Memory-Plattform wie SAP 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 mit Hilfe von In-Memory-Funktionen um ein Vielfaches zu beschleunigen. Aber ist das wirklich realistisch? Es fällt schnell auf, dass alle neuen InMemory-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 der Festplatte. Es gibt aber auch erkennbare Unterschiede der 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 von Microsoft 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 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 der 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 Tabellentypen, IBM hingegen Tabellentypen für rein analytischen Work­ load. 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 DataManipulation-Language-(DML-)Durchsatz verbessert werden soll. (ba)
