Partitionierungsoptionen in DB2

Die DB2 Datenbank auf den Plattformen Linux, Unix und Windows bietet eine Reihe von Möglichkeiten, die Inhalte von Tabellen zu partitionieren. Ab der Version 9 werden drei Konzepte unterstützt. Diese werden in diesem Artikel eingehend beschrieben.

CREATE TABLE VERKAUEFE (DATUM DATE, ARTIKELNR CHAR(8), BUNDESLAND VARCHAR(20),...) DISTRIBUTE BY HASH (ARTIKELNR); Abb. 1: Befehl Create Table beim Hash Partitioning. Abb. 2: Prinzip der Verteilung per Hash-Algorithmus. Vergrößern Abb. 3: Ausführung einer Query mit DPF. Vergrößern CREATE TABLE VERKAUEFE (DATUM DATE, ARTIKELNR CHAR(8), BUNDESLAND VARCHAR(20),...) ORGANIZE BY DIMENSIONS (BUNDESLAND); Abb. 4: Befehl Create Table bei MDC-Tabellen. Abb. 5: Ausführung einer Query mit MDC. Vergrößern CREATE TABLE VERKAUEFE (DATUM DATE, ARTIKELNR CHAR(8), BUNDESLAND VARCHAR(20),...) PARTITION BY RANGE (DATUM) (PART rest STARTING minvalue, PARTITION q1 STARTING '01.01.2009', PARTITION q2 STARTING '01.04.2009', ... ENDING '31.12.2009'); Abb. 6: Befehl Create Table beim Table Partitioning. Abb. 7: Ausführung einer Query mit Table Partitioning. ALTER TABLE VERKAUEFE DETACH PARTITION q1 INTO quartal01; Abb. 8: Entfernen einer Partition in eine separate Tabelle.

Überblick

Bereits Mitte der 90er Jahre begann IBM, mit der DB2 Parallel Edition auf dem Betriebssystem AIX eine Datenbank zur Verfügung zu stellen, mit der eine Partitionierung nach einem Hash-Verfahren möglich war. Mittlerweile gibt es neben dem etablierten Hash Partitioning seit der Version 8 das so genannte „Multidimensionale Clustering“ sowie ab der Version 9 die Möglichkeit, Table Partitioning zu nutzen.

Hash Partitioning

Mit dem Database Partitioning Feature (DPF), welches als Zusatzoption zur DB2 Enterprise Edition erhältlich ist, gibt es die Möglichkeit, über mehrere Partitionen nach einem Hash-Verfahren Daten zu verteilen. Das Verfahren benutzt die Shared Nothing Architektur, d. h. jede einzelne Partition hat ihre eigenen Prozesse, Hauptspeicher- und Plattenplatzbereiche. Wegen der sich daraus ergebenden guten Skalierbarkeit kommt diese Partitionierungsvariante insbesondere in großen OLAPSystemen oft zum Einsatz.

Bereits nach dem Erstellen der Instanz müssen im File db2nodes.cfg die Partitionen definiert werden und später auch beim Anlegen von Tablespaces, Bufferpools und Einstellen von Parametern berücksichtigt werden. Details hierzu sind in den Handbüchern unter [1] und [2] zu finden. Die Anzahl der Partitionen, die in einem System verwendet wird, richtet sich in erster Linie nach der Anzahl der CPUs in dem System, dem Datenvolumen und nach dem Workload in der Datenbank.

Im Befehl CREATE TABLE werden beim Erstellen einer Tabelle eine oder auch mehrere Spalten definiert, die als Partitioning-Key fungieren (siehe Abbildung 1). Nach diesem Schlüssel werden die Daten später beim Befüllen der Tabelle verteilt. Üblicherweise wird als Schlüssel eine Spalte, wie z. B. die Kunden- oder die Artikelnummer gewählt, die eine möglichst große Verteilung hat.

Der Vorteil dieses Konzepts ist, dass die Daten relativ gleichmäßig auf allen Partitionen verteilt werden und bei Lese- und Schreibvorgängen die Prozesse parallel auf allen Partitionen laufen. Für das gleichmäßige Verteilen sorgt die so genannte Partitioning Map, die jedem generierten Hash-Wert (eine Zahl zwischen 0 und 4095) eine Partition zuweist (siehe Abbildung 2).

Beim Ausführen von Abfragen startet ein Coordinator-Prozess einzelne Worker-Prozesse auf den Partitionen, die die entsprechenden Teilabfragen auf ihrer Partition durchführen (siehe Abbildung 3). Durch diese Parallelisierung ist eine enorme Performance-Steigerung gegenüber einem nicht-partitionierten System zu erzielen.

Multidimensionales Clustering

Im Gegensatz dazu steht das multidimensionale Clustering (MDC). Bei diesem Konzept werden beim Erstellen einer Tabelle eine oder mehrere Spalten definiert, nach denen die Daten „dimensioniert“ werden (siehe Abbildung 4). Dies bedeutet, dass beim Schreiben in eine solche Tabelle die Daten, abhängig von ihrer Dimension, in verschiedene Extents geschrieben werden, also in physikalisch unterschiedliche Bereiche auf der Platte.

Der Vorteil ergibt sich beim Selektieren von Daten. Wurde, wie in unserem Beispiel, in einer Tabelle die Spalte „Bundesland“ als Dimension gewählt und in der Where-Bedingung einer Select-Anweisung auf ein Bundesland eingeschränkt, so muss DB2 lediglich die Extents lesen und weiterverarbeiten, die dem Bundesland zugeordnet sind (siehe Abbildung 5). Der Performance-Vorteil ergibt sich aus der Einsparung von Lesezugriffen auf die Platte.

Table Partitioning

Table Partitioning, in anderen Datenbankmanagementsystemen oftmals als Range Partitioning bekannt, ist seit DB2 Version 9 verfügbar. Hier müssen beim Erstellen einer Tabelle eine oder mehrere Spalten definiert werden, nach denen partitioniert wird. In der Definition ist ebenfalls der Wertebereich anzugeben, der den einzelnen Partitionen zugeordnet wird (siehe Abbildung 6). Typischerweise sind dies oftmals Zeitfelder wie z. B. das Jahr, Quartal, etc. Ähnlich wie beim multidimensionalen Clustering besteht der Vorteil darin, dass beim Lesen von Daten nur die entsprechenden Tabellenbereiche gelesen und verarbeitet werden müssen (siehe Abbildung 7).

Ein weiterer wesentlicher Vorteil ist jedoch, dass bequem und performant Partitionen entfernt (roll-out) bzw. hinzugefügt (roll-in) werden können. Statt dem Befehl DELETE zum Löschen von Daten, welcher zeitintensiv sein kann und ggf. auch viele Transaktionslogs benötigt, wird die Option DETACH im Kommando Alter Table benutzt (siehe Abbildung 8). Dies funktioniert aber selbstverständlich nur, wenn Daten einer kompletten Partition gelöscht werden sollen. Umgekehrt kann mit der Option ATTACH im Kommando Alter Table auch schnell eine neue Partition hinzugefügt werden.

Fazit

Mit den drei Partitionierungsoptionen bietet die DB2 Datenbank mittlerweile für viele Anwendungsbereiche eine attraktive Option, Daten zu partitionieren. Insbesondere in großen OLAP-Umgebungen kann eine Option oder eine Kombination dieser Optionen eine Möglichkeit sein, den Zugriff auf die Daten zu beschleunigen.

Michael Spoden (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen