ZWISCHEN ALBTRAUM UND OPTIMALER PERFORMANCE

Transkript

1 ZWISCHEN ALBTRAUM UND OPTIMALER PERFORMANCE Indexierungsstrategie im Data Warehouse Dani Schnider, Trivadis AG DOAG Konferenz, Nürnberg BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN 1

2 Dani Schnider Principal Consultant und DWH/BI Lead Architect bei Trivadis in Zürich Kursleiter für Trivadis-Kurse über Data Warehousing, SQL Optimierung und Oracle Warehouse Builder Co-Autor des Buches «Data Warehousing mit Oracle» 2

3 Über Trivadis Düsseldorf Hamburg Frankfurt Stuttgart München Freiburg Basel Zürich Bern ~180 Mitarbeiter Lausanne ~350 Mitarbeiter Wien ~20 Mitarbeiter Schweizer IT Consulting Unternehmen Hauptfokus Datenbanken Infrastructure Engineering Application Development Business Intelligence Managed Services Business Integration Services Training Mehr als 600 Mitarbeiter in 11 Niederlassungen in der Schweiz, in Deutschland und Österreich 3

4 Wie soll ich mein Data Warehouse indexieren? 4

5 Es gibt verschiedene Meinungen... Ein DWH-System hat mehr Indizes als ein OLTP-System Indizes machen die Abfragen schneller Fall Table Scans sind langsam Ein Data Warehouse sollte keine Indizes haben Indizes verlangsamen die ETL-Prozesse Jede Tabelle muss einen Primary Key haben Indizes sind für ein effizientes Laden der Daten notwendig Eine OLTP-Tabelle hat 2-3 Indizes, eine DWH-Tabelle 5-6 Bitmap Indizes sind für Attribute mit wenigen Werten sinnvoll 5

6 DWH OLTP «It depends...» 6

7 Data Warehouse Architektur Data Warehouse Quellsysteme Staging Area Cleansing Area Core Marts BI Plattform ETL Metadaten Wie sollen die verschiedenen Schichten im DWH indexiert werden? 7

8 Staging Area / Cleansing Area Staging Area Keine Indizes Cleansing Area Primary Key / Unique Key Constraints für Datenvalidierung Oracle erstellt automatisch einen Unique Index pro PK/UK Eventuell Index erst nach dem Laden berechnen (DISABLE / ENABLE CONSTRAINT) Keine weitere Indizes 8

9 Selektivität und Zugriffsmethode Selektivität = Prozentualer Anteil der Datensätze aus einer Tabelle Indexzugriffe sind effizient für selektive Abfragen (< 1-2% der Daten) Gilt sowohl für B-Tree Index als auch Bitmap Index Full Table Scans sind für nicht-selektive Abfragen effizienter In Staging Area und Cleansing Area werden immer 100% der Daten gelesen 9

10 Core Zweck von Core Datenintegration von verschiedenen Quellsystemen Historisierung und Versionierung Datenbasis für Data Marts Indexierung abhängig von verschiedenen Faktoren Logischem Datenmodell (dimensional / relational) Physischem Design (z.b. Partitionierung) Ladefrequenz der Data Marts 10

11 Indexierung von Core Dimensionales Core Primary Key Constraints auf Dimensionstabellen Oracle erstellt automatisch einen Unique Index pro PK/UK Alternativer Ansatz: PK/UK disablen, um Index zu vermeiden Keine Indizes auf Faktentabellen Relationales Core Primary Key / Unique Key Constraints auf Stammdaten Oracle erstellt automatisch einen Unique Index pro PK/UK Alternativer Ansatz: PK/UK disablen, um Index zu vermeiden Möglichst wenige oder keine Indizes auf Bewegungsdaten Indexierung von Foreign Keys nicht notwendig 11

12 Zeitliche Extraktion aus Core Core dient als Basis zum Laden der Data Marts Initiales Laden von Data Marts Keine Datumeinschränkung Eventuell Filter auf aktuelle Version der Stammdaten Bitmap Index auf VALID_TO Inkrementelles Laden der Data Marts Filter auf Gültigkeitsintervall der Stammdaten/Dimensionen Bitmap Index auf VALID_FROM Filter auf Ereignisdatum der Bewegungsdaten/Fakten Bitmap Index auf Ereignisdatum 12

13 Zeitliche Extraktion aus Core: Beispiel Core enthält Daten der letzten 3 Jahre Data Mart wird monatlich geladen Selektivität = 1/12/3 2.8% Full Table Scan Data Mart wird täglich geladen Selektivität = 1/365/3 0.09% Index Scan Besserer Ansatz: Core-Tabelle partitioniert pro Monat Selektivität monatlich = 1 = 100% Full Partition Scan Selektivität täglich = 1/31 3.2% Full Partition Scan 13

14 Benutzerzugriff auf Core Endbenutzer haben keinen Lesezugriff auf Core Ausnahme: Virtueller Data Mart Virtueller Data Mart View Layer für Benutzerzugriff auf Core Zusätzliche Bitmap Indizes auf Filterkriterien notwendig 14

15 B-Tree Index oder Bitmap Index? B-Tree Index ( ) Geeignet für selektive Abfragen Bitmap Index Mehrere Indizes können kombiniert werden Geeignet für selektive Abfragen Geeignet für Kombinationen von unselektiven Filterkriterien =, <, <=, >=, BETWEEN, LIKE, IN =, <, <=, >=, BETWEEN, LIKE, IN (IS NULL) Unique Index möglich Row Locking Standard Edition, Enterprise Edition!=, NOT IN, IS NULL, (IS NOT NULL) Nur Enterprise Edition 15

16 B-Tree Index oder Bitmap Index? Platzbedarf von Bitmap Index ist meistens kleiner Auch für Attribute mit vielen verschiedenen Werten Bitmap (scattered) Bitmap (sorted) B-tree index 16

17 In Data Warehouse generell Bitmap Indizes verwenden B-Tree Indizes werden nur für Primary / Unique Keys verwendet 17

18 Data Marts Dimensionstabellen Primary Key (Unique Index) Bitmap Indizes auf zusätzlichen Filter-Spalten (optional) Faktentabellen Bitmap Indizes auf Dimensionsattributen (Foreign Keys) Bitmap Join Indizes auf oft verwendete Filter-Spalten (optional) Typischerweise kein Primary Key 18

19 Abfrageoptimierung auf Star Schemas Typische Abfragen: Filterkriterien auf (mehreren) Dimensionstabellen Fakten werden durch Join mit Dimensionen selektiert Problem: Tabellen mit Restriktionen sollten zuerst gelesen werden Es können jeweils nur zwei Tabellen gejoined werden Keine Beziehungen zwischen Dimensionstabellen

20 Star Transformation Products Bitmap Index SALES_PROD_BIX AND Sales (Fact Table) Customers Bitmap Index SALES_CUST_BIX 20

21 Bitmap Join Index Bitmap Index definiert auf Faktentabelle Indexiertes Attribut gehört zu Dimensionstabelle Möglich für Star Schemas und Snowflake Schemas 21

22 Fazit Staging Area, Cleansing Area, Core: Weniger ist mehr! Data Marts: Einheitliche Indexierungsstrategie Generell Bitmap Indexes verwenden, B-Tree Indexes nur für Primary/Unique Keys Es gibt immer begründbare Ausnahmen 22

23 VIELEN DANK. Trivadis AG Dani Schnider Europa-Strasse 5 CH-8152 Glattbrugg/Zürich Schweiz Tel Fax info@trivadis.com BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN 23