Partitionieren Sie Ihr Data Warehouse!

Transkript

1 Partitionieren Sie Ihr Data Warehouse! Beat Flühmann Trivadis AG Zürich (Schweiz) Schlüsselworte: BI, DWH, Partitionierung, phys. Modellierung Einleitung Die Technik der Partitionierung ist schon seit Oracle8 bekannt. Nach RANGE-, HASH- und LIST-(Sub-)Partitioning sind in Oracle11g auch die REFERENCE-Partitioning sowie weitere Kombinationen von Composite-Partitioning hinzugekommen. Mit diesen Möglichkeiten lassen sich auch grosse Datenmengen einfacher strukturieren, verwalten und vor allem schneller lesen! Im Bereich Business Intelligence/Data Warehouse (BI/DWH) wird Partitionierung zwar schon vielfach angewendet, aber öfters wäre mit kleinem Zusatzaufwand eine Resourcenschonendere Implementation möglich. Wie partitionieren? Partitionierung ist physische Modellierungsoption Die Partitionierung ist eine klassische physische Modellierungsoption, welche für den Endbenutzer transparent und im Normalfall nur durch bessere Performance sichtbar wird. Statt wie bis anhin, besteht eine Tabelle 1 nicht nur aus einem einzigen Segment, sondern aus einem Set von Segmenten, welche je eine Partition der Tabelle bilden. Der Benutzer greift weiterhin auf dieselbe Tabelle zu, während der Optimizer im Hintergrund dann den Zugriff auf die benötigten Partitionen umlenkt. Partitionierungsmethoden Beim Erstellen einer partitionierten Tabelle wird angegeben nach welchem Attribut (= Partitionierungsschlüssel) partitioniert wird. Der Partitionierungsschlüssel kann aus einem oder mehreren (Multicolumn Partitioning) Attributen bestehen 1 Auch wenn hier meist nur Tabellen erwähnt werden: es können auch Materialized Views oder Indexes partitioniert werden

2 welche Art der Begrenzung gewählt wird o RANGE Aufteilung nach Wertebereichen, z.b. Jahr o LIST Aufteilung nach einer Liste von fixen Werten (z.b. Ländercodes) o HASH Gleichmässige Verteilung der Daten (z.b. für Parallelisierung) o REFERENCE Aufteilung analog zur referenzierten Tabelle (via Foreign Key) ob nur einstufig partitioniert wird, oder ob in einer zweiten Stufe subpartitioniert wird (Composite Partitioning) Ab Oracle 11g sind alle sinnvollen Kombinationen des Composite Partitioning möglich: Beispiel: SUBPARTITION - (none) CREATE TABLE fact( country VARCHAR2(3) NOT NULL, product_id NUMBER(6) NOT NULL, salesdate DATE NOT NULL, amount NUMBER(8,2) NOT NULL) PARTITION BY RANGE (salesdate) SUBPARTITION BY LIST (country) SUBPARTITION TEMPLATE ( SUBPARTITION west VALUES ('F', 'E'), SUBPARTITION east VALUES ('A'), SUBPARTITION cent VALUES ('D', 'CH')) > Subpartition BY LIST ( PARTITION p_2005 VALUES LESS THAN (TO_DATE(' ', 'DD-MM-YYYY')), PARTITION p_2006 VALUES LESS THAN (TO_DATE(' ', 'DD-MM-YYYY')), PARTITION p_2007 VALUES LESS THAN (TO_DATE(' ', 'DD-MM-YYYY')), PARTITION p_2008 VALUES LESS THAN (TO_DATE(' ', 'DD-MM-YYYY')), PARTITION p_2009 VALUES LESS THAN (TO_DATE(' ', 'DD-MM-YYYY'))); CREATE BITMAP INDEX bix_fact_product_id ON fact(product_id) LOCAL; Die Partitionierungsmethode ist hier RANGE gemäss Schlüssel SALESDATE und auf Subpartitionsebene LIST mit Schlüssel COUNTRY. Weiter könnte für jede (Sub-)Partition die Storage Clause wie z. B. TABLESPACE oder COMPRESS (siehe unten) einzeln angegeben werden. Partitionsoperationen PARTITION RANGE LIST HASH REFERENCE RANGE LIST HASH RANGE - - LIST - - HASH - - REFERENCE Operationen auf ganzen Partitionen (ADD, SPLIT, MERGE, DROP, TRUNCATE) ermöglichen es Tabellen so zu strukturieren, dass Teile davon weiterhin in handhabbaren Grössen manipulierbar sind.

3 Nachdem eine Tabelle mit Partitionen 2 angelegt wurde können Partitionen hinzugefügt (ADD), existierende aufgeteilt (SPLIT) oder zusammengefügt (MERGE) oder einzeln gelöscht (DROP) werden. ALTER TABLE fact ADD PARTITION p_2010 VALUES LESS THAN (TO_DATE(' ', 'DD-MM-YYYY'))); In einer solch neu hinzugefügten Partition sind definitionsgemäss noch keinerlei Daten vorhanden, weshalb diese Operation in Millisekunden beendet ist, da dabei nur das Data Dictionary nachgeführt wird. Ebenso schnell wird ein DROP ausgeführt, jedoch ist hier zu berücksichtigen, dass Globale Indizes auf INVALID gesetzt werden (siehe weiter unten), und allenfalls neu gebildet werden müssen. Bei SPLIT und MERGE werden Daten physisch reorganisiert und darauf basierende Indizes aktualisiert. Deshalb können diese Operationen in Abhängigkeit der Datenmenge auch länger dauern. Warum partitionieren? Wie erwähnt ist die Partitionierung eine physische Datenmodellierungsoption. Bei sinnvoller Anwendung kann dadurch die Performance einer DML-Operation beschleunigt werden, ohne dass ein Benutzer seine Befehle ändern muss. Partition Elimination (Pruning) Sofern in der WHERE-Bedingung der Partitionierungsschlüssel eingegrenzt wird, kann alleine aus den Metadaten (Partitionsgrenzen) die effektiv benötigten Partitionen ermittelt werden, bevor auch nur ein einziger Datensatz gelesen wurde. Damit alleine kann ein erheblicher Performancegewinn erreicht werden, da deutlich weniger I/O notwendig wird. Im Execution Plan wird das Partition Pruning in den Spalten P(artition)start und P(artition)stop sichtbar. SELECT * FROM fact WHERE salesdate >= TO_DATE('1-JAN-2007','DD-MON-YYYY') AND salesdate < TO_DATE('1-JAN-2009','DD-MON-YYYY') AND country = 'A' Id Operation Name Pstart Pstop SELECT STATEMENT 1 PARTITION RANGE ITERATOR PARTITION LIST SINGLE 2 2 * 3 TABLE ACCESS FULL FACT Die beiden Subpartitionen P_2007_EAST und P_2008_EAST werden mit einem Full Subpartition Scan gelesen. 2 Eine Umwandlung einer nicht partitionierten in eine partitionierte Tabelle ist weiterhin mit Aufwand verbunden

4 Partition-Wise Joins Bei einem Partition-Wise Join wird der Join aufgeteilt in mehrere kleinere Joins auf einzelnen Partitionen. Full partition-wise Joins Beide Tabellen werden nach dem gleichem Partition Key partitioniert und der Partition Key entspricht dem Join-Attribut. Die Ausführung kann seriell oder parallel vonstatten gehen. Partial partition-wise Joins Nur eine Tabelle ist partitioniert. Deshalb kommt auch nur die parallele Ausführung zum Tragen. Partitionierung im DWH Die Ausführungen bis anhin haben grundsätzlich Gültigkeit sowohl in OLTP- wie auch in DWH-Systemen. Gerade in DWHs, wo oft mit Millionen von Datensätzen und dementsprechend grossen Datenmengen gearbeitet wird, ist es aber von zentraler Bedeutung, dass Partitionierung richtig eingesetzt wird. Fakten-Tabellen In einem DWH sind vor allem Leseoperationen aus den Faktentabellen die grossen I/O- Konsumenten. Da sind durch sinnvolle Anwendung der Partitionierung vielfach grosse Performancegewinne zu erzielen. Partitionierungsschlüssel passt zu den häufigen Abfragen Entgegen dem öfters gesehenen Ansatz, Faktentabellen nach dem Lade-Schlüssel zu partitionieren (LOAD_ID), sollte der Partition Key direkten Bezug zu den (häufigsten) Abfragen haben. Eine Bestellungstabelle sollte deshalb mit dem Schlüssel Buchungsdatum partitioniert werden (= Eingrenzungsmerkmal) und nicht nach dem Ladedatum! Auch wenn es für das Undo eines Ladeprozesses einfacher wäre, wenn mit TRUNCATE PARTITION einfach eine ganze Partition zurückgefahren werden könnte, steht das in keinem Verhältnis zum x-fachen Lesen derselben Tabelle für Auswertungen. Als Lösung käme folgende Variante in Frage: Vielfach ist das Ladedatum direkt korreliert zum abgefragten Buchungsdatum, d.h. das Ladedatum ist zu mehr als 99% dasselbe, wie das Buchungsdatum plus 1 Tag. Vergessene Buchungen kommen in seltenen Fällen vor und können Tage oder sogar Wochen zurückliegen, sind aber von der Anzahl her vernachlässigbar. Eine Ladetabelle wird aufgebaut, welche gleich partitioniert ist, wie die Zieltabelle, welche ihrerseits mit der Ladefrequenz (täglich) partitioniert ist. Nachdem der Ladeprozess als Ganzes okay ist, wird diejenige Partition, mit 99% der Daten, mit Partition Exchange mit der Zieltabelle ausgetauscht. Anschliessend werden die verbleibenden 1% mit einem INSERT AS SELECT geladen.

5 Nur LOCAL Indexes auf partitionierten Tabellen Der einzige Grund in DWH-Systemen, weshalb globale Indizes erstellt werden, ist, um Eindeutigkeit (Primary Key oder Unique Constraints) zu überprüfen. Dies kann aber auch durch geeignete Implementation des ETL-Prozesses realisiert werden. Für die Partitioning-Maintenance mit DROP oder TRUNCATE, wären globale Indexes äusserst hinderlich, da dadurch der gesamte Index INVALID wird. Typischerweise werden auf den Fakten keine Primary oder Unique Key Constraints erstellt. Partition Exchange Eine elegante Variante, um die Daten einer ganzen Partition einer Tabelle hinzuzufügen, existiert mit Partition Exchange. Diese ist ein klassisches DWH-Feature, da der Austausch selber nur eine Metadatenoperation ist und sehr schnell erledigt wird. 1) Aufbau einer unpartitionierten Tabelle (A) mit exakt gleicher Struktur einer partitionierten Tabelle (B) (inkl. Indexes, etc.) CREATE TABLE fact_tmp( country VARCHAR2(3) NOT NULL, product_id NUMBER(6) NOT NULL, salesdate DATE NOT NULL, amount NUMBER(8,2) NOT NULL); 2) Laden von der Datensätze in A (B ist davon nicht betroffen) INSERT INTO fact_tmp AS SELECT FROM CREATE BITMAP INDEX bix_fact_product_id ON fact(product_id); 3) Austausch der Metadaten (!) von A mit einer Partition von B ALTER TABLE fact EXCHANGE PARTITION p_2008 WITH TABLE fact_tmp INCLUDING INDEXES WITHOUT VALIDATION; Sollten Daten vor dem Exchange in p_2008 vorhanden gewesen sein, so sind sie nachher in fact_tmp sichtbar. Verwendung hat das Partition Exchange nicht nur beim Laden der Daten, sondern unter Umständen auch bei der Archivierung von Daten (Rolling History) oder bei Reorganisationen und Datenmigrationen. Statistiken auf partitionierten Tabellen Mit dem DBMS_STATS-Package können bekanntlich Statistiken berechnet werden. Für Tabellen ist der Mechanismus bekannt. Wie verhält sich aber Oracle mit partitionierten Tabellen? Der Parameter GRANULARITY bestimmt, auf welchem Level in partitionierten Tabellen die Statistiken berechnet werden. Fehlen dem Optimizer Statistiken auf Partitionen oder der Tabelle, so werden diese hochaggregiert! Sobald aber einmal globale Statistiken berechnet wurden, so wird dieser Mechanismus nicht mehr angewendet.

6 Dies führt zum Teil zur grotesken Situation, dass die geschätzte Anzahl Records auf Tabellenebene deutlich von der Summe der Records aller Partitionen abweichen kann. Deshalb sollte auf partitionierten Tabellen die Statistiken entweder auf unterster Stufe berechnet werden und auf globale Statistiken verzichtet werden - mit dem Nachteil, dass NUM_DISTINCT nicht nachgeführt sind, oder globale Statistiken periodisch (z.b. am Wochenende) aktualisieren. Bei Partition Exchange ist zu berücksichtigen, dass Statistiken auch ausgetauscht werden. Diese müssen daher entweder vorher auf der Temp-Tabelle (vorzugsweise, denn das DWH ist davon kaum betroffen), oder nachher auf der Partition berechnet werden. Datenarchivierung Da sich Fakten nicht mehr ändern, können am Monatsende die gespeicherten Fakten archiviert werden. Werden die dazu notwenigen Monatspartitionen mit der COMPRESS 3 Option reorganisiert, so lassen sich Platzreduktionen um Faktoren 4 erreichen. Der CPU-Mehraufwand bei der Dekomprimierung wird durch die Reduktion des I/O um ein mehrfaches kompensiert. Wenn zudem diese Partitionen auf separaten Tablespaces liegen, so spricht kaum etwas dagegen, diese Tablespaces anschliessend auf READONLY zu setzen, und so ein effizienteres Backup zu erreichen. Der Nachteil der Komprimierung liegt aber wie immer im Detail. Wenn später die Struktur der Tabelle geändert werden soll (z. B. zusätzliches Attribut), müssen die komprimierten Partitionen vorgängig zuerst dekomprimiert werden. Sollen die Daten nach einer bestimmten Zeit gar nicht mehr online gehalten werden, so können ganze Monate mit TRUNCATE PARTITION einfach auch ganz gelöscht werden. Dimensionen Normalerweise enthält eine Dimension wenige bis einige tausend Datensätze. Hier lohnt sich eine Partitionierung selten, da bei Datenblöcken von 16K, mindestens 5 Datenblöcken pro Segment und einen DB_FILE_MULTIBLOCK_READ_COUNT von typischerweise 64 diese Dimension sowieso immer ein Full Table Scan gemacht wird 5. Mit der Einführung der REFERENCE-Partitioning in Oracle11g kann es aber durchaus sinnvoll sein, auch Kleinstdimensionen zu partitionieren, da gemäss Definition die referenzierende (Fakten-)Tabelle nach dem selben Schlüssel partitioniert wird. Bei häufiger Eingrenzung auf diesem Attribut kann sofort auf der Faktentabelle vom Partition Pruning profitiert werden. 3 komprimierte Tabellen oder Partitionen mit aktualisierten Statistiken - können andere Execution Plans bewirken, mit tendenziell mehr Full Table/Partition Scans 4 Erfahrungswert an aktuellen Projekten: 3-8! 5 Aus demselben Grund sind Nonunique Indexes auf kleinen Dimensionen kaum sinnvoll

7 Beispiel: CREATE TABLE product ( product_id NUMBER NOT NULL, /* Surrogate Key */ product_code VARCHAR2(4) NOT NULL, /* Business Key */ product_group VARCHAR2(20) NOT NULL, /* Desc Attribut */ valid_from DATE NOT NULL, /* SCD II, Gültigkeitsanfang */ valid_to DATE NOT NULL, /* SCD II, Gültigkeitsende */ CONSTRAINT product_pk PRIMARY KEY (product_id)) PARTITION BY LIST (product_group) ( partition group_a VALUES ('A'), partition group_b VALUES ('B')); CREATE TABLE fact ( product_id NUMBER NOT NULL, salesdate DATE NOT NULL, amount NUMBER NOT NULL, CONSTRAINT fk_product FOREIGN KEY (product_id) REFERENCES product (product_id)) PARTITION BY REFERENCE (fk_product); Monster Dimension Leider weicht die Theorie öfters von der Praxis ab, wenn Dimensionen plötzlich Millionen von Datensätzen aufweisen. Dies kommt öfters vor, wenn eine volle Historie (Slowly Changing Dimension, SCD II) einer Dimension verlangt wird, die beschreibenden Attribute häufig wechseln und die Anzahl der Dimensionsausprägungen als Basis schon sehr hoch ist. Bei einem Produktestamm mit 500'000 Produkten und 20% Änderungen pro Monat 6 ergibt das in 5 Jahren 6.4 Mio Datensätze. Aber auch Dimensionen mit 50 Mio Datensätzen sind bekannt. Solche Dimensionen sind dann nicht mehr SCD, sondern tendieren zu Rapidly changing Monster Dimensions. Der Surrogate Key eignet sich kaum als Partitionierunsgschlüssel, der Business Key im seltenen Fall, wenn es sich zu 100% um einen sprechenden Schlüssel handelt, und auch beschreibende Attribute sind selten dafür geeignet. Von der Partitionierung nach Auditing-ID ist sowieso abzusehen. Allenfalls könnten noch Gruppierungsattribute (z.b. Kundenhauptsegmente) für eine (List-) Partitionierung benutzt werden, je nachdem wie oft danach bei den Abfragen eingeschränkt wird. Als Kandidaten für den Partitionierungsschlüssel verbleiben also meist nur die beiden Gültigkeitsattribute VALID_FROM und/oder VALID_TO. Ein RANGE Partitioning auf VALID_FROM bringt auch selten einen grossen Gewinn, da einzelne Datensätze seit weit aus der Vergangenheit weiterhin Gültigkeit haben, und deshalb bei einer Abfrage nicht ausgeschlossen werden dürfen. Als Variante bleibt da die RANGE-Partitioning nach VALID_TO. Aus Erfahrung in laufenden Projekten zeigt sich, dass ein Grossteil der Abfragen auf den Faktentabelle zeitnah sind, betreffen also den aktuellen Monat oder einige Vormonate. D.h. 6 ob in einem solchen Fall das dimensionale Modell ideal ist?

8 die Abfragen grenzen meist auf der Zeitachse die letzten paar Monate ein (z. B. Verkaufsdatum zwischen 1. August und 31. Oktober). Implizit ist darin enthalten, dass Dimensionssätze mit VALID_TO vor dem 1. August ausser acht gelassen werden können, da Fakten nur auf aktuell gültige Dimensionswerte referenzieren dürfen. Mit anderen Worten: Dimensionswerte vor dem Abfragezeitraum sind nicht von Bedeutung. Wenn nun Monster Dimensionen nach VALID_TO (monats-)partitioniert sind, so können dank Partition Pruning ein Grossteil der Dimension eliminiert und damit Ressourcen geschont werden. Ganz gratis ist dieser Gewinn nicht zu erhalten. Abfragen müssen erweitert werden, da dieses implizite Wissen der Datenbank nicht bekannt ist. SELECT FROM fact JOIN dim ON (fact.dim_id = dim.dim_id) WHERE fact.salesdate BETWEEN TO_DATE(' ', 'DD-MM-YYYY') AND TO_DATE(' ', 'DD-MM-YYYY') AND dim.valid_to >= TO_DATE('01-AUG-2009'', 'DD-MM-YYYY') <-- zusätzlich! Row Movement Typischerweise wird bei SCD II bei einer Änderung die Vorversion terminiert, d.h. VALID_TO von 31-DEC-9999 auf heute geändert, und ein neue Version mit VALID_FROM = heute eingefügt (VALID_TO = 31-DEC-9999). Dies würde in den allermeisten Fällen ein Row Movement 7 in eine andere Partition bewirken. Um dies zu vermeiden wird der Mechanismus umgekehrt: Die alte Version wird dupliziert, ausser dem Attribut VALID_TO= heute, und die alten Attribute mit den neuen Werten updated, ausser eben VALID_TO. Der Business Key ist Objekt-Identifikator und bleibt logischerweise bestehen. Surrogate Key Business Key Description Valid_From Valid_To 1 2 ABC Desc Change 01-JAN MAY DEC-99 <-- UPDATE 1 ABC Desc 01-JAN MAY-09 <-- INSERT Man könnte nun einwenden, dass dafür alle existierenden Indexes nachgeführt werden müssen. Korrekt, aber dies ist auch bei einem Row Movement der Fall. 7 da ein Update auf dem Partitionierungsschlüssel gemacht wird

9 Aus diesen Ausführungen wird ersichtlich, dass im Bereich DWH-Partitionierung ein beinahe unendliches Feld von Möglichkeiten bietet. Einige davon wurden hier aufgezeigt, einzelne Themen konnten nur am Rand erwähnt werden, und viele blieben immer noch unerwähnt. Klar ist auf jeden Fall: Partitionieren Sie Ihr Data Warehouse! Kontaktadresse: Beat Flühmann Trivadis AG Europastr. 5 CH-8152 Glattbrugg/Zürich Telefon: +41(0) Fax: +41(0) beat.fluehmann@trivadis.com Internet: