Partitionierung von Datenbanktabellen

Neue Anwendungen, z.B. Data Warehousing, und der zunehmend weit verbreitete Einsatz integrierter betrieblicher Informationssysteme, wie etwa des SAP Systems R/3, führten zu Datenbanken im hohen Gigabyte- oder gar im Terabyte-Bereich. Das Datenvolumen selbst stellt Datenbanken kaum noch vor Probleme. Problematisch hingegen sind oftmals sehr große Tabellen mit Millionen Einträgen pro Tabelle; in der Praxis existieren bereits Datenbanken, wo eine einzelne Tabelle Milliarden Zeilen enthält. Die Datenmanipulation im OLTP-Betrieb (Online Transaction Processing), aber auch eine klassische Datensicherung (Offline-Backup) oder die Reorganisation derartig großer Tabellen begrenzen zum einen die Leistung des gesamten Systems, zum anderen kann dadurch die Verfügbarkeit der Daten wesentlich eingeschränkt werden.

Es gibt verschiedene Ansätze, mit diesen Problemszenarien umzugehen: Eine mögliche Herangehensweise ist der Einsatz verbesserter Techniken u.a. zur Datensicherung und Reorganisation, etwa ein Online-Backup oder eine Online-Reorganisation, wie von verschiedenen DBMS-Produkten bereits angeboten. Dies löst teilweise die Probleme bezüglich der Verfügbarkeit auf Datenbankebene, nicht jedoch Verfügbarkeitsprobleme und Leistungsengpässe aufgrund sehr großer Datenmengen innerhalb einer Tabelle. Deren Anwachsen kann nicht durch Löschen von Daten begrenzt werden, wenn diese aus betriebswirtschaftlichen oder rechtlichen Gründen erhaltenswert oder gar aufbewahrungspflichtig sind. Hier bietet sich das Auslagern von Daten in ein separates Archiv an, das sich auf preisgünstigeren Tertiärspeichermedien befinden kann. Archivierte Daten entlasten somit die Datenbank, sind aber weiterhin auswertbar und können bei Bedarf auch in die Datenbank zurückgeladen werden. Archivierung allein löst allerdings auch nicht alle Probleme. Zum einen sind die archivierten Daten nicht mehr im gewünschten schnellen und direkten Zugriff, was sich nicht nur im Bereich Data Warehousing nachteilig auswirkt. Zum anderen bieten heutige DBMS noch keine integrierte Archivierungsfunktionalität an, was zu "aufgesetzten" Archivierungslösungen (wie in SAP R/3) mit möglichen Leistungseinschränkungen führt oder Integritätsprobleme nach sich ziehen kann.

Eine Alternative zum Erreichen von Leistungs- und Verfügbarkeitsanforderungen für sehr große Datenbanktabellen bieten deshalb Techniken zur Partitionierung bzw. Verteilung dieser Tabellen. Ursprünglich wurden Datenbankdateien partitioniert, wenn sie für eine Festplatte zu groß waren oder die Zugriffsgeschwindigkeit einer einzelnen Platte zu gering war. Das Konzept der Partitionierung wurde in wissenschaftlichen Arbeiten zu verteilten und parallelen Datenbanken auf Datenbanktabellen übertragen und weitergeführt. In verteilten Datenbanken geht es darum, einen großen Datenbestand geographisch zu verteilen und Rechnerknoten so zuzuordnen, daß einerseits knotenübergreifend problemlos Anfragen gestellt werden können (Verteilungstransparenz), andererseits aber aus Leistungsgründen die Daten möglichst dort verfügbar gehalten werden, wo sie vorwiegend gebraucht werden. In parallelen Datenbanken werden Daten vor dem Hintergrund paralleler Datenbankoperationen partitioniert. Die Konzepte zur Verteilung der Daten basieren auf einer Aufteilung der Tabellen, die je nach "Schnittrichtung" durch die Tabelle horizontal bzw. vertikal und entweder wertebasiert (range/hash partitioning) oder zufällig (round robin) erfolgen kann.

In jüngeren Jahren hat die Partitionierung von Datenbanktabellen auch Eingang in zentralisierte Datenbanken gefunden, zunächst vorwiegend in Gestalt vertikaler Partitionierung, um große Objekte (Large Objects, LOBs) abzuspalten und somit physisch von den "eigentlichen" Daten abzutrennen. Damit kann bei einem sequentiellen Zugriff auf die eigentlichen Daten das zu durchsuchende Datenvolumen eingeschränkt werden, jedoch nicht die Anzahl der zu durchsuchenden Datensätze. Mittlerweile wird daher auch die horizontale Partitionierung - wertebasiert oder zufällig - verstärkt in relationale DBMS integriert. Dabei stellen Partitionen eine zusätzliche Zugriffsschicht zwischen Tabellen und Table Spaces dar.

