Performance-Analysen f¨ur Realisierungsansätze im Kontext der
Werbung
Performance-Analysen für Realisierungsansätze im Kontext der Aspektorientierten Datenhaltung Matthias Liebisch Friedrich-Schiller-Universität Jena DBIS-Lehrstuhl, Ernst-Abbe-Platz 2 07743 Jena [email protected] Matthias Plietz ORISA Software GmbH Humboldtstr. 13 07743 Jena [email protected] Abstract: Funktionale Aspekte als Vertreter sogenannter cross-cutting concerns beeinflussen das Design sowohl von Applikationen als auch des zugrundeliegenden Datenmodells. Ähnlich wie das Paradigma der Aspektorientierten Programmierung sollen im Rahmen der Aspektorientierten Datenhaltung funktionale Aspekte als orthogonale Dimensionen zum fachlichen Datenmodell behandelt werden können. Dieses Paper beschreibt zwei mögliche Realisierungsansätze, welche die Konzepte und Anforderungen der Aspektorientierten Datenhaltung in einem relationalen Datenbanksystem implementieren und dabei unterschiedliche Schwerpunkte bezüglich Performance und Normalisierung setzen. Für einen qualitativen Vergleich werden beide Ansätze in einem Benchmark analysiert und anschließend anhand der Ergebnisse bewertet. Abschließend stehen die Grenzen und Möglichkeiten zur Diskussion, um die häufig gegensätzlichen Forderungen nach Performance, Normalisierung, Konsistenz und Flexibilität innerhalb eines Datenmodells zu vereinen. 1 Einleitung Für die Persistierung von Anwendungsdaten haben sich seit ihrer Einführung vor über drei Jahrzehnten relationale Datenbankmanagementsysteme (RDBMS) basierend auf dem relationalen Modell[Cod70] als die geeignetste Möglichkeit durchgesetzt. Dabei müssen im Prozess der Datenmodellierung neben den fachlichen Anforderungen der Anwendung auch sogenannte funktionale Aspekte berücksichtigt werden, beispielsweise die Fähigkeit zur Mehrsprachigkeit, Versionierung oder auch zur Definition verschiedener Preislisten. Gegenüber der traditionellen Herangehensweise, derartige Aspekte mittels iterativer Schema-Evolutionen (DDL-Anweisungen) in ein Datenmodell zu integrieren, wird mit dem Paradigma der Aspektorientierten Datenhaltung[Lie10a] das Ziel einer vom konkreten fachlichen Datenmodell unabhängigen Integration verfolgt. Im Fokus dieser Arbeit stehen zwei Realisierungsansätze (Abschnitt 2), welche diesem Paradigma genügen und basierend auf den Ergebnissen der nachfolgenden Performance-Untersuchungen (Abschnitt 3) miteinander verglichen werden (Abschnitt 4). 1.1 Aspektorientierte Datenhaltung Analog zum Paradigma der Aspektorientierten Programmierung[KLM+ 97] zur Bewältigung sogenannter cross-cutting concerns im Prozess der Software-Entwicklung[CSR02], stellt auch die Abbildung funktionaler Aspekte durch das Konzept der Aspektorientierten Datenhaltung ein geeignetes Entwurfsmuster für die strukturierte Datenmodellierung dar [GHJV94, Pli10]. Die damit einhergehenden Anforderungen werden im Folgenden kurz erläutert, um den Entwurf der in Abschnitt 2 vorgestellten Ansätze zu motivieren. Weitergehende Details und Ausführungen finden sich in [Lie10a]. Das Paradigma der Aspektorientierten Datenhaltung ist geprägt durch fünf Eigenschaften: • Modularität: alle zu einem funktionalen Aspekt gehörenden Informationen sollen in einer logischen Modellierungseinheit zusammengefasst werden können. • Orthogonalität: für beliebige funktionale Aspekte müssen einerseits alle potentiell möglichen Integrationsreihenfolgen das Datenmodell in einen semantisch äquivalenten Zustand überführen und andererseits darf es nicht zu Wechselwirkungen bezüglich der beeinflussten Attributmengen kommen. Damit verbunden ist auch die Forderung, dass die Zuordnung einer konkreten Menge aspektspezifischer Daten zu mehr als einem Aspekt möglich sein muss. • Lokalität: bei der Integration eines Aspektes sollte nicht das gesamte Datenmodell einer Transformation unterzogen werden. • Universalität: für eine maximale Anwendungsbreite über relevante DBMS-Produkte hinweg soll die Realisierung funktionaler Aspekte nur auf Sprachelementen des SQL:92-Standards basieren. • Benutzbarkeit: zur einfachen Integration eines funktionalen Aspektes ist eine Unterstützung des Anwenders erforderlich. Dabei spielen vorallem die Kriterien der Modularität, Orthogonalität und Lokalität für die Entwicklung von Realisierungsansätzen eine entscheidende Rolle. 1.2 Anwendungsszenario Zur Veranschaulichung der Analysen in dieser Arbeit soll beispielhaft die Verwaltung von Modulstrukturen dienen. Wie in Abbildung 1 dargestellt, werden dazu einerseits die Stammdaten der einzelnen Bauteile in der Tabelle M ODUL und andererseits die Stücklisteninformationen in der Tabelle S TRUKTUR gespeichert. Neben dieser rein fachlichen Modellierung sollen nun die funktionalen Aspekte Internationalisierung und Versionierung integriert werden, um beispielsweise Produkte mehrsprachig und in verschiedenen Varianten im globalisierten Handel anbieten zu können. Dabei stellt das Attribut M O DUL .VARIANT ein Kennzeichen für die mögliche Nutzung in einem Konfigurationsprozess dar und soll unabhängig von funktionalen Aspekten sein. Version Modul Struktur PK ModulID Name Preis Variant PK,FK Oberteil PK,FK Unterteil Menge Sprache PK: Primärschlüssel FK: Fremdschlüssel Abbildung 1: Relationales Modell für die Abbildung von Modulstrukturen 2 Realisierungsansätze Basierend auf den in Abschnitt 1.1 beschriebenen Anforderungen für die Aspektorientierte Datenhaltung stellt sich im anschließenden Prozess zur Entwicklung von Modellierungsansätzen wie so häufig die Aufgabe, einen Kompromiss zwischen verschiedenen und teilweise widersprüchlichen Zielen zu finden. Auf der einen Seite müssen Kritieren wie Normalisierung und Konsistenz bei der Abbildung funktionaler Aspekte berücksichtigt werden. Andererseits sollen diese auch in einer möglichst performanten Art und Weise verarbeitet werden können. Nachfolgend werden zwei Realisierungsstrategien jeweils mit dem Schwerpunkt auf einem der beiden Ziele präsentiert, um funktionale Aspekte in relationalen Datenbankmanagementsystemen zu integrieren. Zur Verdeutlichung dieser Ansätze bildet das in Abbildung 1 dargestellte Anwendungsszenario die Grundlage des zu erweiternden Fachmodells. 2.1 Dynamische Aspektintegration Im Zentrum der in Abbildung 2 präsentierten Modellierung stehen die Tabellen A SPECTVALUE und A SPECTA SSIGN, welche beide auf dem EAV-Konzept[NMC+ 99] basieren und dadurch ein hohes Maß an Flexibilität und Dynamik bezüglich der aspektspezifischen Zuordnung bieten. Dazu wird im ersten Schritt in Tabelle A SPECT VALUE zu einer beliebigen über das Tripel (TABLE , C OLUMN , ROW ID) identifizierbaren Tabellenzelle ein Wert (VALUE) als aspektspezifische Ausprägung hinterlegt. Hierfür ist es notwendig, dass alle ursprünglichen Tabellen des fachlichen Datenmodells einen einattributigen typgleichen Primärschlüssel besitzen, wie z.B. S TRUKTUR .ROW ID. Zudem muss für A SPECTVALUE .VALUE ein möglichst generischer Datentyp (z.B. VARCHAR) zur Persistierung verschiedener Datentypen verwendet werden. In einem zweiten Schritt erfolgt in der Tabelle A SPECTA SSIGN die Zuordnung aspektspezifischer Daten (A SPECT VALUE) zu einer konkreten Aspekt-Ausprägung (A SPECT, K EY VALUE) unter Einhaltung der UNIQUE-Bedingung über (A SPECT, K EY VALUE , A S PECT VALUE ). Dabei verweisen Fremdschlüssel-Attribute der beiden bisher beschriebenen Aspekt-Tabellen auf eine feste Anzahl weiterer Tabellen im Bereich Aspektstammdaten, welche notwendige Metadaten zu den im Modell hinterlegten funktionalen Aspekten speichern. Eine genaue Beschreibung von A SPECT D EFINITION , A SPECT K EY VALUE , A SPECT DATATYPE , A SPECT C OLUMN und A SPECT TABLE ist in [Lie10b] zu finden. Modul AspectAssign AspectKeyValue PK ModulID Name Preis Variant PK FK FK FK PK AspKeyID FK Aspect KeyValue Comment Struktur AspectValue AspectDefinition PK RowID FK Oberteil FK Unterteil Menge PK AspValID FK Table FK Column RowID Value PK AspDefID Name Key FK Datatype AspAssID Aspect KeyValue AspectValue AspectDatatype PK AspTypeID TypeName Length Scale AspectColumn PK AspColID FK Table ColumnName FK Datatype AspectTable PK AspTabID TableName Nutzerdaten Aspektverknüpfung PK: Primärschlüssel Aspektstammdaten FK: Fremdschlüssel Abbildung 2: Datenmodell für die dynamische Aspektintegration 2.2 Statische Aspektintegration Die grundlegende Idee des in Abbildung 3 dargestellten Ansatzes besteht im Konzept der sogenannten Schattentabellen. Diese stellen jeweils eine strukturelle Kopie der betreffenden Originaltabelle dar und persistieren die zugehörigen aspektspezifischen Informationen. Um derartige Datensätze auf einheitlichem Weg einem konkreten Aspekt zuordnen zu können, wird jede Schattentabelle um einen neuen Primärschlüssel (ROW ID) ergänzt und der ursprüngliche Schlüssel als Fremdschlüssel mit Bezug auf die Originaltabelle umdefiniert (z.B. A SPECT M ODUL .M ODUL ID referenziert M ODUL .M ODUL ID). Die eigentliche Aspekt-Zuordnung erfolgt entsprechend der Anforderung nach Orthogonalität unabhängig in der Tabelle A SPECTA SSIGN, in der ein spezifischer Datensatz einer Schattentabelle (TABLE , ROW ID) mit einer konkreten Aspekt-Ausprägung (A SPECT, K EY VALUE) unter Einhaltung einer UNIQUE-Bedingung über (A SPECT, K EY VALUE , TABLE , ROW ID) verknüpft wird. Dabei verweisen die Attribute dieser Zuordnungstabelle größtenteils auf weitere Tabellen im Bereich Aspektstammdaten, welche bereits im Rahmen des dynamischen Modellierungsansatzes in Abschnitt 2.1 beschrieben wurden. Modul AspectModul AspectKeyValue PK ModulID Name Preis Variant PK RowID FK ModulID Name Preis Variant PK AspKeyID FK Aspect KeyValue Comment Struktur AspectDefinition AspectStruktur PK,FK Oberteil PK,FK Unterteil Menge PK AspDefID Name Key FK Datatype PK RowID FK Oberteil FK Unterteil Menge AspectDatatype PK AspTypeID TypeName Length Scale AspectAssign PK FK FK FK Nutzerdaten AspAssID Aspect KeyValue Table RowID AspectTable PK AspTabID TableOrigin TableAspect Aspektverknüpfung PK: Primärschlüssel Aspektstammdaten FK: Fremdschlüssel Abbildung 3: Datenmodell für die statische Aspektintegration 3 Testumgebung Nachdem im vorherigen Abschnitt 2 die zu untersuchenden Realisierungsansätze vorgestellt wurden, können diese nun einem Benchmark unterzogen werden. Dazu erfolgt zuerst die Spezifikation sowohl des zugrundeliegenden Testsystems als auch der verwendeten Workload. Der letzte Teil dieses Abschnitts beschreibt schließlich die konkrete Testdurchführung. 3.1 Testsystem Für die Performance-Untersuchungen kommt ein am Lehrstuhl existierender IBM-Server vom Typ RS/6000 7025 Model F80 zum Einsatz[LM00]. Dieser weist folgende Leistungsmerkmale und Systemcharakteristik auf: • Hardware: 2 Prozessoren vom Typ RS64-III mit jeweils 450MHz, 4GB Speicher • Betriebssystem: AIX 5.2 • Datenbanksystem: IBM DB2 8.2.4 LUW Die Verwendung eines weiteren Testsystems bzw. eines anderen DBMS wurde explizit nicht in Betracht gezogen, da eine qualitative Aussage zum Laufzeitverhalten der beiden Realisierungsansätze das Ziel der Arbeit darstellt und nicht der Vergleich von Abarbeitungszeiten nach dem Prinzip IBM DB2 vs. MS SQL“ für eine gewisse Workload im ” Vordergrund steht. Im DB2-System wurden die Werte für einige Speicherkennzahlen so angepasst, dass die vollständige Verarbeitung der in Abschnitt 3.2 beschriebenen Anfragen durch das DBMS gewährleistet werden konnte. Davon betroffen sind die Parameter LOGFILSIZ (4000), STMTHEAP (16384), APPLHEAPSZ (1024) und SORTHEAP (1024) mit einer Pagesize von jeweils 4KB. 3.2 Workload Anfragen in einem Anwendungssystem lassen sich klassifizieren in die Verarbeitung von Individualdaten durch manuelle Prozesse und von Massendaten mittels halbautomatisierter Prozesse. Für beide Gruppen sind in Tabelle 3.2 typische Anwendungsfälle bezüglich des Beispiels in Abbildung 1 mit natürlich-sprachlich formulierten Anfragen angegeben. Massendaten Individualdaten Art ID Operation Anwendungsfall und Beispielanfrage W1 SELECT W2 INSERT W3 UPDATE W4 DELETE W5 SELECT W6 INSERT W7 UPDATE W8 DELETE Darstellung von Modul-Eigenschaften: Ermittle für das ” Modul mit Schlüssel 55 alle internationalisierten Daten.“ Einpflegen neuer Modulübersetzungen: Füge für das ” Modul mit Schlüssel 55 zur spanischen Lokale (es-ES) den Namen Modul55-spanisch und den Preis 55.22 ein.“ Änderung existierender Modultexte: Ändere für das Mo” dul mit Schlüssel 55 den Namen zu Modul55-neu und versioniere den alten Text.“ Löschung von Modulübersetzungen: Lösche für das ” Modul mit Schlüssel 55 alle durch Workload W2 und W3 hinzugefügten aspektspezifischen Daten.“ Extraktion von Modul-Eigenschaften: Ermittle für alle ” Module die internationalisierten Daten zur weiterführenden Analyse (ModulID, Locale, Name, Preis).“ Datenübernahme von externen Systemen: Importiere für ” Modul-Daten die in strukturierter Form vorliegenden internationalisierten Daten für Polen (Lokale pl-PL).“ Datenbereinigung/Normierung: Ergänze die internatio” nalisierte Modulbezeichnung zur Lokale de-CH um den Präfix I18N.“ Archivierung/Datenbereinigung: Lösche alle internatio” nalisierten Datensätze von Module zur Lokale pl-PL.“ Tabelle 1: Klassifizierung der Workload 3.3 Vorgehen In einem ersten Schritt wurden synthetische Testdaten zur Befüllung sowohl der Aspektals auch Fach-Tabellen generiert. Die resultierenden Mengengerüste sind aufgeschlüsselt nach dem statischen und dynamischen Realisierungsansatz in Tabelle 2 dargestellt. AusTabelle M ODUL S TRUKTUR A SPECT M ODUL A SPECT S TRUKTUR A SPECTA SSIGN A SPECT C OLUMN A SPECT DATATYPE A SPECT D EFINITION A SPECT K EY VALUE A SPECT TABLE A SPECT VALUE Zeilenzahl stat. dyn. 3000 3000 2999 2999 15000 – 14995 – 30000 45000 – 5 4 4 2 2 7 7 2 2 – 45000 Tabelle 2: Datenmengen der generierten Testdaten gehend von der inhaltlichen Workload-Definition in Abschnitt 3.2 wurden anschließend alle Anfragen unter Beachtung des jeweiligen Ansatzes bzw. Datenmodells in die passende SQL-Syntax transformiert. In diesem Prozess standen Optimierungsfragen nicht zur Diskussion, da diese Aufgabe durch das DBMS gelöst werden sollte. Jedoch wurden Idents aus den Aspekt-Tabellen als bekannt vorausgesetzt, beispielsweise A SPECT D EFI NITION .A SP D EF ID = 1 für den Aspekt Internationalisierung. Dies ist üblicherweise durch das Speichern derartiger Metadaten in der Anwendung gewährleistet. Die kompletten im Performance-Test verwendeten SQL-Anfragen sind in Abbildung 5 (statischer Ansatz) sowie Abbildung 6 (dynamischer Ansatz) dargestellt. timeDuration = System.currentTimeMillis(); if (withResult) _rs = _stmt.executeQuery(query); else for (int i=0; i<queryList.length; i++) _stmt.execute(queryList[i]); timeDuration = System.currentTimeMillis() - timeDuration; Abbildung 4: Java-Code zur Messung von Ausführungszeiten Die Analyse der SQL-Anfragen erfolgte mit Hilfe eines Java-Programms, welches durch Aufrufe der Methode System.currentTimeMillis() die Zeit zur Ausführung einer Menge von SQL-Anweisungen ermittelt (siehe Code-Fragment in Abbildung 4). Um das Anfrageverhalten unter verschiedenen Bedingungen zu analysieren, wurden für die zwei Realisierungsansätze jeweils die acht verschiedenen Workload-Typen sowie die Nutzung von Indexstrukturen (IDX) und Statistik-Informationen (STAT) betrachtet. Das Erzeugen zusätzlicher Indizes beschränkte sich dabei auf alle Attribute der zentralen Tabellen A SPECT M ODUL und A SPECTA SSIGN im statischen beziehungsweise A SPECT VALUE und A SPECTA SSIGN im dynamischen Ansatz. -- [W1] -SELECT T1.Name, T1.Preis FROM AspectModul T1 INNER JOIN AspectAssign T2 ON T1.RowID = T2.RowID WHERE T1.ModulID = 55 AND T2.Table = 1 AND T2.Aspect = 1; -- [W2] -INSERT INTO AspectModul (RowID, ModulID, Name, Preis, Variant) VALUES (-20, 55, ’Modul55-spanisch’, 55.22, NULL); INSERT INTO AspectAssign (AspAssID, Aspect, KeyValue, Table, RowID) VALUES (-20, 1, 7, 1, -20); -- [W3] -INSERT INTO AspectModul (RowID, ModulID, Name, Preis) SELECT -30, ModulID, Name, Preis FROM Modul WHERE ModulID = 55; INSERT INTO AspectAssign (AspAssID, Aspect, KeyValue, Table, RowID) VALUES (-30, 2, 5, 1, -30); UPDATE Modul SET Name = ’Modul55-neu’ WHERE ModulID = 55; -- [W4] -DELETE FROM AspectAssign WHERE AspAssID IN (-20, -30); DELETE FROM AspectModul WHERE RowID IN (-20, -30); -- [W5] -SELECT T1.ModulID, T3.KeyValue, T1.Name, T1.Preis FROM AspectModul T1 INNER JOIN AspectAssign T2 ON T1.RowID = T2.RowID INNER JOIN AspectKeyValue T3 ON T2.KeyValue = T3.AspKeyID WHERE T2.Table = 1 AND T2.Aspect = 1 ORDER BY T3.KeyValue, T1.ModulID; -- [W6] -INSERT INTO AspectKeyValue (AspKeyID, Aspect, KeyValue, Comment) VALUES (8, 1, ’pl-PL’, ’Polnisch’); INSERT INTO AspectModul (RowID, ModulID, Name, Preis) VALUES (15001, 1, ’Modul1-polnisch’, 1.11), ..., (18000, 3000, ’Modul3000-polnisch’, 3000.11); INSERT INTO AspectAssign (AspAssID, Aspect, KeyValue, Table, RowID) VALUES (30001, 1, 8, 1, 15001), ..., (33000, 1, 8, 1, 18000); -- [W7] -UPDATE AspectModul SET Name = CONCAT(’I18N’,Name) WHERE RowID IN (SELECT RowID FROM AspectAssign WHERE Aspect = 1 AND KeyValue = 4 AND Table = 1); -- [W8] -DECLARE GLOBAL TEMPORARY TABLE DelRows (AspAssID int, RowID int) ON COMMIT PRESERVE ROWS NOT LOGGED; INSERT INTO SESSION.DelRows (AspAssID, RowID) SELECT AspAssID, RowID FROM AspectAssign WHERE Aspect = 1 AND KeyValue = 8 AND Table = 1; DELETE FROM AspectAssign WHERE AspAssID IN (SELECT AspAssID FROM SESSION.DelRows); DELETE FROM AspectModul WHERE RowID IN (SELECT RowID FROM SESSION.DelRows); DELETE FROM AspectKeyValue WHERE Aspect = 1 AND KeyValue = ’pl-PL’; Abbildung 5: SQL-Anfragen für den statischen Integrationsansatz -- [W1] -SELECT CAST(T1.Value AS VARCHAR(50)) AS Name, CAST(T2.Value AS NUMERIC(7,2)) AS Preis FROM AspectValue T1 INNER JOIN AspectValue T2 ON T1.RowID = T2.RowID INNER JOIN AspectAssign T3 ON T1.AspValID = T3.AspectValue INNER JOIN AspectAssign T4 ON T2.AspValID = T4.AspectValue WHERE T1.Table = 1 AND T1.Column = 1 AND T2.Table = 1 AND T2.Column = 2 AND T3.KeyValue = T4.KeyValue AND T3.Aspect = 1 AND T1.RowID = 55; -- [W2] -INSERT INTO AspectValue (AspValID, Table, Column, RowID, Value) VALUES (-20, 1, 1, 55, ’Modul55-spanisch’), (-21, 1, 2, 55, ’55.22’); INSERT INTO AspectAssign (AspAssID, Aspect, KeyValue, AspectValue) VALUES (-20, 1, 7, -20), (-21, 1, 7, -21); -- [W3] -INSERT INTO AspectValue (AspValID, Table, Column, RowID, Value) SELECT -30, 1, 1, ModulID, Name FROM Modul WHERE ModulID = 55; INSERT INTO AspectAssign (AspAssID, Aspect, KeyValue, AspectValue) VALUES (-30, 2, 5, -30); UPDATE Modul SET Name = ’Modul55-neu’ WHERE ModulID = 55; -- [W4] -DELETE FROM AspectAssign WHERE AspAssID IN (-20, -21, -30); DELETE FROM AspectValue WHERE AspValID IN (-20, -21, -30); -- [W5] -SELECT T1.RowID As ModulID, T5.KeyValue, CAST(T1.Value AS VARCHAR(50)) AS Name, CAST(T2.Value AS NUMERIC(7,2)) AS Preis FROM AspectValue T1 INNER JOIN AspectValue T2 ON T1.RowID = T2.RowID INNER JOIN AspectAssign T3 ON T1.AspValID = T3.AspectValue INNER JOIN AspectAssign T4 ON T2.AspValID = T4.AspectValue INNER JOIN AspectKeyValue T5 ON T4.KeyValue = T5.AspKeyID WHERE T1.Table = 1 AND T1.Column = 1 AND T2.Table = 1 AND T2.Column = 2 AND T3.KeyValue = T4.KeyValue AND T3.Aspect = 1 ORDER BY T5.KeyValue, T1.RowID; -- [W6] -INSERT INTO AspectKeyValue (AspKeyID, Aspect, KeyValue, Comment) VALUES (8, 1, ’pl-PL’, ’Polnisch’); INSERT INTO AspectValue (AspValID, Table, Column, RowID, Value) VALUES (45001, 1, 1, 1, ’Modul1-polnisch’), (48001, 1, 2, 1, ’1.11’), ..., (48000, 1, 1, 3000, ’Modul3000-polnisch’), (51000, 1, 2, 3000, ’3000.11’); INSERT INTO AspectAssign (AspAssID, Aspect, KeyValue, AspectValue) VALUES (45001, 1, 8, 45001), (48001, 1, 8, 48001), ..., (48000, 1, 8, 48000), (51000, 1, 8, 51000); -- [W7] -UPDATE AspectValue SET Value = CONCAT(’I18N’,Value) WHERE Table = 1 AND Column = 1 AND AspValID IN (SELECT AspectValue FROM AspectAssign WHERE Aspect = 1 AND KeyValue = 4); -- [W8] -DECLARE GLOBAL TEMPORARY TABLE DelRows (AspValID int) ON COMMIT PRESERVE ROWS NOT LOGGED; INSERT INTO SESSION.DelRows (AspValID) SELECT T1.AspValID FROM AspectValue T1 INNER JOIN AspectAssign T2 ON T1.AspValID = T2.AspectValue WHERE T2.Aspect = 1 AND T2.KeyValue = 8 AND T1.Table = 1; DELETE FROM AspectAssign WHERE Aspect = 1 AND KeyValue = 8 AND AspectValue IN (SELECT AspValID FROM SESSION.DelRows); DELETE FROM AspectValue WHERE AspValID IN (SELECT AspValID FROM SESSION.DelRows); DELETE FROM AspectKeyValue WHERE Aspect = 1 AND KeyValue = ’pl-PL’; Abbildung 6: SQL-Anfragen für den dynamischen Integrationsansatz 4 Ergebnisauswertung Was sich im Prozess der ansatzspezifischen Workload-Transformation bereits erahnen ließ, wurde von den Testergebnissen deutlich bestätigt. Die nach dreifacher Ausführung gemittelten Messzeiten aller in Abschnitt 3.3 beschriebenen Testfälle sind in Tabelle 3 dargestellt, wobei der jeweils schnellste Ansatz hervorgehoben ist. statisch Individualdaten-Workload W1 W2 W3 W4 +IDX +STATS +IDX+STATS dynamisch Szenario +IDX +STATS +IDX+STATS 802 677 617 548 4343 226 3815 995 126 95 96 134 251 126 249 146 108 50 114 59 147 180 92 73 21 14 14 17 1220 37 105 24 Massendaten-Workload W5 W6 W7 198 189 136 145 1053401 3413 4318 1792 5462 8283 5498 8435 17417 23121 12811 20219 453 2601 843 2500 2626 217280 2260 5078 W8 2284 4136 2385 8265 168385 19568 158186 16201 Tabelle 3: Gegenüberstellung der Ausführungszeiten (in ms) Daraus lassen sich die nachstehenden Schlussfolgerungen ableiten. 1. Der dynamische Realisierungsansatz schneidet in fast jedem Testfall signifikant schlechter ab. Begründet ist dieser Umstand durch den notwendigen Einsatz zusätzlicher JOIN-Operatoren zur Verarbeitung der EAV-Tabellen. Dies zeigt sich sehr drastisch für die Anfrage W5, in der zur Ergebnisfindung fünf Tabellen miteinander verknüpft werden müssen und dabei ein potentiell großes Mengengerüst erzeugt wird. Selbst unter Nutzung von Indexstrukturen benötigt deshalb die Anfrage W5 im dynamischen Ansatz mehr als die 13fache Ausführungszeit gegenüber der gleichartigen Anfrage im statischen Ansatz. 2. Durch die Index-Nutzung werden die lesenden Zugriffe teilweise drastisch schneller, beispielweise führt ein Index in Abfrage W5 im dynamischen Ansatz zu einer 300mal schnelleren Verarbeitung (von über 17 Minuten auf gut 3 Sekunden). Gleichzeitig steigen die Ausführungszeiten für ändernde Anweisungen im Bereich der Massendaten-Verarbeitung (W6-W8) aufgrund des zusätzlichen Aufwands zur Index-Aktualisierung. Nicht mit angegeben ist dabei allerdings der Overhead zur initialen Index-Erzeugung. Dieses Ergebnis steht wie erwartet im Einklang mit dem allgemein bekannten theoretischen Hintergrund bezüglich der Verwaltung von Zugriffsstrukturen [HR01]. 3. Die alleinige Verwendung von Statistiken hat in diesem Szenario keine einheitliche Auswirkung. Es gibt sowohl Laufzeitverbesserungen wie beispielsweise für Anfrage W5 als auch Laufzeitverschlechterungen wie z.B. für Anfrage W8 jeweils im statischen Ansatz. 4. Anfragen im Massendaten-Bereich haben aufgrund des (gewollt) größeren Wirkungsradius bezüglich des vorliegenden Mengengerüsts eine deutlich längere Laufzeit, Ausnahme bildet hier merkwürdigerweise die lesende Anfrage W5 im statischen Ansatz. 4.1 Bewertung des statischen Ansatzes Der in Abschnitt 2.2 beschriebene Ansatz zeigt sich als klarer Sieger bezüglich Performance bei der Anfrageauswertung gegenüber dem dynamischen Ansatz. Dies liegt hauptsächlich an den Schattentabellen, welche alle aspektspezifischen Informationen eines Modellierungsobjektes (Tabelle) in gewohnter relationaler Form bereitstellen. Dadurch entsteht kein weiterer Aufwand wie bei der Transformation von EAV-Strukturen im dynamischen Ansatz. Diese Schattentabellen können prinzipiell die gesamte Funktionalität eines RDBMS ausnutzen, beispielsweise beim Erzeugen von Integritätsbedingungen oder Indizes. Einzige Ausnahme bildet das Attribut A SPECT K EY VALUE .K EY VALUE, welches zur Persistierung beliebiger Aspekt-Schlüsselwerte einen möglichst flexiblen Datentyp wie beispielsweise VARCHAR benötigt. Schließlich bietet dieser Modellierungsansatz die Möglichkeit, funktionale Aspekte innerhalb einer Applikation schrittweise zu integrieren, da keine Veränderung der originalen Fachtabellen notwendig ist und somit das Datenmodell ohne Seiteneffekte um funktionale Aspekte ergänzt werden kann. Diesen Vorteilen stehen allerdings auch einige Nachteile gegenüber. So führt das Konzept der Schattentabellen zu einer potentiellen Verdopplung aller Tabellen im Datenmodell, weil zu jeder Fachtabelle <TABLE> mit aspektrelevanten Informationen eine neue Tabelle A SPECT<TABLE> angelegt werden muss. Dadurch wird die Forderung nach Modularität (siehe Abschnitt 1.1) verletzt, da aspektspezifische Informationen über eine Vielzahl von Tabellen verteilt sind. Zudem entstehen in den Schattentabellen redundante Daten für alle Attribute, die von einem spezifischen funktionalen Aspekt nicht abhängig sind, im einleitend dargestellten Anwendungsszenario betrifft dies beispielsweise das Attribut M ODUL .VARIANT. Um diesem Problem zu begegnen wäre es möglich, nur die aspektabhängigen Attribute und deren Werte in der Schattentabelle zu speichern und für alle anderen Attribute NULL-Werte zu hinterlegen. Damit verbunden ist jedoch mehr Aufwand in der Anfrageverarbeitung, da ein vollständiger aspektspezifischer Datensatz dann nur noch unter Einbeziehung der zugehörigen Fachtabelle ermittelt werden kann. 4.2 Bewertung des dynamischen Ansatzes Wie bereits in der Namensgebung angedeutet zeigt sich auch in der Bewertung der in Abschnitt 2.1 erläuterte dynamische Realisierungsansatz quasi als Gegenstück zum statischen Ansatz. Der größte Vorteil ergibt sich direkt aus dem verwendeten EAV-Konzept, wodurch nur explizit mit Informationen besetzte Schlüssel-Wert-Paare gespeichert werden. Damit entsteht ein vollständig normalisiertes und redundanzfreies Datenmodell. Beispielsweise wird für Anfrage W3 im Abschnitt 3.3 nur der zu änderende Modultext kopiert und versioniert, im statischen Ansatz dagegen muss der gesamte Datensatz inklusive nicht zu ändernder Attribute kopiert werden. Zudem ergibt sich eine platzoptimierte Speicherung, da in den EAV-basierten Tabellen A SPECTA SSIGN und A SPECT VALUE keine NULL-Werte auftauchen können wie in den Schattentabellen. Schließlich lassen sich im dynamischen Modellierungsansatz für alle Objekte bzw. Tabellen unabhängig vom Konzept der funktionalen Aspekten zusätzliche Attribute ohne Schema-Veränderung hinzufügen. Wie in anderen Anwendungsfällen auch so bringt die Verwendung des EAV-Konzeptes neben der gesteigerten Flexibilität ebenso einen stark erhöhten Aufwand bei der Anfrageauswertung. Will man die gekippte Speicherform einer EAV-Tabelle in die klassische Tabellenform bringen, wie in diesem Testszenario für Vergleichszwecke geschehen, ist pro Attribut ein JOIN-Operator notwendig. Dies führt logischerweise sehr schnell zu einem Performanceproblem wie bereits für das hier verwendete einfache Beispiel in Tabelle 3 zu sehen ist. Außerdem müssen zur Gewährleistung des zwingend notwendigen einattributigen Primärschlüssels bei der Integration funktionaler Aspekte gegebenenfalls Fachtabellen um diesen Schlüssel ergänzt werden. Dies kann je nach Einsatz von VIEW-Definitionen Auswirkungen auf die darauf zugreifende Anwendung haben. 5 Fazit Diese Arbeit präsentierte nach einer kurzen Einführung der Aspektorientierten Datenhaltung mit der statischen und dynamischen Aspektintegration zwei Ansätze zur Implementierung dieses Paradigmas in relationalen Datenbanken. Diese beiden Modellierungsvarianten wurden anschließend mit einer Menge unterschiedlicher Anfragen aus dem Bereich der Indiviualdaten- und Massendatenverarbeitung in einem Benchmark analysiert und bewertet. Dabei zeigte sich der statische Ansatz signifikant schneller, gerade im Bereich der Massendatenverarbeitung sogar um durchschnittlich Faktor 5. Wie in der Bewertung aufgezeigt wurde, liegen diese Performanceprobleme des dynamischen Ansatzes in der intensiven aber notwendigen Nutzung des JOIN-Operators im EAV-Konzeptes begründet, welches dafür jedoch wichtige Anforderungen der Aspektorientierten Datenhaltung wie Modularität, Orthogonalität und Lokalität unterstützt. Ein Ergebnis dieser Arbeit ist die Schlussfolgerung, dass mit steigender Normalisierung und Flexibilität eines Datenmodells die Performance sinkt. Ähnliche Ergebnisse zeigen sich auch bei [AGJ+ 08] im Rahmen von Analysen für die effiziente Abbildung von Mandanten bzw. Tenants in einem gemeinsam genutzten Datenbankschema. Um diese Abhängigkeit wenigstens zum Teil aufzulösen, lassen sich in nachfolgenden Arbeiten mehrere Alternativen zur Reduzierung des Aufwands untersuchen. Hierzu zählt beispielsweise die Vermeidung umfangreicher JOIN-Operatoren durch applikationsseitige Verarbeitung der Daten mittels Hash-Tabellen[DNB06]. Dabei würde allerdings auch die DBMSFunktionalität zur serverseitigen Filterung und Selektion von Daten umgangen und in die Anwendungsschicht verlagert. Hier muss sich der effektive Performance-Gewinn erst noch in Benchmarks zeigen. Literatur [AGJ+ 08] Stefan Aulbach, Torsten Grust, Dean Jacobs, Alfons Kemper und Jan Rittinger. Multitenant databases for software as a service: schema-mapping techniques. In SIGMOD Conference, Seiten 1195–1206, 2008. [Cod70] E. F. Codd. A relational model of data for large shared data banks. CACM, 13(6):377– 387, 1970. [CSR02] Ruzanna Chitchyan, Ian Sommerville und Awais Rashid. An Analysis of Design Approaches for Crosscutting Concerns. In Workshop on Aspect-Oriented Design (held in conjunction with the 1st Aspect Oriented Software Development Conference AOSD), 2002. [DNB06] Valentin Dinu, Prakash Nadkarni und Cynthia Brandt. Pivoting approaches for bulk extraction of Entity-Attribute-Value data. Computer Methods And Programs in Biomedicine, 82(1):38–43, 2006. [GHJV94] Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [HR01] Theo Härder und Erhard Rahm. Datenbanksysteme: Konzepte und Techniken der Implementierung. Springer, 2001. [KLM+ 97] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, John Irwin und Jean-Marc Loingtier. Aspect-Oriented Programming. In ECOOP, Seiten 220–242, 1997. [Lie10a] Matthias Liebisch. Aspektorientierte Datenhaltung - ein Modellierungsparadigma. In Proceedings of the 22nd GI Workshop Grundlagen von Datenbanken 2010, Seiten 13– 17, Bad Helmstedt, Germany, Mai 2010. [Lie10b] Matthias Liebisch. Supporting functional aspects in relational databases. In Proceedings of the 2nd International Conference on Software Technology and Engineering 2010, San Juan, Puerto Rico, USA, Oktober 2010. [LM00] Stephen Lutz und Shyam Manohar. RS/6000 7025 Model F80: Technical Overview and Introduction. IBM, Austin, TX, Mai 2000. http://www.redbooks.ibm.com/ redpapers/pdfs/redp0033.pdf. [NMC+ 99] Prakash Nadkarni, Luis Marenco, Roland Chen, Emmanouil Skoufos, Gordon Shepherd und Perry Miller. Organization of Heterogeneous Scientific Data Using the EAV/CR Representation. In JAMIA, 6, Seiten 478–493, 1999. [Pli10] Matthias Plietz. Structured Development Process of Configuration Models. In Proceedings of the Workshop on Configuration, affiliated with the 19th European Conference on Artificial Intelligence 2010, Seiten 63–67, Lisbon, Portugal, August 2010.
