Selektion von Aggregationstabellen zur Optimierung der Antwortzeiten eines OLAP-Servers

Transkript

1 TECHNISCHE UNIVERSITÄT ILMENAU Institut für Praktische Informatik und Medieninformatik Fakultät für Informatik und Automatisierung Fachgebiet Datenbanken und Informationssysteme Diplomarbeit Selektion von Aggregationstabellen zur Optimierung der Antwortzeiten eines OLAP-Servers vorgelegt von Matthias Marx Matrikel Betreuer: Prof. Dr. Ing. Kai-Uwe Sattler Dipl. Inf. Daniel Klan Ilmenau, den 2. Juli 2008

2 Inhaltsverzeichnis 1 Motivation und Zielsetzung 1 2 Grundlagen Foodmart als Beispieldatenbank OLAP - Online Analytical Processing ROLAP - Relational OLAP Multidimensionales Datenmodell MDX - Multi-Dimensional Expression Aggregationstabellen Verwandte Arbeiten 8 4 Theoretische Aspekte Aggregationsgitter Knoten Kanten Beispiel Knotenzahl Vereinfachungen/Einschränkungen Kostenmatrix Auswahl von Aggregationstabellen Kostenmodell Nutzen/Kosten für Aggregationstabellen Konfigurationsbestimmung Knotenerzeugung anhand von MDX-Anfragen Verallgemeinerte SQL-Anfragen für Gitterknoten Entwicklungsumgebung Mondrian DB Foodmart - Datenbank TPC-H - Datenbank Implementierung Integration in Mondrian Grundlegender Ablauf Administration GUI Alerter - Ansatz i

3 Inhaltsverzeichnis 6.4 Verwendung des AggGen zur Anfragegenerierung Collapsed Methode Lost Methode Aggregationstabellen in Mondrian Erkennung von Aggregationstabellen Anlegen von Aggregationstabellen Kostenmodell der Implementierung Abschätzung von Anfragekosten Funktionsweise von DB2 - Explain Explain für Knoten des Aggregationsgitters CompleteExplainEvaluator FastExplainEvaluator FakeExplainEvaluator Bestimmung der Kardinalität Bestimmung der Seitenzahl Arbeitsweise OnTheFly - Evaluatoren Auswahl von Aggregationstabellenkonfigurationen OptimalAdvisor GreedyAdvisor Nutzenreduktion Beispiel auf Basis des theoretischen Kostenmodells GreedyBenefitSizeRatioAdvisor Mondrian - Advisor Evaluation Testumgebung Hardware des Testsystems Testgitter Anfragemix für TPC-H CostEvaluators Vergleich der Evaluator-Laufzeiten Vergleich zwischen Complete- und FastExplainEvaluator Problematik des FakeExplainEvaluators Beurteilung der CostEvaluators ConfigurationAdvisor OptimalAdvisor Berechneter Nutzen der Advisor Laufzeit des Anfragemixes DB2 - Design Advisor Negativer Nutzen durch Aggregationstabellen Beurteilung der Advisor Anwendungsszenario Ausblick und Fazit /085/IN02/2254 ii

4 Inhaltsverzeichnis A Anhang 81 A.1 Mondrian - Foodmart - XML Schema /085/IN02/2254 iii

5 Abbildungsverzeichnis 2.1 Datenwürfel anhand von drei Dimensionen der Foodmart-Datenbank Aufbau eines Aggregationsgitters mit fünf Kennzahlen/Dimensionen Aufbau eines Aggregationsgitters mit einer Kennzahl, zwei Dimensionen mit sechs beziehungsweise vier Ebenen Beispiel für eine dünnbesetzte Variante des Aggregationsgitters aus Abbildung Aggregationsgitter bestehend aus vier Knoten inklusive der Kosteninformationen Ausschnitte aus dem Foodmart Datenbankschema Datenbankschema des für Mondrian angepassten TPC-H Benchmarks Interaktion des Aggregationsgitters mit dem Mondrian System Struktur der Optimierungskomponente Oberfläche des Graphical Lattice Viewers, das Administrationswerkzeug der Optimierungskomponente Erzeugte Aggregationstabelle für den Knoten basierend auf der MDX- Anfrage aus Listing Struktur der Evaluator Komponente Struktur der Advisor Komponente Aggregationsgitter zur Veranschaulichung des GreedyAdvisors Struktur des Aggregationsgitters basierend auf einem Anfragemix der TPC- H-Datenbank Größe der Aggregationstabellen der einzelnen TPC-H-Gitterknoten Wahrscheinlichkeitsverteilung der Normalverteilung Anfragehäufigkeiten der Knoten aus Abbildung Evaluator-Laufzeiten für das TPC-H-Aggregationsgitter im Vergleich Durchschnittlicher Fehler der Kostenschätzung des FastExplainEvaluators für die abgeleiteten Knoten des Foodmart Gitters Durchschnittlicher Fehler der Kostenschätzung des FastExplainEvaluators für die abgeleiteten Knoten des TPC-H Gitters Darstellung des Fehlers in der Heuristik für alle von Knoten 1 abgeleiteten Knoten des TPC-H-Aggregationsgitters Fehler von geschätzter zu realer Kardinalität beim FakeExplainEvaluator Rechnerisch ermittelte Kostenreduktion der unterschiedlichen Advisor für den Anfragemix aus Abschnitt iv

6 Abbildungsverzeichnis 9.11 Rechnerisch ermittelte Ausführungskosten der Konfigurationen im Verhältnis zu den Ausführungskosten auf den Basisrelationen für den Anfragemix aus Abschnitt Detaillierte Darstellung des Bereiches zwischen 1 und 20% aus Abbildung Laufzeit des TPC-H-Anfragemixes in Abhängigkeit der durch den Greedy- Advisor bestimmten Konfiguration /085/IN02/2254 v

7 Tabellenverzeichnis 2.1 Ergebnis der MDX-Anfrage aus Listing Gegenüberstellung der entfernten Knoten in Abbildung 4.3 und den dadurch erzeugten direkten Ableitbarkeiten Struktur der Kostenmatrix Dimensionen mit ihren Ebenen des TPC-H-Mondrian-Schemas. Die Ebenen sind von grob- nach feingranular sortiert Kostenmatrix für das Aggregationsgitter aus Abbildung Zusätzliche Informationen über die Knoten aus Abbildung Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyAdvisors, basierend auf dem theoretischen Kostenmodell Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyBenefitSizeRatioAdvisor. Teil Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyBenefitSizeRatioAdvisor. Teil Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyAdvisors, basierend auf dem Kostenmodell für Mondrian Technische Daten des Testsystems Konfiguration bei 1% Speicherplatz der Basisrelation des GreedyAdvisors Konfiguration bei 1% Speicherplatz der Basisrelation des GreedyBenefitSizeRatioAdvisors Gegenüberstellung der ermittelten Nutzwerte der Knoten N 1 und N 2 bei Abarbeitung der unterschiedlichen Advisor vi

8 Listings 2.1 Einfache MDX-Anfrage Exemplarische MDX-Anfrage Extrahierte Dimensionen der MDX-Anfrage aus Listing Generalisierung der Dimensionen aus Listing Knoten erzeugende Dimensionen aus Anfrage XML-Schema-Definition der TPC-H Datenbank für Mondrian Knoten erzeugende MDX-Anfrage Dimensionen des Knotens für MDX-Anfrage aus Listing Verallgemeinerte SQL-Anfrage basierend auf der Collapsed Methode und den Dimensionen aus Listing Verallgemeinerte SQL-Anfrage basierend auf der Lost Methode und den Dimensionen aus Listing SQL-Befehl, um die Aggregationstabelle des Knotens, basierend auf Listing 6.1, zu erzeugen SQL-Befehl, um die Aggregationstabelle aus Listing 6.5 mit Daten zu füllen SQL-Befehl, um die Statistiken der Aggregationstabelle aus Listing 6.5 zu erzeugen Mögliche Syntax einer Explain Anweisung Ausführungsplan der Anfrage Q 1 auf der Aggregationstabelle A 1 des Knotens N 1 aus dem Aggregationsgitter aus Abbildung Syntax einer count(*) Anfrage zur Bestimmung der Kardinalität einer SQL-Anfrage A.1 Auszüge aus dem XML-Schema der Foodmart Datenbank vii

9 Algorithmenverzeichnis 7.1 Kostenschätzung des CompleteExplainEvaluators Kostenschätzung des FastExplainEvaluators Kostenschätzung der OnTheFly-Evaluatoren Konfigurationsbestimmung des OptimalAdvisors Konfigurationsbestimmung des GreedyAdvisors Konfigurationsbestimmung des GreedyBenefitSizeRatioAdvisors viii

10 1 Motivation und Zielsetzung In den letzten Jahren wächst die Datenmenge, die Unternehmen speichern, ununterbrochen. Diese Daten umfassen Informationen über Abläufe eines Unternehmens. Dazu gehören, beispielsweise Daten über Kunden, Lieferanten, Produkte und Bestellungen. Diese Rohdaten enthalten wertvolle Informationen für Analysten anhand denen sie Entscheidungen über Expansionen und Investitionen treffen können. In der Rohform, die Giga-, Tera oder sogar Petabyte umfasst, sind die Daten jedoch nur von geringem Nutzen. Eine Möglichkeit zur Aufbereitung und Analyse der Daten ist OLAP 1. Mit OLAP haben Analysten eine strukturierte Sichtweise auf die vorhandenen Daten. Anstatt einzelne Tupel in der Datenbank zu betrachten wird bei OLAP ein multidimensionaler Cube aufgebaut. Auf Basis des Cubes kann sich der Benutzer schrittweise weitere Informationen über aggregierte Bereiche des Cubes verschaffen indem er beispielsweise Scheiben aus diesem herausschneidet. Ein OLAP-Server unterstützt die Navigation innerhalb des Cubes durch Definition einer multidimensionalen Anfragesprache. Ein von Microsoft entwickelter Standard ist die Anfragesprache MDX. Zur Unterstützung des Benutzers existieren darauf aufbauende grafische Oberflächen. Eine Variante von OLAP ist ROLAP. Hierbei sind die Rohdaten in einer relationalen Datenbank abgelegt. In diesem Fall übernimmt der OLAP-Server die Umsetzung von der multidimensionalen Sichtweise auf die Relationen der Datenbank, welche oftmals als Staroder Snowflake-Schema angelegt sind. Konkret bedeutet dies die Übersetzung von MDX- Anfragen in eine oder mehrere SQL-Anfragen. Diese greifen auf die Basisrelationen anhand der durch das Star- oder Snowflake-Schema definierten Verbundbedingungen, komplexer Gruppierungs- und Aggregationsoperationen zu. Die Abarbeitung dieser erzeugten SQL-Anfragen kann abhängig von der Größe der relationalen Datenbank Minuten, Stunden oder sogar Tage dauern. Um diese Berechnungszeit zu verkürzen werden Aggregationstabellen eingesetzt. Diese aggregieren Rohdaten und speichern die Ergebnisse. Werden an das System Anfragen gestellt mit einer zur Aggregationstabelle passenden Aggregationsgranularität, kann die Aggregationstabelle zur Beantwortung der Anfrage verwendet werden und verkürzt dadurch die Bearbeitungszeit. Aggregationstabellen benötigen zusätzlichen Festplattenspeicherplatz und müssen gewartet werden, um einen konsistenten Datenbestand zu gewährleisten. Bei großen Datenbanken ist es nicht möglich, beziehungsweise sinnvoll alle Aggregationstabellen zu realisieren. Deshalb muss eine Auswahl getroffen werden. Das unter dem Namen View Se- 1 Online Analytical Processing 1

11 1 Motivation und Zielsetzung lection bekannte Problem ist wegen der großen Anzahl möglicher Aggregationstabellen NP-Vollständig [9]. Neben der nativen Unterstützung von Aggregationstabellen in Form von Materialized Views(Oracle), Materialized Query Tables(DB2 ) oder Indexed Views(SQL Server) bieten diese kommerziellen DBMS bereits Werkzeuge, die anhand eines Workloads, eine Auswahl von Aggregationstabellen treffen [1, 29]. Ziel dieser Arbeit ist es für einen OLAP-Server in Kombination mit einer relationalen Datenbank einen Prototypen zu implementieren, der sowohl Daten über die Anfragen aus dem OLAP-Server als auch Informationen über Anfragekosten aus der relationalen Datenbank bezieht. Die Daten sollen nicht statisch sondern dynamisch während des normalen Betriebs des OLAP-Servers ermittelt werden. Der Prototyp soll zusätzlich das View Selection Problem kontinuierlich untersuchen und Aggregationstabellen, welche die Anfragenlaufzeiten reduzieren, vorschlagen /085/IN02/2254 2

12 2 Grundlagen In diesem Kapitel wird eine kurze Einführung in das Umfeld dieser Arbeit gegeben. Es werden fundamentale Begriffe erläutert, die für das weitere Verständnis notwendig sind. Dazu gehören Informationen zur Grundidee eines OLAP 1 -Servers, der Anfragesprache MDX 2, zu Aggregationsgittern und Aggregationstabellen. Eine ausführliche Beschreibung der einzelnen Punkte ist in Kapitel 4 zu finden. 2.1 Foodmart als Beispieldatenbank Die Beispieldatenbank Foodmart wird zusammen mit Mondrian, siehe Abschnitt 5.1, ausgeliefert. Sie enthält Daten eines Kaufhauses, die anhand eines Snowflake-Schemas, siehe Abschnitt 5.3, gespeichert sind. Sie dient den Entwicklern von Mondrian zum Testen ihrer Entwicklungen. Durch die vorhandene Schema-Definition eignet sich diese Datenbank ebenfalls sehr gut zur Verifikation der Implementierungen dieser Arbeit, weil das Schema einige Dimensionen mit vielen Ebenen enthält. Weiterhin werden im Laufe dieser Arbeit zur Erklärung unterschiedlicher Aspekte Beispiele anhand dieser Datenbank vorgestellt. 2.2 OLAP - Online Analytical Processing Unter dem Begriff OLAP wird die analytische Betrachtung großer Datenbestände, unter Verwendung einer multidimensionalen Herangehensweise, zusammengefasst. Im Gegensatz zum OLTP 3 werden keine transaktionsbasierten Vorgänge durchgeführt, welche Lese-/Schreibzugriff beinhalten und mit wenig Daten arbeiten. Hauptsächlich werden Lesezugriffe auf den vorhandenen Daten durchgeführt, wobei üblicherweise große Mengen an Daten aggregiert und aufbereitet werden, die für die Analyse von Nutzen sind. Bei OLAP wird üblicherweise als Basis ein Data-Warehouse 4 verwendet, welches die zur Analyse notwendigen Daten enthält. Dies ermöglicht eine Trennung der operationalen 1 Online Analytical Processing 2 Multi-Dimensional Expression 3 Online Transaction Processing 4 Ein Data-Warehouse entspricht einer Datenbank, die separat zu den operationalen Datenbanken einer Organisation geführt wird. Es integriert die Daten unterschiedlichster Unternehmensbereiche/Applikationen und bietet eine Basis für die Analyse historischer Daten.[8] 3

13 2 Grundlagen Daten von denen, die für die Analyse benötigt werden. Somit ist gleichzeitig eine getrennte Optimierung der beiden Datenbanken, einerseits für OLAP, andererseits für den operationalen Betrieb, möglich ROLAP - Relational OLAP Relational Online Analytical Processing ist eine Sonderform von OLAP. Hierbei kennzeichnet Relational die Verwendung eines relationalen Backends zur Datenspeicherung. Die Daten werden üblicherweise in Form eines Star- oder Snowflake-Schemas gespeichert. Ein Star Schema ist die Beschreibung des Aufbaues eines Datenbankmodells. Dieses Modell besteht aus einer zentralen Faktentabelle, welche die mittels OLAP zu analysierenden Daten enthält und beliebig viele Dimensionstabellen referenziert. Die Dimensionstabellen enthalten die Daten anhand denen in der späteren Analyse das Filtering und Slicing durchgeführt wird. Bei einem Snowflake Schema können zusätzlich die Dimensionstabellen weitere Dimensionen referenzieren, in denen Teile der Dimensionshierarchie gespeichert sind Multidimensionales Datenmodell Bei OLAP ist die Sichtweise auf die Daten durch das multidimensionale Datenmodell geprägt. Hierbei wird für die Daten ein Data Cube 5 anhand von Dimensionen, Dimensionsebenen und Kennzahlen definiert. Im Gegensatz dazu wird beim relationalen Modell eine Aufteilung in Relationen, Spalten und Zeilen bevorzugt. Der Datenwürfel in Abbildung 2.1 ist eine Vereinfachung des komplexen Datenwürfels der Foodmart-Datenbank. Er besitzt die drei Dimensionen Time, Product und Store. Die Schnittlinien stellen die Granularität der einzelnen Dimensionsebenen dar, die Time Dimension ist beispielsweise auf Quarter Ebene aufgespaltet. Der komplette Würfel ist aus Zellen zusammengesetzt. In jeder dieser Zellen steht die Kennzahl Unit Sales unter Berücksichtigung des Quartals, der Produktfamilie und des Geschäftslandes. Der Datenwürfel zeigt nur die obersten Ebenen der Dimensionen, die Produkt Dimension besitzt jedoch zum Beispiel sechs Ebenen. Dies führt zu einer extrem großen Zahl an Zellen, aus denen der Gesamtwürfel zusammengesetzt ist. Für die Analyse werden aus dem Datenwürfel Teilbereiche herausgeschnitten, zusammengefasst und grafisch aufbereitet. Bei Verwendung einer relationalen Datenbank ist es Aufgabe der ROLAP-Applikation dieses multidimensionale Modell auf das relationale Modell umzusetzen. 5 Datenwürfel /085/IN02/2254 4

14 2 Grundlagen [Time].[Year].[Quarter] [Measures].[Unit Sales] [Product].[Product Family] [Store].[Store Country] Abbildung 2.1: Datenwürfel anhand von drei Dimensionen der Foodmart- Datenbank /085/IN02/2254 5

15 2 Grundlagen MDX - Multi-Dimensional Expression MDX dient als Anfragesprache für das multidimensionale Datenmodell. Sie wurde 1998 von Microsoft entwickelt und zusammen mit den OLAP Diensten des Microsoft SQL Servers vorgestellt. Seit diesem Zeitpunkt hat die Verwendung von MDX für den Zugriff auf multidimensionale Daten stetig zugenommen [10]. Ähnlich wie bei SQL ist eine MDX-Anfrage in drei Bereiche select, from und where unterteilt. Die Inhalte dieser Abschnitte sind jedoch nicht mit SQL zu vergleichen. Im select Bereich wird ausgewählt, welche Informationen auf welchen Achsen der Ausgabe erscheinen. Dies wird auch als Filtering bezeichnet [21]. In der from Klausel wird der Datenwürfel ausgewählt, auf den sich die Anfrage bezieht. Abschließend wird in der where Klausel das Slicing durchgeführt, d.h. die Einschränkung von Dimensionen, die nicht in der Ausgabe angezeigt werden. Daraus ergibt sich eine Beeinflussung der aggregierten Kennzahlen. 1 select 2 {[Measures].[Store Sales]} on columns, 3 crossjoin( 4 {[Product].[Food].[Baked Goods]}, 5 {[Store ].[ USA].[OR].[Salem]} 6 ) on rows 7 from [Sales] 8 where [Time].[1997] Listing 2.1: Einfache MDX-Anfrage In Listing 2.1 ist eine einfach MDX-Anfrage dargestellt. In der Spalte wird eine einzige Kennzahl, Store Sales, abgefragt. In der Zeile wird mittels des crossjoin Operators das Kreuzprodukt der beiden Dimensionen Product und Store durchgeführt. Das Resultat der Anfrage ist in Tabelle 2.1 zu sehen. [Measures].[Store Sales] [Product].[Food].[Baked Goods] [Store].[USA].[OR].[Salem] 2, Tabelle 2.1: Ergebnis der MDX-Anfrage aus Listing 2.1 Die Anfrage aus Listing 2.1 ist nur ein Beispiel, dazu noch ein relativ Einfaches. Alle Möglichkeiten und Sprachspezifikationen von MDX hier aufzuführen würden den Rahmen sprengen. Ich verweise deshalb an dieser Stelle auf die Online-Dokumentation von Mondrian [10], in der die Unterschiede der Mondrian spezifischen MDX-Anfragesprache im Vergleich zum Standard beschrieben werden /085/IN02/2254 6

16 2.3 Aggregationstabellen 2 Grundlagen Aggregationstabellen dienen dazu Anfragen von Applikationen zu beschleunigen, dies geschieht meistens auf Kosten von zusätzlichem Festplatten-Speicherplatz. Sie sind zusätzliche Relationen in einem Datenbanksystem und enthalten redundante Daten, die bereits in den existierenden Relationen vorhanden sind, wobei sie jedoch oftmals nicht die gleiche Granularität wie die Originaldaten haben. In einer Aggregationstabelle werden Aggregationsfunktionen anhand der Originaldaten im Vorraus berechnet und abgelegt, um diesen Vorgang nicht bei jeder Anfrage erneut durchführen zu müssen. Ein Beispiel einer Aggregationstabelle für das Foodmart-Schema ist in Abbildung 6.4 zu finden. Der Name Aggregationstabelle dient als Überbegriff, um die Realisierungsmöglichkeiten mittels des DBMS nicht einzuschränken. Einige DBMS unterstützen das Prinzip der Aggregationstabellen, indem sie Strukturen und Methoden schaffen diese zu erzeugen, warten, optimieren und aktualisieren. In Oracle sind es beispielsweise Materialized Views und in DB2 sind es Materialized Query Tables. Um jedoch auch DBMS zu unterstützen, die keine nativen Aggregationstabellen haben besteht die Möglichkeit Tabellen zu erzeugen, welche die selben Daten enthalten wie native Aggregationstabellen. In diesem Fall ist dem DBMS jedoch keine Beziehung zwischen den Daten bekannt. Dies bedeutet, dass der Benutzer beziehungsweise eine Client-Applikation für die Datenkonsistenz verantwortlich ist, denn das DBMS behandelt die Aggregationstabelle wie eine normale Relation /085/IN02/2254 7

17 3 Verwandte Arbeiten Das View Selection Problem wird in der Literatur intensiv untersucht. Es wird oftmals in Zusammenhang mit kommerziellen Datenbank-Management-Systemen aufgegriffen [1, 4, 29]. Die daraus entstandenen Applikationen sind üblicherweise externe Administrationswerkzeuge und wurden für ein spezifisches DBMS entwickelt. Die Arbeitsweise dieser Administrationswerkzeuge basiert auf der Auswahl von Aggregationstabellen auf Basis eines statischen SQL-Workloads. In [1] wird beispielsweise ein Design Werkzeug für den Microsoft SQL Server vorgestellt. Es kann anhand eines repräsentativen Workloads eine Menge an materialisierten Sichten und Indizes vorschlagen. Die Ergebnisse von [1] belegen, dass die kombinierte Auswahl von materialisierten Sichten und Indizes zu einer stärkeren Reduktion der Laufzeit des Workloads führen, als es bei der getrennten und aufeinander folgenden Optimierung der Fall ist. Ein weiteres Werkzeug ist der Design Advisor von DB2 [29]. Ähnlich wie die Applikation aus [1] vereint er die Optimierung von materialisierten Sichten und Indizes. Zusätzlich können jedoch weitere Aspekte, wie die Partitionierung und das multi-dimensionale Clustering von Tabellen optimiert werden. In dieser Arbeit wird jedoch lediglich die Auswahl von Aggregationstabellen berücksichtigt, auch wenn sich in [1, 30] gezeigt hat, dass die kombinierte Betrachtungsweise mit anderen Designmöglichkeiten Vorteile haben kann. Der Grund hierfür ist die hohe Komplexität bei simultaner Betrachtung mehrerer Designmöglichkeiten [29] und die vollständige Neuimplementierung auf Basis eines OpenSource-OLAP-Servers. Das Ziel dieser Arbeit ist es diese Auswahl von einem spezifischen DBMS zu entkoppeln und als externe Applikation, mit möglichen Schnittstellen zu diversen DBMS, zu implementieren. In Anlehnung an [5] soll durch die Trennung von DBMS und Optimierungskomponente die Wartung und Adaption an neue Gegebenheiten vereinfacht werden. Weiterhin werden die Kandidaten für zu realisierende Aggregationstabellen nicht durch SQL-Anfragen bestimmt, sondern durch die an den OLAP-Server gestellten MDX-Anfragen. Auf Basis der abstrakteren Sichtweise der Dimensionen vereinfacht sich die Analyse im Vergleich zur SQL-Ebene von beliebigen Anfragen. Dies gilt sowohl für die Erzeugung von Aggregationstabellenkandidaten anhand von MDX-Anfragen, als auch für die Analyse von Ableitbarkeitsbeziehungen zwischen Aggregationstabellen und Anfragen. Neben der Trennung des Optimierers vom DBMS wird er von einer statischen in eine dynamische Komponente umgewandelt. Dies bedeutet der Optimierer arbeitet nicht anhand eines statischen Workloads, der vom Administrator zusammengestellt und an den Optimierer übergeben wird, sondern er arbeitet parallel zum OLAP-Server. Auf Basis aller 8

18 3 Verwandte Arbeiten eingehender Anfragen werden die bis zu diesem Zeitpunkt gesammelten Daten ausgewertet und kontinuierlich Empfehlungen zu Aggregationstabellenkonfigurationen getroffen. Für Indexe existieren bereits Untersuchungen, die sich mit einer solchen kontinuierlichen Optimierung beschäftigen [2, 20, 26]. Zusätzlich wird die Idee des in [3] vorgestellte Alerter Ansatz für Indexe in dieser Arbeit aufgegriffen und für Aggregationstabellen adaptiert. Der Alerter überwacht die aktuelle Konfiguration von Aggregationstabellen und benachrichtigt den Administrator falls eine geeignetere Konfiguration gefunden wird. Die Struktur der Optimierungskomponente basiert auf dem in [9, 19] vorgestellten Konzept des Aggregationsgitters. Um jedoch die kombinatorische Explosion des Gitters, wie sie in [22] beschrieben wird, zu vermeiden, wird das Aggregationsgitter nicht vollständig aufgebaut. Die Knoten innerhalb des Gitters werden erst erzeugt, wenn sie wenigstens eine Anfrage repräsentieren, die an den OLAP-Server gestellt wurde. Neben der Struktur des Aggregationsgitters wird das in [9] vorgestellte Greedy-Verfahren zur Auswahl von Aggregationstabellenkonfigurationen aufgegriffen. Durch die Verwendung eines OpenSource- OLAP-Servers muss wegen seiner speziellen Behandlung von Aggregationstabellen das Verfahren jedoch angepasst werden. Ein weiterer wichtiger Punkt, in dem sich diese Arbeit von den in [9, 19, 22] vorgestellten Auswahlalgorithmen unterscheidet ist die Basis, auf der die Algorithmen den Nutzen von Aggregationstabellen berechnen. Es wird nicht die Kardinalität der Aggregationstabellen verwendet, sondern Anfragekosten die mittels des DBMS berechnet werden. Hierfür werden die Kostenschätzungen der DBMS-Optimierer ausgenutzt. Die Annahme aus [9], dass sich die Anfragekosten proportional zu der betrachteten Tupelanzahl verhalten, trifft beispielsweise nicht zu, wenn Indexe existieren, welche die Anfragekosten erheblich senken können. Zusätzlich wird bei Verwendung der Kardinalität als Kostenmaß nicht berücksichtigt, dass unter Umständen die Verwendung der Basisrelationen günstiger ist, als die Verwendung von bestimmten Aggregationstabellen /085/IN02/2254 9

19 4 Theoretische Aspekte In diesem Kapitel wird die Idee dieser Arbeit, die Auswahl von Aggregationstabellen anhand eines Aggregationsgitters, vorgestellt. Hierfür wird die Struktur des Aggregationsgitters definiert und anhand von Beispielen veranschaulicht. Es wird das verwendete Kostenmodell erläutert und beschrieben welche Bedingungen bei der Auswahl von Aggregationstabellen berücksichtigt werden müssen. 4.1 Aggregationsgitter Ein Aggregationsgitter ist ein azyklischer, gerichteter Abhängigkeitsgraph, der Beziehungen zwischen Aggregationen beziehungsweise Gruppierungsmengen abbildet. Dieser Graph bildet die Grundlage der in dieser Arbeit durchgeführten Auswahl von Aggregationstabellen. Das Gitter wird während der Laufzeit durch die an das System gerichteten Anfragen erzeugt. Der Vorgang der Knotenerzeugung anhand von MDX-Anfragen ist in Abschnitt 4.4 beschrieben. In diesem Abschnitt wird auf die Struktur und die Definition des Gitters eingegangen Knoten Die Knoten des Aggregationsgitters bestehen aus zwei Komponenten, einerseits aus den Aggregationen und andererseits aus den Gruppierungen. Diese beiden Komponenten sind zwar grundverschieden, können aber im Sinne des Gitters gleich behandelt werden, insbesondere bei der Betrachtung der Ableitbarkeit. Aggregationen entsprechen den algebraischen Funktionen aus SQL, dazu gehören beispielsweise sum 1, count 1 und avg 1. Gruppierungen entsprechen Elementen der GROUP BY -Klausel Komponente einer SQL-Anfrage. Auch wenn die Erzeugung des Gitters anhand von MDX-Anfragen erfolgt, ist die zugrundeliegende Ableitbarkeit der Daten durch Aggregationen und Gruppierungen weiterhin gegeben. In MDX-Anfragen sind Aggregationen als Measures und Gruppierungen als Dimensions enthalten. Diese werden erst bei Transformation von MDX nach SQL wieder in ihre SQL-Konstrukte übersetzt. Die Aggregationen und Gruppierungen definieren einen Knoten im Aggregationsgitter. 1 Summe/Anzahl/Durchschnitt der Werte der spezifizierten Spalte über einen Bereich der Zeilen spezifiziert durch Bedingungen in der GROUP BY -Klausel 10

20 4 Theoretische Aspekte Kanten Die Kanten des Aggregationsgitters bilden die Ableitbarkeit zwischen einzelnen Knoten ab. Die Definition der Ableitbarkeit wurde aus aus dem Buch Datenbanktechnologien für Data-Warehouse-Systeme von Wolfgang Lehner[19] übernommen. Definition: Direkte Ableitbarkeit von Gruppierungskombinationen 2 Zwei Gruppierungskombinationen G 1 und G 2 weisen eine direkte Ableitbarkeit auf, d.h., G 2 ist von G 1 direkt ableitbar, wenn eine der beiden Bedingungen erfüllt ist: Die Gruppierungskombination G 2 hat genau ein Attribut weniger als die Gruppierungskombination G 1, d.h. G 2 G 1 und G 2 = G 1 1. Genau ein Attribut A i wird in der Gruppierungskombination G 1 durch ein Attribut A i ersetzt, wobei gilt, dass das zu ersetzende A i das Attribut A i direkt funktional bestimmt, d.h. A i A i. Die erste Bedingung bezieht sich auf Gruppierungskombinationen bei denen von einem Knoten zum nächsten Dimensionen wegfallen. Beispielsweise ist ( [Measures].[Unit Sales], [Time].[Year] ) mit einer Kennzahl und einer Dimension ableitbar von der Gruppierungskombination ( [Measures].[Unit Sales], [Time].[Year], [Store].[Store Country] ), welche die gleiche Kennzahl und Dimension enthält. Ein Beispiel für die zweite Bedingung ist die Veränderung der Ebene einer Dimension, also deren Granularität. Im folgenden ist die Gruppierungskombination ( [Measures].[Unit Sales], [Time].[Year].[Quarter].[Month] ) mit der gröberen Granularität der [Time] Dimension direkt ableitbar von ( [Measures].[Unit Sales], [Time].[Year].[Quarter].[Month].[Day] ) Die Ableitbarkeit der Aggregationen wird analog zur direkten Ableitbarkeit von Gruppierungen definiert. Sie wird soweit vereinfacht, dass eine Aggregationskombination A 2 direkt ableitbar von einer Aggregationskombination A 1 ist, wenn gilt A 2 A 1 und A 2 = A 1 1. Durch diese Vereinfachung wird die Ableitbarkeit der einzelnen algebraischen Funktionen untereinander nicht berücksichtigt. So wäre avg beispielsweise aus sum und count ableitbar. Zur Vereinfachung der späteren Implementierung wird jedoch davon abgesehen bei den Aggregationen eine genauere Definition zu verwenden. Definition: Ableitbarkeit von Gruppierungskombinationen 3 Eine Gruppierungskombination G 2 ist von einer anderen Gruppierungskombination G 1 innerhalb eines Aggregationsgitters ableitbar, formal bezeichnet durch G 1 G 2, wenn ein Pfad von G 1 nach G 2 im Aggregationsgitter existiert. 2 Zitiert aus [19] 3 Zitiert aus [19] /085/IN02/

21 4 Theoretische Aspekte Beispiel Das Aggregationsgitter aus Abbildung 4.1 ist ein vollständiges Gitter für fünf Dimensionen. Die Zahlen 1-5 in den Knoten entsprechen den jeweiligen Dimensionen, wobei die Dimensionen nur aus einer Ebene bestehen und somit ein relativ kleines Gitter bilden. Es wird lediglich eine Kennzahl abgefragt, die bei allen Knoten gleich ist und deshalb nicht gesondert aufgeführt wird. Die Kanten stellen die direkte Ableitbarkeit der einzelnen Knoten dar. () ,2 1,3 1,4 1,5 2,3 2,4 2,5 3,4 3,5 4,5 1,2,3 1,2,4 1,2,5 1,3,4 1,3,5 1,4,5 2,3,4 2,3,5 2,4,5 3,4,5 1,2,3,4 1,2,3,5 1,2,4,5 1,3,4,5 2,3,4,5 1,2,3,4,5 Abbildung 4.1: Aufbau eines Aggregationsgitters mit fünf Kennzahlen/Dimensionen Der Knoten 1,2,3,4,5 besitzt die feinste Granularität und somit auch die größte Aggregationstabelle. Der Knoten () hingegen aggregiert alle Daten der Faktentabelle zu einem Wert. Abbildung 4.2 ist ein Ausschnitt des Aggregationsgitters der Foodmart Beispieldatenbank. Knoten 1 besitzt die feinste Granularität beider Dimensionen ( [Product].[P. Family].[P. Department].[P. Category].[P. Subcategory].[Brand Name].[P. Name], [Store].[S. Country].[S. State].[S. City].[S. Name] ). Die Granularität nimmt in Richtung Knoten 35 ab, bei jeder Spalte/Zeile wird die Ebene der [Product] beziehungsweise [Store] Dimension reduziert und somit mehr Daten aggregiert. Zusätzlich zu den beiden angegebenen Dimensionen wurde die Kennzahl [Measures].[Store Sales] und der Slicer [Time].[Year] angegeben, da diese beiden Dimensionen bei allen Knoten gleich sind, haben sie keinen Einfluss auf die Ableitbarkeit Knotenzahl Für ein einfaches Gitter wie in Abbildung 4.1 lässt sich die Knotenzahl des vollständigen Gitters nach Formel 4.1 berechnen. Hierbei ist zu beachten, dass für eine gültige Anfrage /085/IN02/

22 4 Theoretische Aspekte [Product]. [Product Family].[Product Department].[Product Category]. [Product Subcategory].[Brand Name].[Product Name] [Store]. [Store Country].[Store State]. [Store City].[Store Name] Abbildung 4.2: Aufbau eines Aggregationsgitters mit einer Kennzahl, zwei Dimensionen mit sechs beziehungsweise vier Ebenen wenigstens eine Kennzahl(m ist die Anzahl Kennzahlen) ausgewählt sein muss, falls keine Dimension(n ist die Anzahl Dimensionen) angegeben ist, wird die gesamte Faktentabelle aggregiert. Bei der Angabe der Dimensionen ist es jedoch irrelevant, ob sie als Filter oder als Slicer verwendet wird. n i=0 ( ) n i m i=0 ( ) m = (2 n ) (2 m 1) (4.1) i Für die Knotenzahl für Gitter, die auf Dimensionen mit mehreren Ebenen aufbauen, gilt die folgende Berechnung nach Formel 4.2. [ n ] (d i + 1) (2 m 1) (4.2) i=1 Als Basis wird Formel 4.1 verwendet, da die Anzahl der Kombination der Kennzahlen gleich berechnet wird, es müssen jedoch die unterschiedliche Anzahl Ebenen für jede Dimension mit einberechnet werden. Die Variablen d 1,..., d n geben die Anzahl der Dimensionsebenen der Dimensionen 1,..., n an. Für den Spezialfall, dass alle Dimensionen nur aus einer Ebene bestehen, d.h. d i = 1 ist, entspricht Formel 4.2 der Formel /085/IN02/

23 4 Theoretische Aspekte Vereinfachungen/Einschränkungen Bereichsanfragen In [19] wird darauf eingegangen, dass es möglich ist das Aggregationsgitter zu einem partitionierten Aggregationsgitter durch Hinzunahme der Ableitbarkeit von Bereichsanfragen zu erweitern. Es wird ebenfalls darauf hingewiesen, dass sich in diesem Fall die Ableitbarkeit extrem verkompliziert. Zur Vereinfachung der Implementierung dieser Arbeit werden Bereichsanfragen nicht gesondert betrachtet. Dünnbesetztes Aggregationsgitter Durch die große Anzahl an möglichen Knoten ist es nicht praktikabel alle Knoten im Gitter vorab zu erzeugen. Aus diesem Grund werden nur Knoten im Gitter erzeugt, die eine tatsächlich gestellte Anfrage repräsentieren. Als Beispiel dient die Komplexität der Foodmart-Datenbank. Obwohl das Schema relativ klein ist mit 11 Dimensionen, 28 Dimensionsebenen und sechs Kennzahlen ergeben sich bereits fast 4,5 Millionen mögliche Gitterknoten. Durch die beliebig erweiterbare Schemadefinition um zusätzliche Kennzahldefinitionen oder neue Dimensionsdefinitionen, um andere Aspekte betrachten zu können, kann die Größe des vollständigen Aggregationsgitters beliebig wachsen. () ,2 1,3 1,4 2,3 2,4 3,4 1,2,4 1,2,5 1,3,5 1,4,5 2,3,4 2,3,5 2,4,5 3,4,5 1,2,3,4 1,2,3,5 1,2,4,5 1,3,4,5 2,3,4,5 1,2,3,4,5 Abbildung 4.3: Beispiel für eine dünnbesetzte Variante des Aggregationsgitters aus Abbildung 4.1 Dies führt dazu, dass die Definition aus Abschnitt der direkten Ableitbarkeit um folgende Bedingung erweitert werden muss. Eine Gruppierungskombination G 2 ist direkt ableitbar von G 1 im dünnbesetzten Aggregationsgitter, wenn G 2 im vollständigen Aggregationsgitter ableitbar von G 1 ist /085/IN02/

24 4 Theoretische Aspekte und keine Gruppierungskombination K im dünnbesetzten Aggregationsgitter existiert mit G 1 K G 2. In Abbildung 4.3 ist eine dünnbesetzte Variante des Aggregationsgitters aus Abbildung 4.1 dargestellt. Es wurden diverse Knoten aus dem ursprünglichen Gitter entfernt. Die neu entstandene direkte Ableitbarkeitsbeziehungen sind durch breitere Linien in Abbildung 4.3 gekennzeichnet und in Tabelle 4.1 aufgeführt. Fehlende Knoten Direkte Ableitbarkeiten (1, 2, 3), (1, 3, 4) (1, 2, 3, 4) (1, 3) (1, 5), (2, 5), (1, 2, 5) (5) (3, 5), (4, 5) (1, 3, 5) (5) (1, 4, 5) (5) (2, 3, 5) (5) (2, 4, 5) (5) (3, 4, 5) (5) Tabelle 4.1: Gegenüberstellung der entfernten Knoten in Abbildung 4.3 und den dadurch erzeugten direkten Ableitbarkeiten. 4.2 Kostenmatrix Die Kostenmatrix wird zur Konfigurationsbestimmung mittels der in Abschnitt 8 vorgestellten Algorithmen benötigt. Der prinzipielle Aufbau ist in Tabelle 4.2 dargestellt. Es ist eine n n Matrix, mit n ist die Anzahl der Knoten, die die Kosteninformationen für die Knoten des Aggregationsgitter enthält. Jede Zelle ij enthält die Kosten c i,j für die Abarbeitung von Q j auf A i. Q 1 Q 2... Q n A 1 c 1,1 c 2,1 c n,1 A 2 c 1,2 c 2,2 c n,2.... A n c 1,n c 2,n c n,n Tabelle 4.2: Struktur der Kostenmatrix Zur Verdeutlichung der Elemente der Kostenmatrix und wie diese mit dem Aggregationsgitter zusammenhängen, ist in Abbildung 4.4 ein Aggregationsgitter bestehend aus vier Knoten dargestellt. Die Ableitbarkeitsbeziehungen sind durch dünne Kanten gekennzeichnet. Die Kosteninformationen c i,j aus der Kostenmatrix sind mittels breiterer Kanten, inklusive Beschriftung dargestellt. Der Knoten 0 entspricht den Basisrelationen, von diesem Knoten sind alle anderen Knoten ableitbar, da alle Knoten mittels den Basisrelationen beantwortbar sein müssen, er besitzt jedoch keine Aggregationstabelle und auch keine eigenen Kosten /085/IN02/

25 c 1,0 c 1,1 4 Theoretische Aspekte 0 c 2,0 c2,1 1 c 3,1 c 3,0 c 2,2 2 c 4,1 3 c 3,3 c 4,2 c 4,0 4 c 4,3 c 4,4 Abbildung 4.4: Aggregationsgitter bestehend aus vier Knoten inklusive der Kosteninformationen. 4.3 Auswahl von Aggregationstabellen Ziel dieser Arbeit ist es für den OLAP-Server Mondrian anhand von eingehenden Anfragen die zugrundeliegende Datenbankstruktur zu optimieren. Hierfür wurden Aggregationstabellen als Optimierungsmöglichkeit ausgewählt, da durch diese eine langfristige Optimierung der Anfragedauer möglich ist. Mondrian besitzt bereits eine Caching-Komponente, welche die Ergebnisse von Anfragen zwischenspeichert und bei ähnlichen Folgeanfragen verwendet. Da Caches eine begrenzte Größe besitzen und die zwischengespeicherten Daten nach einer Weile wieder verdrängt werden, ist Caching alleine nicht für eine Optimierung der Anfragedauer ausreichend. In [6] wird als Beispiel für den Nutzen von Aggregationstabellen eine wöchentliche Anfrage durch einen Geschäftsführer angenommen. Dieser überprüft am Anfang jeder Woche, wieviele Produkte, in allen Regionen im aktuellen Jahr bereits verkauft wurden. Für dieses Szenario müssen, wenn vom Foodmart-Schema ausgegangen wird, alle Daten der Faktentabelle zu einem Wert aggregiert werden. Abhängig von der Größe der zugrundeliegenden Datenbank und des Star-Schemas führt diese Anfrage zu einer aufwändigen SQL-Anfrage mit diversen Verbundoperationen, deren Ergebnis nur ein Tupel liefert. Um die möglicherweise stundenlange oder noch längere Wartezeit auf das Ergebnis zu reduzieren, kann in diesem Fall eine Aggregationstabelle eingesetzt werden, die genau dieses eine Tupel enthält. Durch die Aggregationstabelle entfallen alle Verbundoperationen, Anwendung von Aggregationsfunktionen und Gruppierungen. Es muss nur noch ein Tupel ausgelesen werden. Der Nachteil der Aggregationstabellen ist, dass sie eine Kopie von Daten enthalten, um /085/IN02/

26 4 Theoretische Aspekte diese konsistent zu halten muss der Dateninhalt der Aggregationstabellen regelmäßig aktualisiert werden. In obengenanntem Beispiel könnte die Aktualisierung beispielsweise einmal täglich automatisiert ablaufen. Da die Anzahl möglicher Aggregationstabellen der Anzahl möglicher Knoten in einem Aggregationsgitter entspricht, siehe Abschnitt 4.1.4, ist es nicht möglich aufgrund des anfallenden Speicherplatzbedarfs alle Aggregationstabellen zu realisieren. Im Folgenden wird beschrieben, welcher Ansatz bei der Auswahl in dieser Arbeit verfolgt wird Kostenmodell Anhand des Kostenmodells wird bestimmt, welcher Knoten des Aggregationsgitter welchen Nutzen für die Optimierung des gesamten Aggregationsgitters besitzt. Der benefit(a i, Q j ) der Anfrage Q j eines Knotens N j unter Verwendung einer Aggregationstabelle A i eines Knotens N i wird mittels der Formel 4.3 berechnet. benefit(a i, Q j ) = { 0 wenn (c j,l c j,i ) < 0 (c j,l c j,i ) cnt j sonst { k wenn A k : (A k ist realisiert) (c j,k < c j,0 ) mit l = 0 sonst (4.3) Die Reduktion der Anfragekosten, c j,l, wird durch den Vergleich mit den Anfragekosten auf der Basisrelation, c j,0 oder eines bereits realisierten Knotens berechnet. Bei Verwendung eines bereits realisierten Knotens N l ist es möglich, dass die Kosten c j,i die Kosten c j,l übersteigen. In diesem Fall verwendet die Anfrage Q j die Aggregationstabelle A i nicht und somit ist der benefit(a i, Q j ) = 0. Weiterhin wird mittels der Variablen cnt j berücksichtigt, wie häufig die Anfrage Q j ausgeführt wird. Je häufiger Q j angefragt wird, umso größer ist der benefit, denn bei jeder Anfrage wird der gleiche Betrag an Kosten eingespart. Um den Gesamtnutzen, benefit(a i ), Formel 4.4, der Aggregationstabelle eines Knotens zu bestimmen, werden die Ableitbarkeitsbeziehungen des Aggregationsgitters ausgenutzt. benefit(a i ) = x X benefit(a i, Q x ) mit X = {i} {j} ; j : N i N j (4.4) Es wird sowohl für den Knoten N i als auch für alle abgeleiteten Knoten von N i der benefit bestimmt. Aus der Summe dieser Werte ergibt sich der Gesamtnutzen der Aggregationstabelle A i. Als Voraussetzung für dieses Kostenmodell muss gelten, dass eine Anfrage Q j immer diejenige der realisierten Aggregationstabellen A i verwendet, bei der die Kosten c j,i am /085/IN02/

27 4 Theoretische Aspekte geringsten sind. Weiterhin verwendet eine Anfrage Q j die Basisrelationen anstatt einer Aggregationstabelle, falls c j,i > c j,0 für alle realisierten Aggregationstabellen gilt. Die hier vorgestellten Formeln geben die Grundidee des Kostenmodells wieder. Das Kostenmodell, welches bei der Implementierung verwendet wird und dieses Kostenmodell als Basis besitzt, ist in Abschnitt 6.6 näher erläutert Nutzen/Kosten für Aggregationstabellen Grundvoraussetzung für die Auswahl von Aggregationstabellen ist die Möglichkeit diese bezüglich ihres Nutzens zu Vergleichen. Hierfür werden Daten über die Aggregationstabellen selbst und Anfragen, die diese verwenden können, benötigt. Benötigter Speicherplatz Aggregationstabellen werden im Gegensatz zu Views nicht während des Zugriffs berechnet. Sie werden zu festgelegten Zeitpunkten erzeugt und die berechneten Ergebnisse gespeichert und benötigen deshalb Speicherplatz. Da nicht beliebig viel Speicherplatz für die Optimierung zur Verfügung steht ist dies ein wichtiges Kriterium für die Auswahl von Aggregationstabellen. Der verfügbare Speicher ist der limitierende Faktor für den Selektionsalgorithmus, der die Entscheidung trifft, ob eine Aggregationstabelle für die Realisierung ausgewählt wird. Überschreitet eine Aggregationstabelle den verfügbaren Speicherplatz kann die Kostenreduktion von Anfragen beliebig groß und doch nicht realisierbar sein. Für die Zuweisung von Speicherplatz existieren unterschiedliche Möglichkeiten. Beispielsweise könnte festgelegt werden, dass maximal 10% der Größe der Basistabellen für die Optimierung zur Verfügung steht oder es kann ein statischer Wert verwendet werden. Da der Administrator eines Datenbank-/OLAP-Servers den genauesten Überblick hat, wieviel Speicherplatz für die Optimierung verwendet werden kann, wird in dieser Arbeit von einem statischen Wert ausgegangen. Wartungskosten Ein wichtiger Punkt für ein reales Data-Warehouse sind die Wartungskosten für Aggregationstabellen. Die Korrelation zu den Basisrelationen kann, abhängig von der Größe der Basisrelationen und der Struktur der Aggregationstabellen, erhebliche Kosten verursachen. Diese bestehen einerseits aus den Berechnungskosten für die Aggregationen, als auch aus den I/O-Kosten, denn Aggregationstabellen sind physisch abgelegt. Weiterhin ist zu berücksichtigen, wie auf das Data-Warehouse zugegriffen wird. Wird es nur zur Speicherung historischer Daten verwendet, indem beispielsweise einmal täglich die Daten aus den operationalen Datenbanken des Unternehmens abgelegt werden, fallen die Aktualisierungskosten geringer aus, als wenn die Daten stündlich aktualisiert werden. Wegen der zeitlichen Begrenzung dieser Diplomarbeit ist das Einbeziehen der Wartungskosten im Rahmen der Implementierung dieser Arbeit leider nicht möglich /085/IN02/

28 4 Theoretische Aspekte Konfigurationsbestimmung Das Ziel dieser Arbeit ist es die Auswahl von Aggregationstabellen zu optimieren. Es werden unterschiedliche Algorithmen verwendet, die anhand des Kostenmodells zur Berechnung des Nutzens, die Entscheidung treffen, welche Aggregationstabellen für die Realisierung ausgewählt werden. Die Menge der Aggregationstabellen wird Konfiguration, C, genannt und ist eine Teilmenge der durch das Aggregationsgitter bestimmten Knoten beziehungsweise deren Aggregationstabellen. Die Potenzmenge, P (C), enthält alle möglichen Konfigurationen C. C {A 1, A 2,..., A n } (4.5) size(c) = A i C size(a i ) (4.6) benefit(c) = A i C benefit(a i ) (4.7) Die Suche nach der optimalen Lösung ist im allgemeinen Fall unter Verwendung eines maximal zur Verfügung stehenden Speicherplatzes ein NP-hartes Problem [27]. Deutlich wird dies in der Implementierung des Algorithmus des OptimalAdvisors in Abschnitt 8.1. Für die Algorithmen gelten weiterhin zwei wichtige Annahmen. Die erste ist, dass eine Anfrage immer die Aggregationstabelle verwendet, die die günstigste Ausführung verspricht. Zweitens verwendet eine Anfrage entweder genau eine Aggregationstabelle oder keine und somit die Basisrelationen zur Beantwortung. Der Verbund von mehreren Aggregationstabellen oder Aggregationstabellen und Basisrelationen zur Beantwortung von Anfragen sind nicht möglich. 4.4 Knotenerzeugung anhand von MDX-Anfragen Die Knoten des Aggregationsgitters werden mit den an Mondrian gestellten MDX-Anfragen generiert. Im Folgenden werden exemplarisch, anhand einer Beispiel MDX-Anfrage aus Listing 4.1, die Schritte erläutert, die notwendig sind, um einen Knoten zu Erzeugen. 1 select 2 {[Measures].[Store Cost], [ Measures].[Unit Sales]} on columns, 3 CrossJoin( 4 { 5 [Product].[Food].[Canned Products].[Fruit], 6 [Product].[Food].[Canned Products], 7 [Product].[Food], 8 [ Product].[All Products] 9 }, /085/IN02/

29 4 Theoretische Aspekte 10 { 11 [Gender].[F] 12 }) on rows 13 from [Sales] 14 where [Time].[1997]; Listing 4.1: Exemplarische MDX-Anfrage Die Anfrage aus Listing 4.1 liefert als Resultat eine Auflistung zweier Kennzahlen( Store Cost, Unit Sales ) für die Produkte beziehungsweise Produktkategorien( Fruit, Canned Products, Food, All Products ) für weibliche Kunden( F ) für das Jahr Der erste Schritt bei der Generierung eines Knotens des Aggregationsgitters ist die Extrahierung aller verwendeten Dimensionen(Listing 4.2) aus der gestellten MDX-Anfrage. 18 [ Measures].[Store Cost] 19 [ Measures].[Unit Sales] 20 [ Product].[Food].[Canned Products].[Fruit] 21 [ Product].[Food].[Canned Products] 22 [Product].[Food] 23 [ Product].[All Products] 24 [Gender].[F] 25 [Time].[1997] Listing 4.2: Extrahierte Dimensionen der MDX-Anfrage aus Listing 4.1 Der zweite Schritt besteht in der Verallgemeinerung der spezifischen Selektionen der Anfrage, Listing 4.3. Das Ergebnis sind alle angefragten Dimensionen beziehungsweise ihrer Level für die gestellte MDX-Anfrage. 29 [ Measures].[Store Cost] 30 [ Measures].[Unit Sales] 31 [ Product].[Product Family].[Product Department].[Product Category] 32 [ Product].[Product Family].[Product Department] 33 [ Product].[Product Family] 34 [ Product].[All Products] 35 [Gender].[Gender] 36 [Time].[Year] Listing 4.3: Generalisierung der Dimensionen aus Listing 4.2 Der letzte Schritt bei der Erzeugung eines Gitterknotens ist die Zusammenfassung der angefragten Dimensionen. Von jeder Dimension, in diesem Fall trifft dies nur auf Product /085/IN02/

30 4 Theoretische Aspekte zu, wird nur das niedrigste Level, Listing 4.3, Zeile 31, weiterverwendet. Die drei anderen Product Dimensionen(Listing 4.3, Zeile 32, 33, 34), können aus diesem abgeleitet werden und sind nicht zur Knotendefinition nötig. 40 [ Measures].[Store Cost] 41 [ Measures].[Unit Sales] 42 [ Product].[Product Family].[Product Department].[Product Category] 43 [Gender].[Gender] 44 [Time].[Year] Listing 4.4: Knoten erzeugende Dimensionen aus Anfrage 4.1 Die Dimensionen aus Listing 4.4 bilden den Knoten im Aggregationsgitter. Alle MDX- Anfragen, die die gleiche Menge an Dimensionen und Dimensionsebenen abfragen, werden von diesem Knoten repräsentiert und diesem zugeordnet. 4.5 Verallgemeinerte SQL-Anfragen für Gitterknoten Nach der Knotenerzeugung wird für den Aufbau von Aggregationstabellen und das Abschätzen von Kosten eine allgemeine SQL-Anfrage für jeden Knoten benötigt. Diese allgemeine Anfrage repräsentiert alle Anfragen eines Knotens im Aggregationsgitter. Das bedeutet jede MDX-Anfrage, die durch diesen Knoten repräsentiert wird, kann durch eine Teilmenge des Resultats dieser verallgemeinerten SQL-Anfrage beantwortet werden. Es werden nur Projektionen und Aggregationen verwendet, jedoch keine Selektionen, die den Ergebnisraum einschränken würden. Details zu der Erzeugung anhand eines Beispiels und der Implementierung sind in Abschnitt 6.4 zu finden /085/IN02/

31 5 Entwicklungsumgebung In diesem Kapitel wird ein Überblick über die zur Implementierung notwendigen Komponenten gegeben. Dazu gehört einerseits der OLAP-Server Mondrian und das relationale Datenbankmanagementsystem DB2 andererseits die Beispieldatenbanken, die für Tests und Evaluation verwendet werden. 5.1 Mondrian Mondrian ist ein Community Projekt der Pentaho Corporation, welche eine im Bereich der Business Intelligence operierende Firma ist [24]. Ihre Produktpalette bietet umfangreiche Auswertungsmöglichkeiten von Firmendaten, dazu zählen OLAP Analysen, Dashboards 1, Datenintegration und Data Mining. Als Basis verwendet sie Open Source Software und verkaufen Dienstleistungen, wie zum Beispiel den technischen Support an Endkunden. Das für diese Arbeit interessante Produkt ist das Community Projekt Mondrian. Es ist ein Open Source Projekt unter der Leitung des Hauptentwicklers Julian Hyde. Der entwickelte OLAP-Server Mondrian dient als Schicht zwischen dem Benutzer und einer relationalen Datenbank. Er ermöglicht es, das der Benutzer MDX-Anfragen an das System stellt, welche auf ein relationales Datenbanksystem umgesetzt werden, ohne dass der Benutzer selbst mit dem relationalen Aspekt der Daten in Kontakt kommt. Hierzu zählt beispielsweise auch das Verbergen der notwendigen SQL-Anweisungen. Die Implementierung von Mondrian basiert auf der Programmiersprache Java, die dadurch bedingt ebenfalls in dieser Arbeit verwendet wird. Neben dem OLAP-Server Mondrian existiert ein Applikation, JPivot, die diesen verwendet. JPivot ist eine webbrowserbasierte Benutzerschnittstelle, um auf das multidimensionale Datenmodell zugreifen zu können. Neben der einfachen Navigation innerhalb des Datenwürfels liefert JPivot eine grafische Auswertung der analysierten Daten. Um eine einfache Benutzung zu ermöglichen, muss der Benutzer selbst keine MDX-Anfragen erzeugen, diese Aufgabe wird von JPivot übernommen. Durch die Bereitstellung eines voll funktionsfähigen Systems, welches zudem noch im Quellcode vorhanden ist, kann sich diese Arbeit nur auf die Implementierung eines Aggregationsgitters konzentrieren. Die Analyse und Syntax Definition von Schemainformationen und MDX-Anfragen wird vollständig von Mondrian abgedeckt. Weiterhin ist die automatische Erkennung und Verwendung von Aggregationstabellen durch Mondrian ein Vorteil, der den Aufwand der Implementierung verringert. 1 Dashboards sind eine Visualisierungsform verdichteter Informationen von Geschäftsprozessen. 22

32 5 Entwicklungsumgebung Damit Mondrian vollständig mit der Optimierungskomponente zusammenarbeiten kann, müssen einige Änderungen an Mondrian vorgenommen werden. Diese bestehen teilweise aus der Beseitigung von Fehlern, als auch der Erweiterung von Mondrian. Zu den Erweiterungen zählt das Hinzufügen von Konfigurationsoptionen für die Optimierungskomponente. Diese werden in der MondrianProperties-Klasse ergänzt und in der Standardkonfiguration dokumentiert. Ebenfalls eine Erweiterung ist die Anpassung der CmdRunner-Komponente, um die Fähigkeiten die Optimierungskomponente zu steuern. Damit die automatische Erkennung von Aggregationstabellen durch Mondrian bei Verwendung einer DB2 -Datenbank funktioniert, wird die Liste der gültigen Tabellentypen angepasst. Standardmäßig werden von Mondrian nur Aggregationstabellen vom Typ Table und View erkannt. Bei DB2 besitzen jedoch die Aggregationstabellen den Typ Materialized Query Table. Ohne diese Anpassung werden von Mondrian jegliche vorhandenen, von DB2 nativ unterstützten, Aggregationstabellen ignoriert. Den größten Aufwand bedarf der AggGen, der Aggregate Generator. Laut Dokumentation [6] ist dies keine Kernkomponente von Mondrian und wird nicht intensiv weiterentwickelt. Dies führt dazu, dass diverse Fehler in der Generierung der SQL-Anfragen zur Erzeugung von Aggregationstabellen enthalten sind. Weiterhin erzeugt der AggGen in seiner Standardimplementierung jeweils vollständige SQL-Anfragen, welche zur Erzeugung von herkömmlichen Tabellen und deren Füllen mit Daten dienen. Hierbei wird jedoch nicht berücksichtigt, dass beispielsweise DB2 eine native Unterstützung für Aggregationstabellen besitzt. Aus diesem Grund wird die Schnittstelle des AggGen erweitert, um lediglich die erweiterten SQL-Anfragen aus Abschnitt 6.4 generieren zu können. 5.2 DB2 Als relationales Datenbankmanagementsystem wird IBM DB2 Express-C 9.5 von IBM verwendet [12]. Die Auswahl fällt auf DB2, da es alle notwendigen Eigenschaften besitzt, die von der Implementierung dieser Arbeit benötigt werden. Dazu zählt besonders die explain-funktionalität, die es ermöglicht Kosteninformationen über SQL-Anfragen von dem RDBMS zu erhalten. Weiterhin bietet die native Unterstützung von Aggregationstabellen Vorteile. Dies äußert sich beispielsweise in der relative einfachen Weise, in der Aggregationstabellen beziehungsweise Materialized Query Tables angelegt werden. Es wird lediglich eine SQL-Anfrage benötigt, aus dieser kann DB2 automatisch eine vollständige Aggregationstabelle erzeugen, ohne spezielle Angaben zur Struktur oder Tabellen- und Spaltendefinitionen. Vergleiche Abschnitt 6.5. Ein weiterer positiver Aspekt ist die kostenlose Verfügbarkeit von DB2, zwar mit Einschränkungen bei der Skalierbarkeit, jedoch für die Implementierung vollkommend ausreichend. Es existieren auch weitere RDBMS, die diese Eigenschaften besitzen. Dazu zählen auch Oracle 2 und Ingres 3, da jedoch die Implementierung der Kostenschätzung sehr spezifisch 2 Für nähere Informationen zum Oracle DBMS, siehe [23]. 3 Nähere Informationen über das Ingres DBMS sind unter [16] zu finden /085/IN02/

33 5 Entwicklungsumgebung auf die Datenbank zugeschnitten ist, wird DB2 als Repräsentant ausgewählt. Der Einsatz von DB2 erfolgt weitestgehend ohne besondere Optimierungen. Bei der Foodmart-Datenbank, deren Datenvolumen relativ klein ist, werden keine Anpassungen nach der DB2 -Installation benötigt. Lediglich bei der Verwendung der TPC-H Datenbank müssen einige Datenbankparameter angepasst, um mit den großen Datenmengen arbeiten zu können. Hierzu zählt das Vergrößern des verfügbaren Logging Speicherplatzes für die Datenbank, sodass große Transaktionen, wie sie beim Anlegen der Aggregationstabellen stattfinden, keine Fehler bei der Ausführung erzeugen. Weiterhin wird eine Optimierung vorgenommen, sodass DB2 eigenständig die Verwendung der Aggregationstabellen in Betracht zieht. Hierfür wird der Parameter DFT QUERY- OPT, was für default query optimization level steht, auf den Wert 7 eingestellt. DB2 besitzt unterschiedliche Level für die Optimierung der an das System gestellten SQL- Anfragen, je geringer das Level, desto weniger Optimierung wird vor der Ausführung der Anfrage vorgenommen. Da die Ausführung der in dieser Arbeit verwendeten MDX/SQL- Anfragen mehrere Minuten in Anspruch nimmt, wird der Wert von der Standardeinstellung 5 auf 7 erhöht, um einerseits die Ausführung zu beschleunigen, andererseits auch die automatische Verwendung von Materialized Query Tables zu aktivieren. Zusätzlich wird die Konfigurationsoption DFT REFRESH AGE auf den Wert ANY gesetzt. Diese Option gibt an, wie lange der Zeitraum seit der letzten Aktualisierung eines Materialized Query Tables vergangen sein darf, damit dieser noch verwendet wird. Durch die Angabe von ANY wird jeder vorhandene mit Daten gefüllte Materialized Query Tables verwendet. Weiterhin wurden bei der TPC-H Datenbank diverse Anfragen abgebrochen mit der Meldung, dass die verfügbaren Seiten im Bufferpool der Datenbank erschöpft seien. Dies wird durch das Anlegen eines Bufferpools mit Seiten und 4KB pro Seite, das entspricht ca. 400MB, behoben. Dieser Wert wurde auf Basis von Tests als ausreichend ermittelt. 5.3 Foodmart - Datenbank Die Foodmart Datenbank wird zusammen mit Mondrian zum Herunterladen angeboten. Die Datenbank erlaubt einen Einblick in die Funktionsweise von Mondrian. Die Struktur zusammen mit der XML-Schema-Definition, siehe Anhang A.1, bietet einen tiefen Einblick in die Möglichkeiten von Mondrian. Das Star-/Snowflake Schema der Foodmart Datenbank, Abbildung 5.1, ist ein Ausschnitt des vollständigen Schemas. Es enthält die Komponenten die in dieser Arbeit in Beispielen Verwendung finden. Die Darstellung der multidimensionalen Definition mittels eines XML-Schemas, wie sie von Mondrian benötigt wird, ist in Anhang A.1 zu finden /085/IN02/

34 5 Entwicklungsumgebung FOODMART.promotion promotion_id INTEGER promotion_district_id INTEGER promotion_name VARCHAR (30) media_type VARCHAR (30) cost DECIMAL (10,4) start_date TIMESTAMP end_date TIMESTAMP FOREIGN_PROMOTION_ID FOODMART.customer customer_id INTEGER account_num BIGINT lname VARCHAR (30) fname VARCHAR (30) mi VARCHAR (30) address1 VARCHAR (30) address2 VARCHAR (30) address3 VARCHAR (30) address4 VARCHAR (30) city VARCHAR (30) state_province VARCHAR (30) postal_code VARCHAR (30) country VARCHAR (30) customer_region_id INTEGER phone1 VARCHAR (30) phone2 VARCHAR (30) birthdate DATE marital_status VARCHAR (30) yearly_income VARCHAR (30) gender VARCHAR (30) total_children SMALLINT num_children_at_home SMALLINT education VARCHAR (30) date_accnt_opened DATE member_card VARCHAR (30) occupation VARCHAR (30) houseowner VARCHAR (30) num_cars_owned INTEGER fullname VARCHAR (60) FOODMART.product_class product_class_id INTEGER product_subcategory VARCHAR (30) product_category VARCHAR (30) product_department VARCHAR (30) product_family VARCHAR (30) FOREIGN_PRODUCT_CLASS_ID FOREIGN_PRODUCT_ID FOODMART.sales_fact_1997 product_id INTEGER time_id INTEGER customer_id INTEGER promotion_id INTEGER store_id INTEGER store_sales DECIMAL (10,4) store_cost DECIMAL (10,4) unit_sales DECIMAL (10,4) FOREIGN_CUSTOMER_ID FOREIGN_TIME_ID FOODMART.product product_class_id INTEGER product_id INTEGER brand_name VARCHAR (60) product_name VARCHAR (60) SKU BIGINT SRP DECIMAL (10,4) gross_weight REAL (24) net_weight REAL (24) recyclable_package SMALLINT low_fat SMALLINT units_per_case SMALLINT cases_per_pallet SMALLINT shelf_width REAL (24) shelf_height REAL (24) shelf_depth REAL (24) FOREIGN_STORE_ID FOODMART.store store_id INTEGER FOODMART.time_by_day store_type VARCHAR (30) time_id INTEGER region_id INTEGER the_date TIMESTAMP store_name VARCHAR (30) the_day VARCHAR (30) store_number INTEGER the_month VARCHAR (30) store_street_address VARCHAR (30) the_year SMALLINT store_city VARCHAR (30) day_of_month SMALLINT store_state VARCHAR (30) week_of_year INTEGER store_postal_code VARCHAR (30) month_of_year SMALLINT store_country VARCHAR (30) quarter VARCHAR (30) store_manager VARCHAR (30) fiscal_period VARCHAR (30) store_phone VARCHAR (30) store_fax VARCHAR (30) FOREIGN_REGION_ID first_opened_date TIMESTAMP FOREIGN_REGION_ID last_remodel_date TIMESTAMP store_sqft INTEGER FOODMART.region grocery_sqft INTEGER region_id INTEGER frozen_sqft INTEGER sales_city VARCHAR (30) meat_sqft INTEGER sales_state_province VARCHAR (30) coffee_bar SMALLINT sales_district VARCHAR (30) video_store SMALLINT sales_region VARCHAR (30) salad_bar SMALLINT sales_country VARCHAR (30) prepared_food SMALLINT sales_district_id INTEGER florist SMALLINT Powered by yfiles Abbildung 5.1: Ausschnitte aus dem Foodmart Datenbankschema /085/IN02/

35 5.4 TPC-H - Datenbank 5 Entwicklungsumgebung Der TPC-H Benchmark ist ein von der TPC 4 -Gesellschaft zur Verfügung gestellter Benchmark, um die Leistungsfähigkeit von Datenbankmanagementsystemen bewerten und vergleichen zu können. Die Gesellschaft wurde 1988 gegründet und stellt seit diesem Zeitpunkt Benchmarks für Datenbanken in unterschiedlichen Anwendungsbereichen bereit. Einer dieser Benchmarks ist TPC-H, er besteht aus einer Menge geschäftlich orientierter Ad-hoc-Anfragen bei gleichzeitiger Datenänderung. Der Fokus der Anfragen liegt primär darauf eine große Menge an Daten zu analysieren und somit eine erhebliche Laufzeit zu benötigen [28]. Für die Evaluation der Implementierung dieser Arbeit können diese Anfragen nicht verwendet werden, da es reine SQL-Anfragen sind und es keine auf MDX basierende Version existiert. Was jedoch für die Evaluation Verwendung findet ist die Funktion der Datengenerierung, um eine Datenbank mit Zufallsdaten zu füllen. Mittels des Datengenerators DBGEN, der Teil der TPC-H Distribution ist, können Rohdaten für eine relationale Datenbank von 1GB bis 100TB erstellt werden. Die Größe der einzelnen Relationen basiert auf einer Konstante für jede Relation und einem Skalierungsfaktor, der die Gesamtgröße der Datenbank bestimmt. Der Einsatz von einer TPC-H basierten Datenbank wird in der Evaluationsphase dieser Arbeit nötig. Die Foodmart Datenbank hat zwar einen sehr guten Aufbau als Basis für einen OLAP-Server, jedoch ist der Umfang recht klein. Die Faktentabelle enthält lediglich ca Tupel. Dies führt dazu, dass die Laufzeit von Anfragen sehr kurz ist und sich daraus kaum verwertbare Resultate ableiten lassen. Damit die Daten des TPC-H Benchmarks für Mondrian verwendet werden können, müssen einige Anpassungen vorgenommen werden. Das angepasste Datenbankschema, welches für die Evaluation Verwendung findet ist in Abbildung 5.2 zu sehen. Primär-/Fremdschlüssel Der wichtigste Punkt ist, ist das Mondrian keine zusammengesetzten Primär-/Fremdschlüssel unterstützt, wie das bei der Beziehung zwischen den Tabellen LINEITEM und PARTSUPP der Fall ist. Aus diesem Grund wird der Schlüssel bestehend aus PARTKEY, SUPPKEY durch einen künstlichen Schlüssel PARTSUPPKEY ersetzt. Dieser wird der Tabelle PARTSUPP bzw. PARTEXT als Primär- und der Tabelle LINEITEM als Fremdschlüssel hinzugefügt. Die somit unnötigen Spalten PARTKEY, SUPPKEY der LINEITEM Tabelle werden entfernt. Erzeugen der Zeitdimension, CSHIPDATE Die Erzeugung einer Zeitdimension ist nicht dringend notwendig, jedoch im Kontext einer OLAP-Anwendung durchaus 4 Transaction Processing Performance Council, siehe [28] /085/IN02/

36 5 Entwicklungsumgebung angebracht. Die CSHIPDATE Tabelle wird aus dem Feld L SHIPDATE der LINEI- TEM Tabelle erzeugt. Hierfür werden alle darin gespeicherten Daten nach Jahr, Monat und Tag getrennt in der neu angelegten Tabelle eingefügt. Integration von PART und PARTSUPP Die Tabellen PART und PARTS- UPP werden zu einer neuen Tabelle PARTEXT zusammenfasst. Dies ist notwendig, weil Mondrian keine Unterstützung für Verbundoperationen von einer Tabelle mit zwei weiteren innerhalb einer Dimension bietet. Duplizierung von NATION und REGION Zur Erhöhung der Ebenenanzahl der Order Dimension werden die beiden Tabellen NATION und Region dupliziert und als Tabellen CNATION und CREGION zusätzlich in der Datenbank angelegt. Wegen der geringen Größe dieser Tabellen erfordert dies kaum Speicherplatz. Schema-Definition Das Schema in Listing 5.1 definiert für Mondrian einen Cube, auf Basis des Datenbankschemas auf Abbildung 5.2, bestehend aus drei Dimensionen, Time, Order und Part. In Tabelle 5.1 sind die in Listing 5.1 definierten Dimensionen aufgeführt. Zusätzlich zu den Dimensionen sind die zwei definierten Kennzahlen aufgelistet. In Listing 5.1 werden nicht nur die Dimensionen definiert, sondern auch in welcher Reihenfolge und anhand welcher Spalten die Relationen verknüpft werden müssen. Dies wird über die Join-Klauseln innerhalb der Dimensionsdefinitionen vorgenommen. Dimensionen Relationen/Spalten Bezeichnung Time cshipdate.year Year cshipdate.month Month cshipdate.day Day Order cregion.cr NAME Order Region cnation.cn NAME Order Nation customer.c NAME Customer Name orders.o ORDERDATE Order Date Part region.r NAME Region Name nation.n NAME Nation Name supplier.s NAME Supplier Name partext.p TYPE Part Type partext.p MFGR Part Manufacturer partext.p BRAND Part Brand partext.p NAME Part Name Measures lineitem.l EXTENDEDPRICE Extended Price lineitem.l QUANTITY Quantity Tabelle 5.1: Dimensionen mit ihren Ebenen des TPC-H-Mondrian-Schemas. Die Ebenen sind von grob- nach feingranular sortiert /085/IN02/

37 5 Entwicklungsumgebung FOODMART.CSHIPDATE L_SHIPDATE YEAR MONTH DAY DATE INTEGER INTEGER INTEGER L_SHIPDATE_FK FOODMART.ORDERS O_ORDERKEY INTEGER O_CUSTKEY INTEGER O_ORDERSTATUS CHAR (1) O_TOTALPRICE DECIMAL (15,2) L_ORDERKEY_FK O_ORDERDATE DATE O_ORDERPRIORITY CHAR (15) O_CLERK CHAR (15) O_SHIPPRIORITY INTEGER O_COMMENT VARCHAR (79) O_CUSTKEY_FK FOODMART.CUSTOMER C_CUSTKEY INTEGER C_NAME VARCHAR (25) C_ADDRESS VARCHAR (40) C_NATIONKEY INTEGER C_PHONE CHAR (15) C_ACCTBAL DECIMAL (15,2) C_MKTSEGMENT CHAR (10) C_COMMENT VARCHAR (117) C_NATIONKEY_FK FOODMART.CNATION CN_NATIONKEY INTEGER CN_NAME CHAR (25) CN_REGIONKEY INTEGER CN_COMMENT VARCHAR (152) CN_REGIONKEY_FK FOODMART.CREGION CR_REGIONKEY INTEGER CR_NAME CHAR (25) CR_COMMENT VARCHAR (152) FOODMART.LINEITEM L_ORDERKEY INTEGER L_PARTKEY INTEGER FOODMART.PARTEXT L_SUPPKEY INTEGER PS_PARTSUPPKEY INTEGER L_LINENUMBER INTEGER PS_PARTKEY INTEGER L_QUANTITY DECIMAL (15,2) PS_SUPPKEY INTEGER L_EXTENDEDPRICE DECIMAL (15,2) L_PARTSUPPKEY_FK P_NAME VARCHAR (55) L_DISCOUNT DECIMAL (15,2) P_MFGR CHAR (25) L_TAX DECIMAL (15,2) P_BRAND CHAR (10) L_RETURNFLAG CHAR (1) P_TYPE VARCHAR (25) L_LINESTATUS CHAR (1) L_SHIPDATE DATE PS_SUPPKEY_FK L_COMMITDATE DATE L_RECEIPTDATE DATE L_SHIPINSTRUCT CHAR (25) FOODMART.SUPPLIER L_SHIPMODE CHAR (10) S_SUPPKEY INTEGER L_COMMENT VARCHAR (44) S_NAME CHAR (25) L_PARTSUPPKEY INTEGER S_ADDRESS VARCHAR (40) S_NATIONKEY INTEGER S_PHONE CHAR (15) S_ACCTBAL DECIMAL (15,2) S_COMMENT VARCHAR (101) S_NATIONKEY_FK FOODMART.NATION N_NATIONKEY INTEGER N_NAME CHAR (25) N_REGIONKEY INTEGER N_COMMENT VARCHAR (152) N_REGIONKEY_FK FOODMART.REGION R_REGIONKEY INTEGER R_NAME CHAR (25) R_COMMENT VARCHAR (152) Abbildung 5.2: Datenbankschema des für Mondrian angepassten TPC-H Benchmarks. Powered by yfiles /085/IN02/

38 5 Entwicklungsumgebung 1 <?xml version= 1.0 encoding= UTF 8?> 2 <Schema name= tpch > 3 <Cube name= tpch > 4 <Table name= LINEITEM /> 5 <Dimension name= Time foreignkey= L SHIPDATE > 6 <Hierarchy hasall= true primarykey= L SHIPDATE > 7 <Table name= CSHIPDATE /> 8 <Level name= Year table= CSHIPDATE column= YEAR type= Numeric uniquemembers= false /> 9 <Level name= Month table= CSHIPDATE column= MONTH type= Numeric uniquemembers= false /> 10 <Level name= Day table= CSHIPDATE column= DAY type= Numeric uniquemembers= false /> 11 </Hierarchy> 12 </Dimension> <Dimension name= Order foreignkey= L ORDERKEY > 15 <Hierarchy hasall= true primarykey= O ORDERKEY primarykeytable= ORDERS > 16 <Join leftkey= O CUSTKEY rightalias= CUSTOMER rightkey= C CUSTKEY > 17 <Table name= ORDERS /> 18 <Join leftkey= C NATIONKEY rightalias= CNATION rightkey= CN NATIONKEY > 19 <Table name= CUSTOMER /> 20 <Join leftkey= CN REGIONKEY rightkey= CR REGIONKEY > 21 <Table name= CNATION /> 22 <Table name= CREGION /> 23 </Join> 24 </Join> 25 </Join> 26 <Level name= Order Region table= CREGION column= CR NAME uniquemembers= false /> 27 <Level name= Order Nation table= CNATION column= CN NAME uniquemembers= false /> 28 <Level name= Customer Name table= CUSTOMER column= C NAME uniquemembers= false /> 29 <Level name= Order Date table= ORDERS column= O ORDERDATE type= Date uniquemembers= false /> 30 </Hierarchy> 31 </Dimension> <Dimension name= Part foreignkey= L PARTSUPPKEY > /085/IN02/

39 5 Entwicklungsumgebung 34 <Hierarchy hasall= true primarykey= PS PARTSUPPKEY primarykeytable= PARTEXT > 35 <Join leftkey= PS SUPPKEY rightalias= SUPPLIER rightkey= S SUPPKEY > 36 <Table name= PARTEXT /> 37 <Join leftkey= S NATIONKEY rightalias= NATION rightkey= N NATIONKEY > 38 <Table name= SUPPLIER /> 39 <Join leftkey= N REGIONKEY rightkey= R REGIONKEY > 40 <Table name= NATION /> 41 <Table name= REGION /> 42 </Join> 43 </Join> 44 </Join> 45 <Level name= Region Name table= REGION column= R NAME uniquemembers= false /> 46 <Level name= Nation Name table= NATION column= N NAME uniquemembers= false /> 47 <Level name= Supplier Name table= SUPPLIER column= S NAME uniquemembers= false /> 48 <Level name= Part Type table= PARTEXT column= P TYPE uniquemembers= false /> 49 <Level name= Part Manufacturer table= PARTEXT column= P MFGR uniquemembers= false /> 50 <Level name= Part Brand table= PARTEXT column= P BRAND uniquemembers= false /> 51 <Level name= Part Name table= PARTEXT column= P NAME uniquemembers= false /> 52 </Hierarchy> 53 </Dimension> <Measure name= Extended Price column= L EXTENDEDPRICE aggregator = sum datatype= Numeric formatstring= #,##0.### /> 56 <Measure name= Quantity column= L QUANTITY aggregator= sum datatype= Numeric formatstring= #,##0.### /> 57 </Cube> 58 </Schema> Listing 5.1: XML-Schema-Definition der TPC-H Datenbank für Mondrian /085/IN02/

40 6 Implementierung In diesem Kapitel wird die Implementierung der Optimierungskomponente vorgestellt. Neben der Erzeugung des Aggregationsgitters wird näher auf die Kostenschätzung, die Aggregationstabellenauswahl und die Aggregationstabellenrealisierung eingegangen. 6.1 Integration in Mondrian In Abbildung 6.1 ist die Integration der Optimierungskomponente(Optimization Lattice) dieser Arbeit in das bestehende Mondrian System zu sehen. Um möglichst unabhängig von zukünftigen Änderung von Mondrian zu sein greift das Optimierungsgitter nur an einer Stelle in das System ein. Dieser Einstiegspunkt ist nach der Analyse und der Validierung einer MDX-Anfrage. Nachdem die Optimierungskomponente über die gültige MDX-Anfrage informiert wurde, setzt das Mondrian-System die normale Abarbeitung der Anfrage fort. Der einzige weitere Teil von Mondrian, der von der Optimierungskomponente verwendet wird, ist der AggGen. Wird bei einem Knoten im Aggregationsgitter die verallgemeinerte SQL-Anfrage dieses Knotens abgefragt, wird der Aggregate Generator genutzt, um diese zu erzeugen. Die detaillierte Struktur der Optimierungskomponente und die Interaktion mit Mondrian ist Abbildung 6.2 dargestellt. Der CmdRunner 1 ist eine Kommandozeilen-Applikation, welche es den Entwicklern ermöglicht das Mondrian System zu benutzen und zu steuern. Damit dies ebenfalls bei der Optimierungskomponente möglich ist, wird der CmdRunner um diverse Befehle erweitert, die es ihm ermöglicht mittels des LatticeManagers auf diverse Funktionalitäten des Aggregationsgitters und die anderen Komponenten zuzugreifen. Neben dem CmdRunner ist das Administration GUI die zweite Schnittstelle, mit deren Hilfe der Administrator beziehungsweise Entwickler auf die Optimierungskomponente Einfluss nehmen kann. Einen Überblick über die Möglichkeiten des Administration GUI wird in Abschnitt 6.3 gegeben. 1 Abkürzung für Command Runner. 31

41 6 Implementierung Client Application/s MDX Session Manager MDX Parser MDX Validator Result Evaluator Optimization Lattice Dimensional Layer AggGen Star Layer Aggregate Manager Session + Dimensional Manager SQL Generator RDBMS SQL Layer Abbildung 6.1: Interaktion des Aggregationsgitters mit dem Mondrian System /085/IN02/

42 6.2 Grundlegender Ablauf 6 Implementierung In diesem Abschnitt wird ein Überblick über den Ablauf in der Optimierungskomponente im Bereich der MDX-Anfragenanalyse bis zur Auswahl und Realisierung von Aggregationstabellen gegeben. Die einzelnen Komponenten und deren Interaktion sind in Abbildung 6.2 zu sehen. Optimization Lattice Administration GUI Aggregation Lattice CostMatrix ConfigurationAdvisor Component LatticeManager CostEvaluator Component MDX Validator AggGen CmdRunner AggregationTableCreator Component RDBMS Abbildung 6.2: Struktur der Optimierungskomponente Sobald eine MDX-Anfrage von Mondrian als gültig und zur Abarbeitung freigegeben ist, wird der LatticeManager über diese neue Anfrage informiert, verwendet die bereits analysierte Struktur der Anfrage und erzeugt anhand der enthaltenen Dimensionen, siehe 4.4, einen Knoten. Dieser neu erzeugte Knoten wird an das eigentliche Aggregationsgitter, Aggregation Lattice, übergeben. Es fügt den Knoten zur Gitterstruktur hinzu, wenn dieser noch nicht vorhanden ist. Falls der Knoten bereits existiert, wird lediglich der Anfragenzähler dieses Knotens aktualisiert. Für eine effiziente Implementierung der Benachrichtigung anderer Komponente über die Erzeugung eines neuen Knotens wird das Publisher-Subscriber-Prinzip eingesetzt [7]. Hierbei können sich beliebige Komponenten, die Subscriber, bei dem Aggregationsgitter, dem Publisher, registrieren und werden automatisch benachrichtigt, wenn ein neuer Knoten /085/IN02/

43 6 Implementierung erzeugt wurde. Beispiele von Komponente, welche diese Möglichkeit verwenden, sind das Administration GUI aus Abschnitt 6.3 und die OnTheFly-Evaluatoren aus Abschnitt 7.5. Der Optimierungsprozess der im Aggregationsgitter enthaltenen Knoten wird durch den Administrator angestoßen. Falls kein OnTheFly-Evaluator verwendet wird, muss zuerst ein CostEvaluator gestartet werden, der die Kosten für die einzelnen Knoten bestimmt. Nachdem die Kosten bestimmt und die Kostenmatrix gefüllt wurde, entscheidet sich der Administrator für einen der implementierten ConfigurationAdvisor, konfiguriert diesen durch Angabe des verfügbaren Speicherplatzes für die Optimierung und startet diesen. Die Aggregationstabellen aus der berechnete Konfiguration wird mittels des zum RDBMS passenden AggregationTableCreators im RDBMS realisiert. 6.3 Administration GUI Das Administration GUI, intern GraphicalLatticeViewer genannt, ist ein Werkzeug zur Beobachtung und Steuerung der Optimierungskomponente. Es bildet die Gitterstruktur grafisch ab und bietet Detailinformationen zu den Knoten des Aggregationsgitters. Abbildung 6.3 zeigt die Oberfläche. Neben der Anzeige von Informationen ermöglicht das GUI das Erzeugen/Löschen von Aggregationstabellen und das Aufrufen der ConfigurationAdvisor. Sie ist in vier Bereiche unterteilt. Der erste Bereich, links oben, stellt die Struktur des Aggregationsgitters dar, mittels einer farblichen Unterscheidung wird signalisiert, ob die Aggregationstabelle eines Knotens realisiert ist. Auf der rechten Seite sind Details zu dem aktuell angewählten Knoten abgebildet, dazu gehören Informationen über die Anfragehäufigkeit, die Größe der Aggregationstabelle, die Dimensionen der MDX-Anfrage und die verallgemeinerte SQL-Anfrage. Links unten ist die Kostenmatrix dargestellt aus Abschnitt 4.2, mit den Kosten der abgebildeten Knoten. Zwischen der Kostenmatrix und den Detailinformationen der Knoten ist eine grafische Repräsentation des Alerters zu sehen Alerter - Ansatz Die Idee hinter dem Alerter-Ansatz ist es, den eingehenden Strom an Anfragen, die an das Mondrian-System gestellt werden, kontinuierlich zu analysieren. Der Alerter versucht eine geeignetere als die momentan realisiert Konfiguration zu finden. Hierzu betrachtet er Veränderungen, die durch eingehende Anfrage verursacht werden. Eine solche Veränderung wird beispielsweise durch die erneute Anfrage eines Knotens verursacht. In diesem Fall wird der Anfragenzähler des Knotens erhöht. Dies beeinflusst /085/IN02/

44 6 Implementierung Abbildung 6.3: Oberfläche des Graphical Lattice Viewers, das Administrationswerkzeug der Optimierungskomponente /085/IN02/

45 6 Implementierung wiederum den Nutzen des Knoten, als auch den Nutzen aller Knoten, von denen der veränderte Knoten ableitbar ist. Sobald der Alerter eine Konfiguration findet, deren Nutzen eine gewisse Schwelle überschreitet informiert er den Administrator, dass eine Konfiguration mit einem höheren Nutzen gefunden wurde. Die Aufgabe des Administrators besteht danach in der Verifikation dieser Meldung, dazu gehört möglicherweise die Aktualisierung der Kostenmatrix des Aggregationsgitters. 6.4 Verwendung des AggGen zur Anfragegenerierung Für die Generierung der verallgemeinerten SQL-Anfrage aus Abschnitt 4.5 wird eine bereits existierende Komponente von Mondrian verwendet, bei der diverse Fehler beseitigt und auf die Bedürfnisse des Aggregationsgitters angepasst wurde. Der AggGen 2 erzeugt basierend auf einer gegebenen Liste von Kennzahlen und Dimensionsebenen zwei Formen von SQL-Anfragen. Als Beispiel dient die MDX-Anfrage aus Listing 6.1, diese erzeugt einen Knoten mit den Dimensionen aus Listing 6.2. Dieser Knoten ist die Basis für die erzeugten SQL-Anfragen in Listing 6.3 und select 2 {[Measures].[Store Sales]} on columns, 3 crossjoin( 4 {[Product].[Food].[Baked Goods].[Bread].[Bagels].[Colony].[Colony Bagels]}, 5 {[Store ].[ USA].[OR].[Salem].[Store 13]} 6 ) on rows 7 from [Sales] 8 where [Time].[1997]; Listing 6.1: Knoten erzeugende MDX-Anfrage Die Product Dimension aus Listing 6.2 erstreckt sich über zwei Dimensionstabellen, product und product class, die durch eine Fremdschlüsselbeziehung verbunden sind. 1 [ Measures].[Store Sales ] 2 [ Product].[Product Family].[Product Department].[Product Category].[Product Subcategory].[Brand Name].[Product Name] 3 [ Store ].[ Store Country].[Store State ].[ Store City ].[ Store Name] 4 [Time].[Year] Listing 6.2: Dimensionen des Knotens für MDX-Anfrage aus Listing Kurzform für Aggregate Generator /085/IN02/

46 6 Implementierung Collapsed Methode Die Collapsed Methode wird für das Aggregationsgitter verwendet, um die verallgemeinerten SQL-Anfragen aus Listing 6.3 zu erzeugen. Hierbei wird analysiert, welche Dimensionsebenen in der Aggregationstabelle vorhanden sein sollen. Die Ebenen werden aus der Faktentabelle und den Dimensionstabellen extrahiert, Zeile 2 bis 13, die zusätzliche count(*) Spalte in Zeile 14 wird für die Bestimmung der Anzahl aggregierter Werte benötigt. Für die Verknüpfung der Fakten- und den Dimensionstabellen werden die notwendigen Join-Bedingungen in die verallgemeinerte SQL-Anfrage übernommen, Zeile 22 bis 25. Die Gruppierungsklausel, Zeile 27 bis 37, ist für die Aggregation der Daten zuständig. 1 SELECT 2 time by day. the year AS the year, 3 product. product name AS product name, 4 product. brand name AS brand name, 5 product class. product family AS product family, 6 product class. product subcategory AS product subcategory, 7 product class. product category AS product category, 8 product class. product department AS product department, 9 store. store state AS store state, 10 store. store country AS store country, 11 store. store name AS store name, 12 store. store city AS store city, 13 sum( sales fact store sales ) AS store sales, 14 COUNT( ) AS fact count 15 FROM 16 sales fact 1997 sales fact 1997, 17 time by day AS time by day, 18 product AS product, 19 product class AS product class, 20 store AS store 21 WHERE 22 sales fact time id = time by day. time id and 23 sales fact product id = product. product id and 24 product. product class id = product class. product class id and 25 sales fact store id = store. store id 26 GROUP BY 27 time by day. the year, 28 product. product name, 29 product. brand name, 30 product class. product family, 31 product class. product subcategory, /085/IN02/

47 6 Implementierung 32 product class. product category, 33 product class. product department, 34 store. store state, 35 store. store country, 36 store. store name, 37 store. store city ; Listing 6.3: Verallgemeinerte SQL-Anfrage basierend auf der Collapsed Methode und den Dimensionen aus Listing Lost Methode Die Lost Methode sei nur der Vollständigkeit halber erwähnt. Bei dieser Methode werden aus der Faktentabelle lediglich die Spalten, welche Fremdschlüssel von verwendete Dimensionstabellen enthalten beziehungsweise angefragte Kennzahlen, extrahiert. Zur Realisierung von Aggregationstabellen ist diese Möglichkeit nicht weiter interessant. Es wird zwar die Größe der Faktentabelle durch Verminderung der Spaltenanzahl und Aggregation der verbleibenden Spalten reduziert, aber es müssen weiterhin bei Verwendung dieser Tabelle die Join-Bedingungen mit den Dimensionstabellen berücksichtigt werden. Diese Berechnung erzeugt jedoch einen Großteil der Kosten bei einer Anfragebearbeitung. 1 SELECT 2 sales fact store id AS store id, 3 sales fact product id AS product id, 4 sales fact time id AS time id, 5 sum( sales fact store sales ) AS store sales, 6 COUNT( ) AS fact count 7 FROM 8 sales fact 1997 sales fact GROUP BY 10 sales fact store id, 11 sales fact product id, 12 sales fact time id ; Listing 6.4: Verallgemeinerte SQL-Anfrage basierend auf der Lost Methode und den Dimensionen aus Listing Aggregationstabellen in Mondrian Jeder Knoten des Aggregationsgitters entspricht einer möglichen Aggregationstabelle die einen gewissen Nutzen für das gesamte Gitter besitzt. Damit der zugrunde liegende OLAP /085/IN02/

48 6 Implementierung Server Mondrian diese verwenden kann, beschäftigt sich diese Arbeit ebenfalls mit dem Anlegen dieser Aggregationstabellen. Die hier vorgestellte Vorgehensweise bezieht sich auf das DB2 Datenbankmanagementsystem und dessen Syntax Erkennung von Aggregationstabellen Eine Möglichkeit, damit Mondrian Aggregationstabellen erkennt und verwendet ist die ausführliche Beschreibung dieser Tabellen im XML-Schema des Data-Warehouse. Hierbei kann definiert werden, welche Spalte der Aggregationstabelle welcher Tabelle und Spalte der Basisrelationen entspricht. Es können einzelne Spalten von Aggregationstabellen ignoriert und Dimensionsebenen speziellen Spalten zugeordnet werden. Für die Implementierung dieser Arbeit ist diese Möglichkeit der Aggregationstabellenerkennung nicht weiter interessant, da bereits durch die korrekte Erzeugung der Aggregationstabellen im RDBMS ein Großteil dieser Definition eingespart wird. Mondrian besitzt neben der Erkennung von Aggregationstabellendefinitionen innerhalb des XML-Schemas die Möglichkeit Aggregationstabellen automatisch zu erkennen. Damit dies möglich ist, müssen diverse Konventionen eingehalten werden. Ein Großteil davon besteht in der korrekten Benennung der Aggregationstabelle und den Spalten. Eine vollständige Beschreibung der Namenskonventionen ist in [6] zu finden. Die im Folgenden vorgestellten Definitionen sind lediglich ein Auszug. Die korrekte Erkennung einer Aggregationstabelle fängt mit deren Namen an. Damit Mondrian diese einer Faktentabelle und somit einer Cube-Definition zuordnen kann, muss der Name mit der Kennung agg anfangen und mit dem Namen der Faktentabelle enden. In Listing 6.5 wird die Aggregationstabelle mit dem Namen agg sales fact 1997 erzeugt, hierbei ist sales fact 1997 der Name der Faktentabelle. Für die Zuordnung von Spalten der Aggregationstabelle zu den entsprechenden Dimensionsebenen werden unterschiedliche Muster überprüft. Die einfachste Methode, die in dieser Implementierung hauptsächlich verwendet wird ist die Eindeutigkeit der Spaltennamen und somit die eindeutige Zuordnung zu einer Dimensionsebene. Falls jedoch in dem Datenbankschema unterschiedliche Tabellen mit gleichen Spaltennamen existieren und diese zu einer Aggregationstabelle zusammengefasst werden sollen, werden weitere Namensmuster überprüft, welche dies ermöglichen [6] Anlegen von Aggregationstabellen Mittels der Anfrage aus Listing 6.5 wird die Struktur einer Aggregationstabelle erzeugt. In diesem Fall handelt es sich um die Aggregationstabelle für den auf Listing 6.1 basierenden Knoten. Hierbei wird der Platzhalter GeneralizedQuery durch die verallgemeinerte Anfrage des Knotens aus Listing 6.3 ersetzt /085/IN02/

49 6 Implementierung Die zusätzliche fact count Spalte in der Anfrage aus Listing 6.3 ist zwingend notwendig, damit Mondrian die darauf basierende Aggregationstabelle verwenden kann. Diese Spalte gibt an, wieviele Tupel der Faktentabelle aggregiert wurden, für jedes Tupel der Aggregationstabelle. Der Anteil des Namens ist beliebig. Bei der Implementierung wird hierfür der Java-hashCode des Knotens des Aggregationsgitters verwendet. Dies ist ein eindeutiger Wert, der auf den Dimensionen des Knotens basiert und für alle Knoten, mit den gleichen Dimensionen, gleich ist. Dies ermöglicht die Zuordnung von Knoten zu Aggregationstabellen auch über einen Neustart des Mondrian-Servers hinweg. 1 CREATE TABLE agg sales fact 1997 AS 2 (GeneralizedQuery) 3 DATA INITIALLY DEFERRED REFRESH DEFERRED 4 MAINTAINED BY SYSTEM 5 ENABLE QUERY OPTIMIZATION Listing 6.5: SQL-Befehl, um die Aggregationstabelle des Knotens, basierend auf Listing 6.1, zu erzeugen. Nachdem die Struktur der Aggregationstabelle mittels Listing 6.5 erzeugt wurde, müssen deren Daten aktualisiert werden. Dies erfolgt mittels der Anfrage aus Listing 6.6. Sobald dies abgeschlossen ist kann die Aggregationstabelle zur Optimierung von Anfragen verwendet werden, da nach Abschluss der refresh Operation der Integritätsstatus der Tabelle auf verfügbar gesetzt wird. 1 REFRESH TABLE agg sales fact 1997 Listing 6.6: SQL-Befehl, um die Aggregationstabelle aus Listing 6.5 mit Daten zu füllen. Für die Kostenabschätzung werden zusätzlich aktuelle Statistiken über die Daten der Aggregationstabelle benötigt. Mit der Anweisung aus Listing 6.7 wird DB2 angewiesen diese zu erzeugen. 1 CALL SYSPROC.ADMIN CMD( 2 RUNSTATS ON TABLE FOODMART. agg sales fact ON ALL COLUMNS ALLOW WRITE ACCESS ) Listing 6.7: SQL-Befehl, um die Statistiken der Aggregationstabelle aus Listing 6.5 zu erzeugen. Nach der Durchführung dieser drei Schritte existiert die in Abbildung 6.4 dargestellte Aggregationstabelle zusätzlich zu den vorhandenen Basisrelationen und wird von Mondrian zur Optimierung der Anfragen verwendet /085/IN02/

50 6 Implementierung FOODMART.agg_ _sales_fact_1997 the_year SMALLINT product_name VARCHAR (60) brand_name VARCHAR (60) product_family VARCHAR (30) product_subcategory VARCHAR (30) product_category VARCHAR (30) product_department VARCHAR (30) store_state VARCHAR (30) store_country VARCHAR (30) store_name VARCHAR (30) store_city VARCHAR (30) store_sales DECIMAL (31,4) fact_count INTEGER Abbildung 6.4: Erzeugte Aggregationstabelle für den Knoten basierend auf der MDX-Anfrage aus Listing 6.1. Powered by yfiles 6.6 Kostenmodell der Implementierung In diesem Abschnitt wird das Kostenmodell der Implementierung vorgestellt. Dies unterscheidet sich von dem theoretischen Modell in der Hinsicht, dass es die Implementierung von Mondrian berücksichtigt. Im ursprünglichen Kostenmodell wird davon ausgegangen, dass immer die für eine Anfrage Q j günstigste Aggregationstabelle A k verwendet wird. Hierbei ist günstig im Sinne der geringsten Kosten c j,k zu verstehen, wobei gilt A l mit c j,l < c j,k. Dies trifft jedoch nicht für die Mondrian eigene Auswahl von Aggregationstabellen zu. Mondrian trifft die Auswahl anhand der Kardinalität der Aggregationstabellen card(a i ). Dies bedeutet, dass sobald mehrere Aggregationstabellen zur Verfügung stehen, mit deren Unterstützung eine Anfrage beantwortet werden kann, die Anfrage so umgeschrieben wird, dass sie die Aggregationstabelle mit der geringsten Kardinalität verwendet [6]. Ein weiterer Punkt, in dem sich das implementierte Kostenmodell von der theoretischen Überlegung unterscheidet, ist die Möglichkeit des negativen Nutzens eines Knotens. Ein Beispiel hierfür ist in den Arbeitschritten des MondrianGreedyAdvisors in Tabelle 8.6 zu sehen. Die Berechnung des Gesamtnutzens eines Knotens benefit(a i ) bleibt jedoch unverändert und wird mittels Formel 6.1 berechnet. benefit(a i ) = x X benefit(a i, Q x ) mit X = {i} {j} ; j : N i N j (6.1) /085/IN02/

51 6 Implementierung Zur Berechnung des Nutzens einer Aggregationstabelle benefit(a i, Q j ) eines Knotens N i für die verallgemeinerte Anfrage Q j eines von N i abgeleiteten Knotens N j wird die Formel 6.2 herangezogen. (c j,0 c j,i ) cnt j 1 : N k : N k N j benefit(a i, Q j ) = 0 2 : N k : N k N j card(n k ) < card(n i ) (c j,k c j,i ) cnt j 3 : N k : N k N j card(n k ) card(n i ) (6.2) Der erste Fall in Formel 6.2 tritt dann auf, wenn keine Aggregationstabelle existiert, mittels der die Anfrage Q j, die verallgemeinerte Anfrage des Knotens N j, beantwortet werden kann. Der daraus resultierende Nutzen ist abhängig von den Kosten von Q j auf den Basisrelationen. Sollten die Kosten c j,0 auf den Basisrelationen geringer ausfallen, als die Kosten c j,i auf der Aggregationstabelle A i wird der Nutzen negativ. Dies ergibt sich daraus, dass Mondrian unabhängig von Kosteninformationen vorhandene Aggregationstabellen zur Optimierung von Anfragen verwendet. Sollte in diesem Fall die Aggregationstabelle A i realisiert werden, wird die Anfrage Q j zwingend umgeschrieben, sodass sie A i verwendet, was dazu führt, dass sie mit höheren Kosten und einer daraus resultierenden längeren Bearbeitungszeit ausgeführt wird. Das Aggregationsgitters berücksichtigt einen negativen Nutzen in den Auswahlalgorithmen und verhindert damit, dass Aggregationstabellen ausgewählt werden, die durch die Realisierung das Gesamtsystem verlangsamen. Es ist jedoch durchaus möglich, dass Aggregationstabellen ausgewählt werden, die eine gewisse Anzahl an Anfragen verlangsamt, dies jedoch durch einen größeren Nutzen bei anderen Anfragen ausgeglichen wird. Im zweiten Fall wird berücksichtigt, dass sobald eine Aggregationstabelle A k existiert, die Q j benutzen kann und die eine geringere Kardinalität als die momentan betrachtete A i besitzt, diese von Q j verwendet wird, unabhängig von der Realisierung von A i. Da somit A i nicht von Q j verwendet wird, leitet sich daraus auch kein Nutzen für A i ab. In Fall drei verwendet Q j nach der Realisierung von A i diese Aggregationstabelle, um die Bearbeitung zu optimieren. Dies muss jedoch nicht zu einer Beschleunigung führen, weil die Kosten c j,i höher ausfallen können, als die Kosten c j,k. Dies wird ebenfalls wie in Fall eins durch die Verwendung eines negativen Nutzens berücksichtigt /085/IN02/

52 7 Abschätzung von Anfragekosten In diesem Abschnitt werden die Implementierungen und die Methoden zur Abschätzung von Anfragekosten vorgestellt. Die hier vorgestellte Implementierung bezieht sich auf die in Abbildung 7.1 dargestellte Detailansicht der CostEvaluator-Komponente aus Abbildung 6.2. Der Zugriff auf die Evaluatoren erfolgt mittels des EvaluatorSelectors, dieser entscheidet anhand der Konfiguration, welcher Evaluator für die Schätzung der Anfragekosten verwendet wird. CostEvaluator Component EvaluatorSelector CostEvaluator <<interface>> CompleteExplain FastExplain FakeExplain OnTheFly Abbildung 7.1: Struktur der Evaluator Komponente Die Abschätzung der Anfragekosten wird anhand der verallgemeinerten SQL-Anfragen der Knoten durchgeführt. Dies hat den Grund, dass jeder Knoten eine Menge von Anfragen repräsentiert. Als Basis dieser Anfragen dient die verallgemeinerte Anfrage, welche die größte Anzahl an Ergebnistupeln liefert. Im schlechtesten Fall, bezogen auf die Kosten der Anfrage, liefert somit eine Anfrage die gleiche Anzahl an Ergebnistupeln wie die verallgemeinerte Anfrage. Die Evaluatoren bestimmen das Maximum für die Anfragekosten der Knoten, was sich wiederum auf deren Nutzen auswirkt, der somit der minimale Nutzen ist, für einen Großteil der Anfragen jedoch, die durch einen Knoten repräsentiert werden, größer ist. Somit arbeiten die Advisor mit maximalen Kosten und berechnen eine Konfiguration, die wenigstens den berechneten Nutzen besitzen. 43

53 7 Abschätzung von Anfragekosten 7.1 Funktionsweise von DB2 - Explain Explain ist eine Methode von DB2 Informationen über die Abarbeitung von SQL-Anfragen zu erhalten. Mittels der SQL-Anfrage aus Listing 7.1 wird die zu evaluierende SQL-Anfrage durch den DB2 -Optimierer analysiert und die Anfragekosten geschätzt. Die SQL-Anfrage wird jedoch nicht ausgeführt, sondern es wird lediglich ein Anfrageplan erzeugt und die Kosten anhand der Statistiken der vorhandenen Relationen geschätzt. Die Ergebnisse der Analyse werden in den Explain -Relationen der Datenbank abgelegt. 1 explain plan selection for 2 zu evaluierende SQL Anfrage Listing 7.1: Mögliche Syntax einer Explain Anweisung Im Folgenden werden die in dieser Arbeit verwendeten Werte erläutert. Die Bezeichnung entspricht Tabellenname.Spaltenname. explain stream.stream count Die Tabelle explain stream enthält Daten über den Informationsfluss im Anfrageplan. Es werden jedoch nur wenige Daten für das Aggregationsgitter benötigt. Zur Bestimmung der Kardinalität der Anfrage wird der stream count Eintrag des letzten Operators, dem RETURN Operator, im Anfrageplan ausgelesen. Dieser enthält die geschätzte Kardinalität der evaluierten SQL-Anfrage. explain stream.object name Der Wert dieser Spalte in der explain stream Tabelle gibt an, mit welchen Eingangsdaten ein Operator arbeitet. Der Wert kann entweder null sein, falls der Eingangsdatenstrom dieses Operators der Ausgangsdatenstrom eines anderen Operators ist oder er enthält den Namen des verwendeten Data Objects. Es kann der Name einer Relation sein. Im Aggregationsgitter dient dieser Wert lediglich der Überprüfung einer evaluierten SQL- Anfrage. Er wird verwendet, um verifizieren zu können, ob eine Anfrage eine gewünschte Tabelle verwendet hat. Zum Beispiel ob die SQL-Anfrage von Knoten B, welcher ableitbar von Knoten A ist, die Aggregationstabelle von Knoten A verwendet hat oder ob der Optimierer eine andere Tabelle als ausgewählt hat. explain statement.total cost Dieser Wert gibt die geschätzten Kosten der evaluierten SQL-Anfrage in Timerons 1 an. Der Wert ist die Basis für die Auswahl von bestimmten Aggregationstabellen für die Realisierung. 1 Timeron ist eine künstliche Maßeinheit, um die Kosten von Anfrageplänen vergleichen zu können. Sie basiert auf der Anzahl an CPU-Anweisungen und der Anzahl an I/O-Operationen /085/IN02/

54 7 Abschätzung von Anfragekosten Explain für Knoten des Aggregationsgitters Der Anfrageplan aller Knoten im Aggregationsgitter hat die gleiche Struktur. Dies heißt nicht, dass der Anfrageplan bei allen Knoten gleich ist, denn die Planoperatoren können in zwei Gruppen unterteilt werden. Die in der gleichen Reihenfolge abgearbeitet werden. Der Grund für die gleiche Struktur sind die verallgemeinerten SQL-Anfragen der Knoten, welche alle den gleichen Aufbau besitzen, siehe Abschnitt 6.4. Die verallgemeinerten SQL-Anfragen bestehen aus drei Komponenten, dies sind die Projektionen, die Verbundoperationen und die Gruppierungen. Die Verbundoperationen und die Gruppierungen sind die zwei Komponenten aus denen der Anfrageplan hauptsächlich besteht. Bei der Beantwortung einer Anfrage unter Verwendung der Basisrelationen werden zuerst die Verbundoperationen durchgeführt und abschließend die Gruppierungen. Bei Durchführung eines Explain einer SQL-Anfrage auf den Basisrelationen werden diverse Statistiken, darunter Verteilungsstatistiken über Relationen, Spalten und Indexe verwendet, um eine möglichst exakte Abschätzung der Anfragekosten zu erhalten. Bei der Verwendung von Aggregationstabellen entfallen die Verbundoperationen, denn diese sind bereits durch die Aggregationstabellen durchgeführt worden. DB2 führt in diesem Fall eine Folge von vier Operationen durch. Es sind ein TBSCAN 2, ein SORT, ein weiterer TBSCAN und ein GRPBY. Der erste Tablescan ist notwendig, weil die verallgemeinerten SQL-Anfragen keine Selektionen durchführt und deshalb alle Tupel der Relation unter Berücksichtigung der Gruppierungen abfragt. Ein solcher Anfrageplan ist in Listing 7.2 aufgeführt, er basiert auf der TPC-H Datenbank und dem Knoten 1 des Aggregationsgitters aus Abbildung 9.1, hierbei verwendet Knoten 1 seine eigene Aggregationstabelle. 1 Access Plan: 2 3 Total Cost: 4,46017e+06 4 Query Degree: Rows 7 RETURN 8 ( 1) 9 Cost 10 I/O ,0012e+06 < Number of rows after GRPBY 13 GRPBY 14 ( 2) 2 Der TBSCAN-Operator führt einen Tablescan oder auch Relationenscan durch und liefert die Tupel einer Relation durch direktes auslesen der Datenseiten.[11] /085/IN02/

55 7 Abschätzung von Anfragekosten 15 4,45928e+06 < Cumulative costs up to and including this GRPBY 16 1,38511e+06 < Cumulative I/O costs up to and including this GRPBY ,0012e TBSCAN 20 ( 3) 21 4,45879e ,38511e ,0012e SORT 26 ( 4) 27 3,99292e ,0012e TBSCAN 32 ( 5) ,0012e TABLE: FOODMART 38 agg LINEITEM Listing 7.2: Ausführungsplan der Anfrage Q 1 auf der Aggregationstabelle A 1 des Knotens N 1 aus dem Aggregationsgitter aus Abbildung 9.1. Die Reduzierung des Anfrageplans hat ebenfalls einen Einfluss auf die von Explain verwendeten Statistiken. Durch die Reduzierung der Anfrage auf den TBSCAN-, SORT- und den GRPBY-Operator werden weniger Statistiken benötigt beziehungsweise verwendet, um die Abschätzung der Anfragekosten durchzuführen. Die Schätzung ist deshalb nur abhängig von der Kardinalität und der Anzahl belegter Seiten der Aggregationstabelle. 7.2 CompleteExplainEvaluator Der CompleteExplainEvaluator führt die genaueste Kostenschätzung der hier vorgestellten Methoden durch. Der damit verbundene Aufwand führt dazu, dass er der Evaluator ist, der am meisten Zeit für die Schätzung benötigt. Den größten Anteil an der Laufzeit des CompleteExplainEvaluator hat die Erzeugung der Aggregationstabellen im RDBMS. In Algorithmus 7.1 ist die Arbeitsweise des CompleteExplainEvaluators dargestellt /085/IN02/

56 7 Abschätzung von Anfragekosten Input : M - Kostenmatrix, L - Aggregationsgitter Output : M foreach N i L do Bestimme Kosten c i,0 von Q i auf Basisrelation; if usedaggtable(c i,0 ) == A 0 then Füge c i,0 zu M hinzu; end Erzeuge Aggregationstabellenstruktur von A i ; Aktualisiere den Inhalt von A i ; Aktualisiere die Statistiken von A i ; Bestimme Kosten c i,i von Q i auf A i ; if usedaggtable(c i,i ) == A i then Füge c i,i zu M hinzu; end foreach N j : N i N j do Bestimme Kosten c j,i von Q j auf A i ; if usedaggtable(c j,i ) == A i then Füge c j,i zu M hinzu; end end Lösche A i ; end Algorithmus 7.1 : Kostenschätzung des CompleteExplainEvaluators. 7.3 FastExplainEvaluator Der FastExplainEvaluator verwendet im Gegensatz zum CompleteExplainEvaluator nicht nur die Explain-Funktionalität von DB2. Zur Beschleunigung der Kostenbestimmung wird eine Heuristik verwendet, um die Anfragekosten für alle Q j unter Verwendung einer Aggregationstabelle A i mit N i N j zu bestimmen. Die Heuristik wird aus den Ergebnissen des CompleteExplainEvaluator abgeleitet. Für die Kosten c j,i von abgeleiteten Knoten N j eines Knoten N i wird angenommen, dass sie den gleichen Wert besitzen wie die Kosten c i,i. Dies lässt sich durch die in Abschnitt 7.1 angesprochene gleiche Struktur der verallgemeinerten SQL-Anfragen erklären. Da durch die Aggregationstabelle A i bereits die Verbundoperationen durchgeführt wurden entfallen diese im Anfrageplan der Anfragen Q j. Der Ausführungsplan einer Anfrage Q j besteht lediglich aus den Operatoren SORT, TBSCAN und GRPBY mit A i als Basis. Von diesen drei Operatoren ist wiederum der TBSCAN der Operator, welcher die meisten Kosten 3 erzeugt. Da durch ihn alle Seiten einer Relation gelesen werden und bei der Bestimmung aller Kosten c j,i immer die Aggregationstabelle A i als Grundlage dient, sind diese Kosten konstant. 3 In diesem Fall sind es I/O-Kosten. Diese werden in Timerons umgerechnet und werden somit in die endgültigen Anfragekosten einbezogen /085/IN02/

57 7 Abschätzung von Anfragekosten Der SORT- und der GRPBY-Operator arbeiten zusammen, um die Aggregation der Daten zu erreichen. Abhängig von der Anfrage Q j des Knotens N j wird die Aggregationstabelle A i mehr oder weniger stark aggregiert. Dies hat jedoch kaum Auswirkung auf die Kosten der beiden Operatoren, da deren Abarbeitung von DB2 hochgradig optimiert ist. Die Heuristik findet Anwendung beim Algorithmus 7.2 des FastExplainEvaluators in den Zeilen 12 bis 15. Eine Bewertung der Heuristik findet in Abschnitt statt Input : M - Kostenmatrix, L - Aggregationsgitter Output : M foreach N i L do Bestimme Kosten c i,0 von Q i auf Basisrelation; if usedaggtable(c i,0 ) == A 0 then Füge c i,0 zu M hinzu; end Erzeuge Aggregationstabellenstruktur von A i ; Aktualisiere den Inhalt von A i ; Aktualisiere die Statistiken von A i ; Bestimme Kosten c i,i von Q i auf A i ; if usedaggtable(c i,i ) == A i then Füge c i,i zu M hinzu; foreach N j : N i N j do c j,i = c i,i ; Füge c j,i zu M hinzu; end end Lösche A i ; end Algorithmus 7.2 : Kostenschätzung des FastExplainEvaluators. 7.4 FakeExplainEvaluator Das Ziel des FakeExplainEvaluators ist es den Aufwand beziehungsweise die Kosten für die Bestimmung der eigentlichen Anfragekosten zu senken. Grundidee ist es die komplette Erzeugung der Aggregationstabellen, wie sie der Complete- ExplainEvaluator und der FastExplainEvaluator durchführen, zu umgehen. Da weiterhin die Explain-Funktionalität von DB2 verwendet werden soll, müssen jedoch immer noch die Strukturen vorhanden sein, die Explain für die Kostenberechnung verwendet. Wie in Abschnitt beschrieben werden hierfür die Kardinalität und die Anzahl belegter Seiten der Aggregationstabelle benötigt. Die Kardinalität der Aggregationstabelle, die durch einen Knoten erzeugt wird, entspricht der Kardinalität der verallgemeinerten SQL-Anfrage des Knotens. Diese Anfrage wird jedoch bei der Abarbeitung der knotenerzeugenden MDX-Anfrage nicht notwendigerweise /085/IN02/

58 7 Abschätzung von Anfragekosten ausgeführt. Es besteht also kein Zusammenhang zwischen der Kardinalität des Ergebnisses der MDX- und der SQL-Anfrage. Die benötigte Kardinalität muss gesondert bestimmt werden. Das eigentliche Bestimmen und Berechnen der Kardinalität beziehungsweise der Seitenzahl findet nicht direkt im FakeExplainEvaluators statt. Dieser verwendet lediglich eine Methode der AggregationTableCreator und ihrer DB2 spezifischen Komponente um eine Aggregationstabelle mit manipulierten Statistiken zu erzeugen. Die Trennung wird vorgenommen, da die Idee des FakeExplainEvaluators unabhängig von der zugrundeliegenden Datenbank ist, die Realisierung einer manipulierten Aggregationstabelle jedoch sehr datenbankspezifisch ist. Da dieser Vorgang nur an dieser Stelle Verwendung findet, wird das Vorgehen im Folgenden näher erläutert Bestimmung der Kardinalität Eine Möglichkeit ist es die Kardinalität mittels einer count(*) Anfrage, wie sie in Listing 7.3 dargestellt ist, zu bestimmen. Der positive Aspekt hierbei ist, dass die Kardinalität exakt ermittelt wird und die Kostenschätzung anhand exakter Basisdaten durchgeführt werden kann. Problematisch ist jedoch, dass bei dieser Art der Kardinalitätsbestimmung, die verallgemeinerte SQL-Anfrage vollständig vom DBMS ausgeführt werden muss, denn ein count(*) liefert keine Schätzung, sondern den exakten Wert. Bei einer kleinen Datenbank, wie zum Beispiel der Foodmart-Beispieldatenbank, ist dies möglicherweise noch akzeptabel. Die Ausführungszeit der Anfrage bewegt sich im Millisekundenbereich, bei großen Datenbanken, kann die Ausführung jedoch mehrere Minuten in Anspruch nehmen. 1 select count( ) from ( 2 verallgemeinerte SQL Anfrage 3 ) Listing 7.3: Syntax einer count(*) Anfrage zur Bestimmung der Kardinalität einer SQL-Anfrage Eine weitere und die vom FakeExplainEvaluator verwendete Möglichkeit der Kardinalitätsbestimmung beruht auf der Abschätzung, die das Explain von DB2 trifft. Wie bereits in Abschnitt 7.1 angesprochen, liefert Explain eine Abschätzung der Kardinalität für eine SQL-Anfrage ohne diese jedoch auszuführen. Dies behebt einerseits den Nachteil einer count(*) Anfrage, führt jedoch zu einem Fehler im Vergleich zur realen Kardinalität. In Abschnitt wird die Größe des Fehlers näher untersucht Bestimmung der Seitenzahl Der zweite benötigte Wert einer Aggregationstabelle ist die verwendete Seitenzahl. Diese wird aus der geschätzten Kardinalität, den Statistiken der einzelnen Spalten und weiterer /085/IN02/

59 7 Abschätzung von Anfragekosten Datenbankparameter berechnet. Die Berechnung erfolgt anhand der in [13] im Kapitel How to estimate disk storage for user data vorgestellten Vorgehensweise. Datenbankparameter Cardinality - Die geschätzte oder reale Kardinalität der Aggregationstabelle. PageSize - Die Größe einer Seite in der DB2 -Datenbank. PctFree - Gibt an, wieviel Prozent einer Seite frei gelassen wird. FreePage - Gibt an, für wieviel belegte Seiten eine leere Seite hinzugefügt wird. MaxRows - Die maximale Anzahl an Records auf einer Seite. PageOverhead - Ist der zur Verwaltung einer Seite benötigte Speicherplatz auf dieser. Ist abhängig von PageSize, bei einer Seitengröße von 4KB werden 40Byte zur Verwaltung benötigt. Bei Seitengrößen von 8, 16 oder 32KB hingegen 54Byte. AvgColLen - Ist ein statistischer Wert aus der Tabelle sysstat.columns. Er gibt für eine Spalte die durchschnittliche Länge der darin enthaltenen Werte an. AvgColSize(i) - Durchschnittliche Größe der Spalte i in Byte in Bezug auf den Eintrag im Record, unter Berücksichtigung der AvgColLen und der Verwaltungsinformationen von 1Byte für jedes Feld, welches Nullwerte erlaubt und 2Byte für Felder variabler Länge. AverageRecordSize - Ein Record entspricht in diesem Zusammenhang einer Zeile der Relation. Zur Bestimmung der AverageRecordSize einer Aggregationstabelle wird für jede Spalte, die in der Aggregationstabelle Verwendung findet, die AvgCol- Size bestimmt. Unter Berücksichtigung des zusätzlichen Speicherplatzbedarfs für Verwaltungsinformationen, 8Byte für den gesamten Record, ergibt die Summe der einzelnen Spaltenwerte die AverageRecordSize. Die Parameter PageSize, PctFree, FreePage und MaxRows sind Konfigurationsoptionen der DB2 -Datenbank. Sie werden vom Administrator festgelegt beziehungsweise besitzen Standardwerte. Zur Bestimmung der Seitenzahl werden sie aus der Datenbank ausgelesen /085/IN02/

60 7 Abschätzung von Anfragekosten { 40B : PageSize = 4KB PageOverhead = 54B : PageSize {8KB, 16KB, 32KB} 100 PctFree UsablePageSize = (PageSize PageOverhead) 100 1B : column i allows null values 2B : column i has variable length AvgColSize(i) = AvgColLen(i) + 3B : column i allows null values 0B and has variable length : else (7.1) (7.2) (7.3) AverageRecordSize = 8B + AvgColSize(i) : columns i of aggregation table (7.4) i UsablePageSize RecordsPerPage = min(maxrows, ) (7.5) AverageRecordSize Cardinality PagesUsed = 2B + (7.6) RecordsPerPage { PagesUsed 1 FreePage : Freepage > 0 FreePage TotalPages = (7.7) PagesUsed : FreePage = 0 Unter Verwendung der Formeln 7.1 bis 7.7 wird der Wert für TotalPages bestimmt Arbeitsweise Der FakeExplainEvaluators arbeitet wie der FastExplainEvaluator. Anstatt jedoch die Aggregationstabellen für die Knoten echt zu erzeugen, wird nur die Aggregationstabellenstruktur angelegt und die Statistiken mittels der abgeschätzten Kardinalität und Seitenzahl künstlich angelegt. 7.5 OnTheFly - Evaluatoren Die bisher vorgestellten Evaluatoren arbeiten mit einem statischen Aggregationsgitter. Das heißt sobald das Aggregationsgitter eine gewünschte Größe besitzt, wird der Complete-, Fast- oder FakeExplainEvaluator aufgerufen. Dieser bestimmt der Reihe nach für alle im Gitter enthaltene Knoten die Kosten. Die Idee der OnTheFly-Evaluatoren besteht darin, die Kostenbestimmung während der normalen Abarbeitung einer Anfrage durchzuführen. Sobald eine MDX-Anfrage an das System gestellt und daraus ein neuer Knoten erzeugt wird, bestimmt der OnTheFly- Evaluator die Kosten. Die Vorgehensweise ist in Algorithmus 7.3 dargestellt /085/IN02/

61 7 Abschätzung von Anfragekosten Input : M - Kostenmatrix, L - Aggregationsgitter, N new - Neu erzeugter Knoten Output : M Bestimme Kosten c new,new mittels des eingestellten Evaluators; foreach N j : N new N j do Bestimme c j,new mittels des eingestellten Evaluators; Füge c j,new zu M hinzu; end foreach N l : N l N new do c new,l = c l,l ; Füge c new,l zu M hinzu; end Algorithmus 7.3 : Kostenschätzung der OnTheFly-Evaluatoren. Die Idee ist nur dann praktikabel umsetzbar, wenn die Heuristik aus Abschnitt 7.3 verwendet wird. Aus diesem Grund existieren auch nur OnTheFly-Evaluatoren für den Fast- ExplainEvaluator und den FakeExplainEvaluator. Das Problem beim CompleteExplainEvaluator ist die Bestimmung aller Kosten c new,l, für einen neu eingefügten Knoten N new mit N l N new. Diese Kosten werden mittels Explain aus der DB2 Datenbank abgefragt, dazu muss jedoch die Aggregationstabelle A l existieren. Das bedeutet bei jedem neu eingefügten Knoten müssten alle Aggregationstabellen der ableitbaren Knoten erneut erzeugt werden, was wiederum zu einer Explosion der Laufzeit führen würde /085/IN02/

62 8 Auswahl von Aggregationstabellenkonfigurationen Ziel dieser Arbeit ist es eine Auswahl von Aggregationstabellen zu treffen. Die bisher vorgestellten Komponenten dienen dazu dies zu ermöglichen. Die eigentliche Auswahl geschieht auf der Basis der erzeugten Strukturen und gesammelten Daten. In diesem Abschnitt werden die Implementierungen vorgestellt, die zur Auswahl verwendet werden können. Hierbei ist der AdvisorSelector aus Abbildung 8.1 wie bereits der EvaluatorSelector für den korrekten Zugriff auf die Advisor zuständig. ConfigurationAdvisor Component AdvisorSelector ConfigurationAdvisor <<interface>> Greedy Optimal MondrianGreedy GreedyBenefitSizeRatio MondrianGreedyBenefitSizeRatio Abbildung 8.1: Struktur der Advisor Komponente Die Advisor besitzen zwei Optimierungsziele, dies sind die Minimierung der Anfragekosten und die Ausnutzung des verfügbaren Speicherplatzes. Die Grundlage für die Optimierung sind die Kostenmatrix mit ihren Daten über die Kosten von Knoten auf Knoten und der maximale zur Verfügung stehende Speicherplatz. Als Resultat liefern sie eine Aggregationstabellenkonfiguration C bestehend aus einer Teilmenge der Knoten des Aggregationsgitters. 53

63 8.1 OptimalAdvisor 8 Auswahl von Aggregationstabellenkonfigurationen Der OptimalAdvisor implementiert eine vollständige Suche, d.h. er berechnet alle möglichen Konfigurationen. Die Konfiguration mit dem größten Nutzen ist die optimale Lösung. Einerseits hat es den Vorteil, dass das Optimum gefunden wird, andererseits jedoch ist die Laufzeit des OptimalAdvisor für Aggregationsgitter ab einer bestimmten Größen nicht mehr im Rahmen des praktisch Nutzbaren. Näheres dazu ist in Abschnitt 9.3 zu finden. In Algorithmus 8.1 ist die Implementierung der vollständigen Suche des OptimalAdvisors abgebildet Input : M - Kostenmatrix, maxsize - Verfügbarer Speicherplatz für die Optimierung Output : C max C max = null; benefit(c max ) = 0; foreach C P({A 1, A 2,..., A n }) do if size(c) < maxsize then Bestimme benefit(c); if benefit(c) > benefit(c max ) then C max = C; end end end Algorithmus 8.1 : Konfigurationsbestimmung des OptimalAdvisors. 8.2 GreedyAdvisor Der GreedyAdvisor ist eine Variante des Algorithmus aus [9]. Der Unterschied zum dem in [9] vorgestellten Algorithmus ist die Berechnung des Nutzens einer Aggregationstabelle. Der Nutzen eines Knotens wird lediglich durch die Kostenreduktion bestimmt, nicht jedoch im Verhältnis zum benötigten Speicherplatz. Weiterhin werden solange Aggregationstabellen für die Realisierung ausgewählt, solange Speicherplatz zur Verfügung steht, unabhängig von der Höhe ihres Nutzens Nutzenreduktion Bei Verwendung eines Greedy Ansatzes zur Realisierung einer Aggregationstabellenkonfiguration ist es wichtig die Veränderung des Nutzens von Knoten, abhängig vom Algorithmusfortschritt zu beachten /085/IN02/

64 8 Auswahl von Aggregationstabellenkonfigurationen Input : M - Kostenmatrix, L - Aggregationsgitter, R - Menge der nicht realisierten Aggregationstabellen, maxsize - Verfügbarer Speicherplatz für die Optimierung Output : C - Konfiguration C = null; continue = true; while continue do continue = false; if (R ) (maxsize > 0) then foreach A i R do Berechne benefit(a i ); if (benefit(a i ) > benefit(a max )) (size(a i ) < maxsize) then A max = A i ; continue = true; end end if continue then maxsize = maxsize size(a max ); Füge A max zu C hinzu; Entferne A max aus R; end end end Algorithmus 8.2 : Konfigurationsbestimmung des GreedyAdvisors. Da die Auswahl der zu realisierenden Knoten schrittweise erfolgt, verändert sich bei jedem Schritt der Nutzen der einzelnen Knoten. Durch die Auswahl beziehungsweise Realisierung eines Knotens reduziert sich der Nutzen der abgeleiteten Knoten, wie bereits in Formel 4.3 beschrieben, da diese nicht mehr die Basisrelationen zur Ausführung benötigen und somit deren Ausführungskosten im Vergleich zum vorherigen Schritt gesunken sind. Deshalb ist die Neuberechnung des Nutzens jedes Knotens in Zeile 7 des Algorithmus 8.2 notwendig Beispiel auf Basis des theoretischen Kostenmodells Das Beispiel für die Arbeitsweise des GreedyAdvisors basiert auf der Foodmart-Datenbank. Das Gitter in Abbildung 8.2 ist die Basis dieses Beispiel, es ist ein Ausschnitt des Gitters aus Abbildung 4.2. Es werden jedoch lediglich die neun Knoten (1, 2, 3, 6, 7, 8, 11, 12, 13) verwenden. Durch die automatische Vergabe der Knotennummern bei der Erzeugung im Aggregationsgitter, werden diese mit 1 bis 9 neu durchnummeriert. Die berechneten Werte basieren auf dem theoretischen Kostenmodell aus Abschnitt /085/IN02/

65 8 Auswahl von Aggregationstabellenkonfigurationen [Product]. [Product Family].[Product Department]. [Product Category] [Store]. [Store Country].[Store State]. [Store City] Abbildung 8.2: Aggregationsgitter zur Veranschaulichung des GreedyAdvisors. Eine weitere wichtige Voraussetzung für den GreedyAdvisor ist eine gefüllte Kostenmatrix. Die in Tabelle 8.1 dargestellte Kostenmatrix basiert auf dem Aggregationsgitter aus Abbildung 8.2 und wurde unter Verwendung des CompleteExplainEvaluators mit Daten gefüllt. N 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9 N N N N N N N N N Tabelle 8.1: Kostenmatrix für das Aggregationsgitter aus Abbildung 8.2. Weiterhin werden die in Tabelle 8.2 aufgelisteten zusätzlichen Informationen über die Knoten benötigt. Die Informationen werden ebenfalls durch den CompleteExplainEvaluator bestimmt, jedoch in den Knoten und nicht in der Kostenmatrix gespeichert. Der Wert size(n i ) wird in KB angegeben. Die hier abgebildeten Werte sind wegen der Übersichtlichkeit und Platzmangel gerundete Werte. Der Parameter maxsize wird auf den Wert 4000KB festgelegt. Dies ist ein beliebig festgesetzter Wert /085/IN02/

66 8 Auswahl von Aggregationstabellenkonfigurationen N 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9 size(n i ) card(n i ) c i, Tabelle 8.2: Zusätzliche Informationen über die Knoten aus Abbildung 8.2. Step 0 Step 1 Step 2 Step 3 maxsize N N * N N 4 * N N N * N N Tabelle 8.3: Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyAdvisors, basierend auf dem theoretischen Kostenmodell. In Tabelle 8.3 sind die einzelnen Schritte des GreedyAdvisors bei Verwendung des theoretischen Kostenmodells zu sehen. Die mit (*) gekennzeichneten Werte sind das jeweilige Maximum der Spalte, unter Berücksichtigung der Platzbeschränkung durch maxsize. Im 0. Schritt wird der Knoten N 4 für die Realisierung ausgewählt. Dies hat zur Folge, dass im 1. Schritt der benefit aller Knoten drastisch reduziert wird. Dadurch das die Knoten (N 5, N 6, N 7, N 8, N 9 ) nicht mehr die Basisrelation zur Beantwortung verwenden müssen sinkt ihr direkter/eigener Nutzen als auch der indirekte/fremder Nutzen der abgeleiteten Knoten. Hingegen bei den Knoten (N 1, N 2, N 3 ) sinkt nicht der direkte Nutzen, da sie selbst nicht günstiger bearbeitet werden können, sondern es sinkt nur der indirekte Nutzen durch alle von Knoten N 4 ableitbaren Knoten. Im 2. Schritt wird der anhand des 1. Schrittes ausgewählte Knoten N 2 realisiert, da der Knoten N 1, obwohl er einen höheren Nutzen besitzt, die Platzbeschränkung durch maxsize überschreitet. Die Auswahl von Knoten N 2 hat nur Einfluss auf den Nutzen des Knoten N 1, dessen indirekter und auf Knoten N 3 dessen direkter Nutzen sinkt, da bereits alle anderen Knoten den Knoten N 4 zur Beantwortung verwenden. Im 3. und letzten Schritt wurde der Knoten N 7 realisiert. Hierbei ist zu beobachten, dass sich der benefit von Knoten N 1 nicht mehr verändert, da dessen indirekter benefit bei 0 angelangt ist, da alle Knoten des Gitters entweder N 4 oder N 2 zur günstigeren Beantwortung verwenden /085/IN02/

67 8 Auswahl von Aggregationstabellenkonfigurationen Die als Resultat erhaltene Konfiguration C enthält die Knoten (N 4, N 2, N 7 ). Die Kosten aller Knoten auf der Basisrelation ohne Aggregationstabelle betragen , durch die Realisierung der Konfiguration C werden die Kosten auf gesenkt, dies entspricht einem benefit(c) = , bei einem Platzverbrauch von size(c) = 3988KB. 8.3 GreedyBenefitSizeRatioAdvisor Der GreedyBenefitSizeRatioAdvisor ist dem GreedyAdvisor sehr ähnlich. Der einzige Unterschied zwischen den beiden Advisors ist der Wert, mit dem die Knoten untereinander verglichen werden. Beim GreedyAdvisor wird hierfür direkt der benefit verwendet. Der GreedyBenefitSizeRatioAdvisor hingegen führt einen neuen Wert ein, der nur dazu dient den Wert der Knoten zu vergleichen. Hierfür wird das Verhältnis zwischen benefit und Größe des Knotens verwendet. Dies ermöglicht somit eine Aussage über den benefit eines Knotens pro Speicherplatzeinheit. Dieser Parameter, in der Implementierung comparevalue genannt, ist in Tabelle 8.4 und 8.5 für jeden Schritt in der ratio Spalte aufgelistet. Input : M - Kostenmatrix, L - Aggregationsgitter, R - Menge der nicht realisierten Aggregationstabellen, maxsize - Verfügbarer Speicherplatz für die Optimierung Output : C - Konfiguration 1 C = null; 2 continue = true; 3 while continue do 4 continue = false; 5 if (R ) (maxsize > 0) then 6 foreach A i R do 7 Berechne benefit(a i ); Berechne ratio(a i ) = benefit(a i) 8 ; size(a i ) 9 if (ratio(a i ) > ratio(a max )) (size(a i ) < maxsize) then A max = A i ; continue = true; end end if continue then maxsize = maxsize size(a max ); Füge A max zu C hinzu; Entferne A max aus R; end end end Algorithmus 8.3 : Konfigurationsbestimmung des GreedyBenefitSizeRatioAdvisors /085/IN02/

68 8 Auswahl von Aggregationstabellenkonfigurationen Der hier vorgestellte GreedyBenefitSizeRatioAdvisor ist die Implementierung des Algorithmus aus [9], erweitert um die dort ebenfalls vorgestellten Ergänzungen des Basismodells. Hierzu zählt die Berücksichtigung der Häufigkeit von Anfragen, als auch die Beschränkung des verfügbaren Speicherplatzes für die Realisierung von Aggregationstabellen. Der Unterschied des Algorithmus 8.3 des GreedyBenefitSizeRatioAdvisors zum Algorithmus 8.2 des GreedyAdvisors liegt in den Zeilen 8 und 9. Abschließend wird das Beispiel aus Abschnitt erneut aufgegriffen, um den Einfluss der Änderung dieses Algorithmus auf die Auswahl der Aggregationstabellen zu verdeutlichen. Die Basisdaten für den Algorithmus sind die Selben. Dies bedeutet, es werden die Werte aus Tabelle 8.1, 8.2 und auch der Wert von maxsize übernommen. In den Tabellen 8.4 und 8.5 sind die Daten der einzelnen Schritten des GreedyBenefitSizeRatioAdvisors aufgeführt. Die Auswahl des zu realisierenden Knotens in jedem Schritt wird anhand des ratio Wertes und des verbleibenden Speicherplatzes vorgenommen. Wie bereits das Beispiel aus Abschnitt werden die Daten mittels des theoretischen Kostenmodells aus Abschnitt ermittelt. Step 0 Step 1 Step 2 Step 3 maxsize benefit ratio benefit ratio benefit ratio benefit ratio N N N N *3.59 N N * N * N N * Tabelle 8.4: Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyBenefitSizeRatioAdvisor. Teil 1 Die als Resultat erhaltene Konfiguration C enthält die Knoten (N 9, N 7, N 6, N 4, N 3, N 5, N 8 ). Die Kosten der neun Anfragen belaufen sich unter Verwendung von C auf , das entspricht einem benefit(c) = , bei einem Platzverbrauch von size(c) = 3028KB. Im Gegensatz zum GreedyAdvisor werden hierbei Aggregationstabellen mit einer geringen Größe bevorzugt /085/IN02/

69 8 Auswahl von Aggregationstabellenkonfigurationen Step 4 Step 5 Step 6 Step 7 maxsize benefit ratio benefit ratio benefit ratio benefit ratio N N N * N N * N N N * N Tabelle 8.5: Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyBenefitSizeRatioAdvisor. Teil Mondrian - Advisor Die beiden Mondrian - Advisor aus Abbildung 8.1, der MondrianGreedyAdvisor und der MondrianGreedyBenefitSizeRatioAdvisor arbeiten wie die bereits beschriebenen auf dem Greedy-Prinzip basierenden Advisor. Sie verwenden jedoch anstatt des theoretischen Kostenmodells das auf Mondrian abgestimmte Kostenmodell aus Abschnitt 6.6. Das angepasste Kostenmodell äußert sich in leicht anderen Werten während der Abarbeitung des GreedyAdvisor. In Tabelle 8.6 sind die einzelnen Schritte des MondrianGreedyAdvisor aufgeführt. Hierbei unterscheidet sich der Nutzen der Knoten N 1 und N 9 in Schritt 2 und 3 zu dem Nutzen aus Tabelle 8.3. Der Nutzen von N 9 ist negativ, da bereits der Knoten N 7 realisiert wurde und die Kosten von c 9,7 = betragen, jedoch sind die Kosten c 9,9 = Da jedoch die Kardinalität von card(n 9 ) = 306 geringer als card(n 7 ) = 1325 ist, würde Mondrian alle Anfragen vom Typ Q 9 so umschreiben, dass sie die Aggregationstabelle A 9 verwenden würde. Um dies und damit höhere Kosten zu verhindern, wird der Nutzen von N 9 negativ und somit wird der Knoten nicht für die Realisierung ausgewählt. Bei Verwendung des MondrianGreedyBenefitSizeRatioAdvisor unterscheiden sich die Daten der einzelnen Schritte nur minimal von den in Tabelle 8.4 und 8.5 dargestellten und werden nicht gesondert aufgeführt /085/IN02/

70 8 Auswahl von Aggregationstabellenkonfigurationen Step 0 Step 1 Step 2 Step 3 maxsize N N * N N 4 * N N N * N N Tabelle 8.6: Übersicht über den Nutzen jedes Knotens während der Abarbeitung des GreedyAdvisors, basierend auf dem Kostenmodell für Mondrian /085/IN02/

71 9 Evaluation In diesem Kapitel werden die implementierten Komponenten bewertet. Die Optimierungskomponente soll die Ausführung der an Mondrian gestellten MDX-Anfragen beschleunigen. Daher sind sowohl die berechneten Kostenreduktionen, als auch die tatsächlichen Laufzeiten der Anfragen von Interesse und sind Grundlage der Prüfung der ConfigurationAdvisor. Da die ConfigurationAdvisor auf der Grundlage der Kostenschätzungen der CostEvaluators arbeiten werden diese zuerst betrachtet. Da die CostEvaluators lediglich Schätzungen und Heuristiken verwenden, um die Anfragekosten zu ermitteln, werden sowohl die Kostenschätzungen, als auch die Heuristiken analysiert, um eine Aussage über deren Genauigkeit zu treffen. 9.1 Testumgebung In diesem Abschnitt werden die einzelnen Bestandteile der Testumgebung vorgestellt. Hierzu gehört sowohl die Hardware des Testsystems, als auch der Anfragemix, der für die Beurteilung der unterschiedlichen Bestandteile der Optimierungskomponenten eingesetzt wird Hardware des Testsystems Das Testsystem, auf dem sowohl Mondrian als auch die DB2 Datenbank installiert sind wird hier kurz vorgestellt, damit die realen Laufzeiten der Anfragen mit anderen System verglichen werden können. Die technischen Daten sind in Tabelle 9.1 aufgelistet. Komponente Bezeichnung Betriebssystem Debian GNU/Linux 4.1 (Lenny) 32 Bit Kernel Debian Kernel bigmem Prozessor AMD Athlon(tm) 64 X2 Dual Core Processor Hauptspeicher 4 GB, DDR, 400 MHz Festplatte 250 GB, 7200 RPM, Transferrate ca. 56 MB/s Tabelle 9.1: Technische Daten des Testsystems Wegen der Express Version von DB2 wird von der Datenbank lediglich ein Prozessorkern verwendet. Die Durchsatzdaten der Festplatte, auf der die TPC-H- beziehungsweise 62

72 9 Evaluation Foodmart-Datenbank abgelegt sind, ist von Interesse weil das Anlegen und Auslesen der Aggregationstabellen langwierige I/O-Operationen sind. Die eingebauten Cache-Mechanismen von Mondrian werden für die Tests deaktiviert, damit diese keinen Einfluss auf die Anfragenlaufzeiten haben Testgitter Die Ergebnisse der Evaluation basieren auf dem Aggregationsgitter aus Abbildung 4.2 für die Foodmart-, beziehungsweise auf dem Gitter aus Abbildung 9.1 für die TPC-H- Datenbank. [Part]. [Region Name].[Nation Name].[Supplier Name]. [Part Type].[Part Manufacturer].[Part Brand].[Part Name] [Order]. [Order Region].[Order Nation]. [Customer Name].[Order Date] Abbildung 9.1: Struktur des Aggregationsgitters basierend auf einem Anfragemix der TPC-H-Datenbank. Beide Aggregationsgitter sind lediglich Ausschnitte aus dem vollständigen Gitter der jeweiligen Datenbank. Ein 3 bis n-dimensionales Gitter ist jedoch nicht übersichtlich darzustellen. Deshalb ist der Anfragenmix der jeweiligen Gitter so zusammengestellt, dass er lediglich ein Aggregationsgitter erzeugt, welches in einer Ebene dargestellt werden kann. Die Reduktion auf diese Größe ermöglicht es jedoch weiterhin eine korrekte Evaluation durchzuführen. Die Größe der Aggregationstabellen der einzelnen Knoten ist in Abbildung 9.2 dargestellt /085/IN02/

73 9 Evaluation Sheet1 Größe der Aggregationstabelle in MB Knoten Abbildung 9.2: Größe der Aggregationstabellen der einzelnen TPC-H- Gitterknoten. Knoten Größe in KB Größe in MB , Anfragemix für TPC-H 1803, ,31 Um ein einigermaßen realistisches 759,07 Szenario für die Benutzung von Mondrian zu simulieren wird ein Anfragemix erzeugt, der 173,61 den Umgang mit dem multidimensionalen Datenmodell wiederspiegelt. 6 Es wird davon 1563,65 ausgegangen, dass häufiger Anfragen auf einer grobgranularen Ebene7des Datemodells ,59 stattfinden, bei denen große Mengen an Daten aggregiert werden, als Anfragen auf einer1188,79 feingranularen Ebene, welche die zugrundeliegenden Datentupel anfordern , ,24 Dies tritt beispielsweise bei JPivot, 1465,87 einer Applikation, welche Mondrian verwendet, sehr häufig auf. 12 Dort liegt der Einstiegspunkt 1465,8 des Benutzers auf der Ebene, auf der ein Großteil der Daten aggregiert wird. Diese 1110,91 kann sich der Benutzer schrittweise mittels Drill-Down- Operationen 14in ihre Bestandteile 582,96 zerlegen lassen ,92 Die Basis für die Anfragenverteilung ist eine Normalverteilung, deren Wahrscheinlichkeiten für die Knoten des Gitters aus Abbildung 9.1 in Abbildung 9.3 dargestellt sind , ,99 Um alle Knoten 18 des Gitters wenigstens 946,99 einmal anzufragen, wird die Normalverteilung um 1 in Richtung 19 der Z-Achse verschoben. 433, ,89 Basierend auf 21 dieser Verteilung1172,46 wird der Anfragenmix bestehend aus 200 MDX-Anfragen automatisiert 22 generiert Für jeden 1168,58 der Knoten existieren zehn Anfragen, welche durch diesen repräsentiert werden. Die Auswahl, 42,48 welcher Knoten angefragt wird basiert auf der Normalverteilung. 24 Die 7412 Auswahl, welche 7,24 der zehn Anfragen ausgeführt werden soll, wird jedoch gleichverteilt 25 getroffen , ,52 Die Grafik aus Abbildung 9.4 gibt die Anfragehäufigkeit jedes Knotens aus Abbildung , wieder. Der feingranularste Knoten 1 aus Abbildung 9.1 entspricht den Koordinaten , , Page /085/IN02/

74 9 Evaluation Sheet1 0,1 Anfragewahrscheinlichkeit 0,09 0,08 0,07 0,06 0,05 0,04 0,03 0,02 0, x y #Queries 1 Abbildung 9.3: Wahrscheinlichkeitsverteilung der Normalverteilung. µ 1,2 sigma 2 z-skalierung 2,5 z-verschiebung 0 Anzahl Anfragen ,03 0,07 0, Sheet , , , , ,01 0,01 0, ,01 0,01 0,02 0, ,01 0,02 0,04 0, ,02 0,03 0,06 0, ,02 0,04 0, x y Abbildung 9.4: Anfragehäufigkeiten der Knoten aus Abbildung /085/IN02/