Otto-von-Guericke-Universität Magdeburg. Fakultät für Informatik Institut für Technische und Betriebliche Informationssysteme.

Transkript

1 Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Technische und Betriebliche Informationssysteme Diplomarbeit Entwicklung von Konzepten zur dynamischen Verwaltung der Partitionierung/Verteilung in DBMS. Verfasser: Norbert Siegmund 27. März 2007 Betreuer: Eike Schallehn Universität Magdeburg Fakultät für Informatik Postfach 4120, D Magdeburg Germany

2 Siegmund, Norbert: Entwicklung von Konzepten zur dynamischen Verwaltung der Partitionierung/Verteilung in DBMS. Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, 2007.

3 INHALTSVERZEICHNIS i Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Abkürzungen vi vii ix 1 Einleitung 1 2 Grundlagen Partitionierungsarten Zugriffsmuster Indexe Statistiken in Datenbanken Automatisiertes Datenbank Tuning State of the Art DB2 Design Advisor Recommend Partition Evaluate Partition Abschätzung der Kosten Suchalgorithmus Zusammenfassung Microsoft Database Tuning Advisor Column-Group Restriction & Selection Merging

4 ii INHALTSVERZEICHNIS Zusammenfassung Automatisiertes Layout der Datenbank nach Agrawal et al Database Layout Problem Formulierung Aufbau der Lösung Workload Informationen Suchstrategie Ergebnisse Self-Tuning Data Placement nach Lee et al Data Placement Data Migration Ergebnisse Autonomous Query Driven Index Tuning Processing Index-building Queries Kostenmodell Index Auswahl Ergebnisse Konzept zur Lösung Design Ideen und Probleme der Optimierung Statistik Kostenmodell Verteilungsstrategien Einstellgrößen und Parameter Erweiterbarkeit Kopplung an Indexe Mehrdimensionale Partitionierung Co-allokierte Relationen Änderung des Partitionsschlüssels

5 INHALTSVERZEICHNIS iii Optimierung nach Bedarf Aging-Wert Antwortzeiten Replikation Ergebnisse Ablauf der Simulation Auswertungen Zusammenfassung Zusammenfassung Ausblick Literaturverzeichnis 71 Anhang 77

6 iv INHALTSVERZEICHNIS

7 ABBILDUNGSVERZEICHNIS v Abbildungsverzeichnis 2.1 Vertikale Partitionierung Horizontale Partitionierung Beispiel eines Histogrammes Aufbau des Partition Advisors nach [JZM02] Ergebnisse des DB2 Design Advisors Aufbau des Database Tuning Advisors nach [SCK + 04] Aufbau der Lösung nach [SNCD03] Beispiel Queries aus [SNCD03] Beispiel des Zugriffsgraphen aus [SNCD03] Qualitätsvergleich Full Striping mit TS-Greedy aus [SNCD03] Beispiel 1 nach [LKO + 00] Beispiel 2 nach [LKO + 00] Antwortzeiten der PEs aus [LKO + 00] QUIT - Architektur aus [SGS03] Schematischer Aufbau der Lösung Histogramm der Datenverteilung über gleiche Bucketgrößen Histogramm der Datenverteilung über gleichmäßige Intervallgrenzen Histogramm über die Anzahl von Zugriffen in Fragementen Histogramm der Antwortzeiten von Festplatten Histogramm der Antwortzeiten von Relationen Verteilung von Antwortzeiten einer Partition auf 3 Fragmenten

8 vi ABBILDUNGSVERZEICHNIS 4.8 Beispiel der Plattenoptimierung Beispiel der Relationenoptimierung Mehrdimensionale Partitionierung Definition der Simulationsumgebung Initiale Datenverteilung Übersicht des Simulationsprogrammes Anfangsverteilung der Daten Beginn der Umverteilung Nach erster Umverteilung Nach zweiter Umverteilung Nach dritter Umverteilung Nach vierter Umverteilung Nach fünfter Umverteilung Grundkonfiguration für Test Halbierung der Geschwindigkeit für Platte Erste Umverteilung für Test Endverteilung für Test Optimierung der Tabelle 0 - Start Optimierung der Tabelle 0-1.Ausgleich Optimierung der Tabelle 0-2. Ausgleich Optimierung der Tabelle 0-3. Ausgleich Optimierung der Tabelle 0-4. Ausgleich Optimierung der Tabelle 1 - Start Optimierung der Tabelle 1-1. Ausgleich Optimierung der Tabelle 1-2. Ausgleich Optimierung der Tabelle 1-3. Ausgleich Optimierung der Tabelle 1-4. Ausgleich Optimierung der Tabelle 1-5. Ausgleich

9 TABELLENVERZEICHNIS vii Tabellenverzeichnis 3.1 Beispiel der Kostenmetrik aus [SCK + 04] Beispiel zum Datenbankmodell Abhängigkeiten der verschiedenen Features Queryspeicherung Spaltentabelle Partitionentabelle Verbundtabelle Beispiel zur Kapazitätskontrolle Bereinigung von Abfragezeiten Naiver Ansatz zur Verteilung Tatsächliche Verteilung Bereinigung der Verschiebungszeitwerte Antwortzeiten co-allokierter Tabellen Veränderung der Partitionsgrenzen nach der Optimierung

10 viii TABELLENVERZEICHNIS

11 ix Verzeichnis der Abkürzungen DBMS LRU LFU SQL I/O CPU DTA DBA Datenbankmanagementsystem Last recently Used Least frequently Used Structured Quering Language Input/Output Central Prozessing Unit Database Tuning Advisor Datenbankadministrator

12 x

