Oracle In-Memory & Data Warehouse: Die perfekte Kombination?

Transkript

1 : Die perfekte Kombination? DOAG Konferenz, 16. November 2016 Dani Schnider, Trivadis BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENF HAMBURG KOPENHAGEN LAUSANNE MÜNCHEN STUTTGART WIEN ZÜRICH

2 Unser Unternehmen. Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem Solution Engineering und der Erbringung von IT-Services mit Fokussierung auf - und -Technologien in der Schweiz, Deutschland, Österreich und Dänemark. Trivadis erbringt ihre Leistungen aus den strategischen Geschäftsfeldern: B E T R I E B Trivadis Services übernimmt den korrespondierenden Betrieb Ihrer IT Systeme

3 Mit über 600 IT- und Fachexperten bei Ihnen vor Ort. KOPENHAGEN HAMBURG 14 Trivadis Niederlassungen mit über 600 Mitarbeitenden. Über 200 Service Level Agreements. Mehr als 4'000 Trainingsteilnehmer. DÜSSELDORF Forschungs- und Entwicklungsbudget: CHF 5.0 Mio. / EUR 4.0 Mio. FRANKFURT Finanziell unabhängig und nachhaltig profitabel. GENF BASEL BERN LAUSANNE FREIBURG BRUGG ZÜRICH STUTTGART MÜNCHEN WIEN Erfahrung aus mehr als 1'900 Projekten pro Jahr bei über 800 Kunden

4 Dani Schnider Principal Consultant, Teacher und DWH Lead Architect bei Trivadis in Zürich Co-Autor der Bücher «Data Warehousing mit Oracle» und «Data Warehouse danischnider.wordpress.com

5 Oracle Database In-Memory

6 The innovation of the Oracle In-Memory option is: We store the data both ways we store it two ways. We store it both in row format and in memory in columnar format. Next slide please! When we process queries, we have all the data in memory, and we can scan it very very quickly. So we speed up insert into the database and update to the database two three - four times by dropping these analytic indexes. Those analytic indexes are much more expensive to maintain than the column store that replaces the analytic indexes - and that's magic

7 Oracle Database In-Memory Architektur SGA UPDATE SELECT Buffer Cache IM Column Store TX Journal C1 C2 C3 C4 C5 DBWn User IMCO Wnnn Row Format

8 Vorteile von Oracle Database In-Memory Optimiert für analytische Abfragen und Real-Time-Reporting Schnelle Abfragen und Aggregationen auf grosse Datenmengen Spaltenweise Komprimierung der Daten im Memory Nur benötigte Spalten werden gelesen Weniger Aufwand für Performanceoptimierungen Keine applikatorischen Änderungen notwendig

9 In-Memory & Data Warehouse

10 Braucht es überhaupt noch ein Data Warehouse? Nein. Ja. Analytische Abfragen können direkt auf den operativen Systemen ausgeführt werden Durch In-Memory Column Store werden OLTP-Applikationen nicht belastet Ermöglicht Real-Time-Reporting auf den aktuellen Daten «A data warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decisionmaking process.» Integration von Daten aus unterschiedlichen Quellsystemen Historisierung/Versionierung der Daten (Nachvollziehbarkeit) Bereitstellung von Informationen für thematische Auswertungsbereiche William H. Inmon

11 DWH Architektur (Beispiel) Data Warehouse Quellsysteme Staging Area Cleansing Area Core Marts BI-Plattform ETL Metadaten

12 Welche Daten gehören in den In-Memory Column Store? Staging Area Data Warehouse Cleansing Area Core Marts????? Metadaten

13 Welche Daten gehören in den In-Memory Column Store? Einsatzgebiet von In-Memory im Data Warehouse: Data Marts Begründung: Abfrageoptimierung von häufig verwendeten Queries Star Schema ist idealer Kandidat für In-Memory Column Store Core Marts

14 Oracle Database In-Memory und Star Schema Einsatzgebiet von In-Memory im Data Warehouse: Data Marts Begründung: Abfrageoptimierung von häufig verwendeten Queries Star Schema ist idealer Kandidat für In-Memory Column Store Nur benötigte Spalten müssen gelesen und aggregiert werden

15 Was ändert sich beim Einsatz von In-Memory im DWH? Fast nichts. Aufgaben im Data Warehouse bleiben gleich Architektur (DWH-Schichten) bleibt gleich Datenmodelle bleiben gleich Abfragen, Reports und BI-Applikationen bleiben gleich Was ändert sich? Physisches Design der Data Marts

16 In-Memory & Physisches Design

17 Physisches Design von Data Marts (bisher) Dimensionstabellen: Primary Key Constraint ev. Bitmap Indizes auf Filterattribute Faktentabellen: Partitionierung (in der Regel nach Datum) Foreign Key Constraints auf Dimensionen Bitmap Index auf jedem Dimensionsschlüssel ev. zusätzliche Bitmap Join Indizes Optimizer-Statistiken Materialized Views Materialized Views für häufig verwendete Aggregationsstufen Dimension-Objekte für Hierarchien auf Dimensionstabellen ev. Materialized View Logs auf Core-Tabellen ev. Indizes auf Materialized Views ev. Partitionierung der Materialized Views Aktualisierung der Statistiken nach ETL-Lauf

