Zeilen- vs. spaltenorientierte Datenhaltung im Hauptspeicher Begriffe, Modellierung und reale Probleme mit der Oracle InMemory-Technologie

Transkript

1 Zeilen- vs. spaltenorientierte Datenhaltung im Hauptspeicher Begriffe, Modellierung und reale Probleme mit der Oracle InMemory-Technologie Frank Effenberger, Dresden

2 Zahlen und Fakten Robotron Datenbank-Software GmbH Gründungsjahr 1990 Geschäftsform GmbH (9 Gesellschafter) Mitarbeiterzahl 349 (Stand 01/2015) Stammkapital Umsatz 2013 Umsatz ,4 Mio. EUR 31,1 Mio. EUR 31,2 Mio. EUR Hauptsitz Oracle-Partner ISO 9001 zertifiziert Schulungs- und Kongresszentrum

3 Robotron-Firmengruppe Tschechien: Robotron Database Solutions s.r.o. Schweiz: Robotron Schweiz GmbH Österreich: Robotron Austria GmbH Russland: Robotron Rus GmbH Deutschland: Robotron ECG solutions GmbH Deutschland: SASKIA Informations-Systeme GmbH

4 Unsere Kernkompetenz

5 0. Gliederung 1. Einführung und Überblick 2. Oracle InMemory-Technologie und SQL-Befehle 3. Oracle InMemory für das DWH 4. Technische Rahmenbedingungen 5. Fazit 6. Quellen

6 1. Einführung und Überblick Motivation: DWHs sind read mostly (ohne Betrachtung ETL-Prozess) Abfragen über mehrere Millionen Datensätze mit hoher Datendichte (wenige Null-Werte) => hohe Abfrage- und Antwortzeiten bei komplexen Analysen Ablehnung gegenüber langsamen Produkten, Konkurrenten mit höherer Effizienz werden bevorzugt Idee der spaltenorientierten Abfragen im Hauptspeicher

7 1. Einführung und Überblick Schnelligkeit des Hauptspeichers anhand eines Beispiels: Speicherchip im Prozessor -> Nachdenken Hauptspeicher -> Im Bücherregal eine Information suchen Festplatte -> Mit dem Auto in die nächste Bücherei fahren, Information suchen und zurückfahren Quelle Erzählung: Erzählung Prof. Gräfe zur Studienzeit

8 1. Einführung und Überblick Langfristiges Ziel zur Steuerung der Abfragezeiten: Aufbau einer Speicherhierarchie, wobei: Abfragen über oft abgerufene, große Datenmengen im Hauptspeicher durchgeführt werden ( Wegfall des I/O, aber Erhöhung CPU-Last) Abfragen über seltener abgerufene Datenmengen auf der Festplatte durchgeführt werden

9 1. Einführung und Überblick Bedeutung von InMemory im eigentlichem Sinne: Nutzung von Hauptspeichertechnologien (zeilen- und spaltenorientiert) Bedeutung der Oracle InMemory Option: Spaltenorientierte Speicherung im Hauptspeicher Cache (zeilenorientierte Speicherung) gibt es schon seit langer Zeit bei Oracle und ist nicht neu!

10 1. Einführung und Überblick Oracle Database InMemory Option: Datenbankobjekte wahlweise (!) im Hauptspeicher Reservierung von Hauptspeicher in SGA für InMemory Keine Änderung in der Anwendung nötig (auf den ersten Blick) Spaltenorientiert Komprimiert (2-20fach) Parallelisierung Nutzung bestehender DB-Architektur und Funktionalität Quelle Aufzählung: TiF Seminar, Oracle München, 2015

11 Technologische Konzepte des Vortrags Cache InMemory Compression SIMD Bloomfilter

12 1. Einführung und Überblick Oracle Database InMemory Option: Schlüsselwörter: InMemory Spaltenorientiert Cache = Zeilenorientiert Quelle Abbildung: TiF Seminar, Oracle München, 2015

13 Technologische Konzepte des Vortrags Cache InMemory Compression SIMD Bloomfilter

14 1. Einführung und Überblick Erklärung zu Cache: Cache lässt z. B. eine Tabelle ständig als most recently used (MRU) für das last recently used (LRU) gelten MRU LRU Daten im Cache

15 Technologische Konzepte des Vortrags Cache InMemory Compression SIMD Bloomfilter

