: Die perfekte Kombination? DOAG Konferenz, 16. November 2016 Dani Schnider, Trivadis AG @dani_schnider BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENF HAMBURG KOPENHAGEN LAUSANNE MÜNCHEN STUTTGART WIEN ZÜRICH
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. 2 16.11.2016
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. 3 16.11.2016
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 Blueprints» @dani_schnider danischnider.wordpress.com 4 16.11.2016
Oracle Database In-Memory 5 16.11.2016
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. 6 16.11.2016
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 7 16.11.2016
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 8 16.11.2016
In-Memory & Data Warehouse 9 16.11.2016
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 10 16.11.2016
DWH Architektur (Beispiel) Data Warehouse Quellsysteme Staging Area Cleansing Area Core Marts BI-Plattform ETL Metadaten 11 16.11.2016
Welche Daten gehören in den In-Memory Column Store? Staging Area Data Warehouse Cleansing Area Core Marts????? Metadaten 12 16.11.2016
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 13 16.11.2016
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 14 16.11.2016
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 15 16.11.2016
In-Memory & Physisches Design 16 16.11.2016
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 17 16.11.2016
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 18 16.11.2016
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 19 16.11.2016
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 20 16.11.2016
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 21 16.11.2016
Abfrageoptimierung 22 16.11.2016
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 23 16.11.2016
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 1 3 3 1 2 2 24 16.11.2016
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) 25 16.11.2016
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 11 22 1000 11 24 1200 12 21 300 12 22 3200 12 24 700 13 22 1100 14 21 2000 14 24 800 14 25 1600 14 26 700 15 23 1100 15 24 1200 15 26 500 16 22 2400 16 23 800 17 22 1300 17 25 1100 18 21 900 18 24 2100 18 26 600 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, D22 26 16.11.2016
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 KV1 0 0 1 1 1 2 0 0 KV2 0 0 1 2 3 0 TMP1 1 Beta 2 Gamma TMP2 1 Y green 2 Y blue 3 Y red FACTS 11 22 1000 11 24 1200 12 21 300 12 22 3200 12 24 700 13 22 1100 14 21 2000 14 24 800 14 25 1600 14 26 700 15 23 1100 15 24 1200 15 26 500 16 22 2400 16 23 800 17 22 1300 17 25 1100 18 21 900 18 24 2100 18 26 600 0 0 0 2 0 0 0 0 0 2 1 0 1 0 1 2 1 3 1 0 1 1 1 2 1 0 2 0 2 1 0 0 0 3 0 0 0 2 0 0 Beta Y green 1100 Beta Y blue 2000 Beta Y red 1600 Gamma Y green 800 27 16.11.2016
Die perfekte Kombination? 28 16.11.2016
Quellen und weitere Informationen Oracle Database Online Documentation 12c Release 1 (12.1) Database SQL Tuning Guide, Chapter 5: Query Transformations https://docs.oracle.com/database/121/tgsql/tgsql_transform.htm#tgsql95256 Oracle Database In-Memory: In-Memory Aggregation Oracle White Paper, January 2015 (William Endress) http://www.oracle.com/technetwork/database/bi-datawarehousing/inmemory-aggregation-twp-01282015-2412192.pdf Oracle Database In-Memory Oracle White Paper, July 2015 (Maria Colgan) http://www.oracle.com/technetwork/database/in-memory/overview/twp-oracle-database-in-memory-2245633.html Oracle Scratchpad, In-memory Aggregation, August 2014 (Jonathan Lewis) https://jonathanlewis.wordpress.com/2014/08/24/in-memory-aggregation/ Bloom Filters, Trivadis Article, June 2008 (Christian Antognini) https://antognini.ch/papers/bloomfilters20080620.pdf 29 16.11.2016
Trivadis @ 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! 30 16.11.2016