DOAG SID Data Warehouse

Präsentation zum Thema: "DOAG SID Data Warehouse"—  Präsentation transkript:

1 DOAG SID Data Warehouse
Star Schema Design

2 Was kostet ein Join? Einen zusätzlichen DB Block Read für den Index
Driving Table Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7 Row 8 … ... 07-16 03-06 00-02 rowid Index 0-1 Einen zusätzlichen DB Block Read für den Index Durchlaufen des B*Tree Baums Einen DB Block für die Daten Driven Table Row 1 Row 2 Row 3 ...

3 Was kostet ein Join… Es müssen zwei DB Blöcke gelesen werden
Diese werden (hoffentlich) im Cache gehalten Speziell wenn die Driven Table klein ist liegt sie komplett im Cache Kein sequentielles Lesen möglich da Index und Tabelle getrennt voneinander liegen Aber selbst wenn alles im Cache liegt, ein Join kostet etwas (wenn auch nicht sooo viel) aber: wenn er nur 1ms pro Zeile kostet sind das 1,6 Minuten für rows!

4 Ein Beispiel: Index plus Tabelle

5 Normalisiertes Datenmodell
Account ID Name Customer ID ... Account ID Branch ID Date Revenue ... Customer ID Name Office ID ... Branch ID Name ... Office ID Name ... Reports benötigen viele Joins Updates und inserts sind schnell Eingabemasken können leicht gebaut werden Datenmodell ist komplex (viele Tabellen, weite Wege)

6 Abschätzungen Wie schätzt man die Effektivität eines Datenmodells?
Über die Anzahl MByte die zu lesen sind Diese geben einen guten Anhaltspunkt, denn I/O ist für die Datenbank am teuersten Vernachlässigt dabei viele Faktoren, etwa Sequentielles lesen vs. Random Access oder Caching ja/nein, aber es ist Aufgabe der Datenbank die MByte möglichst effektiv zu lesen

7 Normalisiertes Datenmodell
select the sum(Revenue) per Office Name and Branch Name Account ID Name Customer ID ... Customer ID Name Office ID ... Account ID Branch ID Date Revenue ... (10+190) Bytes * 1*106rows = 200*106 Bytes (7+293) Bytes * 100’000rows = 30*106 Bytes ( ) Bytes *10*106rows = 900*106 Bytes Office ID Name ... Branch ID Name ... (2+38) Bytes * 100rows = 0.004*106 Bytes (4+116) Bytes * 8000rows = 0.96*106 Bytes

8 Normalisiertes Datenmodell
select the sum(Revenue) per Office Name and Customer Name Account ID Name Customer ID ... Customer ID Name Office ID ... Account ID Branch ID Date Revenue ... Office ID Name ... 200*106 Bytes 30*106 Bytes Branch ID Name ... 0.004*106 Bytes 900*106 Bytes 0.96*106 Bytes Offices * 106 Branches * 106 Customers * 106 Accounts * 106 Orders * 106 Offices Index 0MB Branches Index 0MB Customers Index 2MB Accounts Index 30MB + 1162MB to read =

9 Eine große Tabelle Wenn joins so teuer sind, legen wir doch alles in eine Tabelle Die Datenbank muss immer den kompletten Satz lesen Account ID Account Name ... Branch ID Branch Name Office Name Office ID Customer Name Customer ID Date Revenue +( ) for the Fact Data +190 for the Accounts Data +293 for the Customer Data +38 for the Office Data +116 for the Branch Data =727 Bytes 727 Bytes *10*106rows = 7270*106 Bytes 7 GByte müssen gelesen werden!!!

10 Star Schema Branch ID Branch Name Account ID Account Name Branch ID Account ID Customer ID Office ID Date Revenue Office ID Branch Name Customer ID Customer Name Ein geänderter Satz in der Quelle kann mehrere Sätze beeinflussen Nicht Sinnvoll für Eingabemasken Für Reports werden weniger Joins benötigt Datemodell ist einfacher zu verstehen Die zu lesende Datenmenge ist geringer Dafür werden zusätzliche Schlüssel in der großen Fact Tabelle benötigt

11 Star Schema select the sum(Revenue) per Office Name and Branch Name
Account ID Account Name Branch ID Branch Name Branch ID Account ID Customer ID Office ID Date Revenue (10+190) Bytes * 1*106rows = 200*106 Bytes (4+116) Bytes * 8000rows = 0.96*106 Bytes Office ID Office Name ( ) Bytes * 10*106 rows = 990*106 Bytes Customer ID Customer Name (2+38) Bytes * 100rows = 0.004*106 Bytes (7+293) Bytes * 100’000rows = 30*106 Bytes

12 Star Schema select the sum(Revenue) per Office Name and Branch Name
Branch ID Branch Name Branch ID Account ID Customer ID Office ID Date Revenue Account ID Account Name 0.96*106 Bytes 200*106 Bytes Office ID Office Name Customer ID Customer Name 0.004*106 Bytes 990*106 Bytes 30*106 Bytes Offices * 106 Branches * 106 Orders * 106 Offices Index 0MB Branches Index 0MB + 990MB to read =

13 Star Schema select the sum(Revenue) per Office Name and Branch Name
Branch ID Branch Name Branch ID Account ID Office ID Date Revenue Account ID Account Name 0.96*106 Bytes Customer ID Customer Name Office ID Office Name 493*106 Bytes 0.004*106 Bytes 920*106 Bytes Offices * 106 Branches * 106 Orders * 106 Offices Index 0MB Branches Index 0MB + 920MB to read =

14 Star Schema Principles
Joining ist teuer, also vermeiden Eine große Tabelle ist – wie gezeigt - nicht sinnvoll Joining mit kleinen Dimensionstabellen ist optimal da im Cache besonders wenn Einschränkungen auf der kleinen Dimensionstabelle liegen!!! Dimensionstabelle einschränken bedeutet einen Full Table Scan durchzuführen, aber auf den paar Sätzen…

15 Star Schema mit where clause
select the sum(Revenue) per Office Name and Branch Name where Office Name = “SFO” Branch ID Branch Name Account ID Account Name Branch ID Account ID Customer ID Office ID Date Revenue 0.96*106 Bytes 200*106 Bytes Office ID Office Name Customer ID Customer Name 0.004*106 Bytes 30*106 Bytes 90*106 Bytes for SFO Offices * 106 Branches * 106 Orders * 106 + Fact Office Index 3MB = 93MB to read

16 Normalisiertes Datenmodell mit where clause
select the sum(Revenue) per Office Name and Branch Name where Office Name = “SFO” Account ID Name Customer ID ... Customer ID Name Office ID ... Account ID Branch ID Date Revenue ... Office ID Name ... 200*106 Bytes 30*106 Bytes Branch ID Name ... 0.004*106 Bytes 90*106 Bytes for SFO 0.96*106 Bytes Offices * 106 Branches * 106 Customers * 106 Accounts * 106 Orders * 106 Offices Index 0MB Branches Index 0MB Customers Index 2MB Accounts Index 30MB + 352MB to read =

17 Ein typischer Anwendungsfall
Eine Dimensionstablle mit Millionen von Sätzen und ein paar Feldern die häufig benutzt werden Join von großen Tabellen ist besonders teuer Where-Bedingungen sowieso Man könnte diese in zwei Dimensionstabellen aufspalten z.B. eine Tabelle mit Name, Anschrift und eine mit Geschlecht, Status, Altersgruppe

18 Ein typischer Anwendungsfall
Customer Table Customer ID First Name Last Name Street State Martial Status Age Rich/Poor Indicator Diese Felder werden nur für einen Kunden gefragt Diese Felder werden ständig benötigt DIM Customers Customer ID First Name Last Name Street actual State actual Martial Status actual Age actual Rich/Poor Indicator actual Class ID e.g. 10*106 rows Fact Date Customer ID Class ID Revenue DIM Customer Class Class ID State Martial Status Age Rich/Poor Indicator 10*106 rows rows only

19 Ein typischer Anwendungsfall
Savings [Byte] = Source [Byte] - Fact Rows * Key Width [Bytes] - Class Rows * (Class Width + Key Width)

20 Summary Star Schema ist der Kompromiss zwischen
möglichst wenig joins notwendig und nicht alles in eine Tabelle stellen (nur zus. FKs) Die Effektivität kommt dann besonders zu tragen wenn die Dimensionen klein sind und daher ein Full Table Scan keine Zeit benötigt und die Dimensionstabelle komplett im Cache liegt (wird sowieso ständig gelesen)