Über unsMediaKontaktImpressum
Lutz Fröhlich 02. März 2021

Die Oracle-In-Memory-Architektur

Oracle In-Memory ist ein vergleichsweise junges Produkt der Oracle-Datenbank-Familie. Es sollte nicht mit der TimesTen-In-Memory-Datenbank verwechselt werden, die Oracle zwischenzeitlich dazugekauft hatte. Schnell wurde klar, dass TimesTen mit anderen In-Memory-Datenbanken wie zum Beispiel SAP Hana nicht konkurrieren konnte und so entschied Oracle sich zur Entwicklung eines eigenen Produkts.

Oracle In-Memory ist aus dem Konkurrenzdruck entstanden, den vorwiegend SAP Hana und IBM Blu hervorgerufen hatten, und ist seit der Version 12c verfügbar. In den Versionen 19c und 20c ist es Bestandteil der Enterprise Edition (Cloud und On-Premises) sowie der Exadata. Ein entscheidender Vorteil von Oracle In-Memory gegenüber SAP Hana ist, dass sich nicht die gesamte Datenbank im Memory befinden muss. Die Funktionalität kann auf einzelne Objekte (Tabellen) oder auch auf Spaltenebene angewandt werden. Daraus ergeben sich folgende Vorteile:

  • Das Wachstum der Datenbank zieht nicht eine analoge Vergrößerung des Memory nach sich.
  • Es ist möglich, einen gemischten Workload von OLTP und Data Warehouse effizient zu betreiben (Dual-Format-Architektur).

Der Trend für Planung und Einsatz von Datenbanksystemen geht immer mehr weg von einer klassischen Trennung von OLTP- und Data-Warehouse-Datenbanken und hin zur Dual-Format-Architektur. Auswertungs- und Analysedaten werden nicht mehr in speziellen Warehouse-Datenbanken gesammelt und aufbereitet, sondern direkt in der OLTP-Datenbank zur Verfügung gestellt.

In der Version 20c wurden folgende Neuerungen eingeführt:

  • Automatische Verwaltung von In-Memory-Objekten
  • In-Memory Full Text Columns
  • Hybrid In-Memory Scans
  • Optimierung komplexer SQL-Operatoren
  • Verbesserungen für Spalten mit Datentyp JSON

Mit der Version 19c stehen folgende neue Features zur Verfügung:

  • Die Option Wait-on-populate
  • Performance-Verbesserung für interne Tabellen
  • Hybrid-partitionierte Tabellen
  • Der Resource Manager wird automatisch eingeschaltet

Das Spalten-Format

Die Speicherung von Daten im Zeilen-Format wird von den meisten Datenbanksystemen unterstützt. Es hat sich als vorteilhafter Kompromiss für alle bekannten Workloads erwiesen. Allerdings hat das Format für analytische Auswertungen einige nicht zu übersehende Nachteile beim Ressourcen-Verbrauch sowie der Performance. Denken Sie zum Beispiel an eine Tabelle mit Bestellungen, aus der Informationen über ein bestimmtes Produkt aufbereitet werden sollen. Es werden auch alle sonstigen Spaltenwerte gelesen, selbst wenn sie für die Auswertung nicht benötigt werden. Das Problem wird umso größer, je breiter die Tabelle ist.

Das ist einer der Gründe, weshalb man in der Vergangenheit für analytische Zwecke die Daten in einem Data Warehouse gesammelt und aufbereitet hat. So wurden unter anderem Summentabellen gebildet. Ein Data Warehouse verursacht zusätzliche Kosten und die Daten sind häufig nicht aktuell. Sie werden in der Regel in Nachtläufen aktualisiert.

Die Speicherung von Daten im Spalten-Format macht analytische Abfragen signifikant schneller und schont Systemressourcen. Das Konzept von Oracle sieht vor, dass die Daten einer Tabelle sowohl im Zeilen- als auch zusätzlich im Spalten-Format gespeichert werden können. Die Daten im Spalten-Format werden komplett im Hauptspeicher gehalten. Dieser Bereich wird auch als Column Store bezeichnet. Wenn wir von einer In-Memory-Datenbank sprechen, dann sprechen wir nicht nur von der Datenhaltung im Memory, sondern vor allem von einem neuen Format, das die Daten spaltenweise speichert.

Analytische Abfragen werden um ein Vielfaches schneller. Die Versprechungen bewegen sich im Bereich von zehn- oder zwanzigmal schneller, es kann allerdings zu Abweichungen nach unten oder oben kommen. Darüber hinaus sollte man nicht außer Acht lassen, dass die Systemressourcen deutlich geschont werden. Die Unterschiede werden umso größer, je mehr Analyse-Abfragen gleichzeitig gestellt werden.

Was passiert aber, wenn Daten verändert werden? Wie Sie wissen, ist das Zeilen-Format sehr effizient, wenn Daten eingefügt, verändert oder gelöscht werden. Das Einpflegen der Änderungen in das Spalten-Format ist dagegen etwas aufwändiger, da die Spaltenstrukturen verändert werden müssen. Da diese Operationen vorwiegend im Memory stattfinden, hält sich der Aufwand allerdings in Grenzen, wie Sie noch sehen werden. Beachten Sie, dass die Verwendung einer Tabelle im dualen Format nicht bedeutet, dass der doppelte Memory benötigt wird. Zwar wird die Tabelle im Spalten-Format komplett im Memory gespeichert, allerdings erfolgt die Speicherung in komprimierter Form und ist nicht mit dem Buffer Cache des Zeilen-Formats vergleichbar. Die Speicherung einer Tabelle erfolgt in der In-Memory Area. Diese befindet sich in der System Global Area (SGA) und ist in zwei Pools unterteilt:

  • 64KB POOL: Pool für die Metadaten
  • 1MB POOL: Pool für die Daten im Spalten-Format

Bevor wir Oracle In-Memory benutzen können, müssen wir die Größe der In-Memory Area durch den Parameter inmemory_size festlegen. Dieser Bereich muss von der Größe der System Global Area abgezogen werden.

Listing 1: Größe der In-Memory Area

SQL> SHOW PARAMETER inmemory_size

NAME	        TYPE	      VALUE
-------------	------------- -----
inmemory_size	big integer   2G

SQL> SELECT * FROM v$sga;

NAME			 VALUE		CON_ID
------------------------ ----------	------
Fixed Size		    8912184	0
Variable Size		  872415232	0
Database Buffers	 3841982464	0
Redo Buffers		    7864320	0
In-Memory Area		 2147483648	0

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.

Oracle 19c/20c

Der vorliegende Artikel ist ein Auszug aus Lutz Fröhlichs Buch "Oracle 19c/20c – Das umfassende Praxis-Handbuch".

Von der Planung und Installation über Architektur, Infrastruktur und Administration bis hin zu Migration in die Cloud sowie Einsatz der autonomen Datenbank. Mit vielen Beispielen, Konfigurationsanleitungen und wertvollen Tipps für den praktischen Einsatz. Aktuelle Themen wie In-Memory-Technologie, Data Science und Machine Learning.

Autor

Lutz Fröhlich

Lutz Fröhlich ist Diplommathematiker, Oracle Certified Master und arbeitet seit 1993 mit Oracle-Datenbanken. Er ist spezialisiert auf die Themen Performance, Hochverfügbarkeit, Datenreplikation und -Streaming.
>> Weiterlesen
Das könnte Sie auch interessieren

Kommentare (0)

Neuen Kommentar schreiben