Die Oracle-In-Memory-Architektur

Der Parameter inmemory_size kann nicht dynamisch verkleinert werden. Für eine Vergrößerung muss der zusätzliche Platz in der SGA verfügbar sein. Die In-Memory Area besteht aus folgenden Bereichen:

• In-Memory Compression Units (IMCU)
• In-Memory Expression Units (IMEU)
• Snapshot Metadata Units (SMU)

Die In-Memory Compression Unit ist ein komprimierter Speicherbereich, der die Daten für eine oder mehrere Spalten enthält. Sie besteht aus zwei Teilen: den komprimierten Daten (Column Compression Units) sowie Metadaten (In-Memory Storage Index).

Eine IMCU enthält die Daten für maximal ein Objekt (Tabelle, Partition, Materialized View), niemals für mehrere Objekte. Werden keine einzelnen Spalten benannt, dann werden so wie im Beispiel in Listing 2 alle Spalten in eine IMCU geladen.

Listing 2: Eine Tabelle in die IMCU laden

SQL> ALTER TABLE sh.products INMEMORY MEMCOMPRESS FOR QUERY LOW;
Tabelle wurde geändert.

Alternativ können die Spalten angegeben werden, die in die IMCU geladen werden sollen. Damit werden Ressourcen geschont, wenn nicht alle Spalten einer Tabelle für analytische Auswertungen benötigt werden. Es ist also notwendig zu planen, welche Objekte in den Column Store geladen werden sollen. Daraus ergibt sich der Vorteil, dass der zur Verfügung stehende Memory effektiv ausgenutzt wird. Im Beispiel in Listing 3 werden Spalten ausgeklammert.

Listing 3: Einzelne Spalten aus der IMCU ausblenden

SQL> ALTER TABLE sh.customers
  2 INMEMORY MEMCOMPRESS FOR QUERY LOW
  3  NO INMEMORY (cust_postal_code, cust_city, cust_email);
Tabelle wurde geändert.
SQL> SELECT segment_column_id, column_name, inmemory_compression
  2  FROM v$im_column_level
  3  WHERE TABLE_NAME = 'CUSTOMERS'
  4  ORDER BY segment_column_id;
SEGMENT_COLUMN_ID COLUMN_NAME          INMEMORY_CO
----------------- -------------------- -----------
                1 CUST_ID              DEFAULT
                2 CUST_FIRST_NAME      DEFAULT
                3 CUST_LAST_NAME       DEFAULT
                4 CUST_GENDER          DEFAULT
                5 CUST_YEAR_OF_BIRTH   DEFAULT
                6 CUST_MARITAL_STATUS  DEFAULT
                7 CUST_STREET_ADDRESS  DEFAULT
                8 CUST_POSTAL_CODE     NO INMEMORY
                9 CUST_CITY            NO INMEMORY
               10 CUST_CITY_ID         DEFAULT
               11 CUST_STATE_PROVINCE  DEFAULT
               12 CUST_EMAIL           NO INMEMORY

Hinweis: Wird in einer SQL-Abfrage mindestens eine Spalte referenziert, die sich nicht im Column Store befindet, werden die Daten aus dem normalen Buffer Cache, in dem die Daten im Zeilen-Format gespeichert sind, gelesen.

Der für die IMCUs verwendete Kompressionsalgorithmus ist auf Zugriffsgeschwindigkeit optimiert und nicht auf Storage-Verkleinerung. Mit der Kompression ist es möglich, Scan- und Filter-Operationen mit wesentlich weniger Daten und in einer kürzeren Zeit vorzunehmen. Die verwendete Technologie ist mit der Hybrid Column Compression vergleichbar. Beide verwenden Spalten-Vektoren. Die folgenden Kompressionstypen stehen zur Verfügung:

• FOR QUERY (LOW oder HIGH)
• FOR DML
• FOR CAPACITY
• NONE

Üblicherweise sollte der Typ FOR QUERY verwendet werden. Er garantiert die beste Performance für analytische Abfragen. Jede IMCU enthält alle Spaltenwerte für einen Teil der Zeilen der Tabelle. Zwischen einer IMCU und einer Menge von Zeilen besteht demnach eine Eins-zu-n-Beziehung. Eine IMCU unterteilt sich in Kopf und Körper. Im Körper werden die Spaltenwerte hinterlegt. Im Kopf befinden sich die Metadaten für die Spaltenwerte, zum Beispiel Minimum, Maximum oder verschiedene Werte. Eine weitere wichtige Charakteristik ist, dass die Spaltenwerte in der Reihenfolge der ROWIDs gespeichert werden. Dies bietet eine Reihe von Vorteilen und trägt dazu bei, die Geschwindigkeit für Abfragen signifikant zu erhöhen. Betrachten wir eine Abfrage über mehrere Spalten mit der WHERE-Klausel id=4711. Oracle sucht zuerst den Wert in der Spalte id und erhält zusätzlich die Information, dass er sich an Position 83 befindet. Jetzt können im Column Store die anderen Spaltenwerte einfach aus der IMCU von der Position 83 gelesen werden.

So wie im Beispiel in Abb. 2 werden im Kopf des IMCU auch Schlüsselwerte gebildet. Dieses Verzeichnis wird Local Dictionary genannt. Damit müssen keine Texte, sondern nur der zugehörige Key gespeichert werden. Weitere Informationen wie zum Beispiel Minimal- und Maximalwerte beschleunigen die analytischen Abfragen zusätzlich. Unter Umständen muss nicht der Körper, sondern nur der Kopf gelesen werden.

Eine Snapshot Metadata Unit (SMU) enthält sowohl Metadaten als auch transaktionale Informationen über die zugehörige IMCU. Dazu gehören:

• Objektnummern
• Spaltennummern
• Mapping-Informationen für Spalten

Eine SMU enthält ein Transaktions-Journal, was verwendet wird, um die IMCU konsistent zu halten.

Alle DML-Operationen finden im Row Store statt, unabhängig davon, ob ein Column Store existiert oder nicht. Ein UPDATE nimmt wie bekannt Änderungen in den Datenblöcken des Row Store vor. Es hat natürlich auch Auswirkungen auf den Column Store, wenn er für die entsprechenden Objekte eingerichtet wird. In diesem Fall wird die zugehörige ROWID zum Transaktions-Journal der IMCU hinzugenommen und speichert die SCN der Transaktion und markiert sie als "stale". Wenn jetzt eine SQL-Abfrage Zugriff auf die Änderung benötigt, greift Oracle auf den Row Store zu, bevor die Änderung im Column Store eingearbeitet ist. Damit wird die Konsistenz der Abfragen zu jeder Zeit gewährleistet. Die In-Memory Expression Unit (IMEU) ist ein Speicherbereich für materialisierte In-Memory Expression und virtuelle Spalten. Jede IMEU hat eine Eins-zu-eins-Beziehung zu einer IMCU und repräsentiert dieselben Zeilen der Tabelle.

Der Expression Statistics Store (ESS) ist ein Repository zur Evaluierung von Ausdrücken und wird vom Optimizer verwaltet. Er speichert unter anderem, ob ein Ausdruck häufig verwendet wird. Während des Parsings einer SQL-Anweisung werden diese Statistiken herangezogen. Es werden unter anderem folgende Statistiken verwaltet:

• Häufigkeit der Ausführung
• Kosten der Evaluierung
• Zeitstempel der Evaluierung

Der Optimizer weist jedem Ausdruck eine Bewertung basierend auf der Anzahl der Ausführungen sowie der damit verbundenen Kosten zu.

Die Prozess-Architektur

Der Column Store muss natürlich aktuell gehalten werden, ohne dass sich das Transaktions-Processing signifikant verzögert. Sie haben erfahren, wie zum Beispiel Oracle Änderungen mithilfe des Transaktions-Journals zeitgleich in den Column Store implementiert. Der Column Store muss außerdem beim Start der Datenbank initial gefüllt werden.

Für das Laden und die Aktualisierung des Column Store ist die In-Memory-Prozess-Architektur zuständig. Es handelt sich dabei um eine Sammlung von Hintergrund-Prozessen, die mit der Aktivierung des Column Store gestartet werden. Zu den wichtigsten Prozessen gehören:

• In-Memory-Coordinator-Prozess (IMCO)
• Space-Management-Worker-Prozess (Wnnn)
• In-Memory Dynamic Scans (Lightweight-Threads)

Der IMCO-Prozess veranlasst die Population von Daten in den Column Store automatisch für alle Objekte, deren Priorität nicht NONE ist. Objekte mit der Priorität NONE werden in den Column Store eingebunden, sobald auf sie zugegriffen wird. Der IMCO wacht immer wieder auf und prüft, welche Aufgaben zu erledigen sind. Der Space-Management-Worker-Prozess aktualisiert die Daten auf Anforderung durch den IMCO. Zu seinen Aufgaben gehören:

• Identifizierung von virtuellen Spalten
• Virtuelle Spaltenwerte erstellen
• Die Werte für jede Zeile berechnen sowie deren Umwandlung in das Spalten-Format und deren Kompression
• Registrierung von Objekten
• IMEUs mit IMCUs verbinden

In-Memory Dynamic Scans benutzen automatisch zusätzliche zur Verfügung stehende CPU-Ressourcen und parallelisieren damit die Abfragen. Da die Scans dynamisch erfolgen, beeinflussen sie nicht den normalen Workload der Datenbank.

Dynamic Scans werden ausgeführt, wenn CPU-Ressourcen im Ressourcen-Plan aktiviert sind. Dies ist zum Beispiel der Fall für den Plan DEFAULT_PLAN. Lightweight-Threads haben die Eigenschaft, dass sie die Ressourcen des übergeordneten Table-Scan-Prozesses verwenden. Der Resource Manager bestimmt automatisch die Anzahl von Threads, abhängig vom Parameter CPU_COUNT sowie dem aktuellen CPU-Workload. Sobald die Datenbank erkennt, dass Dynamic Scans hilfreich wären, wird der folgende Algorithmus ausgeführt:

• Prozess, der den Table Scan ausführt, startet einen Pool von Lightweight-Threads.
• Der Table Scan unterteilt die Aufgabe in Subtasks pro IMCU.
• Der Resource Manager bestimmt, wie viele Threads den Table Scan unterstützen dürfen.
• Die aktiven Threads holen sich die Aufgaben aus einer Warteschlange und führen diese aus.

Der Resource Manager wird automatisch eingeschaltet, sobald der Parameter inmemory_size auf einen Wert größer als null gesetzt wird.

Die CPU-Architektur

In-Memory-Datenbanken werden im Wesentlichen nach Antwortzeiten für SQL-Abfragen bewertet. Deshalb versuchen die Hersteller, alle Möglichkeiten der beschleunigten Verarbeitung auszureizen. Oracle verwendet eine Technologie mit dem Namen Single Instruction– Multiple Data, kurz SIMD.

Die Idee dahinter ist, die Anzahl von Spalteneinträgen, die die CPU in die Vektor-Register laden kann, zu maximieren. Es erfolgt also eine Parallelisierung, die es ermöglicht, eine Gruppe von Spalten mit einer einzelnen CPU-Anweisung zu verarbeiten. Diese Technologie ermöglicht es, aus logischer Sicht, Milliarden von Zeilen pro Sekunde zu verarbeiten.

Hinweis: Die Oracle-In-Memory-Technologien setzen stark auf Parallelisierung. Neben einer intelligenten Speicherform im Spalten-Format ist dies der Schlüssel für eine schnelle Verarbeitung und kurze Antwortzeiten. Dies unterscheidet sie stark von der bekannten Verarbeitung im Zeilen-Format, wo die meisten Teilprozesse eher seriell ablaufen. Für den Row Store ist daher eher die Clock Speed der CPUs von Bedeutung. Planen Sie die Hardware für den Einsatz von Oracle In-Memory so, dass ausreichend viele CPUs (Threads) zur Verfügung stehen.