Dieses setzt jedoch neben Wissen über den fachlichen Inhalt der Daten auch tiefes Technologieund Datenbankwissen voraus. Deshalb wollen wir am Beispiel von DB2 für LUW (Linux, Unix, Windows) Möglichkeiten vorstellen, um das Datenwachstum aus Datenbanksicht beherrschbar zu machen. Viele der hier aufgezeigten Konzepte sind jedoch allgemeingültig und lassen sich auch mit anderen aktuellen Datenbankprodukten realisieren.

Probleme großer Datenmengen

Die Speicherung extrem großer Datenmengen in der relationalen Tabelle bereitet Probleme in der Verarbeitung und in der Administration. In der Verarbeitung ist das Auffinden gesuchter Zeilen sehr aufwendig. Indizes über einen solchen Datenbestand sind nur beschränkt hilfreich, da auch sie eine Größe erreichen, die nicht mehr leicht handhabbar ist. Daher sind für die Abfragen Techniken zu finden, die parallele Zugriffe auf die Daten ermöglichen. In der Administration kosten die Reorganisation, die Sicherung oder die Wiederherstellung solcher Datenmengen trotz stetig leistungs-fähigerer Hardware einfach zu viel Zeit, um die heutzutage gewünschte Verfügbarkeit erfüllen zu können. Ein erster Lösungsansatz ist die Kompri-mierung der gespeicherten Daten, um die zu verarbeitenden Einheiten kleiner zu halten. Komprimierte Daten belegen weniger Speicherplatz und erfordern weniger I/Os. Ein Nachteil der Kompression ist die zusätzliche, allerdings geringfügige Belastung der CPUs durch die Komprimierungs-/Dekomprimie-rungsoperationen. Ein Lösungsansatz ist die Aufteilung solcher Tabellen in Partitionen. Die Partitionierung muss so erfolgen, dass sie für den Benutzer transparent ist. Üblicherweise wird von den meisten RDBMS die horizontale Partitionierung unterstützt, bei der die Tabellen zeilenweise über die Partitionen verteilt werden. Die Partitionen können übermehrere Server verteilt werden oder nur über mehrere Dateien und Plattenlaufwerke innerhalb eines Server. Die „Teil-Tabellen“ können parallel durchsucht werden, was den Abfrage-vorgang beschleunigt, und als eigenständige Einheiten gesichert, wiederher-gestellt oder reorganisiert werden, was die Administration wesentlich erleichtert. Ein weiterer Lösungsansatz ist die physische Beieinander-Speicherung von Daten, die häufig zusammen ausgewertet werden. Diese Technik ist auch unter dem Begriff Clustering bekannt. Sie bietet Vorteile beim Zugriff auf die Daten, weil sie Lese-Operationen durch die Beieinander-Speicherung spart. Im Folgenden stellen wir Ihnen diese Lösungsansätze am Beispiel von DB2 näher vor.

DB2-Datenorganisation

EinDB2-Server kann eine odermehrere Datenbanken betreiben. In der Enterprise Server Edition (ESE) von DB2 können die Daten einer Datenbank über mehrere Server oder Knoten verteilt werden. Physikalisch unterteilt sich die Datenbank in Tablespaces und Container, die als Dateien, Directories oder Raw Devices auf das jeweilige Betriebssystem abgebildet werden. Logisch unterteilt sich eine Datenbank in Tabellen und Indizes. Dazu kommen noch prozedurale Objekte wie Trigger, Funktionen oder Prozeduren. Für die Speicherung und die Verwaltung der Daten bietet DB2 verschiedene Einheiten. Diese lassen sich auf verschiedenen Ebenen einsetzen. Die oberste Einheit sind der Knoten und die Instanz. Darunter befindet sich eine Datenbank, die wiederumausmehreren Tabellen besteht, die indiziert sein können. Neben dieser, dem Entwickler vertrauten Sicht, gibt es die Ebene der physikalischen Speicherung mit Tabellenbereichen und Partitionen (Werte-, Speicherbereich). DB2 speichert seine Daten in Tabellenbereichen. Die Anzahl der Tabellen-bereiche wird durch das jeweilige Betriebssystembegrenzt. Ein Tabellenbereich kann vom Betriebssystem (SMS) oder von der Datenbank (DMS) verwaltet werden. Inzwischen kann der dafür benötige Platz vom System automatisch allokiert und freigegeben werden. Eine weitere Option, die die DB2-Datenbank dynamisch an gesteigerte Lastanforderungen anpasst ist das Workload Management (WLM). Dieses erlaubt es, die DB2-Ressourcen besser und detaillierter den Anwendungen zuzuteilen.

Datenkompression

Für DB2 for z/OS ist Datenkompression eine bewährte Funktion, die bei klassischen kaufmännisch-administrativen Anwendungen Kompressionsraten von 50-80 Prozent erzielt. Mit Version 9 ist die Datenkompression auch inDB2 for LUW verfügbar. Diese Funktion ist ein gutes Mittel, um sowohl den Plattenplatz als auch das IO-Verhalten intelligent zu verbessern. Die Bitmuster-Kompression mit dem Lempel-Ziv-Algorithmus benötigt ein Dictionary zur Umsetzung. Dieses Dictionary gilt für die gesamte Tabelle und wird im gespeicherten Objekt abgelegt. Die Vorteile der Kompression liegen in der Einsparung von belegtem Speicher, in weniger E/A, in mehr gelesener Zeilen je physischen Zugriff und geringerer Bufferpool-Belegung bei verbesserter Hit-Ratio. Der mit der Datenkompression verbundene Nachteil ist die zusätzliche CPU-Belastung für die Komprimierung und Dekomprimierung. Mit einer Reorganisation wird die Kompression durchgeführt. Derzeit kann nur das Dienstprogramm REORG das Dictionary aufbauen. Um zu entscheiden, wann sich die Kompression lohnt, kann man sich mit dem INSPECT-Kommando die Kompressionsrate und den reduzierten Platzbedarf anzeigen lassen. Generell lohnt sich die Kompression für große Tabellen, die keine LOB’s enthalten. Bei Tabellen, die über das LOAD-Kommando befüllt werden, lohnt es sich, die Tabelle zunächst mit einer kleinen repräsentativen Stichprobe zu füllen. Damit kann durch das REORG-Kommando das initiale Dictionary aufgebaut werden. Dieses kann dann bereits beim Laden verwendet werden, sodass eine spätere Reorganisation schneller passiert. Selbst der Aufbau des Data-Dictionary geht in der aktuellen Version automatisch, wenn ein dafür definierter Schwellwert erstmalig überschritten wird. Da neue Datenbanken mit Unicode-Unterstützung angelegt werden, sollte bei der Datenbankplanung überlegt werden, ob dies benötigt wird, da dadurch mehr Platz belegt wird. Diese wird für die Verwendung des XML-Datentypes zwar nicht mehr benötigt, jedoch für die Verwendung von SAP.

Datenverteilungstechniken

Bei der Verteilung von Daten stehen immer die Ziele verbesserte Zugriffleis-tung und höhere Verfügbarkeit im Vordergrund. Für die Verteilung von Daten sind zweiArten denkbar: die logische und die physische Partitionierung. Deren Kombinationsmöglichkeiten bezüglich logischer und physischer Verteilung sind in Bild 1 dargestellt. Zunächst gehen wir auf die Datenbankpartionierung (DPF) – die Tabellenoder Bereichspartitionierung (TP) ein. Abschließend wer-den wir deren Kombination mit der multidimensionalen Partitionierung (MDC) vorstellen, wie sie in BI-Anwendungen eingesetzt wird.

Datenbankpartitionierung (DPF)

Bisher kannte DB2 nur die Partitionierung auf Datenbank-Ebene über mehrere Rechnerknoten hinweg. Im Regelfall besitzt jeder Knoten dabei eine DB2-Instanz und einen Teil der Datenbank, auf den nur er zugreifen kann: SMP (Shared-nothing-Prinzip) oder MPP (Massenparallelrechner). Allerdings kann man auch mehrere Partitions auf einem SMP-Server einsetzen (shared everything). Mit DPF wird eine Tabelle über mehrere Knoten entsprechend dem spezifizierten Schlüssel verteilt. Bei einer Abfrage auf diese Tabelle wird diese so auf jede Partition aufgeteilt, dass jeder Knoten in den ihn zugeteilten Zeilen der Tabelle sucht. Damit wird eine parallelisierte Abarbeitung der Abfrage erzielt. Somit ist DPF im Prinzip eine Skalierbarkeitsfunktion. Bei wachsendem Datenvolumen kann die Abfrageleistung durch Hinzufügen zusätzlicher Knoten gesteigert und das Antwortzeitverhalten stabil gehalten werden. Wichtig für die optimale Nutzung von DPF ist die richtige Auswahl des Verteilungsschlüssels. Er sollte eine gleichmäßige Verteilung auf die Knoten gewährleisten. Der Schlüssel sollte eine hohe Kardinalität seiner Werte aufweisen.

Tabellenpartitionierung (TP)

Die DB2 Enterprise Server Edition ermöglicht die Partitionierung von Tabellen an einem Rechnerknoten (Range Partitioning). Diese Technik ist schon seit Langem in DB2 for z/OS, Oracle oder INFORMIX bekannt. Die Funktionalität in DB2 for LUW ist aber nicht identisch mit den Möglichkeiten in DB2 for z/OS und betrifft nur Tabellen, keine Indizes. Die Tabellenpartitionierung ist eine Form der Datenorganisation, mit der die Tabellendaten auf mehrere Speicher-objekte - Tabellenbereiche, Container oder Extents - entsprechend den Werten einer odermehrerer Spalten der Tabelle verteilt werden. Die Möglichkeit, Tabellendaten über mehrere Speicherobjekte zu partitionieren, führt zu einer besseren Skalierbarkeit, zu einem vereinfachten Handling großer Daten-mengen und zu besserer Leistung (Query Parallelisierung). Außerdem können Tabellen dadurch erheblich vergrößert werden. Im Zusammenhang mit Tabellenpartitionierung gibt es auch für Indizes Fortschritte: Bei nicht partitionierten Tabellen werden alle Indizes in demselben Speicherobjekt angelegt, das bei DMS (Data Managed Storage) in einem anderen Tabellenbereich liegen kann. Für partitionierte Tabellen wird jeder Index in einem eigenen Speicherobjekt angelegt. Jeder Index kann somit in einen anderen Tabellenbereich gelegt werden. Die Vorteile davon sind effizienterer konkurrierender Zugriff und verbesserte Operationen wie CREATE, DROP oder Reorganisation. Ein weiterer Vorteil, die Tabellenpartitionen in unterschied-lichen Tabellenbereichen zu legen, liegt darin, Partitionen so einzeln sichern oder wiederherstellen zu können. Dadurch können zeitintensive Wartungsauf-gaben flexibler in kleineren Operationen und kleineren Zeitfenstern ausgeführt werden. Performance-Vorteile resultieren aus der Parallelverarbeitung von Partitionen in Abfragen oder dem Ausschluss von Partitionen beim Table-Scan. Ein besonders interessanter Aspekt der Partitionierung ist die Möglichkeit, Partitionen rollieren zu lassen. Das ist besonders nützlich in einer DataWare-house-Umgebung, in der häufig Daten geladen oder gelöscht werden. Werden die Daten von 2005 nicht mehr in der Tabelle VAUFTRAG benötigt, so können sie per DETACH abgehängt werden. Die Partition bildet dann eine eigen-ständige Tabelle, die anschließend archiviert werden kann. Die betroffenen Indizes werden im Hintergrund asynchron angepasst. Analog ist es möglich, eine Tabelle mit kompatibler Struktur per ATTACH als neue Partition zu integrieren. Hierbei muss der Befehl SET INTEGRITY nach dem ATTACH ausgeführt werden, um die Operation zu vollenden. SET INTEGRITY prüft neben der Einhaltung des Partitionsbereiches auch sonstige Bedingungen und pflegt die Indizes. Tabellenpartitionierung kann mit den bisher bekannten Möglichkeiten der Datenanordnung wie Datenbank-Partitionierung (DPF- DISTRIBUTE BY HASH) oder multidimensionales Clustering (MDC) kombiniert werden. Dadurch können Datenbereiche gleichmäßig über Datenpartitionen verteilt werden, um DPF-Features wie abfrageinterne Parallelität oder die Lastverteilung für Datenbankpartitionen zu nutzen, um eine optimale Ver-teilung der Last und eine gute Performance zu erreichen. Zusammen mit dem mehrdimensionalen Clustering (MDC-ORGANIZE BY DIMENSIONS) ermöglicht die Tabellenpartitionierung Zeilen mit ähnlichen Werten für mehrere Dimensionen im selben Tabellenspeicherbereich zu gruppieren.

Multidimensional Clustering (MDC)

Mit Hilfe von Block-Indizes werden Zeilen einer Tabelle mit gleichen Daten-werten über mehrere Dimensionen nah beieinander gespeichert. Die Pages werden in Blöcken gleicher Größe organisiert. Alle Zeilen eines Blocks bein-halten dieselbe Kombination von Dimensionswerten. Auch beim Einsatz von MDC ist die richtige Wahl der Spalten für die Dimensionen ein entscheidender Faktor. Es gilt, die richtige Balance zwischen minimalen Speicheranforderungen und optimaler Gruppierung zu finden. Dazu müssen die wesentlichen Abfragen mit ihren Prädikaten beim Tabellenentwurf bekannt sein. Durch die Bereit-stellung von Blöcken für dieselbe Kombination von Dimensionswerten bleibt bei Neuzugängen die Cluster-Reihenfolge auch ohne Reorganisation erhalten. Blockindizes benötigen weniger RIDs, sodass die Indizes kompakter sind.

Ausblick und Fazit

Ähnlich wie in der Medizin ist Vorsorge besser als Nachsorge, damit einer recht-zeitigen und umfassenden Planung manche späteren „Schmerzen“ und Eng-pässe vermieden werden können. Dem physikalischen Entwurf von Datenban-ken muss bei großen Datenmengen eine hohe Aufmerksamkeit gewidmet wer-den. Profundes Verständnis der Speichertechniken in Datenbankmanagement-systemen und ihre Abbildung auf moderne Storage Systeme sind eine absolute Voraussetzung für die Erzielung guter Performance. Die präventive Ver-meidung von Redundanzen und der gezielte Einsatz der Datenkompression helfen das Datenwachstum ein wenig einzudämmen. Die Partitionierung und die automatische Speicherbereichsverwaltung vereinfachen die Administration und machen diese flexibler und effizienter.  Durch die verschiedenen Funkti-onen der aktuellen DB2 Versionen 9.5 wird nicht nur die Verwaltung sondern auch der Zugriff auf große Datenmengen effizienter und schneller. Außerdem können durch ihren gezielten Einsatz Folgekosten eingespart werden. Dadurch kann ein flexibles und effizientes Informations-Management realisiert werden, wie es für Serviceorientierte Architektur im Petabyte- Zeitalter benötigt wird. Insgesamt kann die Verwendung der hier aufgezeigten Maßnahmen dazu führen, dass der Umgang mit Ressourcen effizienter und der Datenbankbetrieb entspannter stattfinden kann. Das sind sicher gute Gründe für die Unter-nehmen und die betroffenen Administratoren sich näher mit diesen Konzepten zu beschäftigen.

FRANK PIENTKA, HEINZ AXEL PÜRNER

Diesen Artikel finden Sie auch in der Ausgabe Juni 2008 des it management.