13 Kapitel 1. Einleitung 1 Kapitel 1 Einleitung Heutige Datenbanksysteme sind in der Lage eine enorme Menge an Daten zu speichern und zu verwalten. Mit zunehmender Größe der Datenbestände verschlechtert sich im Allgemeinen auch die Performance. Die Antwortzeiten von Abfragen erhöhen sich und die Dauer für Einträge und Änderungen kann ebenfalls zunehmen. Die Gründe dafür liegen mitunter in der erschwerten Lokalisierung der Daten und in der zunehmenden Belastung der Festplatten auf denen die Daten gespeichert sind. Um diese Belastung auszugleichen, wurde das Konzept der Partitionierung bzw. Datenverteilung entwickelt. Die Antwortzeiten können durch Parallelisierung und Lastverteilung wesentlich gesenkt werden. Die Verteilung der Daten ist jedoch vom Zugriffsmuster der ankommenden Abfragen stark abhängig. Ändert sich das Muster im Betrieb, können die Vorteile der Parallelisierung sich negieren und im schlimmsten Fall bilden überlastete Festplatten Flaschenhälse in der Performance. Ein weitere Punkt sind die erheblichen Kosten und Ressourcen die für eine manuelle Konfiguration einer Datenbank anfallen. Datenbankadministratoren sind zudem nicht in der Lage (Zeitgründe, Kosten, etc.), z.b. nach jedem Tag das System für die aktuellen Anforderungen zu verändern. Um diese Probleme zu beheben, wird ein kostenbasiertes Konzept vorgestellt, das zur Laufzeit der Datenbank eine Umverteilung der Daten vornimmt und damit dem aktuellen Workload die bestmögliche Performance gewährleistet. Es sind die Schwierigkeiten erläutert, die sich aus dem Umstand ergeben, dass während der Laufzeit der Datenbank Statistiken zu erstellen und zu verwalten sind. Hinzu kommt, dass die Optimierungs- und Verteilungsphase ebenfalls online erfolgen muss. Das Konzept ist in einer simulierten Umgebung getestet worden. Im 2. Kapitel werden die Grundlagen der Partitionierung und dieser Arbeit beschrieben. In Kapitel 3 folgt eine Vorstellung der momentanen State of the Art Lösungen. Es gibt bereits Programme, die eine optimale Verteilung von Daten vornehmen. Das sind allerdings statische Tools, die bereits einen Workload erfordern. Zudem benötigen sie eine lange Berechnungsdauer und ihre Änderungen sind meist so gravierend, dass sie nur im offline - Modus der Datenbank vorgenommen werden können. Das Konzept wird in Kapitel 4 vorgestellt. Die Ergebnisse der Simulation werden in Kapitel 5 präsentiert und ausgewertet. Das Kapitel 6 liefert eine Zusammenfassung dieser Arbeit und bildet den Abschluss.

14 2

15 Kapitel 2. Grundlagen 3 Kapitel 2 Grundlagen Ursprünglich kam das Konzept der Partitionierung aus dem Anwendungsfeld verteilter und paralleler Datenbanken [DG90],[DG92]. Darunter versteht man die Verteilung der Daten einer oder mehrerer Tabellen auf verschiedene Partitionen. Der Vorgang läuft nur auf der physikalischen Ebene der Datenbank ab. Für den Betrachter bleibt die Tabelle unverändert. In diesem Zusammenhang wird der Begriff Transparenz definiert. Er gibt an, dass Änderungen im physischen Schema keine Auswirkungen auf das logische Schema haben dürfen. Eine Partition besteht meist aus einer Datei, einer Festplatte, einem RAID in einem RAID-System oder aus ganzen Einheiten mit eigenem Speicher und eigenem Prozessor. Das Ziel der Partitionierung ist die Maximierung des parallelen Zugriffs auf Daten und der Lastausgleich der einzelnen Partitionen. Weitere Vorteile sind vereinfachte Wartbarkeit und Administration, sowie verbesserte Archivierung von Datenbeständen. So können z.b. aktuelle und häufig benutzte Daten auf schnellen, jedoch auch teuren und kleinen Platten verteilt werden. Ältere Werte sind auf großen und billigen Datenträgern aufzuteilen. Dies erhöht die Effizienz der Datenbanken und verringert die Kosten der Hardware. Dieses Kapitel stellt die Arten der Partitionierung vor, wie sie z.b. in [SSH05] beschrieben sind. Es erläutert den Workload einer Datenbank, wie ein relevanter Index aufgebaut ist und was automatisiertes Datenbanktuning bedeutet. 2.1 Partitionierungsarten Die Verteilung einer Tabelle kann auf 2 Arten und deren Hybrid erfolgen. Die vertikale Partitionierung teilt die Tabelle an ihren Spalten auf. Zur Identifizierung in den einzelnen Segmenten muss jedesmal der Primärschlüssel mit enthalten sein, damit die ursprüngliche Tabelle durch Joins wieder zusammensetzbar ist. Das Datenvolumen wird hierdurch erhöht. Diese Variante befindet sich kaum in Verwendung, da die Parallelisierung nicht zum Tragen kommen kann. Die vertikale Partitionierung empfiehlt sich vor allem, wenn einige Spalten sehr häufig verändert oder abgefragt, andere dagegen im gleichen Datensatz konstant bleiben und kaum betrachtet werden. Die zweite Möglichkeit ist die horizontale Partitionierung. Hier wird die Tabelle in

16 Partitionierungsarten Abbildung 2.1: Vertikale Partitionierung ihrer Struktur vervielfacht und auf die angegeben Partitionen verteilt. Jede von ihnen erhält eine bestimmte Anzahl von Datensätzen, so dass bei einem Join aller Fragmente wieder die Ursprungstabelle entsteht. Die Verteilung erfolgt nach verschiedenen Verfahren: Hash - Verfahren Mittels einer Hashfunktion werden die Datensätze auf die verschiedenen Partitionen verteilt. An dieser Stelle fließen bereits Randbedingungen der aktuellen Systeme ein, um das Design zu verbessern. Der Microsoft Tuning Wizard [LKO + 00] richtet die Größe der Hashbuckets nach der Kapazität des Hauptspeichers und legt die Anzahl der Buckets auf ein Vielfaches der Prozessoranzahl fest. Diese Variante empfiehlt sich bei unregelmäßigen Zugriffsmustern auf die Daten. Bereichs(Range) - Verfahren Die Zugriffe auf Daten erfolgen meist in bestimmten Mustern. Dabei sind nur Inhalte gesucht, die in bestimmten Wertebereichen vorliegen. Die Verteilung der Daten erfolgt durch Angabe eines Entscheidungsschlüssels. Der Wertebereich wird durch die Anzahl an Partitionen unterteilt. Der Schlüssel gibt an, an welcher Stelle diese Unterteilung statt finden soll. Dies ist ein Kernpunkt des Performancetunings. Er ist abhängig von der Struktur der Datenwerte und der Abfragemuster der Datenbank. Als Schlüssel kann jede Spalte einer Tabelle dienen. Frühe Implementationen der Verfahren sind z.b. in [DGS + 90]und in [LM92] beschrieben. Es existieren zudem Möglichkeiten, die beiden Ansätze zu verbinden. So stellen zum Beispiel Ghandeharizadeh und DeWitt [GD90] eine hybride Bereichspartitionierungsstrategie vor. Eine Analyse über diese 3 Strategien wurde von Nørv ag durchgeführt [Nør].

17 Kapitel 2. Grundlagen 5 Abbildung 2.2: Horizontale Partitionierung 2.2 Zugriffsmuster Immer häufiger kommen Datenbanksysteme zum Einsatz, die Anfragen aus unterschiedlichen Regionen der Erde erhalten. Speziell im Internet existieren Datenbanken die zu jeder Zeit erreichbar sein müssen. So kann der häufig frequentierte Teil des Datenbereichs sich im Laufe des Tages oder der Woche erheblich ändern. Für die Verbesserung der Geschwindigkeit eines DBMS ist die Kenntnis des Zugriffsmusters, im engl. Workload, daher von großer Bedeutung. In ihm ist das Schema bzw. die Struktur der ankommenden Abfragen enthalten. Daraus können stark belastete Bereiche erkannt und die Verarbeitung dafür verbessert werden. Durch diese Informationen leitet das Datenbankmanagmentsystem mögliche Attributkandidaten für die Indexierung ab. Materialisierte Sichten sind für oft wiederkehrende Abfragen über mehrere Tabellen anzulegen. Daten sind so auf Partitionen verteilt, dass die Parallelisierung entsprechend den tatsächlich ankommenden Queries erfolgen kann. Ein früher Ansatz für das automatische Tuning anhand eines komplexen Workloads zeigte bereits Brown et al [BMCL94]. Das Kernproblem in diesem Bereich ist die enorme Menge an ankommenden Daten. Ein simples Verfahren ist die Verbindung von gleichen Abfragen mit unterschiedlichen Attributen bzw. eine Zusammenfassung von Abfragen zu Gruppen und die Einführung von Gewichten für jene Gruppen. Tools, wie der DB2 Design Advisor oder der Microsoft Tuning Wizard verfügen über Verfahren der Komprimierung [DJS + 04],[SCK + 04]. Im DB2 Design Advisor werden die Queries nach ihrer Komplexität absteigend sortiert und nur die obersten k Abfragen werden bis zu einem spezifizierten Prozentsatz komprimiert. Dabei definiert sich die Variable k aus der zur Verfügung stehenden Berechnungszeit. Dies gewährleistet ein effizientes Maß an Komprimierung, um nicht einen Overhead für diese Berechnung zu erhalten. Die Skalierbarkeit ist daher gewährleistet.

18 Indexe 2.3 Indexe Indexe sind Hilfsstrukturen in Datenbanken. Sie ermöglichen eine erheblich schnellere und effektivere physische Lokalisierung der Daten. Eine sehr oft benutzte Form ist der von Rudolf Bayer und Edward M. McCreight 1972 [BM72],[BU77] entwickelte B - Baum. Dieser wurde B+ - Baum. Er ist die Weiterentwicklung des B - Baumes. Das B steht hierbei für balanciert und nicht für binär. Der Baum beinhaltet Werte eines bestimmten Attributes und teilt den Wertebereich dadurch in verschiedene Zweige auf. Die Knoten selber können an die vorkommende Seitengröße angepasst werden. Beim B+ - Baum befinden sich die Zeiger auf den tatsächlichen Ort der Datensätze nur in den Blattknoten. Auf diese Weise kann in logarithmischem Zeitaufwand der Ort eines Datensatzes vom DBMS ermittelt werden, ohne die gesamte Tabelle zu durchsuchen. Zudem können weitere Schlüssel pro Knoten vorhanden sein. Folgende Eigenschaften besitzt der B+ - Baum: Baum mit Knoten die mehr als 2 Nachfolger haben können Linker Nachfolger eines Knotens ist kleiner als der Knoten Rechter Nachfolger ist größer oder gleich dem Knoten Unterbaum definiert Intervallbereich der Elemente Alle Blattknoten haben die gleiche Tiefe Die Wurzel ist ein Blatt oder hat mindestens 2 Nachfolger Interner Knoten hat mindestens k und maximal 2k Schlüsselwerte Interner Knoten hat mindestens k+1 und maximal 2k+1 Nachfolger außer Wurzel Die Ordnung eines Baumes gibt die Höhe des Baumes an Die Anzahl der Werte in den Blattknonten können variieren Ein weiterer wichtiger Index ist das Data Grid. In ihm sind mehrere Attribute indexiert und dienen daher der gleichzeitigen Suche über mehrere Spalten einer Tabelle. Dieser Index kommt vor allem bei mehrdimensionalen Abfragen vor. 2.4 Statistiken in Datenbanken Für die Generierung optimaler Ausführungspläne von Abfragen und für das Tuning der Datenbank, benötigt das DBMS Statistiken über die verwalteten Daten. Ein Histogramm ist eine der wichtigsten Formen dies zu realisieren [Koo80],[PHIS96]. Es dient der Aggregation und Komprimierung von Daten und zur Vorhersage der Selektivität

19 Kapitel 2. Grundlagen 7 eines Attributes [MMK + 05]. Die Verteilung der Daten im gesamten Wertebereich kann zur Abschätzung für performance-relevante Informationen dienen. Die vorgestellte Lösung benutzt Histogramme, um die Verteilung der Queries im Bezug zum Wertebereich darzustellen und eine darauf basierende Partitionierung vorzunehmen. Weiterführende Ansätze gehen dahin, auch die Histogramme während der Laufzeit besser zu optimieren. Dazu stellen Aboulnaga und Chaudhuri eine Lösung vor [AC99]. Ihre Idee besteht darin, dass das Histogramm nicht aufgrund der Daten in der Datenbank erstellt und gepflegt wird, sondern durch die Selektivitätsangabe der Anfrageoptimierer. So wird nach jeder Query das Diagramm verfeinert. Dieser Mechanismus ist mit einer Feedback-Schleife realisiert worden, die nachfolgend kurz beschrieben wird. Abbildung 2.3: Beispiel eines Histogrammes 2.5 Automatisiertes Datenbank Tuning Durch wachsende Administrationskosten und zunehmende Komplexität von Multi - Tier Applikationen gewinnen automatisierte Managementtools immer größere Bedeutung. So gaben Chaudhuri und Weikum auf der SIGMOD 2005 ein ausführliches Tutorial über die wichtigsten Aspekte [CW05]. Die Prinzipien des Auto-Tunings sind wie folgt beschrieben: Kompromiss Eliminierung Falls es Parameter gibt, die eine universelle, nah am Optimum gelegene Performance bieten, sollten diese entfernt werden. Beispiele sind z.b. Cache Strategien (LRU vs. LFU) [OOW93],[WKKS99].

20 Automatisiertes Datenbank Tuning Statische Optimierung Diese Kategorie kann dem physischen Datenbankdesign zugeordnet werden. Neuere Ansätze, wie sie später gezeigt werden, beeinflussen das physische Datenbankdesign in dynamischen Umgebungen. Es ist eine optimale Konfiguration und Auswahl der Indexe, materialisierten Sichten und Partitionen anhand eines gegebenen Workloads unter der Bedingung des begrenzten Speicherplatzes zu finden. Stochastische Vorhersagen Da der Workload bereits statistischen Schwankungen unterliegt, können darauf Vorhersagen über die Auslastung des Systems getroffen werden. Auf diesen beruht die Einteilung der Systemressourcen (CPU-Geschwindigkeit, Cache-Größe, Festplattenanzahl und deren Kapazität,etc.), so dass das DBMS Performancegarantien erfüllen kann. Online Optimierung Die Online Optimierung ist ein breites Feld. Zu ihr gehören die effiziente Speicherverwaltung, die Pflege von statistischen Metadaten sowie komplexe Aufgaben, wie z.b. Umverteilung von Daten. Feedback Control Loop Diese Technik beschreibt eine Schleife in der Steuerung der Datenbank zur Überwachung des Verhaltens oder der Veränderungen eines Systems. Die Qualität von getätigten Eingriffen ist hierdurch ebenfalls überprüfbar. Darauf basierend entwickelten Weikum et al. ein Framework, um die Möglichkeiten des automatischen Tunings zu steigern [WMHZ02]. What-if Analyse Um zu entscheiden, ob zum Beispiel ein Index besser ist als ein anderer, wird das What-if Verfahren angewendet. Es basiert auf dem Was wäre wenn Prinzip. Damit die Datenbank keinen physischen Index kreieren muss, wird ein virtueller Index im Speicher geschaffen. Basierend auf statistischen Informationen ermittelt das DBMS daraufhin einen Ausführungsplan. So finden schnelle Vergleiche statt, um ein optimales Ergebnis zu ermitteln [CN98]. Diese Methodik wird auch für andere Features (Sichten, Partitionen) eingesetzt, die Einfluss auf die Performance einer Datenbank haben. In der Praxis sind die Übergänge fließend. Ein Optimierungstool verwendet gleichzeitig mehrere Aspekte, um ein ganzheitlich wirksames Ergebnis zu erreichen.

21 Kapitel 3. State of the Art 9 Kapitel 3 State of the Art Dieses Kapitel stellt die gegenwärtig führenden Programme und Modelle vor, die sich mit dem Thema der Partitionierung beschäftigen. Zuerst werden zwei statische Lösungen, die nicht zur Laufzeit ausführbar sind, beschrieben. Sie müssen manuell vom Datenbankadministrator gestartet werden und berechnen eine Konfiguration, die für einen gegebenen Workload annähernd optimal ist. Sie beziehen nicht nur die Partitionierung als Optimierungsfaktor ein, sondern besitzen zudem die Möglichkeit Indizes und materialisierte Sichten für ein komplettes physisches Schema zu erstellen. Als nächstes sind zwei Modelle, die sich mit der Umverteilung der Daten befassen, erläutert. Towards Self Tuning ist bereits eine Lösung für die Optimierung zur Laufzeit der Datenbank. Am Ende dieses Kapitels ist eine bereits ausgereifte Lösung des Self-Tunings der Datenbank während der Betriebsphase beschrieben. Das Programm QUIET überprüft die Effektivität von Indexen und kreiert bei Bedarf selbstständig neue Indizes. 3.1 DB2 Design Advisor Der DB2 Design Advisor von IBM verfügt über ein großes Spektrum an Anwendungsfeldern. Er besitzt die Fähigkeit für einen gegebenen Workload ein Datenbankdesign zu erstellen, das Indexe, Materialisierte Sichten, Partitionierung und Multi-Dimensionales Clustering von Tabellen unterstützt [DJS + 04]. Das Tool berücksichtigt die komplexen Abhängigkeiten zwischen den genannten Features und ist daher ein wichtiges Werkzeug für die Performancesteigerung. Für diese Arbeit ist der Bereich der Partitionierung von besonderer Relevanz. Dieses Feature war zuvor ein eigenständiges Tool (DB2 Partition Advisor [JZM02]). Es wurde mit in den Design Advisor integriert. Es benutzt als Verteilungsmethode die Hash - Partitionierung (siehe Kapitel 2). Das Ziel ist für eine gegebene Menge von SQL - Statements die Ausführungskosten zu minimieren. Der schematische Aufbau sieht wie folgt aus: Es sind zwei Änderungen an der Datenbank zu erkennen. Recommend Partition veranlasst die Datenbank für jedes SQL - Statement eine Liste von möglichen Partitionen zu generieren, die als Kandidaten für den Ausführungsplan der Abfrage dienen. Sobald

22 DB2 Design Advisor Abbildung 3.1: Aufbau des Partition Advisors nach [JZM02] der Optimierer einen gültigen Plan ermittelt hat, werden die in ihm vorkommenden Partitionen aller Basistabellen in die CANDIDATE_PARTITIONS - Tabelle geschrieben. Evaluate Partition liest aus dieser Tabelle die Partitionen ein und versucht sie mit den physikalisch tatsächlich vorhandenen zu ersetzen. Danach optimiert die Datenbank die Abfrage so, dass sie die neuen Partitionen verwendet. Auf der Client Seite wird nach der Übermittlung des Workloads jedes Statement zur Datenbank (Recommend Partition) gesendet. Nachdem alle Partitionskandidaten in der Tabelle CANDIDATE_PARTITIONS gesammelt worden, generiert das Tool durch Kombination weitere Kandidaten, damit weitere günstige Varianten gefunden werden, die jedoch nicht durch eine einzelne Abfrage entstanden sind. Die Applikation kombiniert Partitionen von verschiedenen Tabellen und reicht diese an die Datenbank weiter (Evaluate Partition). Die Ausgabe enthält eine Partitionierung für jede Tabelle und deren Kosten für den gegebenen Workload. Zum weiteren Verständnis werden die Begriffe der Knoten und Knotengruppen eingeführt, die der Design Advisor verwendet. Ein Knoten ist ein Prozessor, der eine Abfrage ausführen kann. Um Parallelität zu gewährleisten, wird eine Abfrage aufgeteilt und zu verschiedenen Knoten gesendet, die die Query parallel beantworten. Die Partitionierung anhand einer Spalte wird über diese Knoten verteilt. Knotengruppen können vom Benutzer oder vom System definiert werden und beinhalten alle möglichen Untermengen von allen vorhandenen Knoten im System Recommend Partition In diesem Modus ist das Finden der optimalen Partitionierung einer Tabelle für jede gegebene Abfrage das Hauptziel. Da jede Untermenge von Spalten oder Datensätzen eine Partition bilden können, ist die Anzahl an möglichen Verteilungen enorm hoch. Jedoch re-

23 Kapitel 3. State of the Art 11 duzieren nicht alle Aufteilungen die Kosten der gegebenen Abfrage. Dies macht man sich zu nutze und generiert eine Liste von Kandidaten als Partitionen. Ein Kandidat wird die Partitionierung, bei der die Operationen in der Abfrage von dieser Verteilung profitieren können. Hinzu kommen solche Partitionen die über eine Spalte verteilt sind, deren Werte konstant sind. Da die Beantwortung eines Prädikates einer Abfrage nur Berechnungen auf einem einzelnen Knoten erfordert, kann sich der Kommunikationsaufwand erheblich vermindern. Hinzu kommt die Möglichkeit, kleinere Tabellen auf verschiedene Knoten zu replizieren. Das kann ebenfalls die Kommunikationskosten senken und die Performance erheblich steigern. Der Optimierer erarbeitet anschließend Ausführungspläne für jede (virtuelle) Kandidat-Partitionierung. Anschließend wird die Partition mit den geringsten Ausführungskosten zurückgegeben und in die CANDIDATE_PARTITION Tabelle geschrieben. Zwei Probleme entstehen jedoch. Falls in einer Query mehrmals die gleiche Tabelle abgefragt wird, können innerhalb des Ausführungsplanes unterschiedliche, entgegengesetzte Partitionierungen verwendet werden. Ein solcher Vorgang ist natürlich ungültig. Da aber die Überprüfung erheblichen Rechenaufwand erfordern würde, findet die Kontrolle der Pläne bei der späteren Evaluierung statt. Die zweite Schwierigkeit ergibt sich aus der enormen Anzahl möglicher Pläne für virtuelle Partitionen. Die Berechnungszeit wird dadurch stark erhöht und der Platzbedarf zur Speicherung der Pläne ist enorm. Aus diesem Grund muss das Tool eine Reduktion der Kandidaten vornehmen. Falls eine Tabelle zu einer Knotengruppe mit nur einem Element zugewiesen ist, hat der Partitionsschlüssel überhaupt keinen Einfluss auf das Ergebnis, da die Tabelle unpartitioniert vorliegt. Falls benutzerdefinierte Gruppen existieren, die exakt der voreingestellten default Knotengruppe entsprechen, werden alle Kandidaten für die default Gruppe ignoriert. Diese Aktion begründet sich aus den Erfahrungen des Datenbankherstellers. Es wurde oft beobachtet, dass Administratoren eine eigene Gruppe aus allen verfügbaren Knoten erstellen, die aber exakt der default Gruppe entspricht. Schließlich entfernt das Tool die Kandidaten, deren Tabellen sehr klein sind. Änderungen der Partitionierung haben nur einen geringen Effekt in der Antwortzeit einer Abfrage. Daher wird die originale Verteilung verwendet Evaluate Partition Das Tool markiert in der CANDIDATE_PARTITION - Tabelle genau eine Partitionierung für jede Tabelle. Diese wird in den Evaluate Modus eingegeben. Das DBMS benutzt sie, um die vorhandene Verteilung durch jene neue Verteilung zu ersetzen. Der Optimierer fährt unter der Annahme fort, dass die neue Partitionierung der Realen entspricht. Die Berechnungszeit ist gleich der realen Betriebszeit des Datenbanksystems Abschätzung der Kosten Zur Ermittlung der Kosten einer Abfrage benötigt das Tool statistische Informationen der Datenbank über die Kardinalität einer Tabelle und deren Spalten, Anzahl von Datenseiten, Indexe und Verteilungen der Daten. Die Applikation unterscheidet zwischen

24 DB2 Design Advisor Metadaten, die auf Tabellen - Level und jenen Informationen die auf dem jeweiligen Knoten - Level vorhanden sind. Daraus berechnet sich eine lineare Kombination aus I/O - Kosten, CPU - Geschwindigkeit, Kommunikationskosten und einen Überlappungswert dieser drei Komponenten. Um die Kosten für virtuelle Partitionen zu berechnen, müssen lediglich die Statistiken auf dem Knoten - Level geändert werden. Das System muss die vorhandenen Statistiken an die neue Verteilung anpassen. Dazu liest es die vorhandenen Informationen aus, setzt dabei aber eine gleichmäßige Verteilung (gegeben durch Hash - Partitionierung) voraus. Daraus lässt sich das Verhältnis zwischen der Anzahl der alten Knoten und der Anzahl der neuen Knoten berechnen, sowie die Skalierung der Statistiken. Auf dieser Grundlage schätzt das System die Kosten von Ausführungsplänen ab, wenn reale Partitionen mit Virtuellen getauscht werden Suchalgorithmus Die Kombination der Partitionierungen aus allen Tabellen bildet den Suchraum. Gegeben sind n Tabellen, jede mit p i (0<i<= n) Kandidatpartitionierungen. Es wird eine Konfiguration C = ( c 1, c 2,..., c n )definiert, wobei c i eine der Kandidatpartitionierungen von Tabelle i ist. Für eine Query q sind die Kosten Cost q (C) unter Konfiguration C definiert. Es soll in einem Workload Q C optimal gefunden werden, so dass qεq Cost q (C optimal ) = min qεq Cost q (C) über alle p 1 p 2... p n Möglichkeiten von C gilt. Die Schwierigkeit in der Berechnung liegt an der Fülle von Möglichkeiten. Um diese auf ein akzeptables Maß zu senken, ermittelt das Programm zuerst einen Profitwert für jeden Kandidat jeder Tabelle. Dieser entspricht der Differenz der Kosten aus dem regulären Modus und dem Recommend Modus. Danach wird über sämtliche Abfragen der Gesamtprofit für jede distinkte Kandidatpartitionierung berechnet. Der DB2 Partition Advisor kann daraus die Kosten ermitteln. Das genaue Verfahren ist unter [JZM02] nachzulesen Zusammenfassung Der Partition Advisor konnte eine Verbesserung von 4% im 100 GB TPCH Benchmark erreichen. Die Knoten wurden dabei auf einem einzelnen Computer simuliert. Es wurden keine tatsächlichen Daten verwendet, sondern nur Metadaten, die aus einem description-file einer realen Datenbank erstellt wurden. Bei der getesteten Kundendatenbank, die bereits zuvor von einem Administrator optimiert wurde, ließ sich dennoch eine Verbesserung von 22% feststellen. Beim Test wurden 66% der Abfragen schneller beantwortet und der Rest langsamer oder gleich schnell wie zuvor. Die weiter entwickelte Variante des Tools, der Design Advisor mit allen unterstützten Features, benötigte für die Optimierung einer 1GB TPCH Datenbank und ihren 22 Abfragen ca. 10 Minuten. Der Optimierer berechnete eine Verbesserung von 88.01% für das vorgeschlagene Design. Die tatsächliche Verbesserung von 84.54% liegt nur unwesentlich von der Abschätzung entfernt. Dies ist eine enorme Steigerung der Performance. Diese Berechnung findet allerdings nur statisch statt und muss in Ruhezeiten der Datenbank manuell gestartet werden.

25 Kapitel 3. State of the Art 13 Die Änderungen mit 20 Indexen, 6 multidimensional geclusterten Tabellen, 4 Umpartitionierungen und 2 materialisierten Sichten sind gravierend. Zur Laufzeit ist eine solche Änderung des physischen Schemas der Datenbank nur sehr schwer zu verwirklichen. Abbildung 3.2: Ergebnisse des DB2 Design Advisors 3.2 Microsoft Database Tuning Advisor Der Microsoft Database Tuning Advisor(DTA) ist im SQL Server 2005 implementiert. Er ermittelt für einen gegebenen Workload das Datenbankdesign mit den geringsten Kosten. Das Design beinhaltet die Auswahl von Indexen, materialisierten Sichten und horizontaler Partitionierung [SCK + 04]. Der Datenbankadministrator (DBA) verfügt über die Möglichkeit einzelne Features auszuschalten. Des Weiteren kann er angeben, dass bei der Partitionierung einer Tabelle ihre gesamten Komponenten (z.b. Indexe) identisch verteilt werden. Dies gewährleistet eine bessere Pflege und Archivierung der Daten. Der DBA kann zusätzliche Bedingungen über die Limitierung des Speichers und der zu berechnenden Zeit angeben. Ich beschränke mich wiederum auf den für diese Arbeit relevanten Teil, der Partitionierung [SNY04]. Das Tool besitzt folgenden Aufbau: Zu Beginn wird der Workload eingelesen. Durch die Beachtung der verschiedenen relevanten Designaspekte wird die Menge von potentiell optimierbaren Spaltengruppen enorm groß. Um diese Anzahl zu beschränken, beginnt das Tool mit der Column-Group Restriction. Das Modul filtert jene Mengen Spalten heraus, die nur geringen Einfluss auf ein optimales Design für dieses Workload besitzen. Daraus ergibt sich eine Liste von Kandidaten, die als Grundlage für das physikalische Design dienen. Der Candidate Selection Abschnitt ermittelt für jede Query mit Hilfe des Optimierers eine Menge von sehr guten Konfigurationen für die aktuelle Abfrage. Strukturen die in einer Konfiguration vorkommen, werden als Kandidat betrachtet. Das Tool verwendet einen Greedy Algorithmus, um die Rechendauer effektiver einzuschränken. Damit nicht nur Strukturen Verwendung finden, die für einzelne Abfragen gut sind, verbindet der Merging Schritt diese Grundkandidaten um weitere Elemente zu kreieren, die mehrere Abfragen gleichzeitig effizient

26 Microsoft Database Tuning Advisor Abbildung 3.3: Aufbau des Database Tuning Advisors nach [SCK + 04] beantworten können. Der finale Enumeration Abschnitt berechnet wiederum mit einem Greedy Verfahren die endgültige Lösung aus den zuvor ermittelten Kandidaten Column-Group Restriction & Selection Eine physikalische Designstruktur ist relevant für den Workload, falls es potentiell für die Beantwortung von einer oder mehrerer Abfragen Verwendung finden könnte. Basierend auf dieser Aussage, definieren die Autoren eine Metrik CG-Cost(g) für eine gegebene Spaltengruppe g, die festlegt, wie interessant diese Gruppe für den Workload ist. Dabei gilt, dass eine Gruppe interessant ist, wenn CG-Cost(g) >= f; (0<=f<=1). CG-Cost ist monoton, so dass gilt: g 1 g 2 CG-Cost(g 1 ) CG-Cost(g 2 ). Das bedeutet, wenn eine Column-Group häufig auftritt, kommen auch ihre Teilgruppen häufig vor. Dieses Merkmal fließt in die Berechnung ein, um nicht alle Teilmengen zu verarbeiten. In den Testläufen erwies sich, dass bereits ein Wert von 0,02 für f enorme Auswirkungen auf das Ergebnis hat. So hat selbst ein solch kleiner Wert eine erhebliche Reduzierung potentieller Gruppen zur Folge ohne die Qualität des Ergebnisses signifikant zu verschlechtern. Folgendes Beispiel verdeutlicht dieses Verfahren: Gegeben ist ein Workload mit 10 Queries, die die Tabelle T(A,B,C,D) referenzieren. Eine Zelle in der Tabelle 3.1 gibt an, ob die Abfrage die Spalte referenziert hat 1, oder nicht 0. Der Treshold f ist mit 0,2 definiert. Daraus ergeben sich folgende interessante Spaltengruppen: {A}, {B}, {C}, {A,B}, {A,C}, {B,C} und {A,B,C} mit CG-Cost von: 1.0, 0.3, 0.9, 0.3, 0.9, 0.2 und 0.2. Für Q3 müssen nur physische Designstrukturen auf den oben genannten 7 Spaltengruppen, aber nicht den 15 Gruppen betrachtet werden,

27 Kapitel 3. State of the Art 15 Spalten Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 A B C D Tabelle 3.1: Beispiel der Kostenmetrik aus [SCK + 04] die für Q3 syntaktisch relevant sind, da {D} und die ganzen 15 Column-Groups, die D enthalten, nicht interessant sind Merging Der nächste Schritt ist das Verbinden von Kandidaten. Aufgrund dessen, das die Kandidaten nur optimale Lösungen für einzelne Abfragen bieten, können die jeweiligen Designstrukturen für eine Anfrage gute und für eine andere Query schlechte Ergebnisse liefern. Des Weiteren unterliegen die Werte in Abfragen gewissen Schwankungen. Um diese besser ausgleichen zu können und um ein Design zu erstellen, das für dan gesamten Workload gute Ergebnisse liefert, werden die jeweiligen Kandidaten verbunden. Der für diese Arbeit relevante Teil ist das Range-Partition-Merging. Im Gegensatz zum Verbinden von Indizes, muss bei einer horizontalen Partitionierung die assoziierte Partitionierungsmethode mit verbunden werden. Eine Methode R ist definiert durch ein Tupel (c,v), wobei c dem Spaltentyp und V der geordneten Sequenz von Werten entspricht, z.b.: R=(date,< , >). Gegeben ist ein Paar von Bereichspartitionierungsmethoden P 1 = (S,V 1 ), P 2 = (S, V 2 ). Die beste Methode P 12 = (S, V 12 ) für das verbundene Objekt (Tabelle,Index,View) ist zu finden. Ein einfacher Ansatz dafür ist, alle möglichen Partitionierungsmethoden P 12 zu generieren, die aus jeglichen Teilmengen der Werte in V 1 V2 gebildet werden können. Die Methode mit den minimalsten Kosten, die alle Abfragen beantwortet, ist das Ziel. Um dies zu erreichen, sind die Kosten Cost- Range für das Durchlaufen einer (virtuellen) Partition, wie folgt definiert: 1. Die Kosten die für das Durchlaufen der Teilmenge einer Partition anfallen, die für die Beantwortung der Query Q benötigt werden. 2. Die fixen Kosten des I/O - Overheads für das Öffnen und Schließen eines B+ - Baumes für diese Partition. Es wird somit das V 12 gesucht, das die Summe der Kosten über die verbundenen Abfragen minimiert. Diese Funktion ist ein Greedy Algorithmus, der bei einer simplen Verbindung der Sequenzen von V 1 und V 2 startet und bei jeder Iteration das nächste Paar von adjazenten Intervallen, die am meisten die Kosten reduzieren, verbindet. Der Algorithmus stoppt, falls Cost-Range nicht weiter minimiert werden kann. Es gibt keine Garantie für ein optimales Ergebnis.

28 Automatisiertes Layout der Datenbank nach Agrawal et al Zusammenfassung Der Microsoft Database Tuning Advisor ist auf einer 10 GB TPCH Datenbank angewandt worden. Der Workload bestand aus 22 Queries. Das Tool ermittelte bei einer Berechnungszeit von 35 Minuten eine prognostizierte Verbesserung der Performance von 88%. Nach der Implementation des vorgeschlagenen Designs erwies sich eine tatsächliche Steigerung von 83%. Die Berechnungsdauer, sowie der tatsächliche Nutzen des neuen physischen Datenbankdesigns, ist in etwa vergleichbar mit dem Pendant von IBM. Beide Programme sind für Veränderungen während der Laufzeit jedoch nicht geeignet. 3.3 Automatisiertes Layout der Datenbank nach Agrawal et al. Dieses Modell beschreibt die Problematik der Auswahl einer günstigen physischen Verteilung von Datenbankobjekten, wie z.b. Tabellen, Indexe oder materialisierten Sichten auf Festplatten [SNCD03]. Da viele Datenbanken eine Maximierung der I/O Parallelisierung anstreben, werden alle Objekte über alle Platten verteilt. Dies kann aber zu einer Verschlechterung der Geschwindigkeit führen, wenn z.b. ein Join über zwei große Tabellen durchgeführt wird. Das kann zu vielen zufälligen I/O - Zugriffen auf jeder Festplatte führen. Das Modell berücksichtigt solche co-allokierten Objekte und versucht ein Layout zu ermitteln, das I/O Parallelismus erhält, sowie die Unkosten des Random I/O Zugriffs durch gleichzeitig abgefragte Objekte zu minimieren. Um ein solches Layout bewerten zu können, erstellen die Autoren ein Kostenmodell. Mit dessen Hilfe kann die Auswahl des besten Designs als Optimierungsproblem beschrieben werden Database Layout Eine Datenbank besteht aus einer Menge von Tabellen und den dazugehörigen Designstrukturen. Die Objekte, die dieses Modell betrachtet sind Relationen, Indexe und materialisierte Sichten. Die Menge von n Objekten in der Datenbank ist mit {R 1,.., R n } definiert. Sie sind auf einer Menge von m Festplatten zu verteilen {D 1,.., D m }. Eine solche Festplatte kann wiederum eine Anzahl von Elementen besitzen, z.b. als RAID - System. Die Festplatte D j besitzt folgende Eigenschaften: Kapazität C j Mittlere Suchzeit S j Mittlere Lesetransferrate T R j Mittlere Schreibtransferrate T W j

29 Kapitel 3. State of the Art 17 Zur Verfügung stehende Eigenschaft AV AIL j - None, Parity, Mirroring Beispiel: RAID0 oder Stand alone Platte hat Eigenschaft None, Raid5 entspricht Parity und Raid1 Mirroring. Definition 1: Ein Datenbanklayout ist eine Zuweisung jedes Objektes der DB zu einer Menge von Platten mit der Spezifikation ihrer Verteilung. Definition 2: Ein Layout ist gültig, wenn a) für jede Festplatte die Kapazität im Layout nicht überschritten wird und b) jedes Objekt vollständig zugewiesen ist. Die Autoren beschreiben daher das Layout als eine zweidimensionale Matrix mit den Spalten als Festplatten und den Reihen als Datenbankobjekten. Der Wert einer Zelle x ij in der Matrix ist der Anteil der Verteilung eines Objektes auf der Platte D j bezüglich der Gesamtzahl der physikalischen Blöcke von R i. Mit den zuvor getroffen Definitionen sind folgende Regeln ableitbar: i [1..n], j [1..m]x ij 0 i [1..n] m i=1 x ij = 1 j [1..m] n j=1 R i x ij C j n -Anzahl Objekte; m - Anzahl Festplatten Die ersten beiden Regeln garantieren, dass jedes Objekt vollständig zugewiesen wird. Die dritte Regel garantiert, dass keine Kapazitäten überschritten werden. Folgendes Beispiel illustriert das Modell: Objekte Festplatte 1 Festplatte 2 Festplatte 3 Tabelle Tabelle Mat. Sicht 1 1 0s 0 Tabelle 3.2: Beispiel zum Datenbankmodell Ersichtlich ist, dass die Summe jeder Zeile 1 ergibt. Somit wurden alle Daten der Objekte vollständig verteilt. Nicht nachprüfbar ist die Kapazitätsbedingung, da hierfür zusätzlich die Größe der Objekte bzw. die Kapazitäten der Platten zu definieren wären Problem Formulierung Die I/O - Antwortzeit ist anhand eines gegebene Statements Q und eines Layouts L als gesamt verbrauchte Zeit für die Ausführung dieser Abfrage definiert Cost(Q,L). So formulieren Agrawal et al. das Problem wie folgt: Gegeben: Eine Menge von Datenbankobjekten {R 1,.., R n }, ein Workload W und eine Menge von Festplatten {D 1,.., D m } Finde: Ein gültiges Datenbanklayout mit den kleinsten totalen I/O Antwortzeiten für dieses Workload; Formal: Finde gültiges Layout L, so dass für jedes gültige Layout L gilt:

30 Automatisiertes Layout der Datenbank nach Agrawal et al. Q W W Q Cost(Q, L) Q W W Q Cost(Q,L ) Um bessere Wartbarkeit zu gewährleisten, weisen Datenbankadministratoren häufig frequentierte Tabellen zur gleichen Filegroup (in Oracle und DB2: Tablespaces) zu. Diese zusammen positionierten Objekte (R i, R k ) müssen ein gültiges Layout auf die gleiche Menge an Festplatten verteilen. Daher wird folgende Bedingung hinzugefügt: j [1...m](x ij = 0 x kj = 0) Das Modell lässt sich dahingehend erweitern, dass der DBA eine Verfügbarkeitsbedingung mit einem Objekt koppeln kann. Da bereits die Festplatten über diese Eigenschaften verfügen (AV AIL j ), muss lediglich folgende Bedingung zum Layout hinzugefügt werden: Avail-Requirement(R i ): j [1...m](x ij > 0 AV AIL j = A) Aufbau der Lösung Abbildung 3.4: Aufbau der Lösung nach [SNCD03] Als Eingabe dient eine Datenbank mit ihren Objekten, ein Workload, ein Menge von Bedingungen des DBA s und Festplatteninformationen. Die Ausgabe ist der Vorschlag eines Datenbanklayout s, dass für diese Eingabe die geringste totale I/O Antwortzeit besitzt. Die Analyze Workload Komponente führt nicht die Abfragen aus, sondern lässt sich den Ausführungsplan vom Query Optimizer geben. Dieser fließt in die Suche mit ein, um das Optimierungsproblem zu lösen. Die Suchkomponente durchläuft den gesamten Raum von möglicher Layout s und ermittelt die mit den geringsten Kosten.

