create mobile friendly website
in memory column store

In-Memory-Option der Oracle Database 12c

Einfach und schnell mit dem
In-Memory Column Store?

In diesem Artikel stellen wir den In-Memory Column Store der Oracle Database 12c vor. Es wird gezeigt, wie einfach das Setup dieses neuen Speicherbereiches ist und welche Optionen es für den Aufbau gibt. Zudem zeigen wir Ihnen, wie überprüft werden kann, ob der In-Memory Column Store bei einer Abfrage auch tatsächlich genutzt wurde.

Voraussetzung & Ziel

Oracle Database In-Memory ist eine neue Option der Oracle Enterprise Edition 12c und daher kostenpflichtig.

Das neue Speicherformat im In-Memory Column Store ermöglicht ein schnelleres Ausführen von Scans, Joins und Aggregationen als die traditionellen On-Disk-Formate. Gleichzeitig wird die Performance beim Reporting in OLTP- und Data-Warehouse-Umgebungen gesteigert.

Das neue Format ist besonders geeignet für analytische Applikationen, die im Gegensatz zu OLTP-Operationen auf wenigen Spalten ausgeführt werden und viele Zeilen zurückgeben. Analytische Indizes werden durch das In-Memory-Format überflüssig.

Dual Format

Der In-Memory Column Store ist ein neuer Pool in der SGA (siehe Abbildung 1). Die für diesen Pool ausgewählten Objekte (Tabellen mit häufigem Zugriff, Partitionen, Subpartitionen) werden in ein Spaltenformat konvertiert und nach einem neuen Kompressionsalgorithmus in drei möglichen Stufen komprimiert. Jedes dieser Objekte befindet sich weiterhin in einer 1:1-Beziehung zu einem Objekt auf Platte im Zeilenformat.

Alle Datenformate auf der Disk für permanente Heap-Tabellen und alle Objekttypen wie Partitionen, Materialized Views, Materialized Join Views, Materialized View Logs und Inline LOBs werden durch den In-Memory Column Store unterstützt. Ausgenommen sind lediglich Clustered Tables und Index Organized Tables (IOT).

Die In-Memory-Datenstruktur wird In-Memory Column Unit (IMCU) genannt. Konventionelle Datenbankblöcke sind 8 KB groß. Die IMCUs sind um ein Vielfaches größer. Die genaue Anzahl der Zeilen pro IMCU wird zur Laufzeit festgelegt und basiert auf der Tabellengröße, der Struktur und den Memory-Beschränkungen.

Beim ersten Zugriff auf eine In-Memory-Tabelle durch eine Abfrage oder nach einem Startup der Datenbank werden die IMCUs allokiert. Bei jedem Neustart der Instanz konvertiert die Tabelle vom Zeilen- in das Spaltenformat, da sich die Kopie der Tabelle im Spaltenformat nur im Memory befindet. Nach der Konvertierung steht die In-Memory-Version der Tabelle nach und nach für Abfragen zur Verfügung. Ist eine Tabelle erst teilweise konvertiert, können Abfragen die konvertierten Teile der In-Memory-Version nutzen und den Rest von der Disk oder aus dem Buffer Cache holen, um nicht auf die komplette Konvertierung warten zu müssen.

Der neue Hintergrundprozess IMCO ist eine Art Scheduler, der für das Befüllen und den Refresh der In-Memory Column Units mit Objekten zuständig ist. Um ein Objekt im In-Memory Column Store zu aktualisieren, werden zusätzlich die Hintergrundprozesse SMCO und Wnnn benötigt.

Setup

Grundsätzlich muss ein dedizierter Cache innerhalb der SGA definiert sein. Die Größe des In-Memory Column Store wird über den statischen Parameter INMEMORY_SIZE festgelegt. Über den Parameter INMEMORY_FORCE kann die grundsätzliche Nutzung deaktiviert werden (per Default ist die Nutzung aktiviert). Über den Session Parameter INMEMORY_QUERY kann anschließend die eigentliche Nutzung innerhalb einer Session einschränkt werden (siehe Abbildung 2).

Aktivierungen

Das Enablen des Attributes INMEMORY ohne Vergabe einer Priorität bedeutet nicht, dass ein Objekt sofort in das Spaltenformat des In-Memory Column Store konvertiert wird. Es wird erst dann konvertiert, wenn eine Abfrage gestellt wird, die sich auf dieses Objekt bezieht.

Es ist auch möglich, das Attribut INMEMORY für eine Untermenge zu setzen oder ihr zu entziehen. Eine Tabelle kann mit dem Attribut INMEMORY versehen werden, während einzelne Spalten (im Beispiel c1) ausgeschlossen werden können.

CREATE TABLE BIG_TABLE (…) INMEMORY NO INMEMORY (c1);
ALTER TABLE BIG_TABLE NO INMEMORY (c1);

Dies führt jedoch zu einem Fehler, wenn versucht werden sollte, einzelne Spalten in einer NO INMEMORY-Tabelle mit dem Attribut INMEMORY zu versehen.

Die View V$IM_COLUMN_LEVEL zeigt, welche Spalten einer In-Memory-Tabelle (nicht) im In-Memory Column Store liegen.

Prioritäten

Des Weiteren können Prioritäten für einzelne Objekte vergeben werden, die in das Spaltenformat des In-Memory Column Store konvertiert werden sollen. Durch diese Prio­ritäten wird der In-Memory Column Store unterschiedlich verzögert befüllt. Hier gibt es vier mögliche Prioritäten: LOW, MEDIUM, HIGH und CRITICAL. Das Attribut PRIORITY wird beim Statement CREATE TABLE oder ALTER TABLE mitgegeben, wie das folgende Beispiel zeigt:

CREATE [ALTER] TABLE BIG_TABLE (…) INMEMORY PRIORITY MEDIUM;

Die View V$IM_SEGMENTS zeigt, ob die Objekte für den In-Memory Column Store vollständig konvertiert wurden.

Falls für ein Objekt keine Priorität vergeben wurde, so wird es erst nach einer Abfrage oder einem Instanz Startup in das Spaltenformat des In-Memory Column Store konvertiert. Gibt es Objekte mit höherer Priorität, die den Platz beanspruchen, so landet ein Objekt wegen niedrigerer Prio­rität und einem Mangel an Platz eventuell gar nicht oder nur zum Teil im In-Memory Column Store.

Komprimierung

Durch die Klausel MEMCOMPRESS wird ein möglicher Kompressionslevel für ein Objekt im In-Memory Column Store definiert. Folgende Kompressionslevel können gesetzt werden:

  • NO MEMCOMPRESS
    Es wird nichts komprimiert.
  • MEMCOMPRESS FOR QUERY [LOW|HIGH]
    Es wird ein Kompressionsalgorithmus genutzt, der zu Gunsten von besserer Performance weniger Platz spart. FOR QUERY LOW ist der Default, wenn nur MEMCOMPRESS definiert wurde.
  • MEMCOMPRESS FOR CAPACITY LOW
    Der Zusatz FOR CAPACITY nutzt einen Algorithmus, der eine Balance zwischen hoher Kompression und guter Abfrage-Performance sucht. Der Zusatz LOW kann auch weggelassen werden.
  • MEMCOMPRESS FOR CAPACITY HIGH
    Dieser Algorithmus komprimiert noch stärker als die Variante LOW.
  • MEMCOMPRESS FOR DML
    Die Kompression ist minimal und optimiert für die DML Performance.

Die View V$IM_SEGMENTS zeigt die Kompressionsrate.

Monitoring

Die Session-Statistiken und der Ausführungsplan einer Abfrage zeigen, ob diese gegen den In-Memory Column Store oder den Buffer Cache ausgeführt wurde (Abbildung 3).

Was macht die Abfrage so schnell?

Die spaltenbezogene Speicherung hat bei den typischerweise in einem Data Warehouse verwendeten Abfragen auf Wertebereiche und mit wenigen abgefragten Spalten Vorteile gegenüber der satzbezogenen Speicherung. Die satzbezogene Speicherung ist dafür bei OLTP-typischen Einzelsatzabfragen und vielen Spalten vorteilhaft.

Hinzu kommt der höhere Komprimierungsfaktor, sodass geringere Datenmengen aus dem In-Memory-Speicher zu lesen sind. Die Filterprüfung (WHERE-Klausel und Join-Prüfungen) wendet das System direkt auf die komprimierten Daten an, ohne sie zuvor zu dekomprimieren. Oracle nutzt hierfür ein neu entwickeltes Komprimierungsverfahren, bei dem die Daten im komprimierten Zustand interpretiert werden können.

Die Join-Bedingungen löst das System mittels Bloom-Filtering. Kleine Tabellen, wie die meisten Dimensions­tabellen in einem Star-Schema, wandelt das System in einen Bloom-Filter (eine Art Hash-Tabelle) um und sendet sie direkt zur größeren Faktentabelle. Schon bei dem Zugriff auf die Faktentabelle greift der Join-Filter.

Verfügt das System über mehrere CPU-Kerne, so erhält jeder Kern ein eigenes Bloom-Filter-Objekt und arbeitet direkt die ihm zugeordneten Faktentabellensätze ab.

Aggregationen (GROUP BY) löst das System mit so genannten „Report Outlines“. Ein einmal berechnetes Aggregationsergebnis merkt sich das System dynamisch für nachfolgende Abfragen. Praktisch entsteht „On-The-Fly“ ein OLAP-Würfelim Speicher.

Sinnvolle Anwendungen

Durch die In-Memory-Funktionalität sind Performance-Steigerungen bei bestimmten Abfragen zu erwarten. Zu diesen Abfragen gehören große Scans unter Verwendung von Prädikatfiltern auf eine einzelne Spalten (=, <>, <, <=, >, >=, IN, NULL, NOT NULL, LIKE, SUBSTRING). Effektiv ist das neue Spaltenformat aber auch bei einer Abfrage weniger Spalten auf eine Tabelle mit vielen Zeilen. Weitere sinnvolle Anwendungen sind ein Join einer kleinen Tabelle gegen eine große und die im letzten Abschnitt genannten Aggregationsergebnisse.

Fazit

Die In-Memory-Funktionalität lässt sich schnell und auf den ersten Blick auch sehr einfach umsetzen, da keine Änderungen an bisherigen Anwendungen notwendig sind. Für einzelne Abfragen sind deutliche Performance-Steigerungen möglich. Es stellt sich jedoch die Frage, welche Objekte Kandidaten für diesen Speicherbereich sind.

Auch bei einer Eingrenzung auf die genannten sinnvollen Anwendungen ist der verfügbare Hauptspeicher der limitierende Faktor. Passen nicht alle ausgewählten Kandidaten in den neuen Speicherbereich, so beeinflussen die zu vergebenen Attribute die Kompression und Priorität, ob ein Objekt vollkommen oder nur zum Teil ins Spaltenformat konvertiert wird. Statistiken und Ausführungspläne sollten daher überprüft und der neue Speicherbereich gepflegt werden.

Klaus Reimers
()

ORDIX aktuell

ORDIX sucht Nachwuchs auf der hobit 2017
Mit der hobit 2017 hat die ORDIX AG vom 24. bis 26.01.2017 das erste Mal an der Darmstädter Ausbildungsmesse teilgenomme...
Weiterlesen ...
Lesestoff zum Weihnachtsfest: ORDIX®   news 2/2016
​Die aktuelle ORDIX® news 2/2016 hält zum Ende des Jahres wieder interessante Artikel rund um die IT bereit. Ob Big Data...
Weiterlesen ...
ORDIX auf der DOAG Konferenz und beim Schulungstag
Gefüllte Zuhörerplätze bei unseren Vorträgen und höchste Teilnehmerzahlen beim Schulungstag zeugen vom Erfolg und der Be...
Weiterlesen ...

Kostenloses Kundenmagazin

Abbildungen

Die vollständigen Artikel mit allen Abbildungen finden Sie im blätterbaren PDF.
Eine Übersicht über alle Artikel sowie das PDF zum Download finden Sie im Inhaltsverzeichnis.

Impressum

Impressum der ORDIX® news 1/2015

Link

[1] Oracle Database 12c Release 12.1.0.2 Documentation

Bildnachweis

© istockphoto.com | tiero | file cabinet and folder
© psdgraphics.com | computer database psd icon