Mit der Oracle In-Memory-Option wird sich vieles im Data Warehouse ändern
Warehouse-Systeme sind mehr als nur eine für Reporting-Performance optimierte "dicke" Datenbank. Sie erlauben es, Daten gegenüber ihren operativen Quellsystemen in frei wählbaren Modellen neu zu organisieren, um sie mit beliebigen Methoden zeitunabhängig in alle Richtungen analysieren zu können. Auch andere Systeme können mit In-Memory optimiert werden. Einige können von der Zugriffsoptimierung und Performance profitieren. Oracle Database 12c bietet mit der In-Memory-Option einige neue Möglichkeiten.
In-Memory mit Oracle
Bei den meisten bislang bestehenden In-Memory-Techniken kann nur der komplette Daten-Stack des Auswertesystems In-Memory liegen. Oracle geht dagegen auf die spezifischen Anforderungen eines unternehmensweiten Data Warehouse ein: Je nach Bedarf lassen sich Tabellen, einzelne Spalten, Materialized Views oder Indexe in den Hauptspeicher packen. Und das ohne die Data Warehouse-Anwendung zu verändern.
ALTER TABLE f_umsatz INMEMORY;
Dieses einfache SQL-Statement markiert die Tabelle F_UMSATZ, und das Datenbanksystem lädt Datenobjekte über einen Hintergrundprozess in die neue In-Memory-Area im Hauptspeicher (SGA). Ein Initialisierungs-Parameter legt die Größe der In-Memory-Area fest (INMEMORY_SIZE und Achtung auch SGA_TARGET als Gesamt-SGA-Größe).
Bei diesem Ladevorgang zerlegt das System die Tabellen zunächst in seine Spalten und komprimiert sie mit unterschiedlichen Optionen auf einen Faktor von 4 bis 20. Damit koexistieren beide bekannten Speicher-Konzepte in einer Datenbank: ROW-BASED für die klassische Disk-Speicherung bzw. den Buffer-Pool und COLUMN-BASED für die neue In-Memory-Area.
Das Konzept ist wie geschaffen für ein hochvolumiges Data Warehouse, in dem eventuell nur 10 Prozent der Daten ad hoc sekundenschnell zu lesen sind, während die Masse der Daten oft nur für den „Fall der Fälle“ oder eine Jahresvergleichsabfrage dahin schlummert.
Welche Antwortzeiten entstehen?
Offiziellen Aussagen nach erreicht die Oracle In-Memory-Technologie mehrere Milliarden Zeilen pro Sekunde pro CPU-Core. Diese Werte sind auf eine Spalte bezogen und mit schneller Hardware durchgeführt. Aber bereits auf einem einfachen Laptop und mit realistischeren, weil komplexeren Abfragen lassen sich erstaunliche Performance-Werte erzielen. Das folgende, aus fünf Dimensionen bestehende Beispiel-Star-Schema (aus den Seminaren der Oracle Data Warehouse Community), ist ein praktisches Testszenario und erlaubt Beispielabfragen mittlerer Komplexität.
Die Belegung im Speicher erhält man über den Dictionary View v$im_segments. Erkennbar ist die Kompression der größten Tabelle (50 Mill. Sätze) mit Faktor 5,62. Aus 2,2GB wurden 0,41GB.
Ohne In-Memory läuft eine etwas aufwändigere Abfrage nach den Top 10 Artikeln pro Bundesland im Jahr 2010 auch nach mehrmaligem Aufruf (also auf bereits im Buffer-Pool befindliche Daten-Cache) nicht schneller als 21 Sekunden.
SELECT * FROM (SELECT a.Artikel_Name Artikel, r.Land Bundesland, z.Jahr_nummer Jahr, sum(U.umsatz) Wert, sum(U.Menge) Menge, round(sum(U.umsatz) / sum(U.Menge),2) Ums_pro_Art, RANK() OVER (ORDER BY sum(U.umsatz) DESC ) AS Rangfolge FROM F_umsatz U, D_Artikel A , D_Zeit z, d_region r WHERE U.artikel_id = a.artikel_id and U.REGION_ID = R.REGION_ID AND U.zeit_id = z.zeit_id AND z.jahr_nummer = 2010 GROUP BY a.artikel_name,r.Land,z.Jahr_nummer) WHERE rownum < 11;
Beispielabfrage mit Sub-Select, 4 Join-Tabellen, 3 Gruppierungen und mehreren Filtern.
Schaltet man die In-Memory-Funktion für die Datenbank frei (ALTER SESSION set inmemory_query = enable;), so reduziert sich diese 50 Millionen-Sätze-Abfrage auf unter 1,5 Sekunden bei parallel 4 und das auf einem Windows-Laptop mit einfachem Dual-Core-Prozessor.
Was macht die Abfragen so schnell?
Die Abfrage der In-Memory-Daten ist um ein vielfaches schneller als eine Abfrage von Daten, die sich im Buffer-Pool der Datenbank befinden. Da es sich in beiden Fällen um eine Hauptspeicherablage handelt, muss es noch andere Performance-Faktoren geben:
Spaltenbezogene Speicherung: Ein Grund ist die spalten-bezogene Speicherung der In-Memory-Option. Sie hat bei Data Warehouse-typischen Abfragen auf Wertebereiche und mit wenigen abgefragten Spalten Vorteile gegenüber der Satz-bezogenen Speicherung, die dafür bei OLTP-typischen Einzelsatzabfragen und vielen Spalten punkten kann.
Komprimierung: 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.
Bloom-Filtering: Die Join-Bedingungen löst das System mittels Bloom-Filtering. Kleine Tabellen – wie die meisten Dimensionstabellen 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 zieht der Join-Filter.
SIMD-Verfahren: Verfügt das System über mehrere CPU-Cores, so erhält jeder Core ein eigenes Bloom-Filter-Objekt und arbeitet direkt die ihm zugeordneten Faktentabellen-Sätze ab.
Report Outlines: Aggregationen (GROUP BY) löst das System mit sog. „Report Outlines“. Ein einmal berechnetes Aggregationsergebnis merkt sich das System dynamisch für folgende Abfragen. Praktisch entsteht „On-The-Fly“ ein OLAP-Würfel im Speicher.
Parallelisierung und In-Memory
In vielen gerade kleineren Data Warehouse-Systemen wirkt Parallelisierung aufgrund der geringen IO-Leistung des Storage-Systems nicht besonders gut. Kleinere Systeme haben oft keine nur ihnen zugeordnete Speicherplatten und sind an ein SAN angeschlossen. Sie konkurrieren mit der Masse OLTP-Anwendungen, die eine grundsätzlich andere Art der Storage-Nutzung praktizieren (Einzelsatzlesen vs. Bereichs-bezogenes Lesen). IO-Leistungen von wenigen 100MB/Sekunde sind die Folge. Parallel arbeitende CPUs einer Data Warehouse-Maschine erhalten nicht genügend Daten. Mit In-Memory wächst die IO-Leistung dramatisch in den Bereich von mehreren GB/Sekunde. Damit können die CPUs unter Volllast arbeiten. Ein effektives Parallelisieren ist möglich.
Welche Tabellen sollen in den In-Memory-Speicher?
Wir haben die Wahl: Daten können In-Memory oder auf der Festplatte liegen. Welche sollen jetzt permanent in den Hauptspeicher? Generell sollte ein Data Warehouse-Administrator auch ohne fremde Hilfe wissen, welche Daten dafür infrage kommen: die meist genutzten Daten. Das System bietet hierfür einen Advisor an, der aufgrund der gesammelten Verwendungsinformationen des AWR (Automatic Workload Repository) und des ASH (Active Session History) Vorschläge für die lohnenswertesten Objekte liefert.
Wie werden die Daten aktuell gehalten?
Oracle führt INSERTS und UPDATES nach dem bekannten Verfahren durch. Es können also auch lesende und schreibende Zugriffe parallel durchgeführt werden, ohne einen Lock-Zustand oder inkonsistente Daten zu erzeugen.
Das heißt aber auch umgekehrt, dass das Lesen von Daten aus dem In-Memory-Speicher die zuletzt mit COMMIT bestätigten Daten widerspiegelt. Oracle hat zur Synchronisierung zusätzliche Prozesse implementiert. Dies gilt für einzelne INSERTS und UPDATES, wie sie etwa in einem OLTP-System vorkommen.
Diese Technik ersetzt jedoch nicht die bekannten Massenladeverfahren, die wir aus dem Data Warehouse kennen. Das heißt also die Vorgehensweise, nach der wir z. B. durch einen Direct Path Load zunächst temporäre Tabellen erzeugen, deren Inhalte prüfen und schließlich mit einem „Partition Exchange and Load“ in kürzester Zeit riesige Datenmengen in ein Data Warehouse schieben. Bei dieser gewählten Vorgehensweise „populiert“ man den In-Memory-Speicher dezidiert in einem nachgelagerten Schritt z. B. mit dem Package
DBMS_INMEMORY.repopulate(schema,table,partition).
Diese Vorgehensweise kennen wir bereits von anderen Themen wie dem Aktualisieren von Statistiken, Indexen oder Materialized Views. Hier wird nachgelagert gehandelt, um ETL-Läufe möglichst kurz zu halten.
In-Memory im Data Warehouse
Gerade für Warehouse-Systeme mit sehr vielen historischen Daten ist diese Wahlfreiheit wichtig. In dem Oracle Data Warehouse sind große historisierte Tabellen partitioniert. Während aktuelle und sehr oft genutzte Daten den Vorzug einer In-Memory-Speicherung genießen, lagern ältere und kaum gelesene Daten auf dem klassischen Plattenspeicher. Statistiken belegen, dass weniger als 10 Prozent der in einem Data Warehouse gespeicherten Daten mehr als 90 Prozent der Datenzugriffe erfahren. Diese Statistik berücksichtigt sowohl Satz, als auch Spaltenlevel, denn nicht nur Partitionen, sondern auch nur einzelne Spalten einer Tabelle lassen sich In-Memory vorhalten.
In einer klassischen 3-Schichten-Architektur nach Inmon würde man danach folgende Objekte In-Memory laden:
- Die meisten Dimensionen in den Data Marts (User View Layer), sofern man sie überhaupt nutzt.
- Die jüngsten Partitionen der Faktentabellen und auch nur die genutzten Spalten.
- Data Mining-Tabellen bzw. Tabellen, die über R-Skripte in der Datenbank analysiert werden. R hat durch die Integration in die Oracle Datenbank (ORE) an sich schon einen erheblichen Leistungsschub erfahren. Wandern die Analyse-Tabellen in den In-Memory-Column-Store, so potenzieren sich die Leistungsmerkmale.
- Kennzahlensysteme (basierend auf Materialized Views). Viele Abfragen in Warehouse-Systemen sind vorhersehbar. Zudem gibt es eine Grundmenge an Kennzahlen mit exakt definierten Herleitungsalgorithmen. Solche Objekte würde man weiterhin mit Materialized Views herleiten und auch diese in den In-Memory-Speicher legen.
- In der Kern-Warehouse-Schicht (Enterprise Layer) sind die am häufigsten genutzten Stamm (S)- und Referenz (R)-Datentabellen im Speicher. Die Masse der Stamm- und Referenzdaten sind allerdings meist kleine Tabellen, die das System im „wie im Vorbeiflug“ auch schnell von der Festplatte lesen kann.
- Transaktionale Daten (Bewegungsdaten) müssen in dieser Schicht nur dann in den Speicher, wenn man sie direkt aus dem User-View-Layer heraus referenziert. Diese schichtenübergreifende Referenzierung mag einige verwundern. Aber warum sollte man große Bewegungsdatentabellen als Fakten in die Data Marts kopieren, wenn sich strukturell an den Daten nichts ändert?
- Operational Data Stores verlieren bei In-Memory zunehmend an Bedeutung. Liegen die operativen Anwendungen auf Oracle, dann kann man die benötigten OLTP-Tabellen in den Speicher laden und diese In-Memory-Version für Analysen freigeben. Die operative Anwendung wird durch das In-Memory-Lesen nicht behindert.
Sind Materialized Views jetzt obsolet?
Nein, natürlich nicht. Sie werden sogar noch interessanter. Zunächst sollte man Materialized Views nicht immer nur aus der Performance-Brille betrachten, sondern mit ihrer Hilfe ein methodisch abgestimmtes Konzept verwirklichen:
- Bis zu 80 Prozent aller BI-Auswertungen sind vorhersehbar und sollten in der Datenbank vorberechnet werden.
- Berechnung in der Datenbank ist wesentlich schneller.
- Die Berechnung von Kennzahlen in dem zentralen Data Warehouse wirkt standardisierend und schafft einheitliche abgestimmte Kennzahlen.
- Es wird verhindern, dass jeder BI-Benutzer allgemeingültige Kennzahlen individuell in seinem „privaten Tool“ berechnet.
- Sinnvoll berechnete Kennzahlen stehen einer breiteren Benutzergruppe zur Verfügung, während individuell berechnete Kennzahlen meist auch individuell publiziert werden.
Mit In-Memory sind die Materialized noch schneller. Das folgende Beispiel zeigt über eine Ausführungsplanbetrachtung wie eng In-Memory mit der klassischen Datenbanktechnik verzahnt ist. Folgende generische Materialized View Definition ist bzgl. der oben bereits genutzten Abfrage rewrite-fähig. Das heißt, das System kann sie im Hintergrund anstelle der Abfrage nutzen.
MATERIALIZED VIEW Mav_Region_Zeit_Artikel_umsatz
BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE AS
SELECT sum(u.UMSATZ) Umsatz,
sum(u.menge) Menge,
Z.Zeit_ID,
count(*) Anzahl,
r.region_id,
a.artikel_id
FROM
f_Umsatz U,
d_region r,
d_zeit z,
D_artikel a
WHERE
U.zeit_id = z.zeit_id AND
U.REGION_ID = R.REGION_ID AND
U.artikel_id = a.artikel_id
GROUP BY
a.Artikel_ID,
r.region_id,
z.Zeit_ID;
Auch Materialized Views lassen In-Memory vorhalten: ALTER MATERIALIZED VIEW Mav_Region_Zeit_Artikel_umsatz INMEMORY. Setzen wir jetzt die oben beschriebene Abfrage auf die Top-10 Artikel ab, so läuft sie jetzt nur noch 0,010 Sekunden lang, auch wenn die Materialized View selbst über 100000 Sätze verfügt. Solche generischen Materialized Views enthalten meist keine Filterbedingungen und verfügen auch nur über Schlüsselwerte der Dimensionstabellen (Primary Keys der Dimensionstabellen). Deshalb sind die enthaltenen Datenmengen oft höher. Die speziellen Ausprägungen einer Benutzerabfrage löst das System erst im Rahmen des Query Rewrite auf, also wenn die Original-Benutzerabfrage auf die Materialized View „umgelenkt“ wird. Auch hier kommt die In-Memory-Technik zum Tragen und es zeigt eindrucksvoll, wie der Optimizer mit der Situation umgeht. Dieser Vorgang lässt sich über den Ausführungsplan gut beobachten:
Im unteren Bereich (Zeile 32) ist das Lesen der Materialized View mit 93.207 Sätzen erkennbar. Würde der Query Rewrite nicht stattfinden, so stünde dort TABLE ACCESS INMEORY FULL F_UMSATZ mit 51 Million Sätzen. Weil die Abfrage ARTIKELNAME, LAND und JAHR benötigt, diese Informationen aber nicht in der Materialized View-Definition vorkommen, müssen diese Informationen über ein JOIN-BACK, also einem vollständigen Lesen der Dimensionen D_Artikel, D_Zeit und D_Region nachgelesen werden. Auch diese geschieht über einen „FULL-In-Memory-Lesevorgang“.
Analytische Datenbanken sind passé!
Diese Liste zeigt, dass man doch mit etwas mehr Grips im Kopf an die In-Memory-Thematik im Warehouse herangehen sollte. In-Memory ist ein Segen, gerade im Data Warehouse, aber die oben zitierten flachen Marketing-Aussagen greifen zu kurz und sind selbstentlarvend.
Mit dem Begriff analytische Datenbanken wird man aufräumen müssen, wenn diese Datenbanken im Kern einfach nur mehr Performance versprechen. Der Preis ist hoch: Jede separate Datenhaltung neben dem zentralen Data Warehouse zersplittert die Informationslandschaft und provoziert unnötige Ressourcen-Aufwände, Kosten und die Gefahr von Doppelarbeit mit nicht abgestimmten Ergebnissen.
Es bewahrheitet sich immer wieder: Wer die Daten an einer Stelle zusammenhält, schafft Übersichtlichkeit und gleichzeitig Flexibilität. Mit In-Memory wird er zusätzlich belohnt.
Auch BI-Werkzeuge und BI-Plattformen müssen umdenken
In den letzten Jahren haben BI-Tool-Hersteller ihre Analyse-Umgebungen zu eigenständigen Plattformen weiterentwickelt. Mit dem Ziel, besonders performante Auswertungen zu ermöglichen, wurden In-Memory-Caches und sogar spezielle Analysedatenhaltungen (Files oder OLAP-Cubes) in die Werkzeuge integriert. Ähnlich wie bei den Analytischen Datenbanken kam es auch hier zu zusätzlichen Datentransporten aus der zentralen Warehouse-Datenbank heraus und in die „dezentralen Caches“ hinein. Unschwer zu erkennen: In Zeiten von In-Memory in der zentralen Datenbank ist das alles andere als ein schlankes smartes Analysesystem. Von In-Memory in der Datenbank profitieren heute diejenigen BI-Werzeuge, die mit SQL direkt aus der Datenbank lesen. Der Betrachtungs-Horizont der BI-Administratoren sollte sich auch auf die Möglichkeiten in der Datenbank erstrecken, anstatt alle Kalkulationen und Aufbereitungen innerhalb der BI-Plattform machen zu wollen. Auch ein BI-Administrator sollte sich die Frage stellen: Welche Benutzerabfragen und welche Kennzahlen sind bekannt und lassen sich bereits innerhalb der zentralen Datenbank vorberechnen? Mit In-Memory in der Datenbank wird dieses Denken plötzlich attraktiv.