31 Kapitel 3. State of the Art Workload Informationen Zwei Hauptmerkmale lassen sich aus dem Workload extrahieren. Das erste Merkmal sind die Objekte, auf denen die DB zugreift und die Gesamtzahl für die Objekte gelesenen Blöcke. Die zweite Information beschreibt die Menge der Objekte auf denen gleichzeitig zugegriffen wird und der Gesamtzahl von gelesenen Blöcken. Diese Daten sind als ungerichteter Graph mit gewichteten Kanten repräsentiert, der als Zugriffsgraph G bezeichnet ist. Jeder Knoten u bildet ein Objekt ab. Ein Knoten hat das Gewicht N u, welches der totalen Anzahl von Blöcken entspricht, die während der Ausführung aller Abfragen referenziert wurden. Eine Kante existiert, wenn zwei Objekte u,v gleichzeitig während einer oder mehrerer Queries abgefragt werden. Das Gewicht dieser Kante N u,v ist die Summe der gleichzeitig gelesen Blöcke über alle Abfragen des Workload s. Das Vorhandensein von mehreren Objekten in einem Ausführungsplan impliziert nicht deren gleichzeitiges Abfragen. Es existieren so genannte Blocking Operators, die veranlassen, dass der Zugriff auf einem Objekt nicht beginnt bevor ein anderes Objekt vollständig gelesen wurde. Aus diesem Grund erstellt die Suchkomponente Sub-Pläne, die nur nicht blockende Operatoren beinhalten. An jedem Block Operator beginnt ein Cut. Beispiel: Der Workload umfasst 2 Abfragen mit den Ausführungsplänen, die im Bild 3.5 dargestellt sind. Abbildung 3.5: Beispiel Queries aus [SNCD03] Die Zahlen neben den Relationen geben die gelesenen Blöcke an. Dies entspricht dem Knotengewicht im Zugriffsgraph. Die Kanten im Graph lassen sich aus den Joins berechnen. Beispielsweise ist die Summe der Kante zwischen R 2 und R 3 gleich 1300 (= 700 aus Q aus Q2). Algorithmus zur Konstruktion des Graphen Eingabe: Workload W Ausgabe: Zugriffsgraph G für W 1. Initialisiere G, um einen Knoten für jedes Objekt in der Datenbank zu haben und setze das Gewicht auf Für jede Abfrage Q W ermittle Ausführungsplan P Q. 3. Für jedes Objekt R, auf das in P Q zugegriffen wird, erhöhe das Gewicht des entsprechenden Knotens in G um die Gesamtzahl von Blöcken auf die in P Q zugegriffen wird.

32 Automatisiertes Layout der Datenbank nach Agrawal et al. Abbildung 3.6: Beispiel des Zugriffsgraphen aus [SNCD03] 4. Für jeden nicht-blockenden Sub-Plan S in P Q 5. Kreiere eine Kante, falls keine existiert, in G zwischen jedem Paar von distinkten Objekten auf denen in S zugegriffen wird. Erhöhe das Gewicht der Kante um die Summe der Gesamtzahl der Blöcke von den beiden Objekten, die die Kante definieren Suchstrategie Die Suche nach dem besten Layout, basierend auf diesem Kostenmodell, ist extrem berechnungsintensiv. Aus diesem Grund verwenden die Autoren einen Greedy Algorithmus, um eine vertretbare Geschwindigkeit zu erhalten. Der erste Schritt ermittelt ein initiales, gültiges Datenbanklayout, das versucht, die Kosten für gleichzeitig verwendete Objekte zu minimieren. Der nächste Schritt verbessert diese Lösung durch Hinzufügen von I/O - Parallelismus von Objekten. Der erste Schritt ist daher exakt das Problem der Verteilung der Knoten des Graphes in einer gegebenen Anzahl von Partitionen (p), so dass die Summe aller Gewichte der Kanten, die entlang den Partitionen laufen, maximiert ist. Jede Partition besitzt Knoten die selten oder nie gleichzeitig verwendet werden. In diesem Fall entspricht p der Anzahl der Festplatten m. Im zweiten Schritt wird versucht, in jeder Iteration die Parallelität jedes Objektes zu erhöhen, indem bis zu k zusätzliche Festplatten hinzuzufügen sind, auf denen das Objekt momentan sich noch nicht befindet. k beschreibt daher, wie intensiv dieser Schritt sich berechnet. Der Algorithmus endet, wenn das Programm kein Layout mit geringeren Kosten findet. Die Laufzeit des Algorithmus beträgt O(m k+1 n 2 + n 2 + log(n)) Ergebnisse Das Modell wurde im Microsoft SQL Server 2000 implementiert. Der Unterschied zwischen den langsamsten und schnellsten Festplatten des Testsystems betrug 30%. Der 1 GB TPC-H Benchmark verbesserte sich gegenüber dem Full Striping Layout (alle Objekte auf allen Platten für totale Parallelisierung) um 20%. Mit dem Workload von zwei Tabellen-Joins betrug die Performancesteigerung 25%. Es wurde daher nachgewiesen,

33 Kapitel 3. State of the Art 21 dass eine explizite Verteilung der Objekte auf den Platten eine Verbesserung der Performance zur Folge hat. Abbildung 3.7: Qualitätsvergleich Full Striping mit TS-Greedy aus [SNCD03] 3.4 Self-Tuning Data Placement nach Lee et al. Bisher wurden nur statische Programme und Modelle vorgestellt. Eine Lösung, die zur Laufzeit Umverteilungen der Daten vornimmt, stellen Lee et al. vor [LKO + 00]. Ihre index-basierte Methode zur Reorganisation eines parallelen Datenbanksystems während der Laufzeit ermöglicht eine schnelle und effiziente Migration der Daten. Das Datenbanksystem besteht aus einer Menge von Prozessoreinheiten(PE) mit ihrem eigenen Hauptund physikalischen Speicher. Die Idee besteht darin, eine Zwei-Schichten Indexstruktur eines B+ -artigen Baumes anzulegen, um die Performance für den Datenzugriff und die Migration zu verbessern. Die erste Schicht gibt den Ort(PE) der Daten eines Unterbaumes an. Die zweite Schicht dient als Primärindex in der PE selbst. Die obere Schicht ist auf jedem Knoten repliziert, um keinen Flaschenhals für PE s zu erhalten, die sich nur um die Verwaltung des Indexes kümmern. Die Entwickler geben 4 Hauptaspekte ihrer Strategie an: 1. Die Anzahl der zu migrierenden Daten wird aus den Ästen des Indexes der Quell- PE gewonnen. Dies ermöglicht das Abschneiden eines Zweiges aus dem Quellindex und das Anfügen an den Zielindex auf der Ziel-PE. Die Granularität der Daten kann dynamisch fein durch die Auswahl des Astes auf einem unterschiedlichem Level des Baumes gewählt werden. 2. Die Datenbank migriert die Daten per Bulkload in einen separaten Baum auf der Ziel-PE. Danach kann das DBMS mit nur einem Schritt den Teilbaum am Pri-