Data Warehousing Partitionierung – Seminararbeit – eingereicht von Benjamin Dunst Betreuer Thomas Müller Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Ernst-Abbe-Platz 1-4 07743 Jena Kurzfassung Die Partitionierungstechnik dient im Allgemeinen der Verbesserung der Skalierbarkeit und Verwaltbarkeit von großen Relationen, die im Bereich des Data Warehousing schnell eine Dimension von mehreren Millionen Tupeln annehmen können, und kann auf Tabellen und Indizes angewandt werden. Wenn Tabellen und Indizes sehr umfangreich werden, kann diese Technik durch das Aufteilen der Daten in kleinere Abschnitte sehr hilfreich sein. Dies ist ein wichtiger Punkt für die Anfrageoptimierung. Anfragen, die zum Beispiel gegen partitionierte Tabellen gestellt werden, können die Partitionierung in sofern nutzen, dass nicht alle Partitionen durchsucht werden müssen oder ggfs. parallel gescannt werden können. Davon können vor allem Bereichsanfragen profitieren, welche typische Warehouse-Anfragen sind. Das Ziel ist dabei kurze Antwortzeiten für komplexe Anfragen zu erzielen. -1- Inhaltsverzeichnis 1 Einführung und Motivation ...................................................................................1 2 Grundlagen der Partitionierung............................................................................1 2.1 Partitionierungsverfahren..................................................................................4 2.1.1 Werteabhängige Partitionierung ...............................................................4 2.1.2 Werteunabhängige Partitionierung ...........................................................5 2.2 Tabellenpartitionierung.....................................................................................5 2.2.1 Eindimensionale Partitionierung...............................................................6 2.2.2 Mehrdimensionale Partitionierung............................................................6 2.3 Zugriffspfadpartitionierung...............................................................................8 2.3.1 Lokale und globale Indizes .......................................................................9 2.3.2 Prefixed und Non-Prefixed Indizes.........................................................10 2.4 3 Herstellerspezifische Partitionierungsmöglichkeiten......................................10 Partitionierung im Data Warehousing Umfeld..................................................10 3.1 Optimierungspotenziale ..................................................................................11 3.1.1 Verwaltung sehr großer Relationen ........................................................11 3.1.2 Überspringen von Partitionen bei der Anfrageauswertung.....................11 3.1.3 Ausnutzung paralleler Datenbank- und Systemarchitekturen.................12 3.2 Partitionierungsstrategie für ein Data Warehouse ..........................................12 3.2.1 Beispiel eines Sternschemas ...................................................................12 3.2.2 Anfrageverarbeitung gegen partitionierte Tabellen ................................13 4 Zusammenfassung.................................................................................................14 5 Literatur.................................................................................................................15 -2- Abbildungsverzeichnis Abbildung 1: Möglichkeiten mehrdimensionaler Partitionierung……………….….7 Abbildung 2: Lokal partitionierter Index………………………………………........9 Abbildung 3: Global partitionierter Index…………………………………………..9 Abbildung 4: Vergleich ausgewählter DBMS-Hersteller bez. Part.arten………….10 Abbildung 5: Beispiel für ein Sternschema………………………………………..13 Tabellenverzeichnis Tabelle 1: Ausgangstabelle für horizontale und vertikale Partitionierung…….........2 Tabelle 2: Horizontal partitionierte Ausgangstabelle……………………………….3 Tabelle 3: Vertikal partitionierte Ausgangstabelle…………………………….........3 Tabelle 4: Faktentabelle zum Sternschema………………………………………..13 -3- 1 Einführung und Motivation Die Technik der Partitionierung entwickelte sich ursprünglich aus dem Bereich der verteilten [ÖV99] und parallelen [DG92] Datenbanken. Es wurde dabei beachtet, dass bedingt eine große Relation physisch auf verschiedene Lokalitäten aufgeteilt und somit eine Relation mit zunehmender Detaillierung in einzelne Partitionen zerlegt werden kann. Seit Mitte der 90er Jahre fand diese Technik den Einzug in zentralisierte Datenbankmanagementsysteme. Die Partitionierungstechnik bietet einen Ansatzpunkt für eine Steigerung des Leistungsverhaltens von Anfragen im Zusammenhang mit der Datenverteilung. Sie beruht auf der Idee Relationen in kleinere Partitionen zu zerlegen und stellt durch mögliche parallele Auswertungen, Partitionsausschlüsse und Administrationsaspekte Optimierungspotenziale dar. Die Entwicklung der letzten Jahre hat gezeigt, dass die Datenvolumina in Datenbanken gerade beim Data Warehousing sehr leicht hohe Gigabyte- oder Terabytebereiche erreichen können [WA98]. Jedoch stellen große Datenbestände heutige Datenbankmanagementsysteme kaum noch vor Probleme. Diese machen häufig nur Relationen mit mehreren Millionen oder sogar Milliarden Tupeln [Kim96]. Im Bereich des Data Warehousing laufen viele Daten zusammen, die man schließlich auswerten möchte. Man stelle sich nun eine Verkaufstabelle von einem großen Unternehmen vor, z.B. einem Lebensmitteldiscounter, in der alle Verkäufe mit Datum, Produktnummer, Anzahl und Preis gespeichert werden. An einem einzelnen Tag werden tausende von Tupeln neu in die Verkaufstabelle eingefügt. Eine typische WarehouseAnfrage könnte nun lauten: „Wieviel Umsatz habe ich im letzten Quartal gemacht?“ Idealerweise möchte man jetzt nur genau die Tupel zur Auswertung heranziehen, die tatsächlich im letzten Quartal liegen, ohne alle Tupel der Tabelle durchsuchen zu müssen. Ein Full Table Scan sollte vermieden werden. Gerade solche Bereichsanfragen sind typisch für Data Warehousing. Der entscheidende Vorteil der Partitionierung besteht demnach darin, dass aufgrund der Aufteilung einer Tabelle auf mehrere Partitionen Anfragen durch eine Reduzierung des zu durchsuchenden Datenraums potentiell profitieren können [NM00]. Jedoch ist die Partitionierung eine sehr komplexe Aufgabe, die vom zugrunde liegenden Datenbankschema, den typischen Anfragen, dem Datenvolumen, dem verwendeten Datenbankmanagementsystem und der Hardware abhängig ist [Now01]. Es soll in dieser Arbeit vorgestellt werden, welche Optimierungsmöglichkeiten die Partitionierung vor allem für Warehouse-Anfragen bietet. Dazu werden zuerst Grundlagen der Partitionierung in Kapitel 2 vorangestellt, zu denen zum Beispiel die verschiedenen Partitionierungsarten gehören. In Kapitel 3 werden Optimierungspotentiale eingeführt und eines beispielhaft anhand eines Sternschemas erklärt. 2 Grundlagen der Partitionierung Unter Partitionierung einer Tabelle bzw. eines Indexes versteht man grundsätzlich die Aufteilung von Tupeln dieser Tabelle bzw. dieses Indexes. Die Partitionierungsidee beruht -1- auf dem Prinzip „Divide and Conquer“. Dabei versteht man unter einer Tabellenpartitionierung eine horizontale oder vertikale, vollständige und transparente Aufteilung einer Datenbanktabelle in disjunkte Teiltabellen (Partitionen) [Now00b]. Eine allgemeinere Definition findet man in [Bau00]: Eine Partitionierung von Tabellen und Zugriffspfaden ist eine injektive (eindeutige) Abbildung von Tupeln einer Tabelle bzw. eines Zugriffspfades auf eine oder mehrere Partitionen dieser Tabelle bzw. dieses Zugriffspfades anhand werteabhängier oder werteunabhängiger Kriterien, wobei jedes Tupel genau einer Partition zugeordnet wird. Die einzelnen Partitionen werden dann gezielt physischen Speicherbereichen der Datenbank, etwa Table Spaces, zugeordnet. Der grundlegende Unterschied zwischen einer horizontalen und einer vertikalen Aufteilung besteht darin, dass bei einer horizontalen Aufteilung die einzelnen Tupel einer Tabelle nicht zerlegt werden. Diese beiden Partitionierungsformen werden im Folgenden kurz vorgestellt. Zunächst wird die horizontale Partitionierung betrachtet. Bei dieser Partitionierungsform wird eine Relation zeilenweise in disjunkte Teilmengen zerlegt. Die Zuordnung dieser Teilmengen zu den einzelnen Partitionen erfolgt im Allgemeinen durch ein Selektionsprädikat [Bra01] auf Attributen der Ursprungsrelation. Bei einer vertikalen Partitionierung hingegen wird die ursprüngliche Relation in eine oder mehrere Spalten aufgeteilt, wobei diese bis auf den Schlüssel disjunkt partitioniert ist [Rah94]. Dies ist notwendig, damit eine Rekonstruktion zu einem späteren Zeitpunkt verlustfrei durchführbar ist. Dabei bezieht sich die obige Forderung nach Disjunktheit nur auf solche Attribute, die nicht zum Schlüssel gehören. Ein Überblick über diese beiden Partitionierungsformen soll zusätzlich diese Tabelle liefern, die eine Produkttabelle beinhaltet: Produkttabelle: ProduktNr 1001 1002 1003 1004 1005 : 2001 2002 2003 2004 2005 ProduktName Fussball X16 Fussball X17 Basketball Volleyball Tennisball : Nike Shirt T65 Adidas Cap Nr1 PowerBar Riegel Schuh X1 Schuh X6 ProduktGruppe ProduktPreis 2 30,05 2 59,95 1 70,00 1 21,99 1 2,33 : : 3 65,00 7 20,50 15 2,00 11 149,99 11 269,00 ProduktBild 1001.bmp 1002.bmp 1003.bmp 1004.bmp 1005.bmp : 2001.bmp 2002.bmp 2003.bmp 2004.bmp 2005.bmp Tabelle 1: Ausgangstabelle für horizontale und vertikale Partitionierung Diese Tabelle bietet die Möglichkeit an einem einfachen Beispiel die horizontale und die vertikale Partitionierung zu illustrieren. -2- Bei der Durchführung einer horizontalen Partitionierung beispielsweise in zwei einzelne Partitionen dieser Produkttabelle empfiehlt sich als Selektionsprädikat der Primärschlüssel ProduktNr. Daraus würden sich nun folgende Partitionen P1 und P2 ergeben: P1 : ProduktNr 1001 1002 1003 1004 1005 : ProduktName Fussball X16 Fussball X17 Basketball Volleyball Tennisball : ProduktGruppe ProduktPreis 2 30,05 2 59,95 1 70,00 1 21,99 1 2,33 : : ProduktBild 1001.bmp 1002.bmp 1003.bmp 1004.bmp 1005.bmp : ProduktName : Nike Shirt T65 Adidas Cap Nr1 PowerBar Riegel Schuh X1 Schuh X6 : ProduktGruppe ProduktPreis : : 3 65,00 7 20,50 15 2,00 11 149,99 11 269,00 : : ProduktBild : 2001.bmp 2002.bmp 2003.bmp 2004.bmp 2005.bmp : P2 : ProduktNr : 2001 2002 2003 2004 2005 : Tabelle 2: Horizontal partitionierte Ausgangstabelle Die vertikale Partitionierung wird häufig zum Abspalten von LOBs (Very Large Objects) angewandt, wenn keine Pointer verwendet werden. Physisch werden dann die LOBs von den eigentlichen Daten abgetrennt. Dabei verringert sich bei einem Zugriff das zu durchsuchende Datenvolumen, die Anzahl der zu durchsuchenden Tupel bleibt aber gleich [KN99]. Dies soll hier nur durch das Abspalten des Produkt Bildes des jeweiligen Produktes angedeutet werden. P2 : P1 : ProduktNr 1001 1002 1003 1004 1005 : 2001 2002 2003 2004 2005 ProduktName Fussball X16 Fussball X17 Basketball Volleyball Tennisball : Nike Shirt T65 Adidas Cap Nr1 PowerBar Riegel Schuh X1 Schuh X6 ProduktGruppe 2 2 1 1 1 : 3 7 15 11 11 ProduktPreis 30,05 59,95 70,00 21,99 2,33 : 65,00 20,50 2,00 149,99 269,00 ProduktNr 1001 1002 1003 1004 1005 : 2001 2002 2003 2004 2005 Tabelle 3: Vertikal partitionierte Ausgangstabelle -3- ProduktBild 1001.bmp 1002.bmp 1003.bmp 1004.bmp 1005.bmp : 2001.bmp 2002.bmp 2003.bmp 2004.bmp 2005.bmp Durch die Vollständigkeit wird gefordert, dass jedes Tupel der Ausgangstabelle bei der Partitionierung berücksichtigt werden muss und somit in einer Partition liegt. Aufgrund der Disjunktheit wird sichergestellt, dass sich die einzelnen Partitionen nicht überlappen. Deshalb kann ausgeschlossen werden, dass ein Tupel der ursprünglichen Tabelle in mehreren Partitionen liegt. Betrachtet man nun die beiden Forderungen nach Vollständigkeit und Disjunktheit gleichzeitig, kann man ableiten, dass ein Tupel genau einer Partition zugeteilt wird. Aus diesem Grund kann man die Partitionierung als Funktion auffassen, eine sogenannte Partitionierungsfunktion, die jedem Tupel eine Partition zuordnet [NM00]. 2.1 Partitionierungsverfahren Eine Aufteilung der Datensätze in Partitionen ist abhängig von den Datenbankoperationen und dem zu erreichenden Ziel. Man unterscheidet grundlegend zwischen werteabhängiger und werteunabhängiger Partitionierung. 2.1.1 Werteabhängige Partitionierung Der Grundgedanke einer werteabhängigen oder auch wertebasierten Partitionierung beruht darauf, dass die einzelnen Datensätze bzw. Tupel anhand ihrer Attributwerte den verschiedenen Partitionen mittels einer Partitionierungsfunktion zugeordnet werden mit dem Ziel eine möglichst gute Verteilung auf die Partitionen zu erreichen. Man betrachtet nun eine Ausgangstabelle und legt ein oder mehrere Selektionsprädikate (Partitionierungsprädikate) fest. Daraufhin werden die Tupel dieser Ausgangstabelle auf die vorher angelegten Partitionen verteilt. Jedes Tupel wird mit Hilfe einer Partitionierungsfunktion entsprechend eines oder mehreren abhängigen Parameter (Selektionsprädikate) auf die entsprechenden Partitionen verteilt. Da die Verteilung anhand der Selektionsprädikate erfolgt ist, ist nach der Verteilung bekannt, in welche Partition jedes einzelne Tupel eingefügt wurde. Es ist durch das wiederholte Einsetzen in die vorher definierte Partitionierungsfunktion möglich genau zu bestimmen, in welche Partition das gesuchte Tupel eingefügt wurde. Dies hat den Vorteil, dass man nur diejenige Partition durchsuchen muss, in der das Tupel liegt und alle anderen ausschließen kann. Werteabhängige Partitionierungsfunktionen sind zum Beispiel die Range-, Hash-, die Composite- und die List-Partitionierung, die nun kurz vorgestellt werden. Range-Partitionierung Bei einer Bereichs-Partitionierung werden die Wertebereiche in disjunkte Intervalle zerlegt (vgl. horizontale Partitionierung). Die Zuordnung zu den Partitionen erfolgt mittels einer Partitionierungsfunktion, die die Tupel auf die Partitionen verteilt. Diese Art eignet sich besonders für Bereichsabfragen, da sie den direkten Zugriff auf die relevante Partition ermöglicht (s.o. Auftragstabelle). Die Range-Partitionierung ist vor allem dort angebracht, wo auf Grund der Tabellenstruktur und der Spaltenwerte ‚natürliche’ Partitionierungskriterien vorliegen, die optimalerweise darüber hinaus auch annähernd eine Gleichverteilung der Daten garantieren können [Ora02] (Beispiel: Auftragstabelle nach Quartalen partitioniert und durchschnittlich pro Quartal gleichen Auftragseingang). -4- Hash-Partitionierung Hier wird die Verteilung der Tupel auf eine vorher definierte Anzahl von Partitionen mittels einer vom System vorgegebenen Hash-Funktion vorgenommen. Der Hashwert kann dabei aus einem oder mehreren Attributwerten errechnet werden. Im Gegensatz zur Bereichs-Partitionierung orientiert sich die Verteilung nicht an inhaltlichen Kriterien, sondern basiert ausschließlich auf einer mathematischen Hash-Funktion (üblicherweise h(x):= x mod p) [Leh03]. Diese Art ist sehr für Punktanfragen geeignet, da das DBMS wiederholt die Partition berechnen kann, in der das Tupel abgelegt wurde. Composite-Partitionierung Bei dieser Partitionierungsart werden verschiedene Verfahren kombiniert. Es können unterschiedliche Kombinationen wie z.B. Range-Hash oder auch Range-Range erstellt werden. Dabei erfolgt die Partitionierung zunächst anhand des erstgenannten Verfahrens, danach werden Subpartitionen durch das zweite Verfahren gebildet. Die Composite-Partitionierung eignet sich besonders im Data Warehousing Umfeld, da zum Beispiel mit Range-Range Zeithierachien abgebildet werden können [Bra01]. List-Partitionierung Hier wird vom Administrator eine diskrete Werteliste angelegt, anhand dieser die Tupel auf die Partitionen verteilt werden. Dabei können semantisch nicht zusammenhängende Daten einer Partition zugeordnet werden [Ora02]. 2.1.2 Werteunabhängige Partitionierung Bei der werteunabhängigen oder auch nicht wertebasierten Partitionierung erfolgt die Aufteilung der Tupel zu den Partitionen nicht wie bei der werteabhängigen Partitionierung anhand eines Parameters, sondern durch Partitionierungsfunktionen, die die Tupel auf die Partitionen möglichst gleichmäßig verteilen. Ziel dieser Strategie ist es durch die gleichmäßige Verteilung der Tupel Anfragen parallel abarbeiten zu können, indem mehrere Partitionen gleichzeitig durchsucht werden. Werteunabhängige Partitionierungsfunktionen sind zum Beispiel Round-Robin-Partitionierung und die Random-Partitionierung. Random-Partitionierung Die Tupel werden bei diesem Partitionierungsverfahren zufällig auf die Partitionen verteilt. Es wird vom System eine gleichverteilte Zufallszahl generiert, die die zugeordnete Partition bestimmt. Round-Robin-Partitionierung Hier werden die Tupel sequentiell auf mehrere Partitionen, die einer festen Reihenfolge unterliegen, reihum verteilt. Dabei ist wie bei der RandomPartitionierung nicht nachvollziehbar, zu welcher Partition ein Datensatz zugeordnet wurde. 2.2 Tabellenpartitionierung Unter Tabellenpartitionierung wird im Folgenden stets eine transparente, horizontale und vollständige Partitionierung einer Datentabelle in disjunkte Teiltabellen (Partitionen) -5- verstanden. Die einzelnen Partitionen werden dann gezielt physischen Bereichen der Datenbank, etwa Tablespaces, zugeordnet [Now01]. 2.2.1 Eindimensionale Partitionierung Bei einer eindimensionalen Partitionierung wird eine zugrundeliegende Tabelle bezüglich eines einzelnen Attributes (Partitionierungsattribut) partitioniert. Mit Hilfe einer Partitionierungsfunktion fp kann auf diesem Attribut eine Bereichsverteilung spezifiziert werden, die den Wertebereich des ausgewählten Attributs in Partitionen aufteilt. Dabei lässt sich folgende Partitionierungsfunktion angeben: f p : dom( A ) → {Pj | 1 ≤ j ≤ m} Dies wird nun am bewährten Beispiel einer Auftragstabelle illustriert. Diese Tabelle enthält die Attribute Auftragsnummer, Auftragsdatum, Kundennummer und Bestellmenge. f p ( AUFTRAGSDATUM ) = P1 falls 2005 − 01 − 01 ≤ AUFTRAGSDATUM ≤ 2005 − 03 − 31 P2 falls 2005 − 04 − 01 ≤ AUFTRAGSDATUM ≤ 2005 − 06 − 30 P3 falls 2005 − 07 − 01 ≤ AUFTRAGSDATUM ≤ 2005 − 09 − 30 P4 falls 2005 − 10 − 01 ≤ AUFTRAGSDATUM ≤ 2005 − 12 − 31 P5 sonst Als Ergebnis dieser Partitionierung mit dem Partitionierungsattribut Auftragsdatum erhält man insgesamt fünf Partitionen, wobei die Partitionen P1 bis P4 die vier Quartale und P5 die Restpartition repräsentieren. Es ist nun leicht möglich, Anfragen bezüglich eines Quartals gegen diese Partitionen zu stellen. 2.2.2 Mehrdimensionale Partitionierung Man spricht von einer mehrdimensionalen Partitionierung, wenn bei der Partitionierung mehrere Attribute der ursprünglichen Tabelle als Partitionierungsattribute bzw. Partitionierungskriterium mit einbezogen werden, auf die eine Partitionierungsfunktion folgender Art angewandt wird: f p : dom( A1 ) × ... × dom( An ) → {Pj | 1 ≤ j ≤ m} Dabei wird die zugrundeliegende Tabelle vollständig in einen n-dimensionalen Würfel geteilt. Als Beispiel wird aufgrund der Übersichtlichkeit ein zweidimensionaler Fall betrachtet (siehe Abbildung 1). -6- Die Ausgangstabelle besitzt die Partitionierungsattribute A und B mit den Wertebereichen dom(A) = {1, 2, 3, 4, 5, 6} und dom(B) = {1, 2, 3, 4, 5, 6, 7, 8, 9}. B 6 5 P5 P4 4 3 2 B 6 5 P6 4 3 2 A P2 P1 P4 P3 A P1 P2 P3 1 1 1 2 3 4 5 6 7 8 9 1 (a) Variante 1 2 3 4 5 6 7 8 9 (b) Variante 2 Abbildung 1: Möglichkeiten mehrdimensionaler Partitionierung Zuerst wurde die Tabelle intervallweise bezüglich nach dem einzigen Partitionierungsattribut A partitioniert. Dabei wurde die Partitionierung so durchgeführt, dass alle Tupel mit einem AAttributwert größer als drei in einer und alle anderen Tupel mit einem A-Attributwert kleiner oder gleich drei in einer anderen Partition zugeordnet werden. Danach wurde eine bereichsweise Partitionierung bezüglich des Attributes B durchgeführt, wobei der Wertebereich von B hierzu in drei Intervalle {1, 2, 3}, {4, 5, 6} und {7, 8, 9} zerlegt wurde. Es wird angenommen, dass alle Tupel der ursprünglichen Tabelle einer Partition zuzuordnen sind. Deshalb wird auf eine mögliche Restpartition in diesem Beispiel verzichtet. Es wurden bei der Durchführung des zweiten Schrittes zwei Fälle unterschieden. Man beachte im ersten Fall die Abbildung 2.4(a). Es ist deutlich zu erkennen, dass alle Partitionen aus dem ersten Schritt weiter untergliedert worden sind. Nach dem ersten Schritt hat man zwei Partitionen als einzelne zusammengesetzt aus P1, P2, P3 und P4, P5, P6 erhalten. Hätte man zunächst nach dem Attribut B und danach erst nach dem Attribut A partitioniert, wäre man zu dem selbem Ergebnis gekommen [NM00]. Daraus kann abgeleitet werden, dass bei einer sogenannten vollständigen mehrdimensionalen Partitionierung die Reihenfolge der einzelnen Schritte nicht relevant ist. Sie trägt ihre Bezeichnung deshalb, weil im zweiten Schritt alle Partitionen betroffen sind. Diese beschriebene Partitionierung kann durch folgende Partitionierungsfunktion fvollständig dargestellt werden: f vollständig ( A, B) = P1 falls A ≤ 3 und B ≤ 3 P2 falls A ≤ 3 und 3 < B ≤ 6 P3 falls A ≤ 3 und B > 6 P4 falls A > 3 und B ≤ 3 P5 falls A > 3 und 3 < B ≤ 6 P6 falls A > 3 und B > 6 -7- Im zweiten Fall spricht man von einer partiellen mehrdimensionalen Partitionierung, da nicht alle der im ersten Schritt erhaltenen Partitionen weiter partitioniert werden. Es wurde nur diejenige Partition bezüglich B partitioniert, die die Tupel mit einem A-Attributwert kleiner oder gleich drei enthielt. Dieses Resultat würde sich nicht einstellen, wenn man nun zuerst nach dem Attribut B und danach nach dem Attribut A vorgehen würde. Dies stellt einen Unterschied zur vollständigen mehrdimensionalen Partitionierung dar, denn hier ist die Reihenfolge entscheidend. Diese Partitionierung kann durch folgende Partitionierungsfunktion fpartiell dargestellt werden: f partiell ( A, B) = P1 falls A ≤ 3 und B ≤ 3 P2 falls A ≤ 3 und 3 < B ≤ 6 P3 falls A ≤ 3 und B > 6 P4 falls A > 3 Wenn man eindimensionale und mehrdimensionale Partitionierung vergleicht, stellt man fest, dass die mehrdimensionale Partitionierung, von Ausnahmen abgesehen, einen wesentlichen Vorteil besitzt. Durch die Partitionierung bezüglich mehrerer Partitionierungsattribute kann davon eine größere Zahl von Anfragen profitieren. Eine mehrdimensionale Partitionierung spannt aus multidimensionaler Sichtweise einen Datenraum auf, bei dem mit zunehmender Anzahl der Partitionierungsattribute die Besetzung der einzelnen Partitionen stark nachlässt [NM00]. Es ist aus diesem Grund möglich, dass der Aufwand der Verwaltung von Partitionen zu groß ist, ähnlich wie bei einer eindimensionalen Partitionierung, wenn nur spezielle Anfragen, die das Partitionierungsattribut betreffen, profitieren können. 2.3 Zugriffspfadpartitionierung Indexpartitionierung ist die logische Fortführung des Tabellenpartitionierungsgedankens. Die Vorgehensweise zur Partitionierung von Zugriffspfaden weicht allerdings von derjenigen zur Partitionierung von Tabellen ab, da ein Index eine komplexe Struktur ist und nicht ohne weiteres beliebig in kleinere Einheiten zerlegt werden kann. Stattdessen erfolgt der Aufbau kleinerer separater Teilzugriffspfade [Now01]. Es werden bei partitionierten Zugriffspfaden zwei Eigenschaftspaare unterschieden. Die Elemente der Paare können in unterschiedlichen Kombinationen auftreten und entsprechende Indextypen definieren. Die Elemente des ersten Eigenschaftspaars sind lokale und globale Indizes und beziehen sich auf die Kriterien der Partitionierung. Hingegen bezieht sich das zweite Paar auf die Rolle der Indexspalten (prefixed, non-prefixed) [Ora02]. Daraus ergeben sich nun vier unterschiedliche Kombinationen von partitionierten Indizes: • • • Local prefixed Local non-prefixed Global prefixed • Global non-prefixed -8- 2.3.1 Lokale und globale Indizes Wenn ein partitionierter Index das gleiche Partitionierungskriterium wie die ihm zugeordnete Tabelle aufweist (Equipartitionierung), spricht man von einem lokalen Index. Dabei versteht man in diesem Fall unter dem Partitionierungskriterium das Partitionierungsattribut, nachdem sowohl die Tabelle als auch der Index partitioniert sind. Ist dies gegeben, kann man schlussfolgern, dass jeweils eine Indexpartition genau einer Tabellenpartition zuzuordnen ist [Sin02]. Dieses zeigt nachfolgende Abbildung. Indexpartition I Indexpartition II Indexpartition X … Tabellenpartition I Tabellenpartition II Tabellenpartition X Abbildung 2: Lokal partitionierter Index Man spricht hingegen von globalen Indizes, wenn einer Indexpartition nicht nur eine, sondern mehrere Tabellenpartitionen zugeordnet sind. Indexpartition I Indexpartition II Tabellenpartition I Tabellenpartition II … … Abbildung 3: Global partitionierter Index -9- Indexpartition X Tabellenpartition X 2.3.2 Prefixed und Non-Prefixed Indizes Es ist weiterhin eine Unterscheidung der Reihenfolge der gewählten Partitionierungsattribute vorzunehmen. Dabei ist eine Indexpartitionierung prefixed, wenn die Partitionierungsattribute ein linker Präfix des Indexschlüssels sind [Kau01]. Wenn dies nicht gegeben ist, dann spricht man von einem non-prefixed Index. Für weitere Betrachtungen sei auf [Bau00, Kau01] verwiesen. 2.4 Herstellerspezifische Partitionierungsmöglichkeiten Die DBMS-Hersteller bieten in ihren Systemen unterschiedliche Partitionierungsmöglichkeiten an. Es soll im Folgenden anhand ausgewählter Hersteller aufgezeigt werden, welche Unterschiede bestehen. DBS Partitionierungsarten ADABAS (Tool Adabas Vista) Range Informix Dynamic Server (Enterprise and Workgroup Edition 10.00) Oracle 10g Sybase IQ Round Robin, Expression Range, Hash, List, Composite RH, Composite RL Round Robin, Hash, Range Abbildung 4: Vergleich ausgewählter DBMS-Herstelle bezügl. Partitionierungsarten Die unter 2.1.1 noch nicht vorgestellte Expression-Partitionierung bietet dem Administrator die Möglichkeit eigene Verteilungsfunktionen zu erstellen. Durch diese benutzerdefinierte Funktion können zum Beispiel auch eine Hash- oder Range-Partitionierung erzeugt werden. 3 Partitionierung im Data Warehousing Umfeld Ein mögliches Konzept zur Veränderung des logischen Datenbankdesigns in Hinblick auf die Performancecharakteristik eines Data-Warehouse-Systems ist die Partitionierung. Bei der Partitionierung werden umfangreiche Datenbanktabellen in mehrere kleinere Tabellen aufgeteilt. Es können wie in Kapitel 2 schon erwähnt horizontale und vertikale Aufteilungen unterschieden werden. Die meisten Tuning-Szenarien erfordern eine Kombination aus vertikaler und horizontaler Partitionierung. Die Designentscheidungen sollten an die - 10 - Anfragecharakteristik angepasst werden, da sich Partitionierung ansonsten auch negativ auswirken kann. Die meisten derzeitigen Datenbanksysteme übernehmen die Partitionierung auf physischer Ebene, transparent für den Benutzer, der logisch eine zusammenhängende Tabelle sieht [Leh03]. 3.1 Optimierungspotenziale Wie bereits in Kapitel 1 angesprochen bietet die Partitionierungstechnik ein enormes Optimierungspotenzial. Dabei sind folgende Bereiche relevant: • Verwaltung sehr großer Relationen • Überspringen von Partitionen bei der Anfrageauswertung • Ausnutzung paralleler Datenbank- und Systemarchitekturen Auf diese Bereiche wird im Folgenden kurz eingegangen [Leh03]. 3.1.1 Verwaltung sehr großer Relationen Die Partitionierungstechnik erleichtert das Verwalten von sehr großen Relationen. Sie erlaubt ohne Änderungen des eigentlichen Datenbestandes das Hinzufügen und Löschen einzelner Partitionen durch DDL-Anweisungen und Veränderungen im Metadaten-Katalog des Systems. Gerade die Verwaltung eines Data Warehouse erfordert, dass ständig neue Daten hinzugefügt und entfernt werden müssen, soweit es sich um eine rolling data warehouse scenario handelt. Jedoch sind die klassischen Einfüge- und Löschoperationen (z.B. delete) für große Teile einer Datenbasis auf einzelne Tabellen ineffizient. Die Partitionierung erlaubt zum Beispiel mit einer Anweisung (drop partition) das Löschen einer Partition. Dies ist vor allem im Bereich der Archivierung von großem Nutzen. 3.1.2 Überspringen von Partitionen bei der Anfrageauswertung Die Optimierungsmöglichkeit des Überspringens von Partitionen bei der Anfrageauswertung setzt voraus, dass die entsprechende Datenbankanfrage eine Restriktion aufweist, die über ein Partitionierungsattribut definiert ist. Dies hat den Vorteil, dass zur Beantwortung der Anfrage nicht die gesamte Relation, sondern nur die betroffenen Relationen herangezogen werden müssen. Es findet dann ein möglicher Partitionsausschluss statt bzw. spricht man dabei von partition pruning. Ein Beispiel für den Partitionsausschluss wird in Kapitel 3.2.2 gegeben. - 11 - 3.1.3 Ausnutzung paralleler Datenbank- und Systemarchitekturen Das Ausnutzen paralleler Datenbank- und Systemarchitekturen ermöglicht zum Beispiel die Anwendung spezieller Verbundoperatoren (parallel hash joins), um Verbundoperationen mit großen Relationen zu beschleunigen. Voraussetzung dafür ist die Verteilung einzelner Partitionen auf unterschiedliche Festplatten nach Anwendungsgesichtspunkten. Diese sollte auf mögliche Anfragen optimal zugeschnitten sein. Es wird dadurch ermöglicht, dass Anfragen schneller abgearbeitet werden können, indem parallel auf einzelne Partitionen auf unterschiedlichen Festplatten zugegriffen wird. 3.2 Partitionierungsstrategie für ein Data Warehouse Dem Data-Warehouse liegt die multidimensionale Datenmodellierung zugrunde. Die Idee dabei ist die Betrachtung von Kennzahlen in einem multidimensionalen Datenraum. Für die Realisierung werden meist relationale Datenbanksysteme eingesetzt. Dabei werden die multidimensionalen Zusammenhänge mittels eines relationalen Sternschemas umgesetzt. Dies soll nun an einem Beispiel verdeutlicht werden. 3.2.1 Beispiel eines Sternschemas Ein häufig im Zusammenhang mit Data-Warehouse Anwendungen gebrauchter Begriff ist Sternschema oder Star-Schema. Das bedeutet, dass die Daten in einem Data Warehouse nach Fakten und Dimensionen getrennt werden. Die Faktentabellen sind dadurch gekennzeichnet, dass sie ein sehr großes Datenvolumen haben (mehrere Hundertmillionen Datensätze) und über entsprechende Attribute klassifiziert werden. Die Dimensionstabellen beschreiben dann diese Attribute. Während in einem operativen System die Daten in normalisierter Form abgelegt werden, werden diese Informationen in einem Data-Warehouse-Modell gemischt und mit anderen Zusatzinformationen über den Kunden, die verkauften Produkte und die Zeiträume angereichert. Als Beispiel soll hier eine einfache Verkaufstabelle dienen (vgl. [Ora02]), die z.B. für Marketingzwecke genutzt werden könnte. In dem Data-Warehouse-Modell ist die Tabelle Verkäufe die zentrale Information, die alle Informationen enthält und zusätzlich mit Informationen wie Woche und Produktgruppe angereichert worden ist. Um diese zentrale Tabelle Verkäufe gruppieren sich die näheren Informationen zur Produktgruppe, zu Zeitabschnitten und Einzelheiten zu den Kunden. Diese Art des Datendesigns wird Sternschema genannt, weil sich die Dimensionstabellen um eine zentrale Tabelle gruppieren. - 12 - KUNDEN KDNR Nachname Vorname Adresse PLZ Ort Gebiet Vertrieb ZEITEN ZEITNR Tag Monat Jahr Wochentag Kalenderwoche Quartal VERKÄUFE RECHNR KDNR ZEITNR PRODNR Menge Preis PRODUKTE PRODNR ProdName ProdGruppe PreisEK PreisVK Preis Abbildung 5: Beispiel für ein Sternschema 3.2.2 Anfrageverarbeitung gegen partitionierte Tabellen Typische Data Warehouse Anfragen richten sich an dem zugrundeliegenden Sternschema aus. Um nun von der Partitionierung profitieren zu können, muss die Faktentabelle entsprechend der Anfrage partitioniert sein. Als einfaches Beispiel überlege man sich nun folgende Anfrage, mit den Zusatzinformationen ZeitNr > 90 spricht für das zweite Quartal und Kundennummer zwischen 0 und 1000 für Kunden im Bereich Logistik: „Wieviel Umsatz haben die Kunden im Bereich Logistik im 2. Quartal erbracht?“. Man gehe nun vom folgenden Inhalt der Faktentabelle aus. RECHNR 1 1005 5074 5084 5086 5189 KDNR 1021 1000 1000 1021 1000 1000 ZEITNR 85 86 95 95 120 121 PRODNR 1455 1455 1455 2000 1455 2000 Menge 10 13 31 55 54 45 Tabelle 4: Faktentabelle zum Sternschema - 13 - Preis 50 50 50 100 50 100 Man könnte nun Überlegungen anstellen, wie diese Faktentabelle sinnvoll zu partitionieren sei, wobei man natürlich normalerweise von einer Faktentabelle mit einigen Millionen Tupeln ausgehen müsste. Für dieses Beispiel eignet sich unter Beachtung der oben genannten Anfrage eine Partitionierung mit den Attributen Kundennummer und Zeitnummer. Das Vorgehen in diesem sehr kleinen Beispiel ist auf größere Relationen übertragbar, da man sich dabei ebenfalls die möglichen Anfragen im Vorhinein überlegen sollte, um anhand dieser Anfragen mögliche Partitionierungskriterien auszuwählen. Durch die angestellten Überlegungen kommt man nun zu einer möglichen Partitionierungsfunktion: P1 P 2 f p ( KDNR, ZEITNR ) = P3 P4 falls 0 ≤ KDNR ≤ 1000 und ZEITNR ≤ 90 falls 0 ≤ KDNR ≤ 1000 und ZEITNR > 90 falls KDNR > 1000 und ZEITNR ≤ 90 falls KDNR > 1000 und ZEITNR > 90 Dabei werden drei von den sechs Tupeln der Partition 2 und die drei anderen Tupel jeweils einer Partition zugeordnet. Bei dieser Anfrage müsste man unter entsprechender Partitionierung also nur eine einzige Partiton scannen und keinen Full Table Scan durchführen. Es werden Partitionen ausgeschlossen (partition pruning). Diese Aussagen gelten natürlich nur, wenn der Optimizer die Partitionierung nutzt. 4 Zusammenfassung Das Partitioneren von Tabellen und Indizes vereinfacht die Administration, verbessert die Verfügbarkeit der Daten und kann die Performance von Anfragen erhöhen. Dies ist jedoch von einigen Faktoren abhängig. Anfragen gegen partitionierte Tabellen können nur dann von der Partitionierung profitieren, wenn auch in der Anfrage nach einem Partitionierungsattribut gefragt ist. An dieser Stelle muss abgewogen werden, wie viele Partitionierungskriterien miteinbezogen werden. Wenn zudem parallel gesucht werden soll, müssen die Partitionen auf unterschiedlichen Platten liegen. Ebenfalls muss den DBMS-Hersteller Beachtung geschenkt werden, weil sie im Vergleich doch sehr unterschiedliche Arten der Partitionierung anbieten. Im Hinblick auf die Anwendung im Data Warehouse Umfeld spielt vor allem die Bereichsanfrage eine wichtige Rolle. Dadurch, dass die Partitionierung die Möglichkeit bietet, unter Umständen einzelne Partitionen im Vorfeld auszuschließen, kann die Bereichspartitionierung aus Performancegesichtpunkten interessante Möglichkeiten aufweisen, um diese zu steigern. - 14 - 5 Literatur [Bau00] Robert Baumgarten. Zugriffspfadstrukturen für partitionierte Tabellen in Datenbanksystemen. Diplomarbeit, Friedrich-Schiller-Universität Jena, Institut für Informatik, April 2000. [Bra01] S. Brandt. Klassifikation von Partitionierungsstrategien in relationalen Datenbanksystemen. Diplomarbeit, Institut für Informatik, Friedrich-SchillerUniversität Jena, Mai 2001. [DG92] D. J. DeWitt und J. Gray. Parallel Database Systems: The Future of High Performance Database Systems. Communications of the ACM, 35(6):85-98, Juni 1992. [Kim96] R. Kimball. The Data Warehouse Toolkit. John Wiley & Sons, New York, 1996. [KN99] K. Küspert, J. Nowitzky. Partitionierung von Datenbanktabellen (Aktuelles Schlagwort). Informatik Spektrum, 22(2): S.146-147, April 1999 [Leh03] W. Lehner: Datenbanktechnologie für Data-Warehouse-Systeme. Konzepte und Methoden. Heidelberg: dpunkt.verlag. 2002. [Now00b] J. Nowitzky. Tabellenpartitionierung für die Archivierung im SAP System R/3. Jenaer Schriften zur Mathematik und Informatik Math/Inf/00/06, Institut für Informatik, Friedrich-Schiller-Universität Jena, März 2000. [Now01] J. Nowitzky. Analytische Bestimmung einer Tabellenpartitionierung für ein Data Warehouse. Jenaer Schriften zur Mathematik und Informatik Math/Inf/01/17, Institut für Informatik, Friedrich-Schiller-Universität Jena, August 2001. [NM00] J. Nowitzky und T. Müller. Entwurf und Bewertung von Partitionierungsstrategien für Datenbankschemata. Jenaer Schriften zur Mathematik und Informatik Math/Inf/00/29, Institut für Informatik, Friedrich-SchillerUniversität Jena, Oktober 2000. [Ora02] Oracle 9i für den DBA. München: Addison-Wesley 2002 [ÖV99] M. T. Özsu und P. Valduriez. Principles of Distributed Database Systems. Prentice-Hall, Inc., 2.Auflage, 1999 - 15 - [Rah94] Erhard Rahm. Mehrrechner-Datenbanksysteme – Grundlagen der verteilten und parallelen Datenbankverarbeitung. München: Addison-Wesley, 1994 [WA98] R. Winter, K. Auerbach. The big time. Database Programming & Design, 11 (8):S.36-45, August 1998 - 16 -