Entwicklung eines Workload- Compressing-Index-Wizards für relationale Datenbanken

Transkript

1 Humboldt-Universität zu Berlin Institut für Informatik Diplomarbeit Entwicklung eines Workload- Compressing-Index-Wizards für relationale Datenbanken Benjamin Daeumlich 11. November Gutachter: Prof. Johann-Christoph Freytag 2. Gutachter: Prof. Dr. Ulf Leser Betreuer: Lukas Dölle

2

3 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Begriffsdefinitionen Workload-Compression Indexauswahl DirXWiz SQLIndexWizard Architektur Funktionalität und Einschränkungen Vergleichbare Werkzeuge DB2 Design Advisor Auto Admin für Microsoft SQL Server Workload Compression für Online Index Selection DB2 Grundlagen Statistiken in DB virtuelle Indizes Ausführungspläne Selektivitäten Normalformen für aussagenlogische Formeln Workload-Compression Theoretische Aspekte Partitionierung SELECT-Anfragen i

4 ii INHALTSVERZEICHNIS UPDATE-Anfragen INSERT-Anfragen DELETE-Anfragen Ähnlichkeitsbestimmung der WHERE-Klausel Anfragevektoren Struktur Clustering-Algorithmen Leader-Algorithmus k-means-algorithmus Index-Advisor Bewertung der möglichen Indizes Indexauswahl Theoretische Aspekte Greedy-Algorithmus Dynamische Programmierung Implementation Programmablauf Konfiguration Programmaufruf Evaluierung Zugrunde liegende Daten und Anfragen TPC-H Anfragegenerator Testdaten und Testsystem Workload-Compression-Komponente Vergleich der Methoden zur Ähnlichkeitsbestimmung Evaluierung des Schwellenwertes des Leader-Algorithmus Vergleich der Clustering-Algorithmen Index-Advisor Funktionalität Vergleich der Algorithmen für die Indexauswahl

5 INHALTSVERZEICHNIS iii 6.4 Vergleich mit dem DB2 Design Advisor Zusammenfassung der Ergebnisse Zusammenfassung 85 A Kurzbeschreibung der Implementation 87 A.1 Paketbeschreibung A.2 Klassendiagramme B Tabellen mit Testergebnissen 95 B.1 Indexkonfigurationen B.2 Schwellenwerte des Leader-Algorithmus C Inhalt der beiliegenden CD 98

6 Abbildungsverzeichnis 2.1 Funktionsweise der Workload-Compression Beispiel für ein LDAP-Verzeichnis Architektur des DirXWiz Architektur des SQLIndexWizard Architektur des DB2 Design Advisors Funktionsablauf des DB2 Design Advisors Funktionsweise des Index Selection Tools des Microsoft SQL Servers Beispiel für ein Histogramm Funktionsweise von EXPLAIN Beispiel für einen Ausführungsplan (erzeugt mit DB2) Funktionsablauf der Workload-Compression-Komponente Funktionsablauf des Index-Advisors Funktionsablauf der Implementation TPC-H Schema A.1 Abhängigkeiten der Pakete der Implementation A.2 Abhängigkeiten im Paket application A.3 Abhängigkeiten im Paket clustering A.4 Abhängigkeiten im Paket dbconnection A.5 Abhängigkeiten im Paket filter A.6 Abhängigkeiten im Paket indexadvisor A.7 Abhängigkeiten im Paket querygen iv

7 ABBILDUNGSVERZEICHNIS v A.8 Abhängigkeiten im Paket util A.9 Abhängigkeiten im Paket workload

8 Tabellenverzeichnis 2.1 Werteverteilung für die Spalte Preis Systemtabellen und Spalten von RUNSTATS aktualisiert Systemtabellen und Spalten mit Werten nach Aufruf von RUNSTATS Bestimmung der benötigten Werte für Algorithmus Sel Beispielanfragen für die Partitionierung bei Aggregationen Beispiel für das Rucksack-Problem Beispiel für die dynamische Programmierung Indexbestimmung für die dynamische Programmierung Evalierung der Methoden zur Ähnlichkeitsbestimmung Evaluierung der Nützlichkeit der Workload-Compression Evalierung des Schwellenwertes des Leader-Algorithmus Vergleich der Laufzeiten der Anfragen für verschiedene Schwellenwerte Vergleich der Clustering-Algorithmen Evaluierung der Funktionalität des Index-Advisors Vergleich der Algorithmen für die Indexauswahl Vergleich mit dem DB2 Design Advisor B.1 Indexkonfigurationen der Evaluierung B.2 Evaluierung von Schwellenwert 0,9 des Leader-Algorithmus B.3 Evaluierung von Schwellenwert 0,925 des Leader-Algorithmus B.4 Evaluierung von Schwellenwert 0,95 des Leader-Algorithmus B.5 Evaluierung von Schwellenwert 0,975 des Leader-Algorithmus B.6 Evaluierung von Schwellenwert 1,0 des Leader-Algorithmus vi

9 Algorithmenverzeichnis 1 Selektivitätsberechnung (Sel) Selektivitätsberechnung BETWEEN und IN KNF-Umformung Leader-Algorithmus k-means-algorithmus Bewertung der Indizes Greedy-Algorithmus dynamische Programmierung FPTAS vii

10 Anfrageverzeichnis 1 Beispielanfrage für die Nützlichkeit von Indizes Beispielanfrage für ein Histogramm Beispielanfrage für Frequent Values Beispielanfrage für einen Ausführungsplan Bedeutung der Selektivität für die Ähnlichkeitsbestimmung Beispielanfragen für den Algorithmus Sel Beispielanfragen für die KNF/DNF-Umformung (Teil 1) Beispielanfragen für die KNF/DNF-Umformung (Teil 2) Struktur einer SELECT-Anfrage Beispielanfragen für die Partitionierung der Aggregatfunktion COUNT Beispielanfragen für die Partitionierung von Joins Beispielanfragen für die Partitionierung der GROUP BY-Klausel Beispielanfragen für die Partitionierung der ORDER BY-Klausel Struktur einer UPDATE-Anfrage Beispielanfragen für die Partitionierung einer UPDATE-Anfrage Struktur einer INSERT-Anfrage Struktur einer DELETE-Anfrage Beispielanfragen für Anfragevektoren Beispielanfragen für den Fehler bei Variante Beispielanfragen für den Fehler bei Variante Beispielanfragen für die Ähnlichkeitsbestimmung anhand der Struktur Beispielanfrage für das Problem mit benutzerdefinierten Indizes viii

11 Kapitel 1 Einleitung In einem modernen Datenbankmanagementsystem (im Folgenden DBMS genannt) werden verschiedene Methoden zur Leistungssteigerung verwendet, sodass die Kosten für die Ausführung von Anfragen gesenkt werden. Dies ist gerade in der heutigen Zeit besonders wichtig, da die Datenmengen permanent steigen. Für große Datenbanken werden Administratoren eingesetzt, die durch das Setzen verschiedener Parameter für die Leistungssteigerung verantwortlich sind. Es ist wünschenswert, diese Maßnahmen so weit wie möglich zu automatisieren. Eine Möglichkeit, die Leistung eines DBMS zu steigern, ist die Benutzung von Indizes. Allerdings muss die Indexauswahl sorgfältig durchgeführt werden, da Indizes zwar Selektionsanfragen beschleunigen, aber Modifikationsanfragen auch verlangsamen können. Dies liegt daran, dass bei Modifikation der Daten auch die zum Teil sehr komplexen Indexstrukturen modifiziert werden müssen. Außerdem steht im Allgemeinen auch nur ein begrenzter Speicherplatz für die Erstellung von Indizes zur Verfügung. Das Problem der Indexauswahl, welches seit den 70er Jahren besonders für relationale DBMS studiert worden ist, lässt sich auf das Rucksack-Problem zurückführen, welches NP-vollständig ist. Es existieren in der Praxis Approximationsalgorithmen, welche eine gute Lösung liefern. Grundlage für die Indexauswahl ist eine (zu erwartende) Menge von Anfragen, welche unter Umständen sehr groß sein kann. Allerdings kann davon ausgegangen werden, dass in dieser Menge zum Teil ähnliche Anfragen vorhanden sind, für die 1

12 2 KAPITEL 1. EINLEITUNG gleiche Indizes verwendet werden, welche einen ähnlichen Nutzen versprechen. Somit würde es ausreichen, Gruppen von ähnlichen Anfragen zu bilden und nur jeweils einen Repräsentanten einer Gruppe als Grundlage für die Indexauswahl zu verwenden. Dieses Vorgehen wird Workload-Compression genannt und kann die Indexauswahl erheblich beschleunigen. In dieser Diplomarbeit wird ein Index-Wizard für relationale Datenbanken entwickelt, welcher im Folgenden SQLIndexWizard genannt wird. Bevor die Indexauswahl stattfindet, wird die zugrunde liegende Menge von Anfragen bezüglich der Nützlichkeit von Indizes komprimiert (Workload-Compression). Der SQLIndexWizard gibt letztendlich eine Empfehlung ab, welche Indizes erstellt bzw. gelöscht werden müssen, um die Leistung bezüglich der gegebenen Anfragen möglichst optimal zu steigern, ohne eine vorgegebene Speicherplatzbeschränkung zu überschreiten. Dazu werden im zweiten Kapitel Grundlagen geschaffen, die im weiteren Verlauf der Arbeit eine bedeutende Rolle spielen. Es werden unter anderem wichtige Begriffe eingeführt, die Architektur und Funktionalität des SQLIndexWizard beschrieben, vergleichbare Werkzeuge betrachtet und auf die verwendeten Konzepte des DBMS DB2 von IBM eingegangen, welches als Beispielsystem für den SQLIndexWizard benutzt wurde. Im dritten Kapitel wird die erste Komponente des SQLIndexWizard beschrieben, welche für Workload-Compression verantwortlich ist. Dazu wird ein Ähnlichkeitsmaß für Anfragen entwickelt und es werden Algorithmen für die Gruppierung der Anfragen beschrieben. Das vierte Kapitel beschriebt die Indexauswahl, wobei zuerst erläutert wird, wie die Bewertung der nützlichen Indizes durchgeführt wird. Anschließend werden Approximationsalgorithmen eingeführt, die das Problem der Indexauswahl (Index-Selection-Problem) lösen. Im fünften Kapitel wird die Implementation des SQLIndexWizard beschrieben. Es werden der Programmablauf dargestellt und die Konfiguration des Programms beschrieben. Die Evaluierung des SQLIndexWizard findet im darauf folgenden Kapitel statt. Es werden zuerst die zugrunde liegenden Testdaten erläutert und anschließend alle Komponenten des SQLIndexWizard evaluiert. Abschließend wird einen Zusammenfassung über die Ergebnisse dieser Arbeit gegeben und es wird auf mögliche weiterführende Arbeiten eingegangen. Der SQLIndexWizard basiert auf einem System, welches für das LDAP-DBMS

13 3 der Firma Siemens (DirX-System) entwickelt wurde. Dieses System, der DirXWiz, führt ebenfalls eine Indexauswahl mit vorangegangener Workload-Compression durch. Eine besondere Herausforderung dieser Arbeit ist demnach die Übertragung der Methoden und Konzepte von der LDAP-Anfragesprache auf eine relationale Anfragesprache, wobei in dieser Arbeit die Sprache SQL verwendet wird.

14 4 KAPITEL 1. EINLEITUNG

15 Kapitel 2 Grundlagen In diesem Kapitel werden Grundlagen geschaffen, welche für die folgenden Kapitel dieser Arbeit benötigt werden. Zuerst werden Begriffsdefinitionen vorgenommen. Anschließend wird auf den DirXWiz eingegangen, welcher die Grundlage für diese Arbeit liefert. Nachfolgend wird die Architektur des im Zuge dieser Arbeit entwickelten SQLIndexWizard beschrieben und mit der des DirXWiz verglichen. Im darauf folgenden Abschnitt werden vergleichbare Werkzeuge aus der Literatur näher untersucht. Da der SQLIndexWizard für das relationale DBMS DB2 der Firma IBM entwickelt wird, werden zudem Grundlagen für dieses DBMS geschaffen, wobei insbesondere Systemtabellen, Ausführungspläne und virtuelle Indizes näher erläutert werden. Weiterhin werden für den SQLIndexWizard Selektivitäten benötigt, auf deren Berechnung im Anschluss eingegangen wird. Letztendlich wird die Umformung von aussagenlogischen Formeln eine Normalform (konjunktive bzw. disjunktive Normalform) beschrieben, welche für eine einheitliche Repräsentation der Anfragen benötigt wird. 2.1 Begriffsdefinitionen Im Verlauf dieser Arbeit werden einige Begriffe verwendet, welche in diesem Abschnitt definiert werden. Dabei handelt es sich insbesondere um die Begriffe Workload-Compression und Indexauswahl. 5

16 6 KAPITEL 2. GRUNDLAGEN Workload-Compression In diesem Abschnitt wird der Begriff der Workload-Compression eingeführt. Im Kontext dieser Arbeit ist ein Workload W = {q 1,..., q n } eine Menge von SQL-Anfragen q i, wobei es sich um SELECT-, DELETE-, INSERT- oder UPDATE-Anfragen handelt. Diese Anfragen dienen als Eingabe für eine Anwendung A, welche ein Ergebnis R erzeugt. Ziel der Workload-Compression ist es, ein Workload W = {q 1,..., q m } mit m n zu erzeugen, welches ebenfalls als Eingabe für die Anwendung A verwendet werden kann. Dieses Vorgehen wird in Abbildung 2.1 skizziert: Abbildung 2.1: Funktionsweise der Workload-Compression 1 Das resultierende Ergebnis R muss dem Ergebnis R möglichst ähnlich sein. Weiterhin muss die Gesamtlaufzeit zur Berechnung von R (Laufzeit für die Workload- Compression plus Laufzeit für die Anwendung) geringer sein als die Laufzeit für die Berechnung von R. Durch die Komprimierung des initialen Workloads W wird somit die Ausführung der Anwendung beschleunigt, weil die Größe der Eingabe für diese Anwendung verkleinert wird. Die Anwendung A in dieser Arbeit ist die Indexauswahl. Das Ergebnis R muss in diesem Fall mit dem Ergebnis R nahezu übereinstimmen, sodass beide Ergebnisse annähernd den gleichen Nutzen haben. In Kapitel 3 wird beschrieben, wie genau die Workload-Compression in dieser Arbeit durchgeführt wird Indexauswahl Das Problem der Indexauswahl (Index-Selection-Problem) wird in diesem Abschnitt beschrieben. Zuerst muss dafür allerdings eingeführt werden, was ein Index in einem DBMS ist und welchen Nutzen er dafür hat. 1 Abbildung aus [CGN02]

17 2.1. BEGRIFFSDEFINITIONEN 7 In einem Datenbanksystem werden Tupel im Allgemeinen in Dateien auf einem Speichermedium gespeichert, wobei eine Datei aus mehreren Seiten besteht, welche wiederum mehrere Tupel enthalten. Wenn das DBMS also ein bestimmtes Tupel liest, muss die gesamte Seite, auf der sich das Tupel befindet, in den Hauptspeicher geladen werden. Wenn eine Selektionsanfrage wie beispielsweise Anfrage 1 (Q 1 ) bearbeitet wird, müssen alle Seiten der Datei, in der die Tabelle A gespeichert wurde, in den Hauptspeicher eingelesen werden, um die Tupel mit Attributwert 100 im Attribut A.Alter zu ermitteln. Bei großen Tabellen kann das Durchsuchen der Seiten sehr aufwendig werden. Somit wurden Datenstrukturen entwickelt, welche den Zugriff beschleunigen. Q1 = SELECT FROM A WHERE A.ALTER = 100; Anfrage(n) 1: Beispielanfrage für die Nützlichkeit von Indizes Ein Index ist eine spezielle Datenstruktur, welche eine Menge von Attributwerten auf eine Menge von Tupel-IDs abbildet, wobei ein Tupel über die Tupel-ID eindeutig identifiziert werden kann. Die Tupel-ID enthält im Allgemeinen die Seite und die Position des Tupels innerhalb der Seite, in der sich das Tupel befindet. Werden also bei Selektionsanfragen Tupel mit bestimmten Attributwerten gesucht, kann ein Index auf dem entsprechenden Attribut diese Anfragen erheblich beschleunigen. Auch Anfragen mit Joins können beschleunigt werden, da durch Indizes auf den Join-Attributen die passenden Join-Partner schneller gefunden werden können. Allerdings bringen Indizes auch Nachteile mit sich. Bei Modifikationsanfragen müssen nicht nur die Tupel geschrieben werden, sondern es müssen auch die Indizes verändert werden, welche auf der zu modifizierenden Tabelle existieren. Das Problem der Indexauswahl besteht nun darin, bezüglich der Geschwindigkeit des DBMS eine optimale Menge von Indizes (im Folgenden Indexkonfiguration genannt) zu finden, wobei dafür im Allgemeinen eine bestimmte Speicherkapazität nicht überschritten werden darf. Es dürfen nicht zu viele Indizes angelegt werden, da dadurch Modifikationsanfragen zu langsam ausgeführt werden bzw. zu viel Speicherplatz verbraucht wird, aber auch nicht zu wenige, da dann Selektionsanfragen zu langsam ausgeführt werden.

18 8 KAPITEL 2. GRUNDLAGEN Es ist allerdings unmöglich, eine optimale Konfiguration ohne Einschränkungen zu finden, da dafür die Anfragen, welche in Zukunft an das DBMS gestellt werden, bekannt sein müssen. Üblicherweise werden in der Vergangenheit gestellte Anfragen als Grundlage verwendet, um eine optimale Indexkonfiguration zu finden. Da im Allgemeinen eine Speicherplatzbeschränkung für die zu erstellenden Indizes existiert, entspricht das Problem der Indexauswahl dem bekannten Rucksack-Problem. Jedem Index können die Kosten durch den Speicherplatzverbrauch und der Nutzen bezüglich der gegebenen Anfragen zugewiesen werden. Da das Rucksack-Problem NP-vollständig ist, kann eine optimale Indexkonfiguration nicht durch einen Algorithmus mit polynomieller Laufzeit bestimmt werden, vorausgesetzt P NP. Allerdings existieren Approximationsalgorithmen, welche in Kapitel 4 vorgestellt werden. Weitere Begriffe werden im Verlauf dieses Kapitels bzw. an geeigneter Stelle eingeführt. 2.2 DirXWiz Als Grundlage für den zu entwerfenden SQLIndexWizard für relationale Datenbanken wurde der DirXWiz verwendet. Dieser Index-Wizard wurde für den DirX-LDAP-Server entwickelt, wobei DirX ein Produkt der Siemens AG ist, welches große Mengen von hierarchischen Daten mit Hilfe von Datenbanktechnologien verwaltet. Die Anfragen basieren dabei auf LDAP (Lightweight Directory Access Protokoll). Daten werden in einem so genannten LDAP-Verzeichnis gespeichert. Ein LDAP- Verzeichnis besteht aus baumartig angeordneten Objekten (Einträge) mit getypten Attributen, welche die Daten darstellen. Ein Beispiel für ein LDAP-Verzeichnis zeigt Abbildung 2.2. Die Knoten (als Kreise dargestellt) beinhalten Attribut-Wert-Kombinationen. In jedem Hierarchielevel gibt es ein ausgezeichnetes Attribut, dessen Wert im aktuellen Teilbaum eindeutig ist. Eine LDAP-Suchanfrage besteht aus drei Teilen:

19 2.2. DIRXWIZ 9 Abbildung 2.2: Beispiel für ein LDAP-Verzeichnis 2 1) Starteintrag (Base): spezifiziert den Starteintrag, der die Wurzel des Teilbaumes darstellt, welcher durchsucht werden soll 2) betrachtete Knotenmenge: Suche nur in angegebenem Eintrag (Baselevel), in den direkten Kindknoten des Eintrags (Onelevel) oder im gesamten Teilbaum mit dem spezifizierten Eintrag als Wurzel (Subtree) 3) Suchfilter: boolescher Ausdruck, den die Einträge der Ergebnismenge erfüllen sollen (Verknüpfungsoperatoren: UND (&&), ODER ( ) und NOT (!)) Der Suchfilter einer LDAP-Suchanfrage ist dabei ähnlich zur WHERE-Klausel einer SQL-Anfrage. Es existieren aber keine Tabellen wie bei SQL. Die Eingabe für den DirXWiz ist eine Menge von Anfragen (engl. Workload). Ziel ist es, diejenigen Indizes zu berechnen, die für das Workload der Eingabe am nützlichsten sind. Es wird davon ausgegangen, dass in der Zukunft gestellte Anfragen den Anfragen aus dem Workload ähnlich sind, da die Anfragen der Eingabe im Allgemeinen aus Logdateien erzeugt werden. Ist diese Voraussetzung nicht gegeben, sind die berechneten Indizes im Allgemeinen nicht nützlich, da z. B. andere Tabellen angefragt werden. Die Architektur des DirXWiz ist in Abbildung 2.3 dargestellt. Er besteht aus zwei Hauptkomponenten, dem Log Analyzer und dem Index Advisor. 2 Abbildung aus [DHR08]

20 10 KAPITEL 2. GRUNDLAGEN Abbildung 2.3: Architektur des DirXWiz 3 Der Log Analyzer soll aus den gegebenen Anfragen (initiales Workload) ein repräsentatives Workload (komprimiertes Workload) generieren, welches als Eingabe für den Index Advisor dient. Dazu werden die Anfragen in Gruppen eingeteilt, wobei alle Anfragen einer Gruppe ähnlich zueinander sind. Dazu wurde ein Ähnlichkeitsmaß für verschiedene Anfragen definiert. Ein Repräsentant jeder Gruppe wird anschließend dem repräsentativen Workload hinzugefügt. Dadurch werden überflüssige Anfragen eliminiert. Der Index Advisor ist für die Indexauswahl zuständig. Er bewertet alle Indizes, die für die Anfragen des komprimierten Workloads benutzt werden könnten. Dazu wird der Optimierer des DirX-Systems in einem speziellen RECOMMEND-MODE aufgerufen, in dem die Anfragen nicht ausgeführt werden, sondern lediglich der Nutzen der benutzten Indizes abgeschätzt wird. Da für jede Anfrage der Optimierer für die Berechnung des Nutzens der Indizes angesprochen werden muss, wird jetzt deutlich, weshalb eine Komprimierung des initialen Workloads nützlich ist, denn es werden so Aufrufe des Optimierers eingespart. Anschließend wird aus allen möglichen Indi- 3 Abbildung aus [DHR08]

21 2.3. SQLINDEXWIZARD 11 zes die Menge berechnet, die den maximalen Gesamtnutzen für das komprimierte Workload enthält. Weiterhin werden Nebenbedingungen wie Speicherplatzbeschränkungen erfüllt. 2.3 SQLIndexWizard Dieser Abschnitt gibt einen Überblick über den SQLIndexWizard, welcher in dieser Arbeit entwickelt wird. Es wird zum einen auf die Architektur eingegangen und zum anderen wird die Funktionalität inklusive Einschränkungen beschrieben Architektur Der Ausgangspunkt für den SQLIndexWizard ist der DirXWiz. Die Ideen und Konzepte des DirXWiz wurden dafür größtenteils übernommen aber auch erweitert. Die Herausforderung besteht darin, benutzte Konzepte von der LDAP-Anfragesprache auf eine relationale Anfragesprache zu übertragen. Dafür wird die Sprache SQL verwendet. Weiterhin müssen die Mechanismen des DirX-DBMS auf ein relationales DBMS übertragen werden. In dieser Arbeit wird dafür das System DB2 von IBM verwendet (Version 9.5 für Linux, Unix und Windows). Eine Übertragung der Konzepte und Mechanismen soll aber auch möglichst leicht auf andere relationale DBMS möglich sein. Die Architektur des SQLIndexWizard wird in Abbildung 2.4 skizziert. Dabei weisen die Architekturen des SQLIndexWizard und DirXWiz große Gemeinsamkeiten auf, da der DirXWiz als Basis für den SQLIndexWizard dient. Dies wird aus den Abbildungen 2.3 und 2.4 deutlich. Der SQLIndexWizard besteht wie der DirXWiz ebenfalls aus zwei Hauptkomponenten, der Workload-Compression-Komponente und dem Index-Advisor. Die Workload-Compression-Komponente folgt dabei der Idee des Log Analyzers des DirXWiz. Es werden SQL-Anfragen eingelesen (initiales Workload) und daraus wird anschließend ein repräsentatives Workload (komprimiertes Workload) generiert. Die genaue Funktionsweise der Workload-Compression-Komponente wird in Kapitel 3 beschrieben. Motiviert durch den Index Advisor des DirXWiz ergibt sich die Funktionsweise des

22 12 KAPITEL 2. GRUNDLAGEN Abbildung 2.4: Architektur des SQLIndexWizard Index-Advisors des SQLIndexWizard. Es werden zu den Anfragen des komprimierten Workloads die nützlichen Indizes bestimmt und bewertet. Anschließend wird die Indexmenge mit dem größten Gesamtnutzen für die Anfragen des komprimierten Workloads ermittelt, wobei die Nebenbedingung der Speicherplatzbeschränkung eingehalten wird. In Kapitel 4 wird diese Komponente genauer beschrieben. Beide Komponenten kommunizieren mit dem relationalen DBMS DB2, wobei insbesondere die Systemtabellen und der Optimierer aufgerufen werden Funktionalität und Einschränkungen In diesem Abschnitt wird zum einen die Funktionalität des SQLIndexWizard aufgezeigt und zum anderen werden Einschränkungen festgelegt. Funktionalität Der SQLIndexWizard weist kurz gefasst die folgende Funktionalität auf:

23 2.3. SQLINDEXWIZARD 13 Einlesen von SQL-Anfragen (initiales Workload) Komprimierung des initialen Workloads (komprimiertes Workload), dabei Verwendung verschiedener Verfahren zur Ähnlichkeitsbestimmung und zur Gruppierung Ermittlung und Bewertung der nützlichen Indizes für die Anfragen des komprimierten Workloads Auswahl der bestmöglichen Indexkonfiguration unter Berücksichtigung der Speicherplatzbeschränkung, dabei Verwendung verschiedener Algorithmen Einschränkungen Folgende Einschränkungen werden für den SQLIndexWizard festgelegt: 1) Teil der Sprache SQL bei der Workload-Compression keine Unteranfragen nur Equi-Join Aggregationen nur auf Spalten 2) nur Einattributindizes werden empfohlen 3) keine Berücksichtigung von Spalten vom Typ VARCHAR, CHAR 4) keine Berücksichtigung von Modifikationsanfragen bei der Indexauswahl Die erste Einschränkungen ist bedingt durch die Mächtigkeit des verwendeten Parsers für die Sprache SQL, da dieser die oben genannten Sprachelemente nicht unterstützt. Dies gilt allerdings nur für die Workload-Compression. Anfragen, die der benutzte Parser nicht parst, werden trotzdem zum komprimierten Workload hinzugefügt, sodass sie später bei der Indexauswahl berücksichtigt werden. Weiterhin wird durch diese Einschränkung beispielsweise die Ähnlichkeitsbestimmung für Anfragen vereinfacht. Die verwendeten Methoden der Workload-Compression basieren auf der Verwendung von Einattributindizes. Dies liegt daran, dass bei Berücksichtigung der

24 14 KAPITEL 2. GRUNDLAGEN Mehrattributindizes sehr viele Indizes betrachtet werden müssen (für eine Tabelle mit n Spalten n n! k=1 [VZZ + 00]). Dadurch würde das Problem sehr komplex (n k)! werden und somit empfiehlt der SQLIndexWizard keine Mehrattributindizes. Da Selektivitäten für Attribute vom Typ VARCHAR bzw. CHAR, vor allem bei der Benutzung des LIKE-Operators, nur schwierig berechnet bzw. abgeschätzt werden können, werden Spalten dieser Datentypen nicht unterstützt. Gleiches gilt ebenfalls für komplexe Typen wie BLOB oder CLOB. Modifikationsanfragen werden nicht berücksichtigt, da keine Möglichkeit gefunden wurde, den negativen Nutzen von Modifikationen auf die Indizes vom DBMS DB2 zu erhalten. Wenn eine Modifikationsanfrage gestellt wird, ist es für den Optimierer von DB2 nicht von Bedeutung, ob Indizes auf Attributen der angefragten Tabelle existieren oder nicht. Die Kosten für den Optimierer sind in beiden Fällen identisch, was im Allgemeinen allerdings nicht gilt. 2.4 Vergleichbare Werkzeuge Es existieren in der Praxis bereits Werkzeuge, die eine ähnliche Funktionalität wie der SQLIndexWizard zur Verfügung stellen. Dabei handelt es sich sowohl um Werkzeuge für die Workload-Compression als auch Werkzeuge für die Indexauswahl DB2 Design Advisor Im relationalen DBMS DB2 ist auch ein Index-Advisor implementiert, welcher erstmals in [VZZ + 00] beschrieben wurde und DB2 Design Advisor genannt wird. Er erhält als Eingabe eine Menge von Anfragen (Workload) und gibt dann eine Empfehlung für zu erstellende und zu löschende Indizes aus. Der Vorteil des DB2 Design Advisors ist es, dass er im Gegensatz zum SQLIndexWizard auch Mehrattributindizes betrachtet. Weiterhin werden Modifikationsanfragen berücksichtigt und es wird die komplette Sprache SQL unterstützt. Die Architektur des Design Advisors von DB2 skizziert Abbildung 2.5. Er kann entweder über ein Kommandozeilenwerkzeug oder über ein graphisches Interface ausgeführt werden, wobei letzteres ebenfalls das Kommandozeilenwerkzeug benutzt.

25 2.4. VERGLEICHBARE WERKZEUGE 15 Abbildung 2.5: Architektur des DB2 Design Advisors 4 Das Werkzeug benutzt dabei spezielle Modi des Optimierers. Die Eingabe für den Prozess der Indexauswahl sind neben den Anfragen vorhandene Statistiken auf der Datenbank (siehe Abschnitt 2.5.1). Die Indexauswahl läuft in vier Schritten ab, welche in Abbildung 2.6 veranschaulicht sind. Der erste Schritt ( get workload ) liest das Workload ein. Im zweiten Schritt ( get candidates ) werden mögliche Indizes für das Workload generiert. Dazu wird jede Anfrage der Eingabe in einem speziellen Modus des Optimierers (RECOMMEND INDEXES) ausgeführt, in dem zunächst nach bestimmten Heuristiken virtuelle Indizes (siehe Abschnitt 2.5.2) in das Datenbankschema integriert werden, welche für die entsprechende Anfrage nützlich sein können. Anschließend werden die virtuellen Indizes des besten Ausführungsplans für die entsprechende Anfrage der Menge der möglichen Indizes ( candidates ) hinzugefügt. Im dritten Schritt ( try candidates ) werden alle möglichen Indizes, welche im ersten Schritt generiert wurden ( candidates ), bewertet, wobei der Nutzen die Differenz zwischen den Kosten der Anfrage mit existierenden Indizes und den Kosten der Anfrage mit virtuellen Indizes angibt. Dafür wird der Optimierer ebenfalls in einem 4 Abbildung aus [VZZ + 00]

26 16 KAPITEL 2. GRUNDLAGEN Abbildung 2.6: Funktionsablauf des DB2 Design Advisors 5 Speziellen Modus (EVALUATE INDEXES) ausgeführt. Der vierte Schritt ( output results ) generiert die Ergebnismenge. Es werden die virtuellen Indizes zunächst nach dem Quotienten zwischen Nutzen und Größe sortiert. Die besten Indizes werden dann zur vorläufigen Ergebnismenge hinzugefügt, bis eine Speicherplatzbeschränkung erreicht wird. Anschließend werden von der vorläufigen Ergebnismenge leicht veränderte Varianten erzeugt, welche ebenfalls getestet werden. Die beste Variante, die bis zum Erreichen einer Zeitbeschränkung gefunden wurde, ist die endgültige Lösung. Das Workload der Eingabe wird im DB2 Design Advisor allerdings nicht komprimiert. In Kapitel 6.4 wird der DB2 Design Advisor mit dem SQLIndexWizard verglichen Auto Admin für Microsoft SQL Server Auch Microsoft hat einen Index-Advisor entwickelt, welcher in [CN97] beschrieben wird. Er ist Bestandteil des Auto Admin Werkzeugs des Microsoft SQL Servers. Die Funktionalität entspricht weitestgehend der des DB2 Design Advisors, allerdings werden die möglichen nützlichen Indizes mit einer anderen Methode ausgewählt. 5 Abbildung aus [ZRL + 04]

27 2.4. VERGLEICHBARE WERKZEUGE 17 Die Funktionsweise des Index Selection Tools des Microsoft SQL Servers wird in Abbildung 2.7 skizziert: Abbildung 2.7: Funktionsweise des Index Selection Tools des Microsoft SQL Servers 6 Die Indexauswahl läuft in drei Schritten ab, wobei sich diese iterativ wiederholen, da zuerst nur Einattributindizes und nach und nach auch Mehrattributindizes betrachtet werden. Der erste Schritt ( Candidate index selection ) wählt vielversprechende nützliche Indexkonfigurationen aus. Dafür wird ein Workload von n Anfragen in n Workloads mit jeweils einer Anfrage aufgeteilt. Die Kandidaten werden dann für jedes der n Workloads ermittelt und die Vereinigung der Kandidaten aller n Workloads bildet die Menge der möglichen Indizes ( candidates ). Im zweiten Schritt ( Configuration Enumeration ) werden die in Schritt 1 ermittelten Indizes bewertet und die besten Indizes werden ausgewählt. Dabei wird mit zwei Komponenten kommuniziert: Die erste Komponente ( Cost Evaluation ) soll dabei Optimiereraufrufe einsparen, indem frühere Kostenberechnungen für die aktuellen 6 Abbildung aus [CN97]

28 18 KAPITEL 2. GRUNDLAGEN Berechnungen herangezogen werden. Die zweite Komponente ( What-if Index Creation ) kann mit virtuellen Indizes in DB2 verglichen werden, denn es werden hypothetische Indizes für die Kostenberechnungen betrachtet, für die lediglich Statistiken existieren. Die Bewertung erfolgt folgendermaßen: Die Systemkataloge werden für die hypothetischen Indizes zuerst geändert, der Optimierer führt die Anfragen anschließend in einem bestimmten Modus aus, in der nur die Kosten berechnet werden, und zuletzt werden die Änderungen in den Systemtabellen rückgängig gemacht. Im letzten Schritt ( Multi-column Index Generation ) werden Mehrattributindizes generiert, basierend auf den in Schritt 2 erzeugten Indizes. Diese werden dann zu den möglichen Indizes hinzugefügt. Anschließend wird mit diesen Indizes wieder mit dem ersten Schritt begonnen, sodass die neu erzeugten Indizes erneut bewertet werden. Dieses iterative Vorgehen, in dem zuerst Einattributindizes und erst anschließend Mehrattributindizes erzeugt werden, ist der entscheidende Unterschied zum DB2 Design Advisor, in dem alle Indizes in einem Schritt erzeugt werden ( get candidates, siehe Abbildung 2.6). Auch in diesem Werkzeug werden lediglich Indizes empfohlen, es wird jedoch keine Workload-Compression durchgeführt Workload Compression für Online Index Selection In [Kol08] wird eine Methode für die Komprimierung von Workloads beschrieben, welche auch in dieser Arbeit berücksichtigt wird. Dabei werden Anfragen anhand ihrer Struktur miteinander verglichen. Nur strukturell identische Anfragen sind sich dabei ähnlich, Anfragen mit unterschiedlicher Struktur sind sich komplett unähnlich. Der Ansatz zur Ähnlichkeitsbestimmung wird in Kapitel näher beschrieben. Der verwendete Algorithmus zur Gruppierung der Anfragen wird sowohl im DirX- Wiz als auch im SQLIndexWizard verwendet. Es wird allerdings nur ein Verfahren zur Workload-Compression beschrieben, auf die Indexauswahl wird nicht näher eingegangen. Es wurde festgestellt, dass bereits verschiedene Ansätze sowohl für die Workload- Compression als auch für die Indexauswahl existieren. Allerdings werden in keinem Werkzeug beide Probleme gelöst.

29 2.5. DB2 GRUNDLAGEN DB2 Grundlagen Da im SQLIndexWizard das relationale DBMS DB2 verwendet wird, wird in diesem Abschnitt auf die Funktionalität von DB2 eingegangen, welche in dieser Arbeit benutzt wird. Dabei handelt es sich um Funktionalität, die im Folgenden sowohl für die Workload-Compression-Komponente als auch für den Index-Advisor benötigt wird. Dazu gehören sowohl Statistiken, die für die Berechnung von Selektivitäten von Bedeutung sind, als auch Ausführungspläne und virtuelle Indizes, welche für die Indexauswahl benötigt werden. Es werden insbesondere das Kommando RUNSTATS, welches Statistiken erzeugt, und die EXPLAIN-Tabellen, welche Information über die Kosten und die benutzten Indizes einer Anfrage liefern, verwendet. Weiterhin ist das Konzept der virtuellen Indizes von entscheidender Bedeutung für diese Arbeit Statistiken in DB2 Statistiken werden sowohl für die Berechnungen von Selektivitäten als auch für die Kostenberechnungen des Optimierers benötigt. Es handelt sich dabei beispielsweise um die Anzahl der Tupel in einer Tabelle, um die Anzahl von verschiedenen Tupeln einer Spalte einer Tabelle oder um die Verteilung von Werten einer Spalte. Daraus lässt sich unter anderem abschätzen, wie oft ein bestimmter Spaltenwert (Attributwert) in einer Tabelle auftritt. Es lässt sich somit berechnen, wie viele Tupel gelesen werden müssen, wenn dieser Wert in der WHERE-Klausel einer Anfrage selektiert wird. Diese Statistiken müssen in DB2 allerdings erst erzeugt werden und sollten auch nach Möglichkeit regelmäßig aktualisiert werden, da sich die Daten in den Tabellen durch Update- und Einfügeoperationen permanent ändern können. RUNSTATS Die Erzeugung der Statistiken erfolgt mit dem Kommando RUNSTATS, welches mit verschiedenen Optionen aufgerufen werden kann. In dieser Arbeit werden sowohl Tabellenstatistiken für die Berechnung von Selektivitäten als auch Indexstatistiken für die Bewertung der Indizes benötigt. Dazu wird RUNSTATS mit dem Kommando RUNSTATS ON TABLE <Tabellenname> ON ALL COLUMNS WITH DISTRIBUTION AND INDEXES ALL; aufgerufen. Die durch RUN-

30 20 KAPITEL 2. GRUNDLAGEN STATS erzeugten Daten in den Systemtabellen werden in Abschnitt aufgezeigt. Histogramme Das Kommando RUNSTATS erzeugt mit dem oben genannten Aufruf auch Statistiken für die Verteilung der Daten, die so genannten Histogramme. Ein Histogramm ist die graphische Darstellung der Häufigkeit von Messwerten. Dabei werden nach der Größe sortierte Daten in k Klassen (Quantile) eingeteilt, wobei über jede dieser Klassen ein Rechteck errichtet wird, dessen Fläche proportional zur klassenspezifischen Häufigkeit ist. Weiterhin wird davon ausgegangen, dass in jedem dieser Klassen eine Gleichverteilung auftritt. In einem DBMS können somit Verteilungsstatistiken berechnet werden. Es lassen sich insbesondere Selektivitäten für Bereichsanfragen bestimmen. In DB2 werden equi-depth -Histogramme verwendet, das heißt, jedes Quantil hat die gleiche Anzahl von Werten. Diese Histogramme werden in der Systemtabelle SYSCOLDIST gespeichert. Folgendes Beispiel soll das Konzept des Histogramms veranschaulichen: Beispiel 2.1 Gegeben sei eine Tabelle Auto mit einer Spalte Preis vom Typ Integer. Diese beinhaltet 250 Tupel, wobei verschiedene Werte existieren. Dabei tritt folgende Werteverteilung auf: Preis Anzahl Tabelle 2.1: Werteverteilung für die Spalte Preis Ein equi-depth -Histogramm mit 10 Quantilen für Beispiel 2.1 wird in Abbildung 2.8 graphisch dargestellt:

31 2.5. DB2 GRUNDLAGEN 21 Abbildung 2.8: Beispiel für ein Histogramm Es wird nun folgende Anfrage gestellt: Q1 = SELECT FROM Auto WHERE P r e i s <= 5 0 ; Anfrage(n) 2: Beispielanfrage für ein Histogramm Wenn die Anzahl der Tupel bestimmt werden soll, auf die das Prädikat der WHERE- Klausel von Q1 (P reis 50) zutrifft, würde bei einer angenommenen Gleichverteilung der Werte die Anzahl bei 125 liegen. Aus dem Histogramm kann aber eine Anzahl von 237 bestimmt werden (siehe Abschnitt 2.6), welche deutlich näher an der realen Anzahl 243 liegt, die aus der Werteverteilung in Tabelle 2.1 bestimmt werden kann. Dadurch wird deutlich, dass Histogramme bei der Abschätzung von Verteilungen bei Bereichsanfragen unter Umständen sehr nützlich sein können. Frequent Values Das Kommando RUNSTATS erzeugt ebenfalls so genannte Frequent Values. Das sind die Werte einer Spalte, welche am häufigsten in der Datenbank zu finden sind. Diese Werte werden ebenfalls in der Systemtabelle SYSCOLDIST gespeichert und es lassen sich damit insbesondere die Selektivitäten von Punktanfragen auf diese Werte effizient berechnen. Es wird erneut Beispiel 2.1 betrachtet. Angenommen, es wird folgende Anfrage gestellt und es sind zwei Frequent Values (für die Werte 1 und 2 von Preis) bekannt:

32 22 KAPITEL 2. GRUNDLAGEN Q2 = SELECT FROM Auto WHERE P r e i s = 2 ; Anfrage(n) 3: Beispielanfrage für Frequent Values Wird erneut die Anzahl der Werte, auf die das Prädikat der WHERE-Klausel von Q2 (P reis = 2) zutrifft, bestimmt, liefert eine angenommene Gleichverteilung die Anzahl 31 ( 250 ). Dadurch, dass durch die erzeugten Frequent Values die Anzahl der 8 Werte mit Preis gleich 2 bekannt ist, wird der exakte Wert der Anzahl 75 bestimmt. Es wird deutlich, dass Frequent Values für die Abschätzung von Verteilungen bei Punktanfragen sehr nützlich sein können. Systemtabellen Durch den Aufruf von RUNSTATS werden für diese Arbeit relevante Daten in den Systemtabellen erzeugt, welche in Tabelle 2.2 zu finden sind. Wie in der Tabelle zu Systemtabelle Spalten Bedeutung SYSTABLES CARD Anzahl Tupel in den Tabellen SYSCOLUMNS COLTYPE Datentyp der Spalten COLCARD Kardinalität (Anzahl verschiedener Tupel) der Spalten NQUANTILES Anzahl der Quantile der Spalten NMOSTFREQ Anzahl der Frequent Values der Spalten LOW2KEY zweitkleinster Wert der Spalten HIGH2KEY zweitgrößter Wert der Spalten SYSCOLDIST COLVALUE -für ein Quantil: Anfangswert des Quantils -für ein Frequent Value : Wert VALCOUNT -für ein Quantil: Anzahl der Werte im Quantil -für ein Frequent Value : Anzahl der Werte SEQNO Nur für Quantile: Quantilnummer TYPE Q für Quantil, F für Frequent Value SYSINDEXES NLEAF Anzahl der Blätter der Indizes Tabelle 2.2: Systemtabellen und Spalten von RUNSTATS aktualisiert

33 2.5. DB2 GRUNDLAGEN 23 erkennen ist, werden sowohl Statistiken über Tabellen und Spalten in den Systemtabellen SYSTABLES und SYSCOLUMNS als auch Verteilungsstatistiken der Daten in der Systemtabelle SYSCOLDIST erzeugt. Weiterhin werden auch Informationen über Indizes in der Systemtabelle SYSINDEXES gespeichert. Die in Tabelle 2.2 angegebenen Spalten sind nur eine Teilmenge aller Spalten der Systemtabellen. Zumeist werden auch noch Namen wie Tabellenname, Spaltennamen bzw. Indexnamen und weitere Daten gespeichert. Zur Veranschaulichung der Systemtabellen liefert Tabelle 2.3 Daten für die Systemtabellen SYSTABLES, SYSCOLUMNS und SYSCOLDIST für Beispiel 2.1, nachdem das Werkzeug RUNSTATS für die Tabelle Auto ausgeführt wurde. In der Systemtabelle Systemtabelle Spalten und Werte SYSTABLES NAME CARD Auto 250 SYSCOLUMNS NAME TBNAME COLTYPE COLCARD Preis Auto INTEGER 8 NQUANTILES NMOSTFREQ LOW2KEY HIGH2KEY SYSCOLDIST SEQNO COLVALUE VALCOUNT TYPE Q Q Q Q Q Q Q Q Q Q F F Tabelle 2.3: Systemtabellen und Spalten mit Werten nach Aufruf von RUNSTATS

34 24 KAPITEL 2. GRUNDLAGEN SYSTABLES wird gespeichert, dass eine Tabelle Auto mit 250 Tupeln in der Datenbank existiert. Weiterhin liefert die Systemtabelle SYSCOLUMNS die Informationen, dass eine Spalte Preis von Typ INTEGER mit 8 verschiedenen Werten existiert, für die Verteilungsstatistiken mit zehn Quantilen und zwei Frequent Values generiert wurden. Diese Verteilungsstatistiken werden in der Systemtabelle SYSCOLDIST gespeichert. Neben den zwei Frequent Values können auch die zehn Quantile aus Abbildung 2.8 wiedergefunden werden virtuelle Indizes In DB2 können virtuelle Indizes angelegt werden. Dies sind Indizes, die physisch nicht existieren. Es werden lediglich Indexstatistiken für sie generiert, basierend auf den Statistiken der existierenden Tabelle. Die virtuellen Indizes sind für die Indexauswahl von Vorteil, da sie nützliche reale Indizes repräsentieren, ohne dass diese wirklich (physisch) erstellt werden müssen. Daraus resultiert eine enorme Zeitersparnis, da das Anlegen eines virtuellen Indexes nur Sekundenbruchteile dauert. Einen realen Index anzulegen kann hingegen abhängig von den Daten mehrere Stunden dauern. Weiterhin nehmen virtuelle Indizes nur wenig Speicherplatz ein, da für sie keine Indexdatei angelegt wird. Es ist notwendig, das Kommando RUNSTATS für diese Tabellen ausgeführt zu haben, da die Indexstatistiken ansonsten nicht erstellt werden. Die virtuellen Indizes befinden sich in der Tabelle ADVISE_INDEX und werden als Tupel dargestellt. Die Spalten dieser Tabelle sind ähnlich zu denen in der Tabelle für existierende Indizes (SYSINDEXES) Ausführungspläne DB2 erlaubt es, für eine Anfrage einen Ausführungsplan zu erzeugen. Dieser Plan gibt sowohl die Kosten für die Anfrage als auch die verwendeten Indizes aus. Dazu werden so genannt EXPLAIN-Informationen gesammelt, welche in EXPLAIN- Tabellen, die vom Benutzer angelegt werden müssen, abgelegt werden. Eine kurze Übersicht über die Funktionsweise von EXPLAIN liefert Abbildung 2.9.

35 2.5. DB2 GRUNDLAGEN 25 Abbildung 2.9: Funktionsweise von EXPLAIN 7 Für die Erzeugung eines Ausführungsplans werden Informationen aus der Datenbank (Tabellen, Indizes, Statistiken, Konfigurationsparameter), die Abfrage und weitere Optionen an das Optimierungsprogramm übergeben, welches den Ausführungsplan erzeugt. Es wird nun die Anfrage möglicherweise ausgeführt und eine EXPLAIN-Momentaufnahme erzeugt, welche den Ausführungsplan anhand des aktuellen Zustandes der Datenbank repräsentiert. Der Ausführungsplan kann daraus abschließend entweder als Grafik oder auch als Text ausgegeben werden. Für die graphische Ausgabe stellt DB2 das Werkzeug Visual Explain zur Verfügung, für die Ausgabe als Text wird das Werkzeug db2exfmt benutzt. In Abbildung 2.10 wird ein mit Hilfe von DB2 erzeugter Beispielplan dargestellt, links als Graph und rechts als Text. Die zugrunde liegende Anfrage ist die Folgende: Q2 = SELECT FROM SUPPLIER WHERE S_SUPPKEY = 2 ; Anfrage(n) 4: Beispielanfrage für einen Ausführungsplan An den Ausführungsplänen können zum einen die Kosten für eine Anfrage abgelesen werden, zum anderen können aber auch die benutzten Indizes bestimmt werden. In der Abbildung 2.10 wird auf den Index IDX auf dem Attribut 7 Abbildung aus [IBM09]

36 26 KAPITEL 2. GRUNDLAGEN Abbildung 2.10: Beispiel für einen Ausführungsplan (erzeugt mit DB2) S_SUPPKEY zugegriffen und die Gesamtkosten für die Anfrage sind 332,51 Timerons, wobei Timerons die DB2 -spezifische Einheit für die Kosten einer Anfrage darstellen. Eine wichtige Option für die Erzeugung dieser Ausführungspläne ist der EXPLAIN MODE. Der EXPLAIN MODE kann über den Befehl SET CURRENT EXPLAIN MODE <Mode>; verändert werden. Es gibt dabei 8 Modi, wobei die folgenden 3 für diese Arbeit relevant sind: EXPLAIN: Dieser Modus erzeugt Ausführungspläne für ausgeführte Anfragen. Es werden vorhandene Indizes berücksichtigt. Die Anfragen werden dabei jedoch nicht ausgeführt. RECOMMEND INDEXES: Dieser Modus empfiehlt Indizes für ausgeführte Anfragen, welche für diese Anfragen nützlich sein könnten. Die Tabelle ADVISE_INDEX wird mit diesen Indizes gefüllt. Die Anfragen werden dabei nicht ausgeführt. EVALUATE INDEXES: Dieser Modus erzeugt Ausführungspläne für ausgeführte Anfragen. Es werden vorhandene Indizes und virtuelle Indizes berücksichtigt. Die Anfragen werden ebenfalls nicht ausgeführt.

37 2.6. SELEKTIVITÄTEN 27 Die Idee dabei ist es, zuerst den Modus zu setzten, sodass beispielsweise Indizes empfohlen werden soll (Modus RECOMMEND INDEXES), und anschließend die Anfrage auszuführen, sodass dann die für diese Anfrage nützlichen Indizes in die Systemtabelle ADVISE_INDEX eingetragen werden. 2.6 Selektivitäten Ein wichtiges Maß für die Bestimmung der Ähnlichkeit zwischen verschiedenen Anfragen ist die Selektivität. Die Selektivität ist wie folgt definiert: Definition 2.1 (Selektivität) Die Selektivität eines Prädikats P (σ(p)) ist die Anzahl der Tupel, die auf das Prädikat zutreffen, dividiert durch die Anzahl aller Tupel. Sowohl die verwendete Methode im DirXWiz als auch andere Methoden zur Ähnlichkeitsbestimmung aus der Literatur (z. B. [Kol08]) basieren auf Selektivitäten. Weshalb nicht nur die Struktur von Anfragen zur Ähnlichkeitsbestimmung herangezogen werden kann, verdeutlichen folgende zwei einfache Anfragen, welche von der Struktur her bis auf den Wert des Prädikates in der WHERE-Klausel identisch sind. Q1 = SELECT FROM Auto WHERE P r e i s >= 5 0 ; Q2 = SELECT FROM Auto WHERE P r e i s >= 2 ; Anfrage(n) 5: Bedeutung der Selektivität für die Ähnlichkeitsbestimmung Es werden nun erneut die Daten aus Beispiel 2.1 betrachtet. Das Prädikat der WHERE-Klausel von Anfrage Q1 triff nur auf 5 Tupel zu (siehe Tabelle 2.1), wodurch sich eine geringe Selektivität (σ(auto.p reis 50) = 5 = 0.02) ergibt. Für 250 das Prädikat von Anfrage Q2 kommen 150 Tupel in Frage, sodass sich eine hohe Selektivität im Vergleich zu Q1 ergibt (σ(auto.p reis >= 2) = 150 = 0.6). Durch 250 die geringe Selektivität in Q1 ist die Benutzung eines Indexes auf Auto.Preis vermutlich sehr sinnvoll, da dadurch lediglich der Index und 2% der Tabelle gelesen werden müssen. Ohne Benutzung des Indexes müsste die gesamte Tabelle sequentiell gelesen werden. In Q2 hingegen wird durch die hohe Selektivität wohl eher die

38 28 KAPITEL 2. GRUNDLAGEN Tabelle sequentiell gelesen, da auch bei Existenz des Indexes auf Auto.Preis 60% der Tabelle und der Index gelesen werden müssen. Je geringer die Selektivität eines Prädikats ist, desto nützlicher ist also ein Index auf dem Attribut des Prädikates. Die Selektivität eines Prädikats aus der WHERE-Klausel einer SQL-Anfrage lässt sich für die Operatoren =, >, <, und mit folgendem Algorithmus berechnen: Algorithmus 1 Selektivitätsberechnung (Sel) Eingabe: Prädikat aus der WHERE-Klausel (Attribut, Operator, Wert) Ausgabe: Selektivität if Punktanfrage then if Wert FrequentValues then else #W erte = F requentv alue(w ert) Finde Quantil, in dem sich Wert befindet #W erte = end if if Operator ist!= then #W ertequantil W ertebereich KardinalitaetSpalte W ertebereichquantil #W erte = #T upel #W erte end if else if Bereichsanfrage then Finde Quantil, in dem sich Wert befindet if Operator {<, } then #W erte = #W ertequantilanfang + else if Operator {>, } then #W erte = #T upel end if end if return #W erte #T upel (#W ertequantilanfang + (W ert W ertquantilanfang) #W ertequantil W ertebereichquantil (W ert W ertquantilanfang) #W ertequantil W ertebereichquantil ) Der Algorithmus unterscheidet zwischen Punkt- und Bereichsanfragen. Für Punktanfragen wird zunächst geprüft, ob der angefragte Wert ein Frequent Value ist, da so die Selektivität unmittelbar über den Wert aus der Systemtabelle

39 2.6. SELEKTIVITÄTEN 29 SYSCOLDIST bestimmt werden kann. Ansonsten wird das Quantil (ebenfalls aus der Systemtabelle SYSCOLDIST) bestimmt, in dem sich der Wert befindet und daraus wird die Selektivität berechnet. Für Bereichsanfragen wird die Selektivität stets über das zugehörige Quantil bestimmt. Alle benötigten Werte zum Berechnen der Selektivitäten werden von DB2 zur Verfügung gestellt, vorausgesetzt RUNSTATS wurde ausgeführt. Die folgende Tabelle zeigt, wo sich die benötigten Werte in der Datenbank befinden bzw. wie sie sich bestimmen lassen: Wert FrequentValue(Wert) #WerteQuantilanfang (kurz: #WQAnf) WertQuantilanfang (kurz: WQAnf) #WerteQuantil WertebereichQuantil Wertebereich KardinalitaetSpalte #Tupel Ort VALCOUNT in Tabelle SYSCOLDIST mit TYPE = F und COLVALUE = Wert VALCOUNT in Tabelle SYSCOLDIST mit TYPE = Q für das entsprechende Quantil COLVALUE in Tabelle SYSCOLDIST mit TYPE = Q für das entsprechende Quantil #W QAnf Quantil_i - #W QAnf Quantil_i 1 W QAnf Quantil_i - W QAnf Quantil_i 1 HIGH2KEY - LOW2KEY in Tabelle SYSCOLUMNS für die entsprechnede Spalte COLCARD in Tabelle SYSCOLUMNS für die entsprechende Spalte CARD in Tabelle SYSTABLES für die entsprechende Tabelle Tabelle 2.4: Bestimmung der benötigten Werte für Algorithmus Sel Um Algorithmus 1 zu veranschaulichen, wird erneut Beispiel 2.1 aus Abschnitt betrachtet. Gegeben seien weiterhin folgende drei Anfragen: Q1 = SELECT FROM Auto WHERE P r e i s = 2 ; Q2 = SELECT FROM Auto WHERE P r e i s = 5 0 ; Q3 = SELECT FROM Auto WHERE P r e i s <= 5 0 ; Anfrage(n) 6: Beispielanfragen für den Algorithmus Sel

40 30 KAPITEL 2. GRUNDLAGEN Es soll nun jeweils die Selektivität für das Prädikat der WHERE-Klausel der drei Anfragen bestimmt werden. Im Folgenden wird für den genauen Wert der Selektivität eines Prädikates P die Bezeichnung σ(p ) und für den berechneten Wert der Selektivität die Bezeichnung Sel(P ) benutzt. Für die Punktanfrage Q1 ist der Wert 2 für das Attribut Auto.Preis ein Frequent Value (siehe Systemtabelle SYSCOLDIST in Tabelle 2.3), sodass die Selektivität Sel(Auto.P reis = 2) = 75 = 0, 3 ist. Dies entspricht dem genauen Wert 250 σ(auto.p reis = 2) (siehe Tabelle 2.1). Der selektierte Wert 50 ist für die Punktanfrage Q2 kein Frequent Value, sodass das Quantil ermittelt werden muss, in dem sich der Wert 50 befindet. Bei Betrachtung von Tabelle 2.3 wird festgestellt, dass er sich im letzten Quantil befindet. Somit ergibt sich für die Berechnung von #W erte Folgendes: #W erte = = 1, 59 2 (2.1) Es ergibt sich für die Selektivität der Wert Sel(Auto.P reis = 50) = 2 = 0, 008, 250 welcher ebenfalls dem genauen Wert σ(auto.p reis = 50) entspricht, da der Wert 50 genau zwei Mal vorkommt (siehe Tabelle 2.1). Anfrage Q3 ist eine Bereichsanfrage, sodass auch hier das Quantil ermittelt werden muss, in dem sich der Wert 50 befindet. Dabei wird wie bei Anfrage Q2 vorgegangen. Der Wert von #W erte berechnet sich wie folgt: #W erte = (50 5) = 236, (2.2) Für die Selektivität ergibt sich Sel(Auto.P reis 50) = 237 = 0, 948, was vom 250 realen Wert (σ(auto.p reis 50) = 245 = 0, 98) nur minimal abweicht. 250 Algorithmus 1 lässt sich nur für Datentypen verwenden, die sich in reele Zahlen umwandeln lassen. Diese Datentypen sind SMALLINT, INTEGER, REAL, FLOAT, DOUBLE PRECISION, DECIMAL, DATE, TIME, TIMESTAMP. Für Spalten vom Typ VARCHAR bzw. CHAR funktioniert dieser Algorithmus nicht, da die Berechnungen sonst sehr kompliziert werden. Daher ist dies eine festgelegte Einschränkung in Kapitel

41 2.7. NORMALFORMEN FÜR AUSSAGENLOGISCHE FORMELN 31 Die Selektivitäten für weitere Operatoren wie für den IN-Operator oder den BETWEEN-Operator lassen sich leicht mit Hilfe von Algorithmus 1 berechnen: Algorithmus 2 Selektivitätsberechnung BETWEEN und IN Eingabe: Prädikat aus der WHERE-Klausel (Attribut, Operator, Werte), wobei Operator {IN, BETWEEN} Ausgabe: Selektivität if Operator = IN then for all x Werte do Sel+ = Sel(Attribut = x) end for else if Operator = BETWEEN then Sei Wert1 < Wert2 Sel = Sel(Attribut W ert2) Sel(Attribut W ert1) end if return Sel Für den IN-Operator müssen die Selektivitäten für die einzelnen Werte addiert werden und die Selektivität für den BETWEEN-Operator lässt sich mit Hilfe von Algorithmus 1 berechnen. Mit Hilfe von Algorithmus 1 und Algorithmus 2 lassen sich somit die Selektivitäten für die gängigen Operatoren und Datentypen mit Ausnahme von CHAR und VARCHAR bestimmen. Beim Vergleich der berechneten Werte mit den Berechnungen des DB2 -Optimierers wurde festgestellt, dass sich beide Werte kaum unterscheiden, sodass die Algorithmen im weiteren Verlauf der Arbeit benutzt werden können. 2.7 Normalformen für aussagenlogische Formeln Um die Ähnlichkeit zwischen verschiedenen Anfragen zu bestimmen, ist es erforderlich, dass die Anfragen eine einheitliche Form aufweisen. Somit ist es sinnvoll, die WHERE-Klausel, welche einer aussagenlogischen Formel entspricht, in eine Normalform zu überführen. Dabei kommen sowohl die konjunktive als auch die disjunktive

42 32 KAPITEL 2. GRUNDLAGEN Normalform in Frage. Konjunktive bzw. disjunktive Normalform sind in [Sch00] wie folgt definiert: Definition 2.2 (Konjunktive Normalform (KNF)) Eine aussagenlogische Formel A ist in konjunktiver Normalform (KNF), falls A eine Konjunktion von Disjunktionen von Literalen ist, d. h. falls A die Form A = A 1 A 2... A k hat für ein k N. Dabei hat jedes A i die Form L 1 L 2... L m für ein m N und jedes L i ist ein Literal. Definition 2.3 (Disjunktive Normalform (DNF)) Eine aussagenlogische Formel A ist in disjunktiver Normalform (KNF), falls A eine Disjunktion von Konjunktionen von Literalen ist, d. h. falls A die Form A = A 1 A 2... A k hat für ein k N. Dabei hat jedes A i die Form L 1 L 2... L m für ein m N und jedes L i ist ein Literal. In der WHERE-Klausel entsprechen die Prädikate den Literalen und die Operatoren AND und OR den logischen Operatoren und. Algorithmus 3 aus [Sch00] berechnet aus einer aussagenlogischen Formel die konjunktive Normalform. Um eine disjunktive Normalform zu erhalten, muss in den Zeilen 13 und 14 nur jeweils die duale Formel betrachtet werden, das heißt und sind vertauscht. Die Umformung der WHERE-Klausel ist für die Ähnlichkeitsbestimmung nach der Struktur (siehe Abschnitt 3.3.2) von besonderer Bedeutung. Dies wird an folgenden zwei Beispielanfragen deutlich: Q1 = SELECT FROM Auto WHERE ( Baujahr >= 1997 OR P r e i s >= 3000) AND ( Baujahr >= 1997 OR P r e i s <= 4000) ; Q2 = SELECT FROM Auto WHERE Baujahr >= 2000 OR ( P r e i s >= 4000 AND P r e i s <= 5000) ; Anfrage(n) 7: Beispielanfragen für die KNF/DNF-Umformung (Teil 1) Beide Anfrage weisen eine unterschiedliche Struktur auf, denn die WHERE-Klausel von Q1 ist eine Konjunktion von Disjunktionen (KNF) und von Q2 eine Disjunktion von Konjunktionen (DNF). Wird nun aber Algorithmus 3 auf Q2 angewendet,

43 2.7. NORMALFORMEN FÜR AUSSAGENLOGISCHE FORMELN 33 Algorithmus 3 KNF-Umformung Eingabe: Aussagenlogische Formel A Ausgabe: Aussagenlogische Formel in KNF äquivalent zu A 1: repeat 2: for all Terme der Form (X Y ) do 3: (X Y ) = Y X 4: end for 5: for all Terme der Form (X Y ) do 6: (X Y ) = Y X 7: end for 8: for all Terme der Form X do 9: X = X 10: end for 11: until Negation ist nur noch vor Variablen 12: repeat 13: for all Terme der Form X (Y Z) do 14: X (Y Z) = (X Y ) (X Z) 15: end for 16: until Formel ist in KNF sind beide Anfragen anschließend strukturell identisch. Die umgeformten Anfragen sehen wie folgt aus: Q1 = SELECT FROM Auto WHERE ( Baujahr >= 1997 OR P r e i s >= 3000) AND ( Baujahr >= 1997 OR P r e i s <= 4000) ; Q2 = SELECT FROM Auto WHERE ( Baujahr >= 2000 OR P r e i s >= 4000) AND ( Baujahr >= 2000 OR P r e i s <= 5000) ; Anfrage(n) 8: Beispielanfragen für die KNF/DNF-Umformung (Teil 2) Es wird deutlich, dass sich die Anfragen Q1 und Q2 nur noch in den Werten der Prädikate der WHERE-Klauseln unterscheiden.

44 34 KAPITEL 2. GRUNDLAGEN

45 Kapitel 3 Workload-Compression In diesem Kapitel wird die erste Komponente des SQLIndexWizard beschrieben, welche im Folgenden Workload-Compression-Komponente genannt wird. Ziel dieser Komponente ist es, aus den Anfragen der Eingabe möglichst viele zu eliminieren, ohne dass die spätere Bestimmung der Indizes davon beeinflusst wird. Das bedeutet, dass für das komprimierte Workload nahezu die selben Indizes bestimmt werden wie für das unkomprimierte Workload, sodass der Nutzen annähernd übereinstimmt. Dazu werden zuerst Partitionen gebildet, um von der Struktur her ähnliche Anfragen zu gruppieren. Anschließend findet eine Gruppierung der Anfragen (im Folgenden Clustering genannt) in diesen Partitionen statt, wobei die WHERE-Klauseln der Anfragen in gleichen Partitionen miteinander verglichen werden. Der Funktionsablauf der Workload-Compression-Komponente wird in Abbildung 3.1 grafisch dargestellt. 3.1 Theoretische Aspekte Das Problem der Workload-Compression wurde in [CGN02] zuerst formal definiert. Definition 3.1 (Workload-Compression) Sei A eine Anwendung, die als Eingabe ein Workload W erhält. Weiterhin sei Distance A (q i, q j ) eine Funktion für die Anwendung A, die q i, q j W den Qualitätsverlust für q i berechnet, wenn q j im komprimierten Workload W enthalten ist aber q i nicht. Zudem ist ein Wert gegeben, welcher den maximalen Qualitätsverlust angibt. Das Problem, das kleinste Workload 35

46 36 KAPITEL 3. WORKLOAD-COMPRESSION Abbildung 3.1: Funktionsablauf der Workload-Compression-Komponente W W zu finden, so dass q i W W (min qj W w i Distance A (q i, q j )) <, wird Workload-Compression-Problem genannt. In dieser Arbeit ist die Anwendung aus Definition 3.1 der Index-Advisor, das heißt die Komponente, welche die Indexauswahl durchführt. Die Funktion Distance A (q i, q j ) berechnet den erwarteten Profitverlust für q i, wenn die Menge der empfohlenen Indizes für q j anstatt der empfohlenen Indizes für q i benutzt wird. Der Wert gibt den maximalen Profitverlust an. Wie in [CGN02] gezeigt wird, ist dieses Problem NP-hart. Allerdings soll in dieser Arbeit das Problem nicht gelöst werden. Es soll lediglich ein komprimiertes Workload W berechnet werden, sodass möglichst bei der Indexauswahl für das komprimierte und für das unkomprimierte Workload die selben Indizes bestimmt werden. Eine maximale Kompression wird nicht angestrebt, aber sie soll für die Praxis ausreichend sein. Auch in [CGN02] werden die Anfragen zuerst in Partitionen eingeteilt, sodass dieser Ansatz auch in dieser Arbeit aufgegriffen wird. Ebenfalls werden Selektivitäten zur Bestimmung der Distanzen zwischen Anfragen verwendet. Allerdings wird in dieser Arbeit nicht die Distanz zwischen Anfragen verwendet, sondern die Ähnlichkeit, wobei diese auf einen Wert zwischen 0 und 1 beschränkt ist. Eine Umrechnung zwischen Distanz und Ähnlichkeit ist dabei ohne weiteres möglich.

47 3.2. PARTITIONIERUNG Partitionierung Der erste Schritt bei der Workload-Compression ist die Partitionierung der Anfragen. Dabei werden Anfragen in Partitionen eingeteilt, wobei in jeder Partition von der Struktur her ähnliche Anfragen zu finden sind. Dieses Vorgehen hat sich als nützlich erwiesen, da z. B. Anfragen, welche auf unterschiedliche Tabellen zugreifen, unabhängig bezüglich der möglichen nützlichen Indizes sind. Auch in [CGN02] wird eine Partitionierung durchgeführt. Im Folgenden wird auf die 4 Anfragetypen (SELECT-, UPDATE-, INSERTund DELETE-Anfragen) einzeln eingegangen. Die Ähnlichkeitsbestimmung der WHERE-Klausel wird in Kapitel 3.3 beschrieben, sie hat auf die Partitionierung keinen Einfluss. Die Beispielanfragen, welche zur Begründung der Partitionierung benutzt werden, basieren auf dem TPC-H-Schema und den zugehörigen Daten (siehe Abschnitt 6.1.1), es handelt sich also um reale Anfragen auf realen Daten SELECT-Anfragen Eine SELECT-Anfrage hat die folgende Struktur: SELECT <SELECT Klausel> FROM <FROM Klausel> WHERE <WHERE Klausel> ORDER BY <ORDER BY Klausel> GROUP BY <GROUP BY Klausel> HAVING <HAVING Klausel >; Anfrage(n) 9: Struktur einer SELECT-Anfrage In diesem Abschnitt wird nun auf jeden Teil der SELECT-Anfrage eingegangen und es wird dabei geklärt, inwieweit eine Partitionierung durchgeführt werden muss. SELECT-Klausel In der SELECT-Klausel können einzelne Spalten bzw. Aggregationen auf Spalten vorkommen. Ein Sonderfall ist der *-Operator, welcher für alle Spalten der Tabellen aus der FROM-Klausel steht. Dabei ist nun zu klären, ob durch eine Aggregation ein Index auf einer Spalte nützlicher werden kann. Es werden die Aggregatfunktionen

48 38 KAPITEL 3. WORKLOAD-COMPRESSION MAX, SUM und COUNT betrachtet. Wobei COUNT sowohl auf eine Spalte als auch mit der Wildcard * auf das gesamte Tupel angewendet werden kann. Weiterhin können Spalten ohne Aggregationen auftreten. Im Folgenden wird geklärt, inwiefern Aggregationen Einfluss auf die Benutzung von Indizes haben. Dazu wurden aus den Ausführungsplänen für die folgenden sechs Anfragen die benutzten Indizes bestimmt. Bezeichnung Anfrage Indizes Q 1 SELECT S_ACCTBAL FROM SUPPLIER S_NATIONKEY WHERE S_NATIONKEY = 1; Q 2 SELECT MAX(S_ACCTBAL) FROM S_ACCTBAL SUPPLIER WHERE S_NATIONKEY = 1; Q 3 SELECT SUM(S_ACCTBAL) FROM SUP- S_NATIONKEY PLIER WHERE S_NATIONKEY = 1; Q 4 SELECT COUNT(S_ACCTBAL) FROM S_NATIONKEY SUPPLIER WHERE S_NATIONKEY = 1; Q 5 SELECT COUNT(S_ACCTBAL) FROM S_NATIONKEY SUPPLIER WHERE S_NATIONKEY!= 1; Q 6 SELECT SUM(S_ACCTBAL) FROM SUP- - PLIER WHERE S_NATIONKEY!= 1; Tabelle 3.1: Beispielanfragen für die Partitionierung bei Aggregationen Zuerst muss geklärt werden, ob eine Aggregation überhaupt Einfluss auf die benutzten Indizes für Anfragen hat. Dazu können die Anfragen Q 1 und Q 2 betrachtet werden, welche bis auf die Aggregation MAX auf S_ACCTBAL identisch sind. Da für die Beantwortung von Anfrage Q 1 der Index auf S_NATIONKEY und für Q 2 der Index auf S_ACCTBAL benutzt wird, haben Aggregationen einen Einfluss auf die benutzten Indizes. Es kann vermutet werden, dass lediglich zwischen Spalten mit und ohne Aggregation unterschieden werden muss. Dies kann aber widerlegt werden, denn die benutzten Indizes für die Anfragen Q 2 und Q 3, welche sich lediglich in der Aggregatfunktion unterscheiden, sind verschieden (für Q 2 wird der Index auf S_ACCTBAL und für Q 3 der Index auf S_NATIONKEY benutzt). Dies liegt daran, dass für die Aggregatfunk-

49 3.2. PARTITIONIERUNG 39 tion MAX lediglich ein Tupel gelesen werden muss. Für die Funktion SUM müssen alle Tupel gelesen und die Werte für die entsprechende Spalte müssen aufaddiert werden. Somit gibt es auch keinen Unterschied zwischen der Anwendung der Aggregatfunktion SUM auf eine Spalte A und für eine ohne Aggregation angefragte Spalte A, da in beiden Fällen alle Tupel gelesen werden müssen (vergleiche die Anfragen Q 1 und Q 3 ). Nun wird die Aggregatfunktion COUNT betrachtet. Da auch bei COUNT alle Tupel in die Berechnung des Ergebnisses einfließen, kann davon ausgegangen werden, dass ein Unterschied zur Aggregatfunktion MAX existiert. Dies wird deutlich, wenn die Anfragen Q 2 und Q 4 betrachtet werden. Für Q 2 wird der Index auf S_ACCTBAL verwendet, für Q 4 hingegen der Index auf S_NATIONKEY. Dies entspricht dem erwarteten Ergebnis. Da sowohl bei COUNT als auch bei SUM alle Tupel für die Berechnung des Ergebnisses betrachtet werden, kann davon ausgegangen werden, dass sich beide Funktionen in Bezug auf die benutzten Indizes gleich verhalten. Es können aber Anfragen konstruiert werden, bei denen dies nicht der Fall ist. Dazu werden die Anfragen Q 5 und Q 6 betrachtet. Für die Beantwortung der Anfrage Q 5 wird der Index auf S_NATIONKEY verwendet, für Q 6 allerdings gar kein Index. Somit muss auch zwischen SUM und COUNT unterschieden werden. Weiterhin gibt es einen Unterschied zwischen der Aggregatfunktion COUNT auf eine Spalte A und COUNT(*) auf alle Spalten. Dies lässt sich allerdings nicht mit den oben genannten Anfragen bzw. mit den zugrunde liegenden Daten belegen. Es wurde folgendes Beispiel konstruiert: Sei R eine Tabelle mit zwei Spalten A und B. Die Spalte A enthält dabei 90% NULL-Werte. Nun werden folgende zwei Anfragen gestellt: Q1 = SELECT COUNT( ) FROM R; Q2 = SELECT COUNT(A) FROM R; Anfrage(n) 10: Beispielanfragen für die Partitionierung der Aggregatfunktion COUNT Für die Beantwortung von Q 1 wird kein Index verwendet, da jedes Tupel gelesen werden muss. Im Gegensatz dazu wird für die Beantwortung von Q 2 der Index auf R.A verwendet, da dadurch die Tupel, die keinen NULL-Wert haben, schneller

50 40 KAPITEL 3. WORKLOAD-COMPRESSION gezählt werden können. Ohne den Index müsste auch jedes Tupel gelesen werden, allerdings werden Tupel mit NULL-Wert in Spalte A nicht mitgezählt. Also muss auch zwischen COUNT(*) und COUNT(A) unterschieden werden. Somit können folgende 4 Gruppen gebildet werden: Aggregationen SUM, AVG bzw. keine Aggregation auf eine Spalte A Aggregationen MAX, MIN auf eine Spalte A Aggregation COUNT auf eine Spalte A Aggregation COUNT auf alle Spalten (COUNT(*)) Dies bedeutet für die Partitionierung, dass sobald eine Spalte zweier Anfragen in zwei verschiedenen Gruppen ist, die Anfragen in zwei verschiedene Partitionen eingeteilt werden. FROM-Klausel In der FROM-Klausel stehen die Tabellen, die angefragt werden. Intuitiv kann festgelegt werden, dass zwei Anfragen in verschiedene Partitionen eingegliedert werden, sobald sich die Tabellen der Anfragen unterscheiden. Dies kann anhand von folgendem Beispiel verdeutlicht werden: Wird in einer Anfrage Q1 nur die Tabelle SUPPLIER angefragt, können für diese Anfrage auch nur Indizes auf Spalten der Tabelle SUPPLIER hilfreich sein. Werden hingegen in einer Anfrage Q2 die Tabellen SUPPLIER und NATION angefragt, kommen sowohl die Indizes auf Spalten der Tabelle SUPPLIER als auch Indizes auf Spalten der Tabelle NATION in Frage. Somit sind beide Anfragen verschieden bezüglich der möglichen nützlichen Indizes und sie müssen in verschiedene Partitionen eingeteilt werden. Joins in der WHERE-Klausel In dieser Arbeit werden auch Joins betrachtet, wobei nur Equi-Joins auftreten dürfen. Es wurde festgelegt, dass die Join-Attribute für zwei Anfragen identisch sein müssen, wenn sie in die selbe Partition eingeteilt werden sollen. Sollten sich die

51 3.2. PARTITIONIERUNG 41 beiden Join-Attribute beider Anfragen unterscheiden, wird es intuitiv deutlich, dass beide Anfragen in verschiedene Partitionen eingeteilt werden. Dass dies auch der Fall ist, falls ein Join-Attribut übereinstimmt, wird durch folgendes Beispiel deutlich: Q1 = SELECT FROM SUPPLIER,NATION WHERE S_NATIONKEY = N_NATIONKEY; Q2 = SELECT FROM SUPPLIER,NATION WHERE S_NATIONKEY = N_REGIONKEY; Anfrage(n) 11: Beispielanfragen für die Partitionierung von Joins Für Anfrage Q1 kommen sowohl der Index auf S_NATIONKEY als auch der Index auf N_NATIONKEY für die Beschleunigung der Anfrage in Betracht, für Anfrage Q2 sind es die Indizes auf S_NATIONKEY und N_REGIONKEY. Da sich beide Mengen unterscheiden können, auch wenn ein Joinattribut übereinstimmt, müssen beide Anfragen in verschiedene Partitionen eingeteilt werden. GROUP BY-Klausel Zuerst ist die Frage zu klären, ob ein Index überhaupt nützlich werden kann, falls eine GROUP BY-Klausel in einer Anfrage enthalten ist. Das folgende Beispiel beweist den Einfluss der GROUP BY-Klausel auf die Indexbenutzung: Q1 = SELECT S_ACCTBAL FROM SUPPLIER GROUP BY S_ACCTBAL, S_NATIONKEY; Q2 = SELECT S_ACCTBAL FROM SUPPLIER GROUP BY S_NATIONKEY, S_ACCTBAL; Anfrage(n) 12: Beispielanfragen für die Partitionierung der GROUP BY-Klausel Für die Beantwortung von Q1 wird der Index auf S_ACCTBAL genutzt, für die Beantwortung von Q2 hingegen wird kein Index genutzt. Es wird dadurch auch deutlich, dass die Elemente der GROUP BY-Klausel identisch sein müssen und in der gleichen Reihenfolge auftreten müssen, damit zwei Anfragen in die selbe Partition eingeteilt werden.

52 42 KAPITEL 3. WORKLOAD-COMPRESSION HAVING-Klausel Die HAVING-Klausel ist im Prinzip eine WHERE-Klausel, wobei auch Aggregationen auf Spalten vorkommen dürfen. Dabei ist es allerdings nicht ohne weiteres möglich, die Selektivitäten dieser Aggregationen zu bestimmen, sodass eine Behandlung äquivalent zu der der WHERE-Klausel nicht gegeben ist. Somit werden nur identische HAVING-Klauseln in die selbe Partition eingeteilt. Dadurch wird kein Fehler gemacht, es ist allerdings auch möglich, dass ähnliche Anfragen in unterschiedliche Partitionen eingeteilt werden. ORDER BY-Klausel Die ORDER BY-Klausel verhält sich wie die GROUP BY-Klausel. Es lässt sich das gleiche Beispiel konstruieren, nur dass anstatt des GROUP BY ein ORDER BY benutzt wird: Q1 = SELECT S_ACCTBAL FROM SUPPLIER ORDER BY S_ACCTBAL, S_NATIONKEY; Q2 = SELECT S_ACCTBAL FROM SUPPLIER ORDER BY S_NATIONKEY, S_ACCTBAL; Anfrage(n) 13: Beispielanfragen für die Partitionierung der ORDER BY-Klausel Für die Beantwortung von Q1 wird der Index auf S_ACCTBAL genutzt, für die Beantwortung von Q2 hingegen wird kein Index genutzt. Somit müssen auch die ORDER BY-Klauseln identisch sein, damit zwei Anfragen in die selbe Partition eingeteilt werden UPDATE-Anfragen Eine UPDATE-Anfrage hat die folgende Struktur: UPDATE <Tabellen Name> SET <Spalten und Werte> WHERE <WHERE Klausel >; Anfrage(n) 14: Struktur einer UPDATE-Anfrage

53 3.2. PARTITIONIERUNG 43 Der Tabellen-Name muss wie bei SELECT-Anfragen identisch sein, da für UPDATE-Operationen auch nur Indizes auf der zu aktualisierenden Tabelle nützlich sein können. Auch die zu aktualisierenden Spalten müssen übereinstimmen, was durch folgendes Beispiel verdeutlicht werden soll: U1 = UPDATE SUPPLIER SET S_NATIONKEY=5 WHERE S_SUPPKEY = 6 ; U2 = UPDATE SUPPLIER SET S_SUPPKEY=5 WHERE S_SUPPKEY = 6 ; Anfrage(n) 15: Beispielanfragen für die Partitionierung einer UPDATE-Anfrage In U1 ist ein Index auf S_SUPPKEY abhängig von der Selektivität des Prädikates der WHERE-Klausel potentiell nützlich. Auch in U2 kann dieser nützlich sein, aber falls viele Werte aktualisiert werden, muss auch der Index aktualisiert werden, was den positiven Nutzen vom Index auf S_SUPPKEY wieder aufheben kann. Somit müssen die zu aktualisierenden Spalten übereinstimmen INSERT-Anfragen Eine INSERT-Anfrage hat die folgende Struktur: INSERT INTO <Tabellen Name und Spalten> SET <Werte >; Anfrage(n) 16: Struktur einer INSERT-Anfrage Ähnlich wie bei der UPDATE-Anfrage müssen auch hier Tabellen-Name und Spaltennamen übereinstimmen. Allerdings kann für eine INSERT-Anfrage ein Index keinen positiven Nutzen erhalten, sondern nur einen negativen Nutzen, da durch das Einfügen von Werten der Index aktualisiert werden muss DELETE-Anfragen Eine DELETE-Anfrage hat die folgende Struktur:

54 44 KAPITEL 3. WORKLOAD-COMPRESSION DELETE FROM <Tabellen Name> WHERE <WHERE Klausel >; Anfrage(n) 17: Struktur einer DELETE-Anfrage Bei DELETE-Anfragen muss der Tabellen-Name übereinstimmen. Alle Indizes auf Spalten der angefragten Tabelle bekommen einen negativen Nutzwert, welcher allerdings durch die Prädikate der WHERE-Klausel wieder aufgewogen werden können. 3.3 Ähnlichkeitsbestimmung der WHERE-Klausel Nachdem die Anfragen in Partitionen eingeteilt sind, muss die Ähnlichkeit zwischen den Anfragen in den einzelnen Partitionen bestimmt werden. Die Anfragen in den Partitionen unterscheiden sich in der Regel nur durch die WHERE-Klausel, weswegen ein Ähnlichkeitsmaß für diese gefunden werden muss. Der DirXWiz benutzt dafür Anfragevektoren, wobei zwei Anfragen ähnlicher zueinander sind, je kleiner der Winkel zwischen deren Anfragevektoren ist. Ein Ansatz aus der Literatur ([Kol08]) definiert die Ähnlichkeit über die Struktur der WHERE-Klausel, das heißt, dass nur strukturell ähnliche WHERE-Klauseln überhaupt miteinander verglichen werden. Beide Verfahren werden im Folgenden beschrieben und es wird auf Vor- und Nachteile eingegangen Anfragevektoren In [DHR08] werden Anfragevektoren eingeführt, mit deren Hilfe ein Ähnlichkeitsmaß definiert wird. Dieser Ansatz wird in dieser Arbeit aufgegriffen und benutzt. Anschließend wird untersucht, ob eine Anpassung der Anfragevektoren eine bessere Ähnlichkeitsbestimmung ermöglicht. Es stellt sich aber noch die Frage, wie die Anfragevektoren aufgebaut sind. Dazu wurden drei verschiedene Ansätze entwickelt, welche alle auch implementiert wurden.

55 3.3. ÄHNLICHKEITSBESTIMMUNG DER WHERE-KLAUSEL 45 Variante 1 Die erste Variante ist zum Ansatz in [DHR08] identisch. Für alle Spalten der angefragten Tabellen wird eine Dimension im Anfragevektor angelegt. Alle Dimensionen haben anfangs den Wert 0. Für eine Spalte A in einem Prädikat der WHERE- Klausel wird nun der Wert der entsprechenden Dimension im Anfragevektor wie folgt festgelegt, wobei P A ein Prädikat der WHERE-Klausel ist, welches A als Spalte enthält: dim(a) = P A (1 Sel(P A )) (3.1) Es wird deutlich, dass nicht die Selektivität selbst, sondern der von Eins abgezogene Wert den Wert der Dimension bestimmt. Somit resultiert aus einer geringen Selektivität ein hoher Wert für die Dimension. Um den Aufbau der Anfragevektoren zu veranschaulichen, sollen folgende zwei Anfragen als Beispiel dienen: Q1 = SELECT FROM R WHERE R.B > 6 AND R.C > 4 ; Q2 = SELECT FROM R WHERE R.A = 6 AND R.B > 5 ; Anfrage(n) 18: Beispielanfragen für Anfragevektoren Die Tabelle R habe dabei drei Spalten A, B und C. Die Selektivitäten für die Prädikate sind die Folgenden: Sel(R.B > 6) = 0, 4, Sel(R.C > 4) = 0, 3, Sel(R.A = 6) = 0, 1 und Sel(R.B > 5) = 0, 3. Daraus ergeben sich dann die zugehörigen Anfragevektoren V 1 = (0; 0, 6; 0, 7) und V 2 = (0, 9; 0, 7; 0). Nachdem der Aufbau der Anfragevektoren definiert ist, lässt sich auch das Ähnlichkeitsmaß sim(q i, Q j ) zwischen zwei Anfragen definieren. Dafür gibt es mehrere Möglichkeiten. Es kann beispielsweise der Abstand zwischen zwei Anfragevektoren herangezogen werden. Weiterhin ist es möglich, den Winkel zwischen zwei Vektoren zu benutzen. Dieser Ansatz, welcher auch in [DHR08] benutzt wurde, wird auch in dieser Arbeit verwendet. Um einen Zahlenwert zu erhalten, wird der Kosinus des Winkel zwischen zwei Vektoren herangezogen.

56 46 KAPITEL 3. WORKLOAD-COMPRESSION Gegeben seien zwei Anfragen Q i und Q j, aus denen sich die Anfragevektoren V i und V j konstruieren lassen. Die Ähnlichkeit zwischen den beiden Anfragen ist wie folgt definiert: sim(q i, Q j ) = cos(v i, V j ) = V i V j V i V j (3.2) Der Kosinus wird als Skalarprodukt der Vektoren geteilt durch die Längen der beiden Vektoren berechnet. Da in einer Partition lediglich Anfragen mit den selben Tabellen enthalten sind und nur Anfragen aus der selben Partition miteinander verglichen werden, lässt sich das Skalarprodukt stets berechnen. Werden für zwei Anfragen unterschiedliche Spalten in den Prädikaten der WHERE-Klausel selektiert, ist das Skalarprodukt 0 und die Anfragen sind grundsätzlich verschieden. Nur wenn gleiche Spalten in den Prädikaten selektiert werden, hat die Ähnlichkeit einen von 0 verschiedenen Wert. Eine geringe Selektivität eines Prädikates auf einer Spalte (und somit ein hoher Wert für die Dimension dieser Spalte) hat dabei einen größeren Einfluss auf den berechneten Wert. Da der Kosinus nach Definition nur einen beschränkten Wertebereich hat, wird der Wert für die Ähnlichkeit wie folgt beschränkt: 0 sim(q i, Q j ) 1 (3.3) Je näher der Wert an 1 ist, desto ähnlicher sind sich zwei Anfragen Q i und Q j, denn für den Kosinus eines kleinen Winkels zwischen den zugehörigen Anfragevektoren V i und V j ergibt sich ein hoher Wert von cos(v i, V j ). Ist der Wert 0, werden in den WHERE-Klausel von Q i und Q j verschiedene Spalten selektiert und somit sind auch nur verschiedene Indizes nützlich. Das heißt, dass die Anfragen grundsätzlich verschieden sind. Für die Anfragen aus dem oben genannten Beispiel lässt sich folgender Ähnlichkeitswert bestimmen: sim(q 1, Q 2 ) = cos(q 1, Q 2 ) = V 1 V 2 V 1 V 2 = 0 0, 9 + 0, 6 0, 7 + 0, 7 0 0, , 7 2 0, , 7 2 0, 4212 (3.4)

57 3.3. ÄHNLICHKEITSBESTIMMUNG DER WHERE-KLAUSEL 47 Dies bedeutet, dass sich beide Anfragen nicht sehr ähnlich sind, da lediglich Spalte B in beiden Anfragen selektiert wird. Diese Variante funktioniert sehr gut für Anfragen mit mehreren Prädikaten in der WHERE-Klausel, sollte allerdings nur ein Prädikat auf dem gleichen Attribut enthalten sein, kann es zu Problemen kommen. Dies wird im folgenden Beispiel verdeutlicht: Q1 = SELECT FROM S WHERE S.A = 1 ; Q2 = SELECT FROM S WHERE S.A > 1 ; Anfrage(n) 19: Beispielanfragen für den Fehler bei Variante 1 Sei S eine Tabelle mit nur einer Spalte A. Weiterhin seien Sel(S.A = 1) = 0, 01 und Sel(S.A > 1) = 0, 9. Es wird angenommen, dass für die Anfrage Q1 aufgrund der geringen Selektivität des Prädikates der WHERE-Klausel ein Index auf S.A nützlich ist, für Q2 allerdings nicht (aufgrund der hohen Selektivität). Somit müssten sich beide Anfragen nur wenig ähnlich sein, sodass der Wert von sim(q 1, Q 2 ) gering sein sollte. Die Anfragevektoren für Q1 und Q2 sind V 1 = (0, 99) und V 2 = (0, 1) (siehe Gleichung 3.1). Es ergibt sich folgender Wert für sim(q 1, Q 2 ): sim(q 1, Q 2 ) = cos(q 1, Q 2 ) = V 1 V 2 V 1 V 2 = 0, 99 0, 1 0, 992 0, 1 2 = 1 (3.5) Demnach sind sich beide Anfragen maximal ähnlich, was allerdings wie oben gezeigt wurde nicht der Fall ist. Variante 2 In der zweiten Varianten werden für alle Spalten der angefragten Tabellen zwei Dimensionen angelegt. Eine Dimension hat dabei stets den Wert 1,0 und der Wert der anderen Dimension wird wie bei Variante 1 festgelegt. Dies soll den Fehler von Variante 1 korrigieren. Es ergibt sich also Folgendes für eine Spalte A:

58 48 KAPITEL 3. WORKLOAD-COMPRESSION dim 1 (A) = 1, 0 dim 2 (A) = P A (1 Sel(P A )) (3.6) Die Ähnlichkeitsberechnung erfolgt wie bei Variante 1 (siehe Gleichung 3.2). Werden die Anfragen 19 betrachtet, ergeben sich die Vektoren V 1 = (1, 0; 0, 99) und V 2 = (1, 0; 0, 1). Somit ergibt sich für sim(q 1, Q 2 ) folgender Wert: sim(q 1, Q 2 ) = 1, 0 1, 0 + 0, 99 0, 1 1, , , = 0, 7771 (3.7) , 12 Dies entspricht dem erwarteten Ergebnis, wonach sich beide Anfragen wenig ähnlich sind. Aber auch für diese Variante lassen sich Beispiele konstruieren, für die sie nicht funktioniert. Es werden nun die folgenden drei Anfragen betrachtet: Q1 = SELECT FROM S WHERE S.A = 1 ; Q2 = SELECT FROM S WHERE S.A = 1 OR S.A = 2 ; Q3 = SELECT FROM S WHERE S.A < 2 0 ; Anfrage(n) 20: Beispielanfragen für den Fehler bei Variante 2 Dabei seien Sel(S.A = 1) = 0, 01, Sel(S.A = 2) = 0, 01 und Sel(S.A < 20) = 0, 9. Es wird angenommen, dass der Index auf S.A für Q1 sehr nützlich, für Q2 auch sehr nützlich (aber weniger nützlich als für Q2) und für Q3 nicht nützlich ist. Somit muss gelten: sim(q 1, Q 2 ) sim(q 2, Q 3 ) sim(q 1, Q 3 ) (3.8) Aus den nach Variante 2 bestimmten Vektoren für die drei Anfragen V 1 = (1, 0; 0, 99), V 2 = (1, 0; 1, 98) und V 3 = (1, 0; 0, 1) ergeben sich folgende

59 3.3. ÄHNLICHKEITSBESTIMMUNG DER WHERE-KLAUSEL 49 Ähnlichkeitswerte: sim(q 1, Q 2 ) = sim(q 2, Q 3 ) = sim(q 1, Q 3 ) = 1, 0 1, 0 + 0, 99 1, 98 1, , , = 0, , 982 1, 0 1, 0 + 1, 98 0, 1 1, , , = 0, 5374 (3.9) , 12 1, 0 1, 0 + 0, 99 0, 1 1, , , = 0, , 12 Es wird deutlich, dass die Beziehung aus 3.8 nicht erfüllt ist, sodass auch diese Variante nicht für alle Anfragen funktioniert. Variante 3 Somit wurde eine dritte Variante entwickelt, für die sich ebenfalls zwei Dimensionen für alle Spalten der angefragten Tabellen ergeben. Die erste Dimension jeder Spalte hat wie in Variante 2 den Wert 1,0. Die zweite Dimension berechnet sich folgendermaßen: dim 1 (A) = 1, 0 dim 2 (A) = max {0, 1 P A Sel(P A )} (3.10) Die Ähnlichkeitsberechnung erfolgt ebenfalls wie bei Variante 1 (siehe Gleichung 3.2). Die Vektoren für die drei Anfragen 20 sind damit V 1 = (1, 0; 0, 99), V 2 = (1, 0; 0, 98) und V 3 = (1, 0; 0, 1) und es ergeben sich folgende Ähnlichkeitswerte: sim(q 1, Q 2 ) = sim(q 2, Q 3 ) = sim(q 1, Q 3 ) = 1, 0 1, 0 + 0, 99 0, 98 1, , , = 0, , 982 1, 0 1, 0 + 0, 98 0, 1 1, , , = 0, 7803 (3.11) , 12 1, 0 1, 0 + 0, 99 0, 1 1, , , = 0, , 12

60 50 KAPITEL 3. WORKLOAD-COMPRESSION Die Beziehung aus 3.8 ist somit erfüllt Struktur Im zweiten Verfahren werden nur WHERE-Klauseln als potentiell ähnlich angesehen, welche die gleiche Struktur haben. Das bedeutet, dass sich nur die Werte der Prädikate in der WHERE-Klausel unterscheiden dürfen. Zur Verdeutlichung werden die folgenden drei Anfragen betrachtet: Q1 = SELECT FROM R WHERE R.A = 1 ; Q2 = SELECT FROM R WHERE R.A = 5 ; Q3 = SELECT FROM R WHERE R.A = 5 AND R.B = 6 ; Anfrage(n) 21: Beispielanfragen für die Ähnlichkeitsbestimmung anhand der Struktur Es haben nur Q1 und Q2 die gleiche Struktur, ein potentieller Index für beide Anfragen wäre der Index auf R.A. Für Q3 wären Indizes auf R.A und R.B denkbar. In [Kol08] wird erstmal nicht die Ähnlichkeit zwischen Anfragen, sondern die Distanz betrachtet. Diese ist wie folgt definiert: max{sel(p max 1 ),Sel(p 2 )} d(q 1, Q 2 ) = 1 Q p 1 P red(q 1 ),p 2 P red(q 2 ),p 1 p max{sel(p 1 ),Sel(p 2 )} 1 Q sonst (3.12) Dabei gilt: Q 1 Q 2 steht für zwei strukturell ähnliche Anfragen Pred(Q) ist die Menge der Prädikate aus der WHERE-Klausel von Q p 1 p 2 steht für zwei Prädikate, die sich nur im konstanten Wert unterscheiden Sel(p) steht für die Selektivität des Prädikates p mit 0 Sel(p) 1

61 3.4. CLUSTERING-ALGORITHMEN 51 Da sich dieser Wert im Bereich zwischen 0 und bewegt, die Ähnlichkeit aber im Bereich zwischen 0 und 1 sein sollte, wird die Distanz wie folgt normiert: sim(q 1, Q 2 ) = 1 dist(q 1, Q 2 ) + 1 (3.13) Es wird deutlich, dass das Prädikat mit dem größten Unterschied in der Selektivität als Maß für die Ähnlichkeit von zwei Anfragen herangezogen wird. Diese Methode sorgt für eine quantitativ schlechteres Clustering als die Methoden, die auf Anfragevektoren basieren. Dies liegt daran, dass nur strukturell komplett ähnliche Anfragen verglichen werden. Das bedeutet, dass anders als bei den auf Anfragevektoren basierenden Methoden die WHERE-Klausel bis auf die konstanten Werte der Prädikate komplett identisch sein müssen. Diese Methode hat aber auch den Nachteil, dass möglicherweise ähnliche Anfragen als unähnlich angesehen werden (wodurch allerdings kein Fehler gemacht wird). Wäre jetzt beispielsweise die Selektivität vom Prädikat R.A = 6 in Q3 (aus Anfragen 21) sehr hoch, würde der Index auf R.B vermutlich nicht nützlich sein und Q2 und Q3 wären sich sehr ähnlich. Allerdings ist das Clustering qualitativ besser. 3.4 Clustering-Algorithmen Nachdem die Anfragen in Partitionen eingeteilt sind und zwischen Anfragen in Partitionen ein Ähnlichkeitsmaß definiert ist, müssen die Anfragen einer Partition im letzten Schritt der Workload-Compression-Komponente in Gruppen entsprechend ihrer Ähnlichkeit zueinander eingeteilt werden. Es existieren verschiedene Algorithmen, mit denen eine Gruppierung durchgeführt werden kann. Wie im DirXWiz werden in dieser Arbeit der Leader-Algorithmus und der k-means-algorithmus näher betrachtet Leader-Algorithmus Der Leader-Algorithmus ist ein einfacher, effizienter Clustering-Algorithmus, welcher auch im DirXWiz und in [Kol08] für die Gruppierung der Anfragen benutzt

62 52 KAPITEL 3. WORKLOAD-COMPRESSION wird. Dabei wird jedem Cluster ein so genannter Leader zugeordnet, welcher Repräsentant des Clusters ist. Der erste Anfragevektor, der einem Cluster zugeordnet wird, ist der Leader. Die Eingabe des Algorithmus sind die Anfragevektoren der Anfragen einer Partition und ein Schwellwert ρ, die Ausgabe sind die Leader der erzeugten Cluster, woraus sich die zugehörigen Anfragen extrahieren lassen. Der Leader des ersten Clusters ist der erste Anfragevektor. Für jeden weiteren Anfragevektor wird nun der ähnlichste Leader gefunden. Ist die Ähnlichkeit zwischen dem Anfragevektor und dem ähnlichsten Leader größer als der Schwellwert ρ, wird der Anfragevektor in das Cluster eingeteilt. Dazu muss nicht der Anfragevektor im Cluster gespeichert werden, sondern nur die Größe des Clusters entsprechend der Gewichtung des Anfragevektors inkrementiert werden. Andernfalls wird ein neuer Cluster mit dem Anfragevektor als Leader erzeugt. Der Leader-Algorithmus wird im Folgenden dargestellt: Algorithmus 4 Leader-Algorithmus Eingabe: n Anfragevektoren V 1,..., V n, Schwellenwert ρ Ausgabe: Repräsentanten des Clusterings Erzeuge neuen Cluster mit V 1 als Leader for i = 2 to n do Leader V l mit größter Ähnlichkeit zu V i finden Sei Q i der Repräsentant von Leader V i und Q l der Repräsentant von Leader V l if sim(q i, Q l ) ρ then else Lege V i in den Cluster von V l Erzeuge neuen Cluster mit V i als Leader end if end for return Menge aller Leader V l Der Nachteil dieses Algorithmus ist es, dass stets der erste Anfragevektor Leader und somit Repräsentant des Clusters wird. Besser wäre es, aus allen Anfragevektoren

63 3.4. CLUSTERING-ALGORITHMEN 53 des Clusters den Anfragevektor auszuwählen, der sich möglichst im Mittelpunkt des Clusters befindet. Dadurch wird ein besserer Repräsentant ermittelt, da die Summe seiner Ähnlichkeiten zu allen anderen Anfragevektoren im Cluster maximiert wird. Vorteil von Algorithmus 4 ist die geringe Laufzeit von O(n k), wobei n die Anzahl der Anfragevektoren und k die Anzahl der ermittelten Cluster ist. Es kann davon ausgegangen werden, dass k im Allgemeinen sehr viel kleiner als n ist k-means-algorithmus Der Nachteil des Leader-Algorithmus wird vom k-means-algorithmus ausgeräumt. Dieser Algorithmus erhält ebenfalls die Menge der Anfragevektoren der Anfragen einer Partition als Eingabe, aber zusätzlich muss eine konstante Clusteranzahl (k) festgelegt werden. Die Ausgabe sind die Mittelpunkte der Cluster. Zuerst werden zufällig k Anfragevektoren als Clustermittelpunkte gesetzt. Nun werden alle Anfragevektoren ihrem nächstgelegenen Mittelpunkt zugeordnet und anschließend werden die neuen Mittelpunkte als Schwerpunkt der entsprechenden Anfragevektoren bestimmt. Dies geschieht solange, bis sich die Zuordnung nicht mehr ändert. Der k-means-algorithmus wird im Folgenden dargestellt: Algorithmus 5 k-means-algorithmus Eingabe: n Anfragevektoren V 1,..., V n, Clusteranzahl k Ausgabe: Repräsentanten des Clusterings Setze zufällig k Anfragevektoren als Clustermittelpunkte while Zuordnung ändert sich do Ordne jedem Anfragevektor den nächstgelegenen Mittelpunkt zu Setze neue Mittelpunkte in den Schwerpunkt der zugehörigen Anfragevektoren end while return Menge aller Mittelpunkte V m Ein Problem des k-means-algorithmus ist die Initialisierung des Clusterings. Zum einen muss die Clusteranzahl k gewählt werden und zum anderen müssen die initialen Mittelpunkte bestimmt werden. Dieses Problem kann im SQLIndexWizard

64 54 KAPITEL 3. WORKLOAD-COMPRESSION gelöst werden, indem zuerst der Leader-Algorithmus auf die Anfragevektoren angewendet wird. Der Wert von k wird dann auf die Anzahl der vom Leader-Algorithmus bestimmten Cluster gesetzt und die initialen Clustermittelpunkte sind die Leader des Clusterings. Es besteht aber ebenfalls die Möglichkeit den k-mean-algorithmus ohne vorherige Ausführung des Leader-Algorithmus aufzurufen. In diesem Fall wird der Wert von k festgesetzt, wodurch erreicht werden kann, dass nach dem Clustering höchstens eine bestimmte Anzahl von Anfragen übrig bleibt. Die initialen Anfragevektoren werden in diesem Fall zufällig festgesetzt. Die Laufzeit des k-means-algorithmus ist O(k n r), wobei n die Anzahl der Anfragevektoren, k die Clusteranzahl und r die Anzahl der Iterationen ist. Somit ist seine Laufzeit im Vergleich zu der des Leader-Algorithmus (O(n k)) größer, wenn davon ausgegangen wird, dass mehr als eine Iteration (d. h. r > 1) durchlaufen wird. Da r im Allgemeinen nicht bekannt ist, ist eine genaue Abschätzung der Laufzeit schwierig. Allerdings hat die Praxis gezeigt, dass der k-means-algorithmus relativ schnell konvergiert. Es wird empfohlen, zuerst den Leader-Algorithmus auszuführen, da für einen schlecht gewählten Wert von k das Clustering sehr schlecht werden kann. Das heißt, dass entweder zu wenige Anfragen zurückgegeben werden, wodurch die falschen Indizes bei der Indexauswahl bestimmt werden, oder aber zu viele Anfragen, wodurch die Indexauswahl unnötig lange dauert.

65 Kapitel 4 Index-Advisor In diesem Kapitel wird die Funktionsweise der zweiten Komponente des SQLIndex- Wizards beschrieben, welche Index-Advisor genannt wird. Diese Komponente soll für eine gegebene Menge von Anfragen diejenigen Indizes bestimmen, die für diese Anfragen nützlich sind (Indexauswahl). Dabei darf eine gegebene Speicherplatzbegrenzung nicht überschritten werden. Der Ablauf erfolgt in zwei Schritten: Im ersten Schritt wird für jede Anfrage des nun komprimierten Workloads die Menge der möglichen Indizes bestimmt, wobei diese Indizes gleichzeitig bewertet werden. Im zweiten Schritt werden daraus die nützlichsten Indizes ausgewählt, welche dann die Ergebnismenge bilden. Der Funktionsablauf des Index-Advisors wird in Abbildung 4.1 dargestellt. Die endgültige Empfehlung der zweiten Komponente sieht folgendermaßen aus: virtuelle Indizes, die sich in der Ergebnismenge befinden, sollen erzeugt werden benutzerdefinierte reale Indizes, die sich nicht in der Ergebnismenge befinden, sollen gelöscht werden reale Indizes, die von DB2 benötigt werden (Indizes auf Primär- bzw. Fremdschlüsseln), sollen beibehalten werden Dies ist allerdings nur eine Empfehlung, der Benutzer entscheidet letztendlich, welche Indizes erzeugt bzw. gelöscht werden. 55

66 56 KAPITEL 4. INDEX-ADVISOR Abbildung 4.1: Funktionsablauf des Index-Advisors 4.1 Bewertung der möglichen Indizes Der erste Schritt bestimmt die nützlichen Indizes für eine Menge von Anfragen und bewertet diese. Dazu werden zum einen die Kosten der Anfragen mit vorhandenen Indizes und zum anderen die Kosten der Anfragen unter Einbeziehung von virtuellen Indizes bestimmt. Es müssen hierfür zuerst die virtuellen Indizes angelegt werden, wozu der DB2 -Optimierer im Modus RECOMMEND INDEXES aufgerufen wird. Um die Kosten der Anfragen unter Einbeziehung der vorhandenen Indizes zu bestimmen, wird der Optimierer von DB2 in den Modus EXPLAIN versetzt. In diesem Modus werden die Anfragen nicht ausgeführt, sondern nur deren Ausführungspläne inklusive Kosten bestimmt. Die Kosten der Anfragen unter Einbeziehung der virtuellen Indizes werden im Modus EVALUATE INDEXES bestimmt. Die Kostenersparnis durch die Benutzung von virtuellen Indizes wird auf diese als Nutzen verteilt, sodass jeder benutze virtuelle Index letztendlich einen positiven Nutzwert besitzt. Algorithmus 6 führt die Bestimmung und Bewertung der nützlichen Indizes durch. In diesem Algorithmus werden allerdings benutzerdefinierte reale Indizes nicht berücksichtigt, da sie sowohl im Plan ohne virtuelle Indizes (COST INIT IAL ) als auch im Plan mit virtuellen Indizes (COST V IRT UAL ) benutzt werden. Es ist allerdings wünschenswert, dass sie im Plan ohne die virtuellen Indizes nicht berücksichtigt werden, da dort möglichst keine Indizes benutzt werden sollen.

67 4.1. BEWERTUNG DER MÖGLICHEN INDIZES 57 Folgende Anfrage verdeutlicht das Problem: SELECT FROM SUPPLIER WHERE S_NATIONKEY = 1 ; Anfrage(n) 22: Beispielanfrage für das Problem mit benutzerdefinierten Indizes Es wird davon ausgegangen, dass ein benutzerdefinierter Index auf S_NATIONKEY existiert und dass dieser Index für die Ausführung der Anfrage nützlich ist. Wenn Algorithmus 6 Bewertung der Indizes Eingabe: n SELECT-Anfragen Q 1,..., Q n mit dazugehörigen Clustergrößen c 1,..., c n Ausgabe: Nutzwert (Profit) p(i) für alle nützlichen Indizes 1: Leere die Tabelle ADVISE_INDEX 2: Versetze den Optimierer von DB2 in den Modus RECOMMEND INDEXES 3: for all Angefragte Spalten der Anfragen Q 1,..., Q n do 4: Anfrage: SELECT Spaltenname FROM Tabellenname 5: Dadurch wird ein Eintrag in die ADVISE_INDEX-Tabelle geschrieben, sodass nun ein virtueller Index auf Spaltenname existiert 6: end for 7: for i = 0 to n do 8: Versetze den Optimierer von DB2 in den Modus EXPLAIN 9: Führe Q i aus, dadurch können die Kosten COST INIT IAL und die Menge der benutzten Indizes V INIT IAL unter Berücksichtigung der vorhandenen Indizes bestimmt werden 10: Versetze den Optimierer von DB2 in den Modus EVALUATE INDEXES 11: Führe Q i aus, dadurch können die Kosten COST V IRT UAL und die Menge der benutzten Indizes V V IRT UAL unter Berücksichtigung der vorhandenen und virtuellen Indizes bestimmt werden 12: Setze V Qi = V INIT IAL V V IRT UAL 13: for all Indizes I V Qi do 14: p(i)+ = (COST INIT IAL COST V IRT UAL ) c i V Qi 15: end for 16: end for

68 58 KAPITEL 4. INDEX-ADVISOR dieser Index in beiden Plänen benutzt wird, sind die Kosten in beiden Fällen gleich und der Index bekommt den Nutzwert 0 (da dann COST INIT IAL COST V IRT UAL = 0). Somit wird möglicherweise empfohlen, den Index auf S_NATIONKEY zu löschen, da er den Nutzwert 0 hat, obwohl er für die Anfrage einen Nutzen hat. Wird er also nun im Plan ohne virtuelle Indizes nicht berücksichtigt, erhält er einen positiven Nutzwert (da dann COST INIT IAL COST V IRT UAL ). Dieses Problem lässt sich lösen, indem die Blattanzahl NLEAF des entsprechenden Indexes in der Systemtabelle SYSINDEXES durch eine Updateoperation auf einen sehr hohen Wert gesetzt wird (das Maximum des Wertebereichs des Datentyps). Dadurch wird der Index auf S_NATIONKEY im Plan ohne Berücksichtigung virtueller Indizes nicht mehr benutzt. Nachdem die Anfrage im Modus EXPLAIN ausgeführt wurde, muss die Blattanzahl wieder auf den ursprünglichen Wert zurückgesetzt werden. Dadurch erhalten alle benutzten virtuellen und benutzerdefinierten realen Indizes einen positiven Nutzwert. Von DB2 benötigte Indizes (z. B. Indizes auf Primärbzw. Fremdschlüsseln) werden nicht bewertet, da diese in jedem Fall beibehalten werden. Neben dem Nutzwert für einen Index wird auch dessen Größe für die Indexauswahl benötigt. Diese wird wie folgt berechnet: s(i) = NLEAF P AGESIZE (4.1) Diese Gleichung berechnet die Indexgröße in MegaByte. Der Wert NLEAF gibt die Blattanzahl an, welche für virtuelle Indizes in der Systemtabelle ADVISE_INDEX und für reale Indizes in der Systemtabelle SYSINDEXES gefunden werden kann. Die Seitengröße PAGESIZE in Bytes befindet sich in der Systemtabelle SYSBUFFERPOOLS. Die Indexgröße wird von DB2 mit der gleichen Gleichung berechnet. 4.2 Indexauswahl Nachdem die möglichen Indizes im ersten Schritt bestimmt und bewertet wurden, können anschließend die Indizes bestimmt werden, welche den größten Gesamtnutzen versprechen. Die Selektion ist notwendig, da im Allgemeinen eine Beschränkung des

69 4.2. INDEXAUSWAHL 59 Speicherplatzes gegeben ist. Es entsteht ein Problem, welches sich auf das bekannte Rucksack-Problem zurückführen lässt. Dieses Problem ist NP-vollständig und kann dadurch (wenn P NP) nicht von einem polynomiellen Algorithmus gelöst werden. Somit werden Approximationsalgorithmen verwendet um die Indexmenge mit dem größten Gesamtnutzen zu bestimmen. In diesem Abschnitt wird zuerst das Rucksack-Problem genauer beschrieben und anschließend wird auf zwei Approximationsalgorithmen näher eingegangen Theoretische Aspekte Das Rucksack-Problem wird wie folgt beschrieben: Gegeben sind n Gegenstände g 1,..., g n mit Werten v 1,..., v n und Gewichten w 1,..., w n und eine Gewichtsschranke G. Zulässige Lösungen sind Zahlen a 1,..., a n {0, 1} mit n i=1 a iw i G, das heißt jeder Gegenstand wird entweder vollständig oder gar nicht benutzt. Gesucht ist eine zulässige Lösung mit möglichst großem Gesamtwert n i=1 a iv i. In unserem speziellen Fall der Indexauswahl entsprechen die Gegenstände g i den Indizes I i, die Werte v i dem Nutzwert p(i i ), die Gewichte w i der Größe der Indizes s(i i ) und die Gewichtsschranke G der Speicherplatzbeschränkung Greedy-Algorithmus Der Greedy-Algorithmus (Algorithmus 7) berechnet die Effizienz der Indizes als Quotient zwischen dem Nutzwert und der Größe der Indizes. Die Indizes werden nach Effizienz sortiert und in die Ergebnismenge eingeordnet, bis der verfügbare Speicher gefüllt ist. Der Vorteil des Greedy-Algorithmus ist seine Laufzeit von O(n log n). Allerdings kann die Lösung des Algorithmus beliebig schlecht werden. Dazu kann ein einfaches Beispiel konstruiert werden: Gegeben sei ein Index I 1 mit Größe 1 und Nutzen 2 und ein Index I 2 mit Größe B und Nutzen B (wobei B > 2). Die Gewichtsschranke ist ebenfalls durch B gegeben. Der Algorithmus 7 würde nun zuerst den kleineren Index I 1 auswählen und zur Ergebnismenge M hinzufügen, da sein Nutzen-Größe-Verhältnis größer ist als das vom größeren Index I 2. Anschließend würde aber der größere Index nicht mehr zur Ergebnismenge hinzugefügt werden

70 60 KAPITEL 4. INDEX-ADVISOR Algorithmus 7 Greedy-Algorithmus Eingabe: Menge von Indizes I, jeweils mit Nutzwert p(i) und Größe s(i), Gewichtsschranke G Ausgabe: Menge M empfohlener Indizes 1: Sortiere alle Indizes I nach dem Quotienten aus Nutzwert und Größe ( p(i) s(i) ) 2: Setze M = 3: Setze SIZE = 0 4: while SIZE G do 5: M = M {nächstbester Index I best } 6: SIZE = SIZE + s(i best ) 7: end while 8: return M können, da dadurch die Gewichtsschranke überschritten wird. Der Gesamtnutzen wäre also 2, allerdings würde I 2 alleine die Gewichtsschranke B nicht überschreiten und einen Gesamtnutzen von B (mit B > 2) haben, sodass dies eine bessere Lösung wäre. Dieses Problem kann allerdings behoben werden, indem nach Erreichen der Gewichtsschranke zusätzlich der nächstbeste Index betrachtet wird. Ist dessen Größe kleiner als die Gewichtsschranke und sein Nutzen größer als der Gesamtnutzen der bisher in der Ergebnismenge vorhandenen Indizes, stellt er das Ergebnis dar. Durch diese Erweiterung ist der Greedy-Algorithmus eine 2-Approximation, das heißt seine Lösung ist maximal doppelt so schlecht wie die optimale Lösung. Zur Veranschaulichung von Algorithmus 7 soll folgendes Beispiel dienen: Beispiel 4.1 Gegeben sind vier Indizes, wobei Größe und Nutzen in Tabelle 4.1 zu finden sind. Index p(i) s(i) p(i) s(i) Tabelle 4.1: Beispiel für das Rucksack-Problem

71 4.2. INDEXAUSWAHL 61 Die Gewichtsschranke sei durch 4 gegeben. Es wird nun der Greedy-Algorithmus auf diese vier Indizes angewendet. Nach dem Sortieren nach dem Quotient aus Nutzen und Größe (siehe vierte Spalte in Tabelle 4.1) ergibt sich die folgende Reihenfolge für die vier Indizes: I 4 > I 3 > I 2 > I 1. Es wird zuerst I 4 und anschließend I 3 zur Ergebnismenge M hinzugefügt, wodurch die Größe bei 2 liegt. Der nächstbeste Index I 2 mit Größe 3 kann nicht mehr zu M hinzugefügt werden, da die Gewichtsschranke dadurch überschritten wird. Somit ist M = {I 4, I 3 } mit Gesamtnutzen 4 und Größe 2 die Lösung. Diese Lösung ist nicht optimal, da I 1 noch zur Ergebnismenge hinzugefügt werden könnte ohne die Gewichtsschranke zu überschreiten. Dadurch würde der Gesamtnutzen auf den Wert 5 anwachsen. Zusammenfassend kann festgestellt werden, dass der Greedy-Algorithmus eine gute Laufzeit mit O(n log n) aufweist, allerdings ist seine Lösung möglicherweise doppelt so schlecht wie die optimale Lösung Dynamische Programmierung Eine weitere Methode zur Bestimmung der Indexmenge mit dem größten Gesamtnutzen ist die dynamische Programmierung. Dazu wird eine Funktion g(i, p) für i = 1,..., n und p Z definiert, die den Wert des minimalen Gesamtgewichts einer Teilmenge der ersten i Indizes mit Gesamtnutzen mindestens p wiederspiegelt. Diese Funktion ist wie folgt für alle i = 0,..., n und alle ganzzahligen p definiert: 0 falls p 0 g(i, p) = falls p > 0, i = 0 min {g(i 1, p), s(i i ) + g(i 1, p i)} falls i > 0, p > 0 (4.2) Der optimale Wert für eine Instanz des Rucksack-Problems ist gegeben durch max {p : g(n, p) G}. Folgender Algorithmus berechnet den optimalen Wert:

72 62 KAPITEL 4. INDEX-ADVISOR Algorithmus 8 dynamische Programmierung Eingabe: Menge von n Indizes I, jeweils mit Nutzwert p(i) und Größe s(i), Gewichtsschranke G Ausgabe: Menge M empfohlener Indizes 1: Setze M = und p = 0 2: for i = 0 to n do 3: g(i, 0) = 0 4: end for 5: while g(n, p) G do 6: p = p + 1 7: g(0, p) = 8: for i = 1 to n do 9: if p p(i i ) 0 s(i i ) + g(i 1, p p(i i )) < g(i 1, p) then 10: g(i, p) = s(i i ) + g(i 1, p p(i i ) 11: else 12: g(i, p) = g(i 1, p) 13: end if 14: end for 15: end while 16: for j = p to 1 do 17: if g(n, j) G then 18: p opt = j 19: break 20: end if 21: end for 22: Setze p = p opt 23: for indexp os = n to 0 do 24: if g(indexp os, p) g(indexp os 1, p) then 25: M = M I indexp os 26: p = p p(i indexp os ) 27: if p <= 0 then 28: break 29: end if 30: end if 31: end for 32: return M

73 4.2. INDEXAUSWAHL 63 Dieser Algorithmus berechnet im ersten Teil (bis Zeile 15) die Funktion g(i, p) und anschließend den maximalen Nutzwert p opt (Zeile 16 bis 21). Zuletzt werden daraus die benutzten Indizes bestimmt (Zeile 22 bis 31). Die Funktion g(i, p) kann auch als Tabelle dargestellt werden, indem die Zeilen die Indizes und die Spalten die Nutzwerte repräsentieren. Nun wird erneut Beispiel 4.1 betrachtet und darauf die dynamische Programmierung angewendet. Für p = 0 sind nach Gleichung 4.2 die Werte von g(i, p) für alle i gleich 0. Für p = 1 ergibt sich ebenfalls nach Definition von g(i, p) Folgendes: i=0: g(0, 1) = i=1: g(1, 1) = min {g(0, 1), g(0, 1 1) + 2} = min {, 2} = 2 i=2: g(2, 1) = min {g(1, 1), g(1, 1 2) + 3} = min {2, 3} = 2 i=3: g(3, 1) = min {g(2, 1), g(2, 1 3) + 1} = min {2, 1} = 1 i=4: g(4, 1) = min {g(3, 1), g(3, 1 4) + 1} = min {1, 1} = 1 Die weiteren Werte von g(i, p) berechnen sich mit Hilfe von Gleichung 4.2, sodass sich folgende Tabelle ergibt: g(i, p) Tabelle 4.2: Beispiel für die dynamische Programmierung Da die Gewichtsschranke in Beispiel 4.1 bei 4 liegt, ergibt sich für den optimalen Nutzwert der Wert 5, da max {p : g(4, p) 4} den Wert p = 5 liefert. Die benutzten Indizes werden wie folgt über den zweiten Teil von Algorithmus 8 (Zeile 22 bis 31) bestimmt:

74 64 KAPITEL 4. INDEX-ADVISOR indexpos p M g(indexp os, p) Ergebnisanpassung g(indexp os 1, p) 4 5 { } true M = {I 4 }, p = {I 4 } false {I 4 } true M = {I 4, I 2 }, p = Abbruch da p = 0 Tabelle 4.3: Indexbestimmung für die dynamische Programmierung Somit liefert die dynamische Programmierung M = {I 4, I 2 } also Lösung mit einem Gesamtnutzen von 5. Diese Lösung ist optimal und besser als die des Greedy- Algorithmus, welcher eine Lösung mit einem Gesamtnutzen von 4 ermittelt hat. Die Laufzeit des Algorithmus der dynamischen Programmierung ist durch O(n 2 p max ) gegeben, wobei p max der Größte Wert des Nutzens ist. Diese Laufzeit scheint auf den ersten Blick polynomiell zu sein, da aber die Eingabegröße von p max ( p max ) die Anzahl der benötigten Bits ist, kann p max einen Wert von 2 pmax annehmen. Für eine polynomielle Laufzeit müsste p max aber durch O(log n) beschränkt sein, was im Allgemeinen nicht der Fall ist. Somit ist Algorithmus 8 zwar polynomiell in der Anzahl der Eingabewerte (pseudopolynomiell), aber nicht polynomiell in der Größe bzw. Länge der Eingabe. Es gibt allerdings die Möglichkeit, die Laufzeit der dynamischen Programmierung zu verbessern. Dazu wird der Nutzen von jedem Index nach unten skaliert. Dieser Algorithmus 9 wird in der Literatur auch FPTAS genannt. Er hat eine Laufzeit von O(n 2 p max 1 ) und ist somit schneller als Algorithmus 8. Allerdings verursacht ɛ die verbesserte Laufzeit eine Verringerung der Güte der Lösung, denn die mit Algorithmus 9 berechnete Lösung ist nun nicht mehr optimal, sondern nur noch eine 1 + ɛ-approximation, das heißt sie kann um den Faktor 1 + ɛ schlechter sein als die optimale Lösung. Abschließend kann gesagt werden, dass die dynamische Programmierung im Vergleich zum Greedy-Algorithmus eine genauere Lösung des Problems liefert. Allerdings ist die Laufzeit vom Greedy-Algorithmus besser. Die Praxis hat gezeigt, dass der Greedy-Algorithmus eine ausreichend gute Lösung liefert (siehe Kapitel 6).

75 4.2. INDEXAUSWAHL 65 Algorithmus 9 FPTAS Eingabe: Menge von n Indizes I, jeweils mit Nutzwert p(i) und Größe s(i), Gewichtsschranke G, Faktor ɛ > 0 Ausgabe: Menge M empfohlener Indizes 1: Setze k = n ɛ 2: for all Indizes I i do 3: Setze p(i i ) = p(ii ) p max k 4: end for 5: Führe die dynamische Programmierung mit angepassten Nutzwerten aus und erhalte eine Lösung M 6: return M.

76 66 KAPITEL 4. INDEX-ADVISOR

77 Kapitel 5 Implementation Im Zuge dieser Arbeit wurde ein Programm in der Programmiersprache Java implementiert, welches für gegebene Anfragen (initiales Workload) die nützlichen Indizes ausgibt. Dazu wird das initiale Workload zuerst komprimiert. Anschließend werden nützliche Indizes für die Anfragen des komprimierten Workloads bestimmt und bewertet, sodass letztendlich in Abhängigkeit einer Speicherplatzbeschränkung die nützlichen Indizes selektiert werden. In diesem Kapitel wird auf den Programmablauf eingegangen und es werden Parameter zur Konfiguration beschrieben. Abschließend wird der Programmaufruf beschrieben und die Ausgabe anhand eines Beispielaufrufs erläutert. Eine kurze Beschreibung der Pakete der Implementation ist in Anhang A zu finden. Weiterhin existiert eine Bedienungsanleitung für das Programm auf der beiliegenden CD (Inhalt siehe Anhang C). 5.1 Programmablauf Das Programm liest das initiale Workload ein, komprimiert dieses, bestimmt und bewertet die nützlichen Indizes, wählt daraus die bestmögliche Indexkonfiguration unter Beachtung der Speicherplatzbeschränkung aus und erzeugt letztendlich eine Ausgabe. Der Programmablauf wird in Abbildung 5.1 skizziert. Die sechs Schritte aus der Abbildung werden im Folgenden näher beschrieben. 67

78 68 KAPITEL 5. IMPLEMENTATION Abbildung 5.1: Funktionsablauf der Implementation 1. Schritt: Einlesen der Anfragen Im ersten Schritt wird das initiale Workload generiert. Dazu werden Anfragen aus einer oder mehreren Logdateien eingelesen. Die Anfragen werden geparst und mit entsprechenden Datenstrukturen repräsentiert, wobei zwischen SELECT-, UPDATE-, INSERT- und DELETE-Anfragen unterschieden wird. Alle Teile der Anfragen werden dazu in entsprechende Datenstrukturen überführt, sodass später darauf zugegriffen werden kann. Die WHERE-Klauseln der Anfragen werden hierbei gegebenenfalls in KNF bzw. DNF überführt. Anfragen, die nicht geparst werden können, werden ebenfalls im Workload als Zeichenketten gespeichert. Dies liegt daran, dass der benutzte Parser (Zql, nicht unterstütze SQL-Anfragen (z. B. mit Unteranfragen) nicht parst. Für diese Anfragen wird keine Workload-Compression durchgeführt, sie werden allerdings im Index-Advisor trotzdem berücksichtigt, das heißt es werden auch dafür nützliche Indizes bestimmt und bewertet. 2. Schritt: Partitionierung Nachdem das initiale Workload erzeugt wurde, wird dieses komprimiert. Dazu

79 5.1. PROGRAMMABLAUF 69 werden in diesem Schritt zuerst Partitionen gebildet (siehe Abschnitt 3.2). 3. Schritt: Clustering Bevor das Clustering durchgeführt werden kann, müssen zuerst die Selektivitäten für alle Prädikate der Anfragen des initialen Workloads berechnet werden (siehe Abschnitt 2.6). Daraus können anschließend die Anfragevektoren erzeugt werden (siehe Abschnitt 3.3). Im Anschluss wird für jede Partition das Clustering mit dem ausgewählten Clustering-Algorithmus durchgeführt (siehe Abschnitt 3.4). Nun ist das komprimierte Workload erzeugt. 4. Schritt: Bewertung der Indizes Für alle Anfragen des komprimierten Workloads werden in diesem Schritt die nützlichen Indizes bestimmt und bewertet (siehe Abschnitt 4.1). Zuerst werden dazu die virtuellen Indizes angelegt, indem jeweils ein Eintrag in der Systemtabelle ADVISE_INDEX erzeugt wird. Anschließend werden für jede Anfrage die Ausführungspläne mit Kosten unter Berücksichtigung der aktuellen Indexkonfiguration (mit Ausnahme der benutzerdefinierten Indizes) und unter Berücksichtigung der virtuellen Indizes erzeugt, sodass der Nutzen für die virtuellen Indizes ermittelt werden kann. Weiterhin wird in diesem Schritt die Größe der Indizes berechnet. 5. Schritt: Indexauswahl Aus allen bewerteten nützlichen Indizes werden nun mit dem entsprechenden Rucksack-Algorithmus die nützlichsten Indizes bestimmt, sodass die Speicherplatzbeschränkung eingehalten wird (siehe Abschnitt 4.2). 6. Schritt: Erzeugung der Ausgabe Abschließend wird die Ausgabe erzeugt. Es wird empfohlen, dass alle virtuellen Indizes aus der Menge der nützlichsten Indizes erzeugt werden. Alle benutzerdefinierten realen Indizes, welche nicht in dieser Menge enthalten sind, sollen gelöscht

80 70 KAPITEL 5. IMPLEMENTATION werden. Die SQL-Befehle für diese Empfehlung werden in einer Textdatei gespeichert. 5.2 Konfiguration Das Programm wurde variabel implementiert, das heißt, es können viele Parameter vom Entwickler festgelegt werden. Dabei handelt es sich um die folgenden Parameter: Format der WHERE-Klausel der Anfragen: CNF, DNF oder keine Umformung Clustering-Algorithmus: Leader-Algorithmus, k-means-algorithmus bzw. beide Algorithmen Schwellwert ρ für den Leader-Algorithmus Wert k für den k-means-algorithmus Methode für die Ähnlichkeitsbestimmung der WHERE-Klauseln Rucksack-Algorithmus: Greedy-Algorithmus oder dynamische Programmierung Wert ɛ für die dynamische Programmierung Weiterhin kann der Entwickler ein von DB2 verschiedenes DBMS verwenden, indem er die Klassen im Paket dbconnection anpasst. Auch weitere Methoden für die Ähnlichkeitsbestimmung der WHERE-Klauseln können implementiert und auch verwendet werden. Der Benutzer kann ebenfalls Einstellungen in einer Konfigurationsdatei (sqlindexwizard.properties) vornehmen: Konfiguration der Datenbankverbindung (Host, Benutzername, Passwort, Datenbankschema) Periode, in der das Tool RUNSTATS ausgeführt werden soll Speicherplatzbegrenzung für die Indexauswahl Speicherort und Name für die Ausgabedatei

81 5.3. PROGRAMMAUFRUF Programmaufruf Das Programm befindet sich in einer ausführbaren JAR-Datei und wird mit den Logdateien, in der sich die Anfragen befinden, als Parameter aufgerufen. Im Folgenden wird ein Programmaufruf dargestellt: amsel daeumlic 28 ( ~/ ) > java -jar SQLIndexWizard.jar demo.txt Workload-Compression Algorithm: Leader BoundValue: 0.95 initial Workload: SELECT * FROM LINEITEM WHERE (LINEITEM.L_SUPPKEY = 5); SELECT * FROM LINEITEM WHERE ((LINEITEM.L_SUPPKEY = 5) AND (LINEITEM.L_EXTENDEDPRICE > 910.0)); SELECT * FROM LINEITEM WHERE (LINEITEM.L_SUPPKEY = 7); SELECT * FROM NATION WHERE (NATION.N_NATIONKEY = 5); SELECT * FROM NATION WHERE (NATION.N_NATIONKEY = 8); nrqueries: 5 compressed Workload: SELECT * FROM LINEITEM WHERE (LINEITEM.L_SUPPKEY = 5); SELECT * FROM NATION WHERE (NATION.N_NATIONKEY = 5); nrqueries: 2

82 72 KAPITEL 5. IMPLEMENTATION Clustering Ratio: 2/5 = Index-Advisor /2 [====================] Algorithm: Greedy Space-Constraint: 80.0 Index-Space: Total Benefit: Recommended Indexes: IDX (LINEITEM.L_SUPPKEY) Deleteable Indexes: NATIONUD(NATION.N_REGIONKEY) amsel daeumlic 29 ( ~/ ) > Das Programm wird mit der Datei demo.txt aufgerufen, welche fünf Anfragen enthält. Die Workload-Compression wird mit dem Leader-Algorithmus mit Schwellwert 0,95 durchgeführt und es bleiben zwei Anfragen übrig. Der Index-Advisor stellt mit dem Greedy-Algorithmus fest, dass ein Index auf der Spalte L_SUPPKEY der Tabelle LINEITEM nützlich ist. Der benutzerdefinierte Index auf N_REGIONKEY der Tabelle NATION wird hingegen nicht mehr benötigt.

83 Kapitel 6 Evaluierung In diesem Kapitel wird das im Zuge dieser Arbeit implementierte Programm evaluiert. Das Problem dabei bestand darin, dass sowohl geeignete Daten als auch Anfragen gefunden werden mussten. Als Datensatz wurden die Daten des TPC-H-Schemas benutzt, welches in [Cou08] beschrieben wird. Dazu existieren 22 Anfragen, welche für gängige Performance-Benchmarks benutzt werden. Diese Anfragen sind allerdings zumeist sehr komplex, das heißt sie enthalten entweder Unteranfragen oder Funktionen in Aggregation, welche aufgrund der Einschränkungen aus Abschnitt nicht für die Workload-Compression berücksichtigt werden. Somit können diese Anfragen nicht für die Evaluierung benutzt werden. Aus diesem Grund wurde ein einfacher Anfragegenerator implementiert, welcher zufällige Anfragen für das TPC-H-Schema generiert. Im Folgenden werden zuerst das TPC-H-Schema und der Anfragegenerator eingeführt. Anschließend werden die Workload-Compression-Komponente und der Index- Advisor evaluiert. 6.1 Zugrunde liegende Daten und Anfragen In diesem Abschnitt werden das TPC-H-Schema und der dafür implementierte Anfragegenerator beschrieben. 73

84 74 KAPITEL 6. EVALUIERUNG TPC-H Das TPC-H-Schema enthält acht Tabellen, wobei sechs der Tabellen eine variable Anzahl von Tupeln enthalten können. Das TPC-H-Schema inklusive Beziehungen zwischen den Spalten wird in Abbildung 6.1 skizziert. Abbildung 6.1: TPC-H Schema 8 Dabei entsprechen die Werte in Klammern nach den Tabellennamen dem Prefix vor den Spalten der jeweiligen Tabelle und die Pfeile skizzieren die Fremdschlüsselbeziehungen zwischen den Tabellen. Die Formel unter den Tabellennamen steht für die Kardinalität der jeweiligen Tabelle. Für die nachfolgenden Tests wurde der Wert von SF auf 1 gesetzt, sodass im gesamten Schema Tupel vorhanden 8 Abbildung aus [Cou08]

85 6.1. ZUGRUNDE LIEGENDE DATEN UND ANFRAGEN 75 sind. Die Daten werden von einem Generator (DBGEN) generiert, wobei die Werte gleichverteilt sind Anfragegenerator Da die vom TCH-Schema zur Verfügung gestellten Anfragen zu komplex sind und somit vom SQLIndexWizard für die Workload-Compression nicht berücksichtigt werden, wurde ein einfacher Anfragegenerator implementiert. Er erzeugt einfache Anfragen mit existenten Werten für die Spalten der einzelnen Tabellen. Dabei werden Anfragen mit den folgenden Eigenschaften generiert, wobei die entsprechenden Wahrscheinlichkeiten eingestellt werden können: eine oder zwei angefragte Tabellen (mit Wahrscheinlichkeit) zufällige Anzahl von Elementen in der SELECT-Klausel bzw. Wildcard Aggregationen auf die Elemente in der SELECT-Klausel WHERE-Klausel mit zufälliger Anzahl von Prädikaten (mit Wahrscheinlichkeit) GROUP BY-Klausel mit zufälliger Anzahl von Elementen ORDER BY-Klausel mit zufälliger Anzahl von Elementen Equi-Joins in der WHERE-Klausel Für die Existenz jeder Klausel können Wahrscheinlichkeiten angegeben werden und für die Anzahl der Elemente bzw. Prädikate kann ein Maximalwert festgelegt werden. Die logischen Operatoren zur Verknüpfung von Prädikaten der WHERE-Klausel und die Operatoren und Werte der Prädikate werden zufällig ausgewählt. Mit dem Generator lassen sich somit beliebig viele zufällige Anfragen generieren Testdaten und Testsystem Als Testdaten dienen Anfragen, welche mit dem Anfragegenerator aus dem vorangegangenen Abschnitt generiert wurden. Es handelt sich dabei ausschließlich

86 76 KAPITEL 6. EVALUIERUNG um Selektionsanfragen, da der Index-Advisor keine Modifikationsanfragen unterstützt (siehe Abschnitt 2.3.2). Die Anfragen haben folgende Eigenschaften: zufällig ein oder zwei Tabellen in der FROM-Klausel bis zu drei Elemente in der SELECT-Klausel bis zu fünf Prädikate in der WHERE-Klausel mit Wahrscheinlichkeit von 10% ein Equi-Join mit Wahrscheinlichkeit von 20% Aggregationen in der SELECT-Klausel mit Wahrscheinlichkeit von 10% eine GROUP BY-Klausel mit Wahrscheinlichkeit von 10% eine ORDER BY-Klausel Als Testsystem wurde ein PC mit einem 1.6 GHz Prozessor und 1 GB Arbeitsspeicher verwendet, auf dem DB2 in der Version 9.5 installiert ist. 6.2 Workload-Compression-Komponente In diesem Abschnitt wird die Workload-Compression-Komponente evaluiert. Dazu werden zuerst die verschiedenen Methoden zur Ähnlichkeitsbestimmung, welche in Kapitel 3.3 beschrieben werden, verglichen. Anschließend wird der Schwellenwert für den Leader-Algorithmus evaluiert. Zudem werden abschließend die beiden Clustering-Algorithmen (Leader-Algorithmus und k-means-algorithmus) gegenübergestellt Vergleich der Methoden zur Ähnlichkeitsbestimmung Zum Vergleich der vier Methoden zur Ähnlichkeitsbestimmung wurde jede Methode aus 3.3, das heißt die drei Varianten des Ansatzes über Anfragevektoren und der Ansatz über die Struktur der Anfragen, mit den Testanfragen aufgerufen. Dazu wurde als Clustering-Algorithmus stets der Leader-Algorithmus mit Schwellwert 0,95 (Begründung siehe Abschnitt 6.2.2) verwendet und die Indexauswahl wurde stets mit dem Greedy-Algorithmus mit einer Speicherplatzbeschränkung von 80 MB

87 6.2. WORKLOAD-COMPRESSION-KOMPONENTE 77 durchgeführt. Es wurden anschließend die Anzahl der Anfragen im komprimierten Workload, die Laufzeiten der Workload-Compression-Komponente, des Index-Advisors und des Gesamtvorgangs und die ermittelten Indexkonfigurationen bestimmt. Die durch die komprimierten Workloads bestimmten Indexkonfigurationen wurden schließlich mit der Indexkonfiguration verglichen, die bei Anwendung des Index-Advisors auf das initiale Workload ermittelt wurde. Die Ergebnisse sind in Tabelle 6.1 zu finden: ohne Anfragevektoren Struktur Variante 1 Variante 2 Variante 3 Anfragen vor Kompression Anfragen nach Kompression Partitionen Laufzeit 0:00 Min 0:15 Min 0:15 Min 0:15 Min 0:14 Min Workload- Compression Laufzeit Index- 65:13 Min 9:30 Min 12:50 Min 18:22 Min 30:15 Min Advisor Laufzeit Gesamt 65:13 Min 9:45 Min 13:05 Min 18:37 Min 30:29 Min Indexkonfiguration I 1 I 2 I 2 I 2 I 2 Tabelle 6.1: Evalierung der Methoden zur Ähnlichkeitsbestimmung Es wird festgestellt, dass die Workload-Compression-Komponente mit dem Ansatz über die Struktur der Anfragen die meisten Anfragen zurückgibt. Dieses Ergebnis war zu erwarten, da nur strukturell ähnliche Anfragen in ein Cluster eingeordnet werden können und sich im Allgemeinen viele Anfragen in ihrer Struktur unterscheiden. Die erste Variante der Anfragevektoren liefert die wenigsten Anfragen, gefolgt von der zweiten und dritten Variante. Auch dieses Ergebnis war zu erwarten, da in der zweiten Variante Anfragen, die in der ersten Variante noch komplett ähnlich waren, einen unterschiedlichen Wert für die Ähnlichkeit erhalten und so-

88 78 KAPITEL 6. EVALUIERUNG mit in verschiedene Cluster eingeordnet werden. Der gleiche Sachverhalt tritt auch beim Vergleich zwischen der zweiten und dritte Variante auf, denn auch in der dritten Variante wurde die Ähnlichkeitsbestimmung im Vergleich zur zweiten Variante nochmals verfeinert. Somit werden mit der dritten Variante im Vergleich zu den ersten beiden Varianten die meisten Anfragen zurückgegeben. Die Anzahl der Partitionen ist mit 451 für alle Methoden identisch, da die Bestimmung der Partitionen unabhängig von der Methode zur Ähnlichkeitsbestimmung ist. Auch für den Ansatz über die Struktur der Anfragen wird zuerst die Partitionierung wie beim Ansatz über Anfragevektoren durchgeführt, erst im Anschluss beim Vergleich der Anfragen in einer Partition wird die Struktur der WHERE-Klauseln verglichen. Die Indexkonfigurationen, die durch die komprimierten Workloads ermittelt wurden, sind für alle vier Methoden zur Ähnlichkeitsbestimmung identisch. Diese Indexkonfiguration I 2 unterscheidet sich allerdings von der Indexkonfiguration I 1, die durch Anwendung des Index-Advisors auf das initiale Workload ermittelt wurde, um einen Index (siehe Tabelle B.1). Nun muss noch getestet werden, welche Zeit für die Ausführung der Testanfragen mit den beiden Indexkonfigurationen benötigt wird und ob aus der Workload-Compression ein Vorteil resultiert. Die Testergebnisse sind folgender Tabelle zu finden: I 1 I 2 Laufzeit SQLIndexWizard 1:05:13 Std 0:09:45 Std Laufzeit Anfragen 29:58:16 Std 30:12:38 Std Gesamtlaufzeit 31:03:29 Std 30:22:23 Std Tabelle 6.2: Evaluierung der Nützlichkeit der Workload-Compression Aus den Tests wird deutlich, dass die Anfragen mit der Indexkonfiguration I 1, für die der Index-Advisor mit dem initialen Workload aufgerufen wurde, schneller ausgeführt werden als mit der Indexkonfiguration I 2, die mit dem komprimierten Workload ermittelt wurde. Die Zeitersparnis liegt bei ca. 0,8%. Wenn allerdings die Laufzeit des SQLIndexWizard ebenfalls berücksichtigt wird, resultiert aus der Workload-Compression ein Vorteil von ca. 41 Minuten, was einer Zeitersparnis von ca. 2,2% entspricht.

89 6.2. WORKLOAD-COMPRESSION-KOMPONENTE 79 Somit wird durch die Workload-Compression ein Vorteil erzielt Evaluierung des Schwellenwertes des Leader- Algorithmus Im vorangegangenen Abschnitt wurde als Schwellenwert für den Leader-Algorithmus der Wert 0,95 benutzt. Nach der Durchführung von Tests für verschiedene Schwellenwerte hat sich herausgestellt, dass dieser Wert besonders günstig ist. Tabelle 6.3 zeigt die ermittelten Indexkonfigurationen bei verschiedenen Werten für den Schwellenwert unter Benutzung der vier Methoden zur Ähnlichkeitsbestimmung der WHERE-Klauseln. Es wurden stets der Leader-Algorithmus für das Clustering und der Greedy-Algorithmus für die Indexauswahl (Speicherplatzbeschränkung 80 MB) verwendet. Schwellenwert Anfragevektoren Struktur Variante 1 Variante 2 Variante 3 0,9 I 2 I 2 I 2 I 3 0,925 I 2 I 2 I 2 I 3 0,95 I 2 I 2 I 2 I 2 0,975 I 2 I 2 I 2 I 2 1,0 I 2 I 2 I 2 I 2 Tabelle 6.3: Evalierung des Schwellenwertes des Leader-Algorithmus Es wird deutlich, dass für Schwellenwerte ab 0,95 mit allen Methoden zur Ähnlichkeitsbestimmung der WHERE-Klauseln die Indexkonfiguration I 2 ermittelt wird, für Werte kleiner als 0,95 hingegen wird mit der Methode über die Struktur der Anfragen die Indexkonfiguration I 3 ermittelt. Nun wurden die Zeiten für die Ausführung der Anfragen unter den Indexkonfigurationen I 2 und I 3 bestimmt. Die Ergebnisse sind in folgender Tabelle zu finden: Mit Indexkonfiguration I 2 werden die Anfragen schneller ausgeführt als mit Indexkonfiguration I 3. Auch unter Berücksichtigung der Laufzeit des Werkzeugs ist die Laufzeit für die Indexkonfiguration I 2 besser. Somit wird als Schwellenwert für den Leader-Algorithmus der Wert 0,95 empfohlen. Mit einem geringeren Wert wird ei-

90 80 KAPITEL 6. EVALUIERUNG I 2 I 3 Laufzeit Werkzeug 0:30:29 Std 0:31:20 Std Laufzeit Anfragen 30:12:38 Std 30:29:47 Std Gesamtlaufzeit 30:43:07 Std 31:01:07 Std Tabelle 6.4: Vergleich der Laufzeiten der Anfragen für verschiedene Schwellenwerte ne Indexkonfiguration ermittelt, für die die Anfragen langsamer ausgeführt werden. Höhere Werte ermitteln zwar die gleiche Indexkonfiguration, die Laufzeit des SQL- IndexWizard ist dadurch jedoch größer, da nach der Workload-Compression mehr Anfragen übrig bleiben (siehe B.2) Vergleich der Clustering-Algorithmen Dieser Abschnitt vergleicht die beiden Clustering-Algorithmen. Dazu wurden die Anfragen zuerst mit dem Leader-Algorithmus und anschließend mit dem k-means- Algorithmus komprimiert (bei vorheriger Anwendung des Leader-Algorithmus). Der Index-Advisor wird mit dem Greedy-Algorithmus und einer Speicherplatzbeschränkung von 80 MB aufgerufen. Die Laufzeiten und die ermittelten Indexkonfigurationen wurden ermittelt und miteinander verglichen, die Ergebnisse sind in Tabelle 6.5 zu finden. Leader-Algorithmus k-means-algorithmus Anfragen vor Kompression Anfragen nach Kompression Laufzeit Kompression 0:15 Min 0:22 Min Laufzeit Index-Advisor 9:30 Min 9:55 Min Indexkonfiguration I 2 I 2 Tabelle 6.5: Vergleich der Clustering-Algorithmen Die Indexkonfigurationen, die durch beide Algorithmen ermittelt wurden, sind identisch. Auch die Anzahl der Anfragen nach der Kompression unterscheidet sich nicht. Die Laufzeit des k-means-algorithmus ist minimal länger (25 Sekunden) als

91 6.3. INDEX-ADVISOR 81 die des Leader-Algorithmus, wobei dieses Ergebnis zu erwarten war, da für eine geeignete Initialisierung des k-means-algorithmus zuerst der Leader-Algorithmus angewendet wurde. Somit scheint der Leader-Algorithmus für die durchgeführten Tests ein ausreichend gutes Ergebnis zu erzielen, allerdings wird trotzdem die Anwendung des k-means-algorithmus empfohlen, da er nur minimal mehr Zeit benötigt (25 Sekunden) und in der Theorie ein qualitativ besseres Clustering verspricht. 6.3 Index-Advisor Dieser Abschnitt evaluiert den Index-Advisor. Dazu wird zuerst getestet, ob die empfohlenen Indizes überhaupt nützlich für die Testanfragen sind. Anschließend werden die Algorithmen für die Indexauswahl miteinander verglichen Funktionalität Zum Test der Funktionalität des Index-Advisors wurden die Testanfragen zuerst ohne Indizes und anschließend mit den vom SQLIndexWizard empfohlenen Indizes (bei Ausschaltung der Workload-Compression, Indexkonfiguration I 1 ) ausgeführt. Die entsprechenden Laufzeiten sind in Tabelle 6.6 zu finden. keine Indizes Indizes des SQLIndexWizard Laufzeit Werkzeug 0:00:00 Std 1:05:13 Std Laufzeit Anfragen 38:22:12 Std 29:58:16 Std Gesamtlaufzeit 38:22:12 Std 31:03:29 Std Tabelle 6.6: Evaluierung der Funktionalität des Index-Advisors Es wird deutlich, dass durch die vom SQLIndexWizard empfohlenen Indizes ca. 8,5 Stunden bei der Ausführung der Anfragen eingespart werden, was einer Zeitersparnis von ca. 21,9% entspricht. Selbst wenn die Laufzeit des SQLIndexWizard berücksichtigt wird, werden immernoch ca. 7,4 Stunden und somit ca. 19,3% eingespart. Somit ist die Funktionalität des Index-Advisors für die Testanfragen nachgewiesen, da die Anfragen mit den empfohlenen Indizes schneller ausgeführt werden

92 82 KAPITEL 6. EVALUIERUNG als ohne Indizes Vergleich der Algorithmen für die Indexauswahl Der Vergleich zwischen den beiden Algorithmen wurde folgendermaßen durchgeführt: Es wurde die Workload-Compression (Parameter: Leader-Algorithmus, Schwellwert 0,95, Ähnlichkeitsbestimmung mit Variante 1 der Anfragevektoren) durchgeführt und anschließend wurden die Anfragen des komprimierten Workloads bewertet, sodass eine Menge von bewerteten Indizes gegeben ist. Nun wurden beide Algorithmen auf diese Indizes angewendet (Speicherplatzbeschränkung 80 MB), wobei die Indexkonfigurationen und die Laufzeiten der Algorithmen bestimmt wurden. Die Ergebnisse sind in Tabelle 6.7 zu finden: Greedy-Algorithmus dynamische Programmierung Laufzeit Indexauswahl 0:15 Min 2:47 Min Gesamtlaufzeit 9:30 Min 12:02 Min Indexkonfiguration I 2 I 2 Tabelle 6.7: Vergleich der Algorithmen für die Indexauswahl Es wird festgestellt, dass die Laufzeit des Greedy-Algorithmus ca. zehn Mal so hoch ist wie die des Greedy-Algorithmus, wobei die ermittelten Indexkonfigurationen identisch sind. Für die dynamische Programmierung musste der Algorithmus 9 (FPTAS) ausgeführt werden, da ansonsten der zur Verfügung gestellte Arbeitsspeicher von 1 GB nicht ausreicht. Dadurch wird unter Umständen keine optimale Lösung mehr ermittelt. Der hohe Speicherverbrauch liegt an den hohen Werten für den Nutzen der Indizes, welcher bei vielen Anfragen entsteht. Somit wird empfohlen, den Greedy-Algorithmus zu verwenden, da die dynamische Programmierung für die durchgeführten Tests keinen Vorteil offenbart.

93 6.4. VERGLEICH MIT DEM DB2 DESIGN ADVISOR Vergleich mit dem DB2 Design Advisor In diesem Abschnitt wird der SQLIndexWizard mit dem DB2 Design Advisor verglichen. Dazu wurden die Anfragen zuerst an den SQLIndexWizard (Leader- Algorithmus mit Schwellwert 0,95, Greedy-Algorithmus) und anschließend an den DB2 Design Advisor übergeben, wobei der Speicherplatz durch 80 MB beschränkt ist. Zuerst wurden die Laufzeiten der Werkzeuge und die Indexkonfigurationen ermittelt. Anschließend wurden die Anfragen ausgeführt und die dafür benötigte Zeit wurde gemessen. Die Ausführung erfolgte mit den folgenden drei Indexkonfigurationen: keine Indizes (nur Indizes auf Primär- bzw. Fremdschlüsseln) Indizes vom SQLIndexWizard empfohlen (mit Workload-Compression) (I 2 ) Indizes vom DB2 Design Advisor empfohlen (I 4 ) Die ermittelten Werte sind in Tabelle 6.8 zu finden. ohne SQLIndexWizard DB2 Design Advisor Laufzeit Werkzeug 0:00:00 Std 0:09:45 Std 0:12:22 Std Indexkonfiguration - I 2 I 4 Laufzeit Anfragen 38:22:12 Std 30:12:38 Std 28:34:24 Std Gesamtlaufzeit 38:22:12 Std 30:22:23 Std 28:46:46 Std Tabelle 6.8: Vergleich mit dem DB2 Design Advisor Es wird festgestellt, dass der DB2 Design Advisor eine längere Laufzeit als der SQLIndexWizard aufweist, da er auch Mehrattributindizes betrachtet. Die ermittelten Indexkonfigurationen stimmen in der Hälfte der Indizes überein (siehe Tabelle B.1). Es wird zudem deutlich, dass der DB2 Design Advisor Mehrattributindizes ermittelt. Die beiden Spalten der Mehrattributindizes, die der DB2 Design Advisors empfiehlt, werden vom SQLIndexWizard als zwei Einattributindizes empfohlen, sodass auch hier gewisse Parallelen zu erkennen sind. Bei Betrachtung der

94 84 KAPITEL 6. EVALUIERUNG Laufzeit der Anfragen offenbart der DB2 Design Advisor einen Vorteil, was durch die Mehrattributindizes auch zu erwarten war. Es werden ca. 1,5 Stunden eingespart, was einer Zeitersparnis von 5% entspricht. Diese Ersparnis verändert sich auch bei Betrachtung der Laufzeiten der Werkzeuge kaum, da der Unterschied zwischen den Laufzeiten beider Werkzeuge nur ca. 2,5 Minuten beträgt. 6.5 Zusammenfassung der Ergebnisse Die Evaluierung des SQLIndexWizard hat gezeigt, dass sowohl die Workload- Compression-Komponente als auch der Index-Advisor für die gegebenen Anfragen Vorteile offenbaren. Auch im Vergleich zum DB2 Design Advisor ist der SQLIndexWizard nur um ca. 5% langsamer. Diese Ergebnisse beziehen sich allerdings nur auf die generierte Testanfragen und auf die gleichverteilten Testdaten des TPC-H-Schemas. Um den wirklichen Nutzen für die Praxis zu ermitteln, sollten reale Daten und Anfragen für die Evaluierung benutzt werden. Diese standen aber leider nicht zur Verfügung. Die anhand der benutzten Daten ermittelten Testergebnisse sind allerdings sehr vielversprechend.

95 Kapitel 7 Zusammenfassung In diesem Kapitel werden die Ergebnisse der Arbeit zusammengefasst, es wird deren Nutzen für die Praxis erläutert und ein Ausblick auf weiterführende Arbeiten gegeben, in denen die Ergebnisse dieser Arbeit verwendet werden können. In dieser Diplomarbeit wurde ein Workload-Compressing-Index-Wizard für relationale Datenbanken entwickelt, welcher zuerst eine Workload-Compression und anschließend eine Indexauswahl für eine gegebene Menge von Anfragen (Workload) durchführt. Die Grundlage dafür war der DirXWiz, welcher für die LDAP- Anfragesprache entwickelt wurde. Die darin benutzten Konzepte wurden auf die relationale Sprache SQL übertragen und verfeinert. Für die Beispielimplementation wurde das relationale DBMS DB2 von IBM verwendet, wobei eine Übertragung der Konzepte auch auf andere relationale Systeme ohne weiteres möglich ist. Bei der Entwicklung der Workload-Compression-Komponente musste zuerst ein Ähnlichkeitsmaß für SQL-Anfragen entwickelt werden. Es stellte sich heraus, dass einige Anfragen schon von der Struktur her keine Ähnlichkeit bezüglich der nützlichen Indizes aufweisen, z. B. wenn auf verschiedene Tabellen zugegriffen wird. Somit wurden die Anfragen zuerst in Partitionen eingeteilt. Für Anfragen in einer Partition wurden dann die WHERE-Klauseln miteinander verglichen, wofür verschiedene Ansätze entwickelt wurden. Zum einen wurde der Ansatz des DirXWiz benutzt, welcher anschließend verfeinert wurde, und zum anderen wurde ein Ansatz aus der Literatur ([Kol08]) aufgegriffen. Nachdem das Ähnlichkeitsmaß definiert wurde, konnten gängige Clustering-Algorithmen benutzt werden, um die Anfragen einer Partition 85

96 86 KAPITEL 7. ZUSAMMENFASSUNG zu gruppieren. Der Index-Advisor musste zuerst die nützlichen Indizes ermitteln und bewerten. Dafür wurden spezielle Modi des Optimierers von DB2 benutzt. Die Indexauswahl wurde anschließend mit Hilfe bekannter Approximationsalgorithmen durchgeführt. Im Zuge dieser Arbeit wurde ein Programm implementiert, welches die Workload- Compression und Indexauswahl durchführt. Dieses Programm wurde so implementiert, dass durch den Austausch von wenigen Klassen ein von DB2 verschiedenes relationales DBMS eingesetzt werden kann. Die Evaluierung der Implementation hat den Nutzen des SQLIndexWizard gezeigt. Sowohl die Workload-Compression-Komponente als auch der Index-Advisor offenbarten Vorteile. Im Vergleich zum DB2 Design Advisor war der SQLIndex- Wizard langsamer, was daran liegt, dass keine Mehrattributindizes berücksichtigt werden. Somit können die Konzepte des SQLIndexWizard in der Praxis eingesetzt werden, z. B. zur Entwicklung eines Index-Wizards für relationale DBMS, welche noch keinen Index-Wizard zur Verfügung stellen. In weiterführenden Arbeiten können die Konzepte der Workload-Compression für die Verwendung von Mehrattributindizes angepasst werden. Eine weitere Möglichkeit zur Weiterentwicklung wäre die Betrachtung der gesamten Sprache SQL bei der Workload-Compression. Weiterhin können Modifikationsanfragen für den Index- Advisor berücksichtigt werden. Außerdem sollten Tests mit Realdaten durchgeführt werden, um den Nutzen in der Praxis zu verifizieren.

97 Anhang A Kurzbeschreibung der Implementation Dieser Bereich des Anhangs beschreibt die Implementation. Zuerst werden die Pakete und anschließend die Klassen anhand von Klassendiagrammen beschrieben. A.1 Paketbeschreibung Im Folgenden gibt es eine kurze Beschreibung der Pakete der Implementation, welche in der Programmiersprache Java implementiert wurde. application: Dieses Paket enthält das Hauptprogramm. Dieses muss mit einer oder mehreren Logdateien als Argument aufgerufen werden. Weiterhin ist eine Klasse mit Optionen für das Programm enthalten. clustering: Alle Klassen für die Workload-Compression-Komponente sind in diesem Paket enthalten. Dabei handelt es sich um Klassen für die Partitionierung, für die Anfragevektoren und für die Clustering-Algorithmen. dbconnection: Die Klassen, welche für den Verbindungsaufbau zur Datenbank bzw. für die Anfragen an die Datenbank verantwortlich sind, befinden sich in diesem Paket. Wenn also ein anderes DBMS als DB2 verwendet werden soll, müssen lediglich diese Klassen angepasst bzw. ersetzt werden. 87

98 88 ANHANG A. KURZBESCHREIBUNG DER IMPLEMENTATION filter: Dieses Paket ist für die Repräsentation der WHERE-Klausel und der Elemente der anderen Klauseln (SELECT-, GROUP BY- und ORDER BY- Klausel) verantwortlich. indexadvisor: In diesem Paket ist der Index-Advisor enthalten. Es werden Indizes repräsentiert und es sind die Algorithmen für das Rucksack-Problem (Greedy und dynamische Programmierung) implementiert. querygen: Der in Kapitel beschriebene Anfragegenerator ist in diesem Paket implementiert. util: In diesem Paket sind Werkzeuge beispielsweise für das Einlesen der Konfiguration aus der Konfigurationsdatei oder für das Logging enthalten. workload: Die Repräsentation des Workloads befindet sich in diesem Paket. Dazu gehören Klassen für die 4 Anfragetypen. Auch das Einlesen und Parsen der Anfragen aus den Logdateien ist in diesem Paket implementiert. Die Pakete der Implementation sind größtenteils miteinander verknüpft. Beide Komponenten des SQLIndexWizard (Workload-Compression-Komponente und Index-Advisor) werden vom Hauptprogramm (Paket application) aufgerufen. Die Workload-Compression-Komponente (Paket clustering) erhält als Eingabe ein Workload (Paket workload) und gibt ebenfalls ein Workload aus, welches der Index-Advisor (Paket indexadvisor) wiederum als Eingabe erhält. Ein Workload enthält Anfragen mit Klauseln (z. B. WHERE-, SELECT-, ORDER BY- oder GROUP BY-Klausel), repräsentiert im Paket filter. Weiterhin kommunizieren sowohl die Workload-Compression-Komponente als auch der Index-Advisor mit dem relationalen DBMS DB2 (Paket dbconnection). Die Abhängigkeiten der Pakete werden in der folgenden Abbildung skizziert:

99 A.2. KLASSENDIAGRAMME 89 Abbildung A.1: Abhängigkeiten der Pakete der Implementation A.2 Klassendiagramme In diesem Abschnitt wird zu jedem Paket ein Klassendiagramm beschrieben. application Das Paket application enthält die Klassen Main.java, welche die beiden Komponenten ausführt, und Input.java, in der Konfigurationsparameter enthalten sind. Abbildung A.2: Abhängigkeiten im Paket application

100 90 ANHANG A. KURZBESCHREIBUNG DER IMPLEMENTATION clustering Im Paket clustering wird die Workload-Compression durchgeführt. Die Hauptklasse dafür ist die Klasse WorkloadCompression.java. Darin wird zuerst das Clustering vorbereitet über PrepareClustering.java, indem die Selektivitäten für alle Prädikate der WHERE-Klauseln bestimmt werden. Anschließend werden Partitionen (ListOfPartitions.java) erzeugt. Auf die Anfragen in den Partitionen werden die Clustering-Algorithmen (KMeansAlgo.java und LeaderAlgo.java) angewendet. Dazu werden Anfragevektoren benötigt, welche über die Klasse QueryVector.java definiert sind. Diese Klasse ist abstrakt, sodass mehrere Varianten für die Ähnlichkeitsbestimmung dieser Anfragevektoren benutzt und implementiert werden können (QueryVectorSim1.java bis QueryVectorSim4.java). Aus den beim Clustering ermittelten Anfragevektoren kann dann das komprimierte Workload generiert werden. Abbildung A.3: Abhängigkeiten im Paket clustering

101 A.2. KLASSENDIAGRAMME 91 dbconnection Das Paket dbconnection stellt die Schnittstelle zum relationalen DBMS DB2 dar. Die Klasse ConnectionDB2.java erzeugt dabei die Verbindung zur Datenbank. Die 3 Subklassen können nun auf die Datenbank zugreifen: IndexDB2.java kann Indizes für Anfragen bestimmen und bewerten, SelectivityDB2.java berechnet die Selektivitäten und TableInfoDB2.java bestimmt Informationen über die Tabellen und Spalten der Datenbank. Die Klasse RunstatsDB2.java prüft, ob das Werkzeug RUNSTATS ausgeführt werden muss und führt dieses gegebenenfalls in einem separaten Prozess aus. Abbildung A.4: Abhängigkeiten im Paket dbconnection filter Im Paket filter werden alle Klauseln einer SQL-Anfrage repräsentiert. Dabei handelt es sich zum einen um die WHERE-Klausel (ListOfWhereElements.java), welche als ein Baum repräsentiert wird. Dazu wurden die logischen Operatoren (AndWhereElement.java, OrWhereElement.java und NotWhereElement.java) und Prädikate (ItemWhereElement.java) von der Superklasse WhereElement.java abgeleitet. Zum anderen werden die Elemente der SELECT-, GROUP BY- oder ORDER BY-Klausel (SelectElement.java) repräsentiert.

102 92 ANHANG A. KURZBESCHREIBUNG DER IMPLEMENTATION Abbildung A.5: Abhängigkeiten im Paket filter indexadvisor Das Paket indexadvisor implementiert den Index-Advisor. In der Hauptklasse IndexAdvisor.java werden dazu die Indizes ListOfIndexes.java für die Anfragen des komprimierten Workloads bestimmt und bewertet. Anschließend wird die Indexauswahl mit Hilfe der Klasse KnapsackAlgorithm.java durchgeführt. Abbildung A.6: Abhängigkeiten im Paket indexadvisor querygen Die synthetischen Anfragen für die Evaluierung der Implementation werden im Paket querygen generiert. Die Hauptklasse QueryGen.java führt die Generierung durch, nachdem die Tabellen und Spalten inklusive realer Werte in die Datenstruk-

103 A.2. KLASSENDIAGRAMME 93 turen Table.java und Column.java eingelesen worden sind. Abbildung A.7: Abhängigkeiten im Paket querygen util Im Paket util befinden sich Werkzeuge, die für die Implementation benötigt werden. Dabei handelt es sich zum Beispiel um die Konfiguration des Loggers (Log4jConfiguration.java), eine Anzeige für den aktuellen Status des Index-Advisors (ProgressBar.java) oder das Einlesen von Werten aus einer Konfigurationsdatei (Config.java). Abbildung A.8: Abhängigkeiten im Paket util workload Das Paket workload ist für die Erzeugung eines Workloads verantwortlich. Die Hauptklasse Workload.java liest dazu die Anfragen in entsprechende Listen ein (ListOfQueries.java). Eine Anfrage wird dabei von einer abstrakten Klasse Query.java repräsentiert, wobei für jeden Anfragetyp eine Implementation für diese abstrakte Klasse erfolgen muss (z. B. SelectQuery.java für eine SELECT-Anfrage).