18 Physisches Design von Data Marts (mit In-Memory) Dimensionstabellen: Primary Key Constraint Faktentabellen: Partitionierung (in der Regel nach Datum) Foreign Key Constraints auf Dimensionen ev. Partial Bitmap Indexes auf Faktentabellen Optimizer-Statistiken Aktualisierung der Statistiken nach ETL-Lauf In-Memory Column Store Alle Dimensionstabellen Kleine Faktentabellen (vollständig) Bei grossen Faktentabellen ev. nur häufig verwendete Kennzahlen / Dimensionsschlüssel Bei partitionierten Faktentabellen ev. nur aktuelle (bzw. häufig verwendete) Partitionen In-Memory Compression Type Meistens MEMCOMPRESS FOR QUERY LOW

19 Konfiguration von INMEMORY pro Tabelle Ganze Tabelle ALTER TABLE sales INMEMORY Einzelne Spalten ALTER TABLE sales INMEMORY (cust_id,time_id) Einzelne Partitionen ALTER TABLE sales MODIFY PARTITION p_2016 INMEMORY

20 In-Memory Compression Type Compression Level NO MEMCOMPRESS MEMCOMPRESS FOR DML MEMCOMPRESS FOR QUERY LOW MEMCOMPRESS FOR QUERY HIGH MEMCOMPRESS FOR CAPACITY LOW MEMCOMPRESS FOR CAPACITY HIGH Description Data is populated without any compression Minimal compression optimized for DML performance Optimized for query performance (default) Optimized for query performance as well as space saving Balanced with a greater bias towards space saving Optimized for space saving

21 In-Memory & Partial Local Index Index Partition P1 Index Partition P2 Index Partition P3 Index Partition P4 Index Partition P5 Index Partition P6 Table Partition P1 Table Partition P2 Table Partition P3 Table Partition P4 Table Partition P5 INMEMORY Table Partition P6 INMEMORY INDEXING ON INDEXING OFF

22 Abfrageoptimierung

23 In-Memory Performance Features In-Memory Scan Spaltenweises Lesen der Daten aus dem IM Column Store Aggregation auf gewünschte Granularität In-Memory Join Effiziente Methode, um Tabellen zu joinen Verwendung von sogenannten Bloom Filters In-Memory Aggregation Vergleichbar mit Star Transformation Verwendung von Key Vectors statt Bitmap Indizes

24 Abfrageoptimierung auf Star Schemas Typische Abfragen auf Star Schema: Filterkriterien auf Dimensionen Fakten werden durch Join mit Dimensionen ermittelt Problemstellung: Tabellen mit Filterkriterien sollten zuerst evaluiert werden Join nur auf jeweils zwei Tabellen Keine Beziehungen zwischen Dimensionen

25 In-Memory Aggregation (Vector Transformation) Phase 1 (für jede Dimension mit Filterkriterien) 1. Scan auf Dimensionstabelle (inkl. Filterung der Daten) 2. Ermittlung von Key Vector 3. Aggregation der Daten (In-Memory Accumulator) 4. Erstellen von temporärer Tabelle Phase 2 5. Full Table Scan auf Faktentabelle, Filterung anhand von Key Vectors 6. Aggregation mittels HASH GROUP BY / VECTOR GROUP BY 7. Join auf temporäre Tabellen (Join Back) 8. Ev. Join von weiteren Dimensionen (ohne Filterkriterien)

26 In-Memory Aggregation (Vector Transformation) DIM1 11 Alpha 12 Alpha 13 Beta 14 Beta 15 Beta 16 Gamma 17 Delta 18 Delta DIM2 21 X green 22 X blue 23 Y green 24 Y blue 25 Y red 26 Z red FACTS SELECT D1, D21, D22, SUM(FACTS.F) FROM FACTS JOIN DIM1 ON (...) JOIN DIM2 ON (...) WHERE D1 IN ('Beta', 'Gamma') AND D21 = 'Y' GROUP BY D1, D21, D

27 In-Memory Aggregation (Vector Transformation) DIM1 11 Alpha 12 Alpha 13 Beta 14 Beta 15 Beta 16 Gamma 17 Delta 18 Delta DIM2 21 X green 22 X blue 23 Y green 24 Y blue 25 Y red 26 Z red KV KV TMP1 1 Beta 2 Gamma TMP2 1 Y green 2 Y blue 3 Y red FACTS Beta Y green 1100 Beta Y blue 2000 Beta Y red 1600 Gamma Y green

28 Die perfekte Kombination?

29 Quellen und weitere Informationen Oracle Database Online Documentation 12c Release 1 (12.1) Database SQL Tuning Guide, Chapter 5: Query Transformations Oracle Database In-Memory: In-Memory Aggregation Oracle White Paper, January 2015 (William Endress) Oracle Database In-Memory Oracle White Paper, July 2015 (Maria Colgan) Oracle Scratchpad, In-memory Aggregation, August 2014 (Jonathan Lewis) Bloom Filters, Trivadis Article, June 2008 (Christian Antognini)

30 DOAG 2016 Stand: 3ter Stock direkt an der Rolltreppe Know how, T-Shirts, Gewinnspiel und Trivadis Power to go Wir freuen uns wenn Sie vorbei schauen Weil Sie mit Trivadis immer gewinnen!