16 2. Oracle InMemory-Technologie und SQL-Befehle Erklärung zu InMemory (Voraussetzungen): Parameter INMEMORY_SIZE in z.b. Init.ora gesetzt: show parameter inmemory_size; Eigene SGA neben Cache für In-Memory mit SGA_Target Parameter gesetzt (Init.ora): select * from V$SGA; (In-Memory Area muss zugewiesen sein) ALTER SESSION SYSTEM set inmemory_query = enable; (disable) ALTER TABLE fact_table inmemory; (no inmemory) ALTER TABLE dimension_table cache; (nocache) Kein Migrationsprojekt (wenn man 12c hat)

17 2. Oracle InMemory-Technologie und SQL-Befehle Voraussetzungen: Nach einem ALTER TABLE X inmemory; muss ein Select auf die Tabelle ausgeführt werden, ehe sie in den Hauptspeicher geladen wird (oder Priority auf Critical setzen, dann laden bei Öffnung der DB) Bei Abfragen entscheidet der SQL-Optimizer je nach Größe der Tabelle und Wiederholerwerten, ob IN-Memory oder normal auf der Datenbank abgefragt wird Wenn Parallelisierung möglich, tut dies der SQL-Optimizer automatisch (ggf. Parameter aktivieren)

18 Technologische Konzepte des Vortrags Cache InMemory Compression SIMD Bloomfilter

19 2. Oracle InMemory-Technologie und SQL-Befehle Komprimierung (vereinfacht): Zeilenorientiert: 01, Alice, Golf; 02, Bob, Jacht; 03, Mallory, Jacht; Spaltenorientiert mit Komprimierung (Spalten-ID): 01, 02, 03; Alice, Bob, Mallory; Golf, Jacht:002,003;

20 2. Oracle InMemory-Technologie und SQL-Befehle Komprimierung: Komprimierung allgemein (auch partitionsweise, da extra Partitionierungslizenz nötig) In spaltenorientierten Systemen viele Wiederholer (Komprimierung 4-20fach möglich) Create Table fact_table ( column1 number, column2 varchar(2), column3 number) INMEMORY [PRIORITY CRITICAL] MEMCOMPRESS FOR DML(column2);

21 2. Oracle InMemory-Technologie und SQL-Befehle Zusätzliche Performancesteigerung: InMemory kann bereits komprimierte Werte ohne Dekompression untereinander vergleichen (Komprimierung benötigt keine Advanced- Compression-Option!) Spaltenorientierte, komprimierte Werte können auch parallelisiert werden und mithilfe von Buckets (Max/Min-Werte) noch performanter gemacht werden Es ist möglich, nur ausgewählte Spalten in den Hauptspeicher zu laden und den Rest bei Bedarf nachzuladen

22 Technologische Konzepte des Vortrags Cache InMemory Compression SIMD Bloomfilter

23 2. Oracle InMemory-Technologie und SQL-Befehle SIMD*: Parallele CPU-Verarbeitung von Where-Bedingungen * = Single Instruction processing Multiple Data values Quelle Abbildung: Oracle White Paper: Oracle Database In-Memory, S. 11. (Oktober 2014)

24 Technologische Konzepte des Vortrags Cache InMemory Compression SIMD Bloomfilter

25 2. Oracle InMemory-Technologie und SQL-Befehle Bloom-Filter (Anwendung bei InMemory-Hash-Joins): Tabelle 1 Bisheriges Vorgehen Tabelle 2 ID V 1 A 2 B 3 C Quelle Abbildung: Oracle White Paper: Oracle Database In-Memory, S. 11. (Oktober 2014) FK ID V 1 1 C 2 2 A 3 3 B 2 4 A 2 5 C 1 6 D 77 7 F - 8 G - 9 H ( ) ( ) ( )

26 2. Oracle InMemory-Technologie und SQL-Befehle Bloom-Filter (Anwendung bei InMemory-Hash-Joins): Tabelle 1 Bisheriges Vorgehen ID V 1 A 2 B 3 C Hash V 97 1,A Hash (ID) 98 2,B 99 3,C Tabelle 2 FK ID V 1 1 C 2 2 A 3 3 B 2 4 A 2 5 C 1 6 D 77 7 F - 8 G - 9 H ( ) ( ) ( ) Anmerkung: V = Value. Die Hashtabellen sind vereinfacht dargestellt.

27 2. Oracle InMemory-Technologie und SQL-Befehle Bloom-Filter (Anwendung bei InMemory-Hash-Joins): Tabelle 1 Tabelle 2 ID V 1 A 2 B 3 C Hash (ID) Hash Anmerkung: V = Value. Die Hashtabellen sind vereinfacht dargestellt. V 97 1,A 98 2,B 99 3,C Bisheriges Vorgehen Hash (FK) Hash (FK) FK ID V 1 1 C 2 2 A 3 3 B 2 4 A 2 5 C 1 6 D 77 7 F - 8 G - 9 H ( ) ( ) ( )

28 2. Oracle InMemory-Technologie und SQL-Befehle Bloom-Filter (Anwendung bei InMemory-Hash-Joins): Tabelle 1 Tabelle 2 ID V 1 A 2 B 3 C Hash (ID) Hash Anmerkung: V = Value. Die Hashtabellen sind vereinfacht dargestellt. V 97 1,A 98 2,B 99 3,C Neues Vorgehen Bitvektor Hash V 97 1,1,A 98 2,2,B 99 3,3,C 98 2,4,A 98 2,5,C 97 1,6,D 135 3,7,F - 3,8,G - 3,9,H ( ) ( ) FK ID V 1 1 C 2 2 A 3 3 B 2 4 A 2 5 C 1 6 D 77 7 F - 8 G - 9 H ( ) ( ) ( )

29 2. Oracle InMemory-Technologie und SQL-Befehle Bloom-Filter (Anwendung bei InMemory-Hash-Joins): Tabelle 1 Tabelle 2 ID V 1 A 2 B 3 C Hash (ID) Hash Anmerkung: V = Value. Die Hashtabellen sind vereinfacht dargestellt. V 97 1,A 98 2,B 99 3,C Neues Vorgehen Bitvektor Hash V 97 1,1,A 98 2,2,B 99 3,3,C 98 2,4,A 98 2,5,C 97 1,6,D 135 3,7,F - 3,8,G - 3,9,H ( ) ( ) FK ID V 1 1 C 2 2 A 3 3 B 2 4 A 2 5 C 1 6 D 77 7 F - 8 G - 9 H ( ) ( ) ( )

30 2. Oracle InMemory-Technologie und SQL-Befehle Bloom-Filter (Anwendung bei InMemory-Hash-Joins): Hashtabelle 2 Hash V 97 1,1,A 98 2,2,B 99 3,3,C 98 2,4,A 98 2,5,C 97 1,6,D 135 3,7,F - 3,8,G - 3,9,H ( ) ( ) SIMD Bitvektor Gefilterte Hashtabelle 2 Hash V 97 1,1,A 98 2,2,B 99 3,3,C 98 2,4,A 98 2,5,C 97 1,6,D Hashtabelle 1 Hash V 97 1,A 98 2,B 99 3,C Quelle Abbildung: Oracle White Paper: Oracle Database In-Memory, S. 11. (Oktober 2014)

31 3. Oracle InMemory für das DWH Für die Oracle Database InMemory Option, ebenso wie für die Erhöhung des Caches wird RAM benötigt und muss gekauft werden. Unabhängig von diesen notwendigen Ausgaben stellt sich folgende Frage: Lohnt es sich, zusätzliches Geld für die InMemory-Option auszugeben oder sollte der bereits vorhandene Cache weitergenutzt werden?

32 3. Oracle InMemory für das DWH Nutzung im DWH: Vermutung: Spaltenorientierung ist im OLAP sinnvoll und erhöht die Performance. Dimensionstabellen lohnen sich wegen den Wiederholerwerten und Virtualisierung (Materialized View) spaltenorientiert zu speichern? Faktentabellen lohnen sich in der spaltenorientierten Speicherung, wenn nur wenige Spalten abgefragt werden? Praxis: Kann man das wirklich so pauschal sagen? Test der Fragestellung anhand vom mehreren Testfällen spannende Ergebnisse

33 3. Oracle InMemory für das DWH Erkenntnisse aus den Tests: Ziel ist eine Sensibilisierung: Nicht jede Query im DWH wird automatisch durch In-Memory schneller. Nicht nur Abfragen auf viele Spalten bremsen Performance, sondern: Anzahl der Joins und damit beteiligte Tabellen Art der Where-Bedingung Art der DML (Select, Insert, Update, )

34 3. Oracle InMemory für das DWH Erkenntnisse aus den Tests: Manchmal ist Cache genauso gut wie InMemory : Abfrage 1: SELECT sum(stunden_stz_kst), sum(stunden_stz_projekt), sum(stunden_budget_kst) FROM FAKT_KFP; Abfrage 2: SELECT sum(stunden_stz_kst), sum(stunden_stz_projekt), sum(stunden_budget_kst) FROM FAKT_KFP, DIM_PROJEKTE, DIM_MITARBEITER WHERE DIM_PROJEKTE.Projektname = :p_projektname AND DIM_MITARBEITER.Mitarbeitername= :p_mitarbeitername AND DIM_PROJEKTE.Projekt_ID = FAKT_KFP.Projekt_ID AND DIM_MITARBEITER.Mitarbeiternummer = FAKT_KFP.Mitarbeiternummer (Abfrage aus Datenschutzgründen parametrisiert)

35 3. Oracle InMemory für das DWH Erkenntnisse aus den Tests (Extrembeispiel): Zeitfaktor = Dauer gecachte Abfrage / Dauer InMemory-Abfrage 14 13,28 Zeitfaktor ,07 0 Abfrage 1, keine joins Abfrage 1, keine joins Abfrage 2, spezifische joins Abfrage 2, spezifische joins Anmerkung: Ergebnisse sind arithmetische Mittel mehrerer Kontrollabfragen, um ggf. andere parallel laufende Prozesse auszuschließen.

36 3. Oracle InMemory für das DWH Erkenntnisse aus den Tests: Abfragen des BI-Servers meist komplex (bei lange dauernden, zu optimierenden Anfragen) Oft werden spaltenorientierte Systeme gezwungen, zeilenorientiert zu arbeiten und kein Performancegewinn durch InMemory Bei OBIEE Hoffnung auf 12c-Version Für OLTP-Systeme und dem bisherigen ETL-Prozess ist InMemory nicht geeignet SQL-Review und Code-Review nötig, um optimale Nutzung für In- Memory zu garantieren!

37 3. Oracle InMemory für das DWH Erkenntnisse aus den Tests: InMemory bringt bei DWH-Abfragen mit großen Datenmengen und FULL Table Scans Performancegewinne, I/O sollte aber das einzige Bottleneck sein! Deutliche Reduzierung der physical und logical (!) reads aufgrund der spaltenorientierten Abbildung im Speicher Statistiken consistent gets (NO INMEMORY) physical reads (NO INMEMORY) 252 consistent gets (INMEMORY) 0 physical reads (INMEMORY) rows processed

38 4. Techn. Rahmenbedingungen Die Tests wurden unter folgenden Rahmenbedingungen durchgeführt: Testsystem 1 (kleines System): Oracle Release: DB-Host: rdslinux40 mit 2 GB RAM (nur für InMemory) Testsystem 2 (großes System): Oracle Release: DB-Host: rdslinux17 mit 64 GB RAM (nur für InMemory) Anmerkung: Es wurde keine Partitionierung verwendet.

39 5. Fazit Es wurde festgestellt, dass: InMemory nur in bestimmten Situationen Performancegewinne bringt (lesende Abfragen, Joins, Where-Bedingungen, gekoppelte Programme) Das Bottleneck auf die CPU verschoben wird Die von Oracle angebotenen BI-Tools Optimierungsbedarf haben Die Alternative Cache sinnvoll sein kann Deswegen: Vorher SQL- und Codereviews durchführen und Optimierungspotentiale abschätzen Verhältnis von Kosten und Nutzen untersuchen

40 5. Fazit Mit dem Hauptspeicher ist man immer schneller als im Vergleich zur Festplatte. Die eigentliche Frage / Diskussion sollte sein: Soll ich den Hauptspeicher zeilen- oder spaltenorientiert nutzen?

41 M.Sc. Frank Effenberger Systemberater Business Analytics externer Doktorand TU Dresden, Business Intelligence Research Telefon: Fragen?

42 [6. Quellen] Literatur: [AbMH08 S. 5ff] Abadi; Madden; Hachem, (2008). Column-Stores vs. Row-Stores: How Different Are They Really? [DOAG15 S. 16ff] Pokolm, Jens-Christian, (2015). Datenbank-Konsolidierung mit Multitenant und In Memory. DOAG SOUG News, Konsolidierung räumt die IT auf.erste Ausgabe Februar [Orac14 S. 7] Oracle White Paper: Oracle Database In-Memory. (Oktober 2014). Von abgerufen Kursmaterial aus TiF-Seminar, Oracle München (Schlaucher), Folie 251,252: /index.php?dir=downloads/01_DWH_Seminare_Kurs_Materialien_Folien_und_Skripte/01_01_DWH%20Technik%20i m%20fokus%20reihe_tif/ Bilder: