Oracle Database: In-Memory
Oracle In-Memory Database soll die Antwortzeit von Datenbankanwendungen drastisch verkürzen, indem Subsets der Daten im Column Store der Datenbank zwischengespeichert werden. Günther Stürner (Oracle) im Gespräch mit "Informatik Aktuell".
Informatik Aktuell: Wie sind die Erfahrungen Ihrer Kunden: Ist die neue Technologie in jedem Fall schneller?
Günther Stürner: Die Oracle In-Memory Option stellt eine spalten-orientierte Repräsentation einer Tabelle, einer Partition oder von einzelnen Spalten einer Tabelle dar. Diese Art der Repräsentation hat eine Reihe von sehr interessanten Vorteilen gegenüber der satzorientierten Buffer-Cache Repräsentation, insbesondere im Bereich Reporting und Analytics. Hier sehen wir teilweise extreme Performance-Verbesserungen. Auch im Bereich von gemischten Systemen, etwa aus OLTP und Analytics, sehen wir erstaunliche Ergebnisse: extrem gute Performance bei Reports und gleichzeitige Verbesserung der OLTP-orientierten Anwendungsteile, obwohl wir auf der Transaktionsseite keine expliziten Änderungen im Code durchgeführt haben. Die Verbesserungen bei OLTP kommen dabei durch einen Nebeneffekt zustande. Durch Nutzung des In-Memory Column Stores sind oft eine Vielzahl von analytischen Indices nicht mehr notwendig. Weniger Index-Pflege bedeutet hier schlicht bessere Performance und als weiterer Seiteneffekt weniger Plattenplatz. Bei 100 Prozent OLTP-orientierten Systemen macht diese neue Option aber wenig Sinn.
Informatik Aktuell: Wie wurde die Oracle-Lösung denn intern umgesetzt?
Günther Stürner: Die Grundidee bei unserer Lösung war, das Beste aus zwei Welten zu vereinen: Die satzorientierte Verarbeitung, wie wir sie bei Oracle seit Anbeginn kennen und schätzen, mit der spalten-orientierten Verarbeitung. Die Nutzung der Vorteile beider Repräsentationen war eines der wichtigsten Ziele. Die vollständige und optimale Integration dieser neuen Spaltentechnologie in das Oracle Eco-System war ein weiterer wichtiger Designaspekt. Eine Aufgabe, die auf den ersten Blick wie die Quadratur des Kreises erscheint. Das Ergebnis ist, so glaube ich zumindest, extrem gut gelungen. Wir haben die bisherige Row-Repräsentation auf den Platten und im Buffer-Cache unverändert gelassen. Wird ein DB-Objekt als ‚inmemory‘ Objekt definiert, wird es automatisch in den neuen Column-Store (Teil der SGA) eingelagert (transformiert, komprimiert und transportiert). Beide Repräsentationen sind gleichzeitig nutzbar und vorhanden. Alle DML-Operationen laufen ab wie bekannt, alle internen Prozesse werden wie immer genutzt.
Informatik Aktuell: Wie wird die Persistenz der Daten gesichert? Wie bisher über die Transaktionslogs? Oder gibt es hier Änderungen in der Architektur?
Günther Stürner: Hier gibt es keinerlei Unterschiede zu den Systemen ohne In-Memory Option. Redo-Log, Undo-Segmente, etc. werden behandelt wie bisher auch, denn alle Transaktionen werden über die bekannten Mechanismen des Buffer-Caches abgewickelt. Der Column-Store selbst ist eine reine In-Memory Repräsentanz und spielt bei der Persistierung der Daten keine Rolle. Natürlich muss der Column-Store synchron mit dem Buffer-Cache und der Plattenrepräsentation gehalten werden. Dies wird durch sehr effiziente Mechanismen, Datenstrukturen und Prozesse erreicht.
Informatik Aktuell: Was ist beim Praxiseinsatz von In Memory zu beachten?
Günther Stürner: Wer die In-Memory Option einsetzen will, muss auch den entsprechenden zusätzlichen Hauptspeicherbereich zur Verfügung stellen. Der Column-Store ist ein neuer Bereich in der SGA und die Größe dieses Bereiches gibt vor, wieviele Tabellen, Partitionen, Spalten etc. man als spaltenorientierte Repräsentation vorhalten kann.
Die zweite Aufgabe ist, zu bestimmen, welche Objekte in diesem Column-Store eingelagert werden sollen. Hierbei hilft ein Advisor, der auf Grund der bisherigen Zugriffsprofile auf die Objekte eine Vorschlagsliste liefert.
Das Definieren der Columnar-Objekte selbst ist extrem einfach: "alter table xxx inmemory" erledigt diese Sache. Genauso einfach nimmt man ein Objekt aus dem Store: "alter table xxx no inmemory". Ist ein Objekt als In-Memory Objekt definiert, wird es immer dann genutzt, wenn der Optimizer den Zugriffsweg über den Column-Store als den effizientesten und schnellsten ermittelt. Alle SQL-Befehle laufen wie immer, nur meist schneller.
Informatik Aktuell: Welche Hürden gibt es bei der Umstellung? Worauf ist zu achten?
Günther Stürner: Es ist eigentlich keine richtige Umstellung. Es ist eher eine Definition. Vergleichbar mit dem Anlegen eines Indexes. Sehr einfach.
Informatik Aktuell: Gibt es Konstellationen, in denen andere Lösungen besser sind?
Günther Stürner: Es gibt sicherlich Konstellationen und Anwendungsfälle bei denen andere Technologien mehr Sinn machen, das ist ohne Zweifel der Fall. In-Memory ist immer gut, aber es gibt auch Situationen, bei denen andere geniale Ideen noch besser sind. Auch ist eine Kombination von unterschiedlichen Technologien inkl. In-Memory Columnar oft das Maß aller Dinge. Oracle Text, eine Technologie, die eine extrem gute Voll-Textrecherche zur Verfügung stellt, wird durch In-Memory nicht abgelöst, kann aber durch In-Memory optimiert werden. Der Text-Index, die Basis von Oracle Text, kann im Column-Store vorgehalten werden, was unter Umständen die Text- Zugriffsgeschwindigkeit nochmals verbessert. Mein persönliches Highlight ist In-Memory Columnar kombiniert mit "result_cache" – unschlagbar schnell. Diese Kombination ist nicht überall einsetzbar, aber dort wo es Sinn macht ist sie das Maß der Dinge.
Informatik Aktuell: Wie wird aus technischer Sicht der Wechsel von einer Standard Oracle-Datenbank auf Oracle In-Memory durchgeführt? Gibt es einen Parameter, der umzusetzen bzw. zu aktivieren ist? Wird einfach nur der Cache hochgesetzt? Wie findet die Umstellung einer bestehenden Datenbank genau statt?
Günther Stürner: Das ist eine sehr einfache Sache. Man definiert über einen neuen init.ora Parameter die Größe der Column-Stores. Zum Beispiel inmemory_size=100GB. Man benennt die Objekte, die im Column-Store vorgehalten werden sollen und ist damit fertig!
Informatik Aktuell: Sind Schnittstellen oder Clients anzupassen? Oder verhält sich die In-Memory-Option komplett transparent?
Günther Stürner: Nein, keinerlei Anpassungen sind notwendig. Wirklich keine! Dies ist auch eine schöne Möglichkeit, Anwendungen mit und ohne In-Memory zu testen. Man schaltet für eine Session die In-Memory-Funktion aus (alter session set inmemory_query=disable) und wieder an (alter session set inmemory_query=enable). So kann man das Verhalten und die Performance studieren.
Informatik Aktuell: Können Sie schon etwas zur Lizenzierung sagen? Soweit man hört, ist die In-Memory Option ein Zusatz für die Enterprise Edition. Ist das richtig?
Günther Stürner: Die Oracle12c In-Memory Technologie wird als Oracle DB Enterprise Option angeboten. Damit steht sie für alle Oracle12c EE Plattformen zur Verfügung (AIX, HP-UX, Linux, Solaris, Windows). Alle EE Optionen sind kostenpflichtig. Der Preis ist aktuell noch nicht bekannt.
Die Oracle12c In-Memory Option muss lizenziert werden. Der Aufwand um ein System als In-Memory System zu nutzen und die Auswahl der Objekte ist ein sehr überschaubares Projekt.
Informatik Aktuell: Vielen Dank für das Interview, Herr Stürner.