Der Ansatz kann wie folgt beschrieben werden: Eine (typischerweise sehr große) Datenbanktabelle wird mittels eines Partitionierungsschemas horizontal unterteilt, die entstehenden einzelnen Partitionen können zielgerichtet den physischen Bereichen der Datenbank, den Table Spaces, zugeordnet werden. Der Partitionierungsgedanke kann dabei auf Zugriffspfade (Indexe) übertragen werden. Verschiedene Tabellen können bei Bedarf nach gleichem Kriterium partitioniert werden (beispielsweise eine Abteilungstabelle und eine Mitarbeitertabelle jeweils nach gleichen Abteilungsnummerintervallen). Die so entstandene logische Beziehung zwischen den Partitionen der beiden Tabellen kann sich in einer Zuordnung zum gleichen Table Space widerspiegeln (Clustering). Die Partitionierung erfolgt in den bekannten DBMS-Produkten generell vollständig und disjunkt, um Datenverluste und Redundanz zu vermeiden. Beispiele für DBMSe, die eine Partitionierung unterstützen, sind DB2, Oracle, Informix und Adabas. Die Realisierungsformen und Möglichkeiten in diesen Systemen unterscheiden sich teilweise erheblich voneinander.

Insgesamt erhofft man sich von einer Partitionierung eine ganze Reihe potentieller Vorteile hinsichtlich der Leistungsfähigkeit und der Administration sehr großer Tabellen, aber auch bei der Unterstützung spezieller Anwendungen, wie beispielsweise Data Warehousing oder Archivierung. Eine partitionierte Tabelle stellt sich nicht mehr als ein großer Monolith dar, das DBMS kann durch Parallelisierung Such- und Änderungsoperationen auf einem großen Datenbestand potentiell effizienter ausführen. Durch effizientere Ausführungsstrategien können viele Anfragen auf einige wenige Partitionen der Tabelle eingeschränkt werden. Für dieses Eingrenzen ist die Optimierungskomponente des DBMS verantwortlich; es soll selbstverständlich nicht Aufgabe des Anwenders sein, hier"von Hand" zu optimieren. Die Anfrageausführung kann darüber hinaus von der Tabellenpartitionierung profitieren, wenn die globalen Tabellenindexe durch kleinere lokale Partitionsindexe ersetzt oder ergänzt werden. Aus Sicht des Administrators können bei entsprechendem physischen Design administrative Aufgaben (Backup/Recovery, Reorganisation u.a.) wesentlich feingranularer, nämlich auf Partitionsebene, ausgeführt werden. Die Datenbanktabelle wird dadurch nicht als ganzes für längere Zeit blockiert, sondern nur die einzelne, aktuell angesprochene Partition für einen vergleichsweise kurzen Zeitraum. Weiterhin ist es möglich, Partitionen einer Tabelle verschiedenen Speichermedien (unterschiedliche Leistungscharakteristika, Preis-Leistungs-Verhältnis) zuzuordnen. Dies kann u.U. als Alternative zum expliziten Archivieren von Daten dienen, wobei auf Tertiärspeicher liegende Partitionen mit einem Archiv vergleichbar sind.

Partitionierung erhöht natürlich auch die Komplexität der Datenbankadministration. Die Partitionierung als strukturelle Erweiterung erfordert die Erstellung und Pflege eines Partitionierungsschemas, welches sowohl die logische als auch die physische Ebene umfaßt. Daneben müssen Verwaltungs- und statistische Informationen auf Partitionsebene bereitgestellt werden, um durch geeignete Administrationstechniken, Zugriffsstrukturen und interne Optimierungsverfahren die gewünschten Vorteile zu erzielen. Außerdem ist für Prädikate in Datenbankanfragen intern die Partitionierung zu berücksichtigen. Aus Sicht des praktischen Einsatzes weisen existierende DBMS noch manche Defizite in bezug auf die Partitionierungskonzepte auf, wie Untersuchungen gezeigt haben. So ist u.a. das Kriterium der Datenunabhängigkeit nicht immer voll erfüllt, und der Anwender wird teils in seinen Definitions- und Änderungsmöglichkeiten eingeschränkt. Auch bei der Anfrageoptimierung wird die Tabellenpartitionierung oft noch nicht hinreichend berücksichtigt. Derartige Einschränkungen und Defizite sollten sich im Laufe der technologischen Weiterentwicklung der Produkte reduzieren, wie beispielsweise ein Vergleich zwischen Oracle8i und Oracle8 zeigt.

Die Partitionierung ist ein mächtiger Mechanismus, der einerseits einen Mehraufwand darstellt und durchdachte physische Entwurfsentscheidungen verlangt und sich andererseits wesentlich auf das Leistungsverhalten und die Verfügbarkeit des Systems - auch negativ - auswirken kann. Nicht nur die Praxis hat hier noch Nachholbedarf, auch von seiten der Wissenschaft gibt es noch Klärungsbedarf etwa für verfeinerte und angepaßte Algorithmen zur Optimierung, für die Leistungsvorhersage und für eine bessere Administrationsunterstützung. Entsprechende Forschungsarbeiten sind am laufen.