Data Warehousing Partitionierung - Fakultät für Mathematik und

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 -