Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung

Transkript

1 Seminar 1912 Sommersemester 2005 Lehrgebiet Datenbanksysteme für neue Anwendungen Prof. Dr. Ralf Hartmut Güting Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung 10. The Tukwila Data-Integration-System Jan Engelkamp

2 10. The Tukwila Data Integration System (Jan Engelkamp) 2 Inhaltsverzeichnis 1. Data-Integration-Systems 3 2. Die Ziele des Tukwila-Systems 4 3. Wichtige Komponenten des Tukwila-Systems 5 4. Adaptive Techniken im Tukwila-System Fragmente und Materialisierungspunkte Die Event-Condition-Action-Regeln Dynamische Datenkollektoren Der Double-Pipelined-Hash-Join Adaptive Data-Partitioning Arten des Adaptive Data-Partitioning Adaptive Data-Partitioning im Tukwila-System Zusammenfassung und Diskussion 14 Literaturverzeichnis 15

3 10. The Tukwila Data Integration System (Jan Engelkamp) 3 1. Data-Integration-Systems Der Begriff Data-Integration-System 1 bezeichnet solche Systeme, die es Anwendungsprogrammen und Benutzern ermöglichen, in einheitlicher Art und Weise Anfragen an eine Menge heterogener und über ein Netzwerk verteilter Datenquellen zu stellen [7]. Derartige Systeme bilden somit eine einheitliche Schnittstelle für den Zugriff auf Datenquellen unterschiedlicher Art und Strukturierung. Und gerade darin liegt ihr zentraler Nutzen: Anwendungsprogramme und Benutzer eines Data-Integration-System 2 brauchen die letztendlich verwendeten Datenquellen, ihre Speicherorte und Spezifika nicht zu kennen. Sie müssen sich in keiner Weise darum kümmern, wie Anfragen, die innerhalb ihrer spezifischen Benutzersicht an die Datenbasis gestellt werden, auf die tatsächlichen Strukturen der konkreten Datenquellen abgebildet werden, oder darum, wie umgekehrt die Abbildung von Anfrageergebnissen auf die jeweilige Benutzersicht erfolgt. Und sie können sich darauf verlassen, dass die verschiedenen Datenquellen gemeinsam ausgewertet und Zwischen-, sowie Endergebnisse geeignet miteinander verbunden und kombiniert werden [4, S. 299]. Insbesondere jedoch dann, wenn die Datenquellen über ein WAN (Wide-Area-Network, Weitverkehrsnetz) und nicht über vergleichsweise sichere und schnelle Datenleitungen eines lokalen Netzwerks erreichbar sind, schlägt sich dies in zahlreichen Aspekten nieder, die teils direkte, teils indirekte Auswirkungen auf den Datenzugriff und die Anfrageverarbeitung haben. Dies gilt speziell für Datenbanken, auf die über das Internet respektive das World-Wide-Web zugegriffen wird. Auf einzelne Aspekte wird im folgenden noch näher einzugehen sein, zentrale Lösungsansätze stehen im Zentrum der vorliegenden Arbeit. Doch zunächst werden in Form eines kurzen Überblicks einige wichtige Herausforderungen, die sich für ein Data-Integration- System ergeben, vorgestellt: Aus der Tatsache, dass die Datenbasis aus autonomen und heterogenen Datenquellen besteht, die in einem WAN verteilt sind bzw. zumindest sein können, folgt, dass ein Data-Integration-System mit großen und unvorhersehbaren Verzögerungen, die ggf. beim Datentransport auftreten, umgehen können muss. Grundsätzlich sind hohe I/O-Kosten (Kosten für den Input und Output von Daten, für das Lesen von Daten aus und das Schreiben in Datenquellen) anzunehmen [4, S. 299; 5, S. 20]. Des weiteren kann kein wahlfreier Zugriff auf einzelne Datensätze vorausgesetzt werden, da Daten über ein Netzwerk und ggf. zahlreiche Netzwerkknoten transportiert werden. Größere Datenmengen treffen als Datenstrom beim Data-Integration-System ein [5, S. 20]. Um die Systemeffizienz zu erhöhen, bietet es sich an, an unterschiedlichen Stellen im System Daten-Caches (temporäre Zwischenspeicher) vorzusehen, sowie einmal bereits berechnete Zwischenergebnisse mehrfach zu verwenden sei es innerhalb ein und derselben Anfrage, oder in anderen, nachfolgenden Anfragen. Caching-Strategien müssen stets jedoch berücksichtigen, dass die einzelnen Datenquellen einer verteilten Datenbasis autonom sind in dem Sinne, dass sie von Benutzern und Anwendungsprogrammen verwendet werden können, welche nicht mit Hilfe des Data-Integration-System, sondern unabhängig davon darauf zugreifen und die gespeicherten Daten ändern. Benutzer eines Data-Integration-System haben prinzipiell jedoch den Anspruch, 1 Fachbegriffe insbesondere englische werden bei ihrer erstmaligen Nennung in Anführungsstriche gesetzt. Im Weiteren werden sie dann ohne besondere Hervorhebungen verwandt. In Überschriften entfallen Anführungsstriche. 2 Da es sich bei Data-Integration-System um einen englischsprachigen Begriff handelt, wird hier wie im folgenden kein s im Genitiv Singular angehängt. Ebenso wird im Nominativ Plural anstelle des deutschen Suffixes en die englische Pluralendung s verwandt. Gleiches gilt für andere englischsprachige Begriffe wie z.b. Wrapper.

4 10. The Tukwila Data Integration System (Jan Engelkamp) 4 dass zur Beantwortung ihrer Anfragen stets möglichst aktuelle Daten ausgewertet werden und niemals veraltete [5, S. 20]. Die Ansprüche der Benutzer eines Systems an die Qualität, Korrektheit und Vollständigkeit von Anfrageergebnissen bzw. an die Systemperformance sind bei Data-Integration-Systems nicht geringer, als bei klassischen, homogen strukturierten und nicht-verteilten Datenbanksystemen. Die Systemperformance gewinnt insbesondere in solchen Anwendungszusammenhängen an Bedeutung, die einen hohen interaktiven Charakter haben, sowie dort, wo viele und ggf. heterogene Anfragen von unterschiedlichen Benutzern parallel gestellt und vom System ausgewertet werden. Häufig ist es aus Benutzersicht interessanter, sehr schnell eine erste, vorläufige und evtl. unvollständige Antwort zu erhalten, als lange auf das vollständige Anfrageergebnis warten zu müssen [4, S. 300; 5, S. 19, 21, 24, 25]. Man denke etwa an eine integrierte Suche nach freien Hotelzimmern in einer bestimmten Stadt und innerhalb eines bestimmten Zeitraums über eine Menge vernetzter, aber unabhängiger und insbesondere unterschiedlich schnell antwortender Buchungssysteme hinweg. Eine weitere Herausforderung an Data-Integration-Systems ergibt sich wiederum aus der Tatsache, dass die Datenbasis aus autonomen und heterogenen Datenquellen besteht: Ein solches System kann sich weniger als ein konventionelles Datenbankmanagementsystem auf selbst erstellte respektive zu einer Datenquelle gespeicherte Metadaten verlassen, wie etwa Selektivitäten von Joins, Kardinalitäten von Relationen und Zwischenergebnissen und die Werteverteilung innerhalb einer Relation. Zudem ist grundsätzlich davon auszugehen, dass sich einzelne Datenquellen inhaltlich überschneiden, Daten also redundant gespeichert werden [4, S ]. 2. Die Ziele des Tukwila-Systems Das Data-Integration-System Tukwila wurde an der Universität von Washington entworfen. Es wird kontinuierlich im Rahmen von Forschungsarbeiten und -projekten weiterentwickelt und ergänzt [5, S. 20]. Sein Name verweist auf eine nach Ansicht der Tukwila-Projektleiter malerische Kleinstadt in der Nähe von Seattle im Nordwesten der Vereinigten Staaten von Amerika [4, S. 300]. Ein aus Benutzersicht zentrales Element des Tukwila-Systems ist ein sogenanntes Mediated Schema, eine Tukwila-eigene relationale Zwischendarstellung der Datenbasis, in welcher Benutzeranfragen formuliert und auf die autonome Datenquellen und ihre Inhalte abgebildet werden. (In neueren Versionen wird statt einer relationalen Zwischendarstellung XML verwandt; darauf wird später noch kurz einzugehen sein.) Anfragen an die Datenbasis werden systemintern in Anfragen an die zur Datenbasis gehörigen, heterogenen Datenquellen überführt, ihre Rückmeldungen verarbeitet und zu einem Gesamtergebnis kombiniert [4, S. 301; 5, S. 20; 7]. Dabei kommen zahlreiche adaptive Techniken und Strategien zur Anwendung. Ein entscheidender Ansatz ist die Verzahnung von Auswertungsplanerzeugung und -ausführung. Es wird nicht wie in klassischen Datenbankmanagementsystemen in einem in sich abgeschlossenen Prozess ein vollständiger Auswertungsplan erzeugt und optimiert, welcher dann zur Ausführung gebracht, also auf die Datenbasis angewendet wird. Stattdessen wird zunächst nur ein Teil des Auswertungsplans ausgeführt, um später anhand eines bereits vorliegenden Teilergebnisses und eventuell zwischenzeitlich eingetretener Ereignisse zu entscheiden, wie weiter zu verfahren ist. Die Anfrageoptimierung wird somit zu einem mehrstufigen Prozess mit einer beständigen Reoptimierung und Anpassung nachfolgender Auswertungsschritte zur Ausführungszeit. Auf diesen Aspekt wird noch genauer einzugehen sein. Entscheidungen die

5 10. The Tukwila Data Integration System (Jan Engelkamp) 5 weitere Auswertungsplanausführung betreffend werden auf der Basis von ebenfalls noch eingehender zu diskutierenden Event-Condition-Action-Regeln getroffen (Ereignis- Bedingung-Handlung-Regeln), wobei mögliche Events (Ereignisse) z.b. ein Mangel an Speicher oder ein Ausbleiben von Daten aus einer bestimmten Datenquelle sein können [4, S. 300]. Adaptivität wird des weiteren realisiert in Form von adaptiven Operatoren: Im Folgenden werden der Double-Pipelined-Hash-Join sowie dynamische Datenkollektoren vorgestellt. Letztere dienen dazu, Ausführungsteilergebnisse aus einer großen Anzahl autonomer und sich inhaltlich zumindest potentiell überschneidender Datenquellen zusammenzufassen [4, S. 300]. Mit Hilfe der systemeigenen Zwischendarstellung der Datenquelleninhalte (Mediated Schema), sowie adaptiver Techniken und Strategien erreicht Tukwila es, eine effiziente Integration autonomer Datenquellen in eine gemeinsame Datenbasis zu realisieren, sowie eine effiziente Anfrageausführung auch in solchen Fällen, in denen nur wenige verlässliche Informationen (Metadaten) über die Datenquellen und ihre Inhalte vorliegen. Des weiteren wird die Geschwindigkeit der Anfrageausführung zumindest aus Benutzersicht dadurch erhöht, dass dann, und nur dann, wenn dies im Anwendungszusammenhang sinnvoll erscheint (siehe das o.g. Hotelzimmerbeispiel), Ergebnisse zunächst unvollständig angezeigt und später nach und nach ergänzt werden. So können etwa langsam antwortende Datenquellen zunächst ignoriert werden. Ein anderer Ansatz ist, erste Anfrageergebnisse ausschließlich mit Hilfe initialer, ggf. zentral zwischengespeicherter, aber potentiell veralteter Daten zu generieren, um sie später mit Hilfe aktueller Daten aus entfernten Datenquellen zu korrigieren. Man spricht in diesem Zusammenhang von Ergebnis-Updates [5, S. 21, 25]. 3. Wichtige Komponenten des Tukwila-Systems Wie oben bereits angesprochen, ist ein Element von Tukwila das sogenannte Mediated Schema, eine systemeigene Zwischendarstellung der Datenbasis, in der Anfragen an das System gestellt und Ergebnisse ausgegeben werden. Sämtliche zur Verfügung stehenden Informationen über die Datenquellen und ihre Inhalte, die für einen effizienten Datenzugriff relevant sind respektive sein können, sind in einem sogenannten Datenquellenkatalog verzeichnet. Dazu gehören statistische Informationen über das Antwortverhalten und insbesondere die Antwortgeschwindigkeit der einzelnen Datenquellen, aber auch, wie oben bereits angesprochen, Informationen zu den Kardinalitäten von Relationen und der Werteverteilung innerhalb von Relationen. Der Datenquellenkatalog enthält auch Informationen darüber, inwieweit sich die Inhalte von Datenquellen überschneiden (overlap-information). Beachtenswert ist, dass es auch dann sinnvoll ist, verschiedene Datenquellen in diesem Katalog zu verzeichnen, wenn sie exakte Kopien voneinander darstellen. Es könnte schließlich sein, dass sich Situationen ergeben, in denen eine oder mehrere Quellen nicht erreichbar sind [4, S. 301]. Eine Anfrage von einem Benutzer oder Anwendungsprogramm wird zunächst von einer Anfragen-Neuformulierungs-Komponente (query reformulation component) entgegengenommen und in eine Menge Einzelanfragen überführt, die sich jeweils auf eine im Datenquellenkatalog verzeichnete Datenquelle beziehen. Diese Einzelanfragen werden weitergereicht an den Anfragenoptimierer des Systems (query optimizer), welcher jede der Anfragen in je einen optimierten Auswertungsplan übersetzt, um mit diesem sodann die Ausführungskomponente (query execution engine) aufzurufen. Der Anfragenoptimierer erzeugt wie oben beschrieben nicht zwangsläufig vollständige Auswertungspläne, sondern dann, wenn dies aufgrund etwa fehlender Metadaten zu den Inhalten einer Datenquelle oder potentieller Unsicherheiten z.b. die Erreichbarkeit einer Datenquelle betreffend sinnvoll erscheint, lediglich Teile davon.

6 10. The Tukwila Data Integration System (Jan Engelkamp) 6 Gleichzeitig erzeugt er auch einen Satz von Regeln (Event-Condition-Action-Regeln), um festzulegen, wann und wie der Auswertungsplan ggf. zu modifizieren ist [4, S. 301; 7]. In der ursprünglichen Konzeption des Tukwila-Systems wurden der Kommunikation von Ausführungskomponente und tatsächlicher Datenquelle sogenannte Wrappers zwischengeschaltet. (Dieses englische Wort lässt sich wohl am ehesten übersetzen mit Schutzumschlag, Verpackung, Deckblatt oder Ummantelung.) Wrappers übertragen die im Tukwila-System verwendeten Datenformate in datenquellenspezifische Datenformate und umgekehrt. Dabei ist es konzeptionell unerheblich, ob man sie als Schnittstelle von Tukwila zu den Datenquellen oder als Schnittstelle der Datenquellen zu Tukwila begreift und an welcher Stelle in einem verteilten System sie letztendlich zur Ausführung gelangen [4, S. 301; 5, S. 23]. Mit der Verbreitung von XML (extensible Markup Language) und der damit einhergehenden Entwicklung, dass in den meisten modernen Datenbanken ein Export nach XML realisiert werden kann, verliert das Wrapper-Konzept an Bedeutung. Auch für andere (strukturierte) Datenquellen existieren Werkzeuge zur Überführung der Inhalte in XML, etwa solche, die HTML-Seiten in XML- Dokumente überführen [5, S. 23]. Nachdem Tukwila so ausgelegt wurde, dass von einer Datenbasis bestehend aus XML- Datenquellen ausgegangen wird, war der nächste (naheliegende) Schritt zur Optimierung des Systems der Verzicht auf eine Überführung der Datenquelleninhalte in ein Tukwila-internes relationales Schema. Stattdessen wurde Tukwila zu einem XML Data-Integration-System mit speziellen Operatoren für XML-strukturierte Daten. Inhalte relationaler Datenquellen werden nun nach XML überführt [5, S. 23; 7]. Bei der Tukwila-Implementierung wird soweit es möglicht ist auf verbreitete Standards und Programmiersprachen zurückgegriffen [4, S. 306]. Abbildung 1: wichtige Tukwila-Komponenten [vgl. 4, S. 302; 7]

7 10. The Tukwila Data Integration System (Jan Engelkamp) 7 4. Adaptive Techniken im Tukwila-System Ursprünglich verfolgte die Entwicklung von Tukwila das Ziel, vier Arten von Adaptivität zu realisieren, bei denen (a) die Reihenfolge von Operatoren innerhalb von Auswertungsplänen zur Ausführungszeit umgestellt wird (Scheduling-Based-Methods), (b) aus alternativen Auswertungsplänen zur Laufzeit ein bester ausgewählt wird (Redundant-Computation- Methods), (c) Auswertungspläne nicht ein geschlossenes Ganzes bilden, sondern zur Ausführungszeit modifizierbar sind (Plan-Partitioning-Methods), und (d) nicht alle Daten zwangsläufig über ein und denselben Auswertungsplan verarbeitet werden müssen, sondern zur Ausführungszeit entschieden wird, welche Daten wie verarbeitet werden (Data-Partitioning- Methods) [6, S. 396]. Neuere Entwicklungen hingegen versuchen, unterschiedliche Techniken und Strategien unter dem Begriff Adaptive Data-Partitioning zu einem einheitlichen Ansatz zu vereinen. Hierauf wird im folgenden noch einzugehen sein. Die adaptive Technik, aus mehreren alternativen Auswertungsplänen zur Laufzeit einen besten auszuwählen, stellt ein zumindest partiell redundantes Berechnungsverfahren dar, da nicht versucht wird, im Vorhinein zu ermitteln, welcher von mehreren alternativen Auswertungsplänen der effizienteste zu sein scheint. Stattdessen werden mehrere Auswertungspläne parallel gestartet und nach einer bestimmten Berechnungszeit oder zu einem festgelegten Zeitpunkt überprüft, die Abarbeitung welchen Planes am weitesten fortgeschritten ist. Dieser wird weiter ausgeführt, die Abarbeitung der übrigen abgebrochen [6, S. 396]. Wenn Auswertungspläne nicht als in sich geschlossenes Ganzes betrachtet, sondern in Abschnitte unterteilt werden, so kann nach einem jeden Abschnitt entschieden werden, wie weiter vorzugehen ist: So kann etwa einer von mehreren alternativen nachfolgenden Auswertungsplanabschnitten ausgewählt werden, oder zur Ausführungszeit wird der ursprünglich vollständig entworfene Auswertungsplan vom nachfolgenden Abschnitt an neu berechnet (re-optimiert) [6, S. 296]. Auf die Frage der Unterteilung von Auswertungsplänen in Abschnitte (Fragmente) wird im nachfolgenden Abschnitt genauer einzugehen sein Fragmente und Materialisierungspunkte Die einzelnen Abschnitte, in die ein Auswertungsplan aufgeteilt wird, heißen Fragmente. Jedes Mal, wenn ein Fragment eines Auswertungsplans vollständig abgearbeitet worden ist, wird die Ausführung unterbrochen und die bis dahin berechneten Zwischenergebnisse werden materialisiert, d.h. explizit erzeugt. Aus diesem Grunde spricht man auch von Materialisierungspunkten, die sich am Ende eines jeden Fragments befinden [4, S. 302]. Würde ein Auswertungsplan als in sich geschlossenes Ganzes optimiert, so würde in vielen Fällen auf eine Materialisierung, also eine tatsächliche Erzeugung von Zwischenergebnissen (das sind klassischerweise Relationen) verzichtet, da mehrere Operatoren ggf. effizient durch einen komplexen Operator mit identischer Funktionsweise ersetzt, d.h. mehrere Operatoren gruppiert werden könnten [10, S. 181], oder die Ausgabedaten eines Operators (klassischerweise Datensätze, Tupel) könnten direkt von einem anderen Operator als Eingabedaten gelesen werden; man spricht in diesem Falle davon, dass Ströme von zu verarbeitenden Objekten (Tupeln) einerseits produziert und andererseits eingelesen werden, also eine Stromverarbeitung stattfindet [10, S. 199]. Ein Auswertungsplan besteht aus Fragmenten plus einer Menge von Regeln, mit welchen festgelegt wird, wie nach Abarbeitung eines jeden Fragments entschieden wird, was weiter zu

8 10. The Tukwila Data Integration System (Jan Engelkamp) 8 tun ist [4, S. 302]. Auf die Regeln wird im folgenden Abschnitt genauer einzugehen sein. Ein jedes Fragment besteht aus einem Operatorbaum, in dessen inneren Knoten sich jeweils ein algebraischer Operator (wie etwa eine Selektion, ein Join, eine Projektion, eine Vereinigung o.ä.) befindet, inkl. einer in der konkreten Anwendung sinnvollen und im Idealfall optimalen Implementierung des Operators (z.b. Index-Nested-Loop-Join, Hash-Join, Double-Pipelined- Hash-Join etc.), sowie einige Zeiger und Metainformationen [4, S. 302; 10, S. 172]. Wenn Auswertungspläne in Fragmente unterteilt werden, dann stellt sich zwangsläufig die Frage, in wie viele und wie groß die Fragmente optimalerweise sein sollten, d.h. aus wie vielen Operatoren bzw. Knoten die entsprechenden Operatorbäume für die einzelnen Fragmente bestehen sollten. Sehr viele Fragmente ziehen sehr viele Materialisierungspunkte nach sich, was sich negativ auf die Effizienz und Performance der Anfrageausführung auswirken kann. Nur wenige Fragmente führen zu wenigen Materialisierungspunkten, woraus folgt, dass seltener in die Anfrageausführung korrigierend eingegriffen, der potentielle Nutzen dieses adaptiven Ansatzes somit herabgesetzt wird [5, S. 24]. Des weiteren ist entscheidend, wann ein Fragment endet und ein neues beginnt, an welcher Stelle des Auswertungsplans also eine Materialisierung von Zwischenergebnissen erfolgt. Oben wurde bereits die Stromverarbeitung angesprochen, sowie die Gruppierung von Operatoren. Es ist offensichtlich, dass es Operatoren gibt, bei denen sich eine Gruppierung anbietet (z.b. die Sortierung einer Relation und eine nachfolgende Projektion mit Duplikateliminierung, oder der Join zweier Relationen und eine nachfolgende Projektion). Zwischen solchen Operatoren sollte demnach grundsätzlich keine Materialisierung erfolgen [5, S. 24; 10, S. 181]. Im Tukwila-System werden Materialisierungspunke zudem auch adaptiv festgelegt, also während der Ausführungszeit. Insbesondere, wenn ein Mangel an Hauptspeicherplatz auftritt oder droht, ist es sinnvoll, Zwischenergebnisse zu materialisieren und auf Externspeicher auszulagern [5, S. 24] Die Event-Condition-Action-Regeln Die Regeln, die am Ende eines jeden Fragments zur Ausführung kommen, bilden einen Schlüsselmechanismus der adaptiven Ansätze im Tukwila-System. So wird etwa von der Ausführungskomponente überprüft, ob die zuvor vom Anfragenoptimierer geschätzten Kardinalitäten mit den tatsächlichen Kardinalitäten der materialisierten Zwischenergebnisse übereinstimmen oder ob signifikante Abweichungen festzustellen sind. Es wird auch überprüft, ob die Datenquellen, auf die im nachfolgenden Fragment zugegriffen werden soll, erreichbar sind und ein Zugriff darauf möglich ist [4, S. 302; 5, S. 22]. Von ihrer äußeren Form her sind die Regeln recht einfach; sie lauten: Wenn ein Ereignis stattgefunden hat und falls eine Bedingung erfüllt ist, dann sind bestimmte Handlungen auszuführen (when event if condition then actions). Aus dem strukturellen Aufbau dieser Regeln leitet sich auch ihre Bezeichnung ab: Event-Condition-Action-Regeln (Ereignis- Bedingung-Handlung-Regeln). Ein einfaches Beispiel ist: Wenn Fragment F i beendet wurde und die Kardinalität des Zwischenergebnisses K Z größer ist als ein Faktor c mal die geschätzte Kardinalität des Zwischenergebnisses K gz, dann ist der Auswertungsplan von der aktuellen Position an neu zu berechnen. [vgl. 4, S. 302] Das typische Ereignis, das zur Überprüfung einer Bedingung führt, ist die Beendigung eines Fragments. Ereignisse stellen aber auch Fehlersituationen dar, oder das Ausbleiben von Daten aus einer Datenquelle, ein Hauptspeichermangel oder die Tatsache, dass ein Operator mehr Ergebnistupel produziert hat als eine festgelegte maximale Anzahl. Bedingungen, die nach Eintreten eines Ereignisses überprüft werden, sind z.b. die Kardinalität eines bestimmten, soeben

9 10. The Tukwila Data Integration System (Jan Engelkamp) 9 erzeugten Zwischenergebnisses, die seit einem festgelegten Zeitpunkt verstrichene Zeit, die Menge an noch verfügbarem Speicherplatz, die Geschwindigkeit, mit der eine Datenquelle Daten liefert o.ä. Von den Ereignissen und den Ergebnissen der Bedingungsüberprüfung hängt es ab, welche Handlungen nunmehr ausgeführt werden: Der gesamte Auswertungsplan von der aktuellen Position an wird ggf. neu berechnet; ein zum eigentlich vorgesehen nachfolgenden Fragment alternatives Fragment wird ausgeführt; parallel ausführbare Operatoren werden in einer anderen Reihenfolge als ursprünglich vorgesehen ausgeführt; statt einer ursprünglich vorgesehenen Implementierung eines Operators kommt eine andere Implementierung zur Ausführung; eine andere Datenquelle als zunächst vorgesehen wird verwendet etc. Es kann sogar sein, dass die Entscheidung getroffen wird, die aktuelle Berechnung mit einer Fehlermeldung abzubrechen [4, S 302; 5, S. 22]. Wie oben bereits angesprochen, besteht bei Tukwila ein Auswertungsplan aus zweierlei, aus den Fragmenten, die der Anfragenoptimierer der Ausführungskomponente zuführt, einerseits und aus Event-Condition-Action-Regeln andererseits. Diese Regeln übergibt der Anfragenoptimierer einer bislang noch nicht vorgestellten Systemkomponente: dem Event-Handler. Falls während der Anfrageausführung ein Ereignis (Event) eintritt, ruft die Ausführungskomponente dann unmittelbar diesen Event-Handler auf, welcher die Regeln ausführt und somit wie oben beschrieben die Entscheidung darüber trifft, welche Handlungen nunmehr auszuführen sind [4, S. 303] Dynamische Datenkollektoren Ein anderer als die bisher vorgestellten Ansätze zur Realisierung von Adaptivität im Tukwila- System ist die Verwendung spezieller adaptiver Operatoren. Der Double-Pipelined-Hash-Join, welcher im folgenden Abschnitt vorgestellt wird, und dynamische Datenkollektoren stellen solche adaptiven Operatoren dar. Sie reagieren auf Veränderungen in den Eigenschaften des Netzwerks, über welches Daten aus entfernten Datenquellen zwangsläufig transportiert werden müssen [5, S. 22]. Dynamische Datenkollektoren sind in solchen Fällen verwendbar, in denen sich die Datenquellen der Datenbasis teilweise inhaltlich überlappen oder einige Datenquellen vollständige Replikate anderer darstellen. Zusätzlich muss der Anfragenoptimierer Zugriff auf zumindest geschätzte Informationen darüber haben, inwieweit sich die Inhalte der Datenquellen überschneiden (overlap-information). Wie oben beschrieben, greift er dazu auf den Datenquellenkatalog des Tukwila-Systems zurück. Eine weitere Voraussetzung, die erfüllt sein muss, ist, dass der Anfragenoptimierer eine Reihenfolge festlegen kann, in der redundante Datenquellen angesprochen werden. Diese Reihenfolge kann aufgrund des Antwortverhaltens einer jeden Datenquelle festgelegt werden, oder aufgrund für den konkreten Fall speziell zu definierenden Kosten, die jede der in Frage kommenden Datenquellen verursacht. Zunächst muss also jede Datenquelle mindestens einmal kontaktiert und ihr Antwortverhalten beobachtet und protokolliert werden. Letztendlich führen die so ermittelten Informationen zur Aufstellung einer Menge von Event-Condition-Action-Regeln, wie sie im vorangegangenen Kapitel beschrieben wurden. Dynamische Datenkollektoren ergeben sich somit als Zusammenfassung von Methoden zum Zugriff auf in Frage kommende Datenquellen und einer Menge von Event- Condition-Action-Regeln [4, S. 303].

10 10. The Tukwila Data Integration System (Jan Engelkamp) Der Double-Pipelined-Hash-Join Der Join ist eine der am häufigsten benutzten relationalen Operationen, gleichzeitig aber auch eine der teuersten. Aus diesem Grunde existieren zahlreiche Implementierungen (wie der Nested-Loop-Join, der Sort-Merge-Join, der Hash-Join uvm.), und die Entscheidung darüber, welche der Implementierungen konkret zu verwenden ist, kann i.d.r. nur für die jeweilige Situation und abhängig von mehreren Faktoren getroffen werden. Einer der wichtigsten dieser Faktoren ist die Frage, in welcher Form die im Rahmen eines Join zu verknüpfenden Relationen vorliegen (sortiert, unsortiert; mit Index, ohne Index etc.). So ist etwa der einfache Hash-Join besonders für solche Fälle geeignet, in denen zwei zu verknüpfende Relationen unterschiedlich groß sind und die kleinere von beiden in einem ersten Arbeitsschritt effizient und vollständig in den Hauptspeicher eingelesen werden kann [10, S. 190ff]. Es ist unmittelbar ersichtlich, dass dieser einfache Hash-Join keine gute Join-Implementierung für ein Data-Integration-System wie Tukwila darstellt. Denn erstens muss eine sichere Entscheidung darüber getroffen werden können, welche von zwei Relationen die kleinere ist. Tukwila müsste sich also in jedem Falle vollständig auf die Größenangaben der Datenquellen verlassen können; dies wird umso wichtiger, wenn entschieden werden muss, ob die kleinere Relation tatsächlich in den Hauptspeicher passt und also die Standardimplementierung des Hash-Join verwandt werden kann, oder ob die Relation vielleicht gerade eben nicht mehr in den Hauptspeicher passt; dann müsste nämlich zunächst eine Partitionierung erfolgen. Zweitens wäre der einfache Hash-Join in dem Moment keine gute Implementierung, in dem sich herausstellt, dass die Datenquelle, die die kleinere Relation liefert, die schlechteren Antwortzeiten hat. Und drittens müssen die zu verknüpfenden Relationen nacheinander eingelesen werden, und die kleinere zunächst vollständig. Dies aber ist in Hinblick auf die Verzögerungen, die beim Transport der Daten über ein Netzwerk entstehen können, nicht sinnvoll; besser wäre es, wenn Verzögerungen beim Zugriff auf Datenquelle A dadurch überdeckt werden könnten, dass unmittelbar auf Datenquelle B umgeschaltet wird. Ein paralleles Einlesen aus beiden Datenquellen ist also wünschenswert. Daraus leitet sich ein vierter Punkt ab: Der einfache Hash- Join liefert erst mit einer gewissen Verzögerung erste Ergebnisse (verknüpfte Tupel), in vielen Anwendungen wird jedoch gewünscht, dass möglichst schnell ein erster Ergebnisoutput erfolgt [4, S. 304; 10, S. 192f]. Eine speziell für Data-Integration-Systems entwickelte und in Tukwila verwandte Join- Implementierung stellt der Double-Pipelined-Hash-Join dar. Auf seine Implementierung soll an dieser Stelle nicht genauer eingegangen werden (vgl. dazu 4, S. 304f), stattdessen werden einige besondere Eigenschaften dieses adaptiven Operators kurz aufgezählt: Die Zeit, die das System benötigt, um erste Ergebnisse (verknüpfte Tupel) zu liefern, ist minimal. Zu jedem Zeitpunkt t werden alle Ergebnistupel, die mit Hilfe der bis dahin eingelesenen Daten berechnet werden können, unmittelbar berechnet und auch ausgegeben. Es muss des weiteren keine Entscheidung darüber getroffen werden, welche Relation kleiner ist als die andere respektive zuerst eingelesen werden soll o.ä. Die zu verknüpfenden Relationen werden symmetrisch verarbeitet. Sobald sich das Antwortverhalten einer Datenquelle verschlechtert, wird dies dadurch kompensiert, dass mehr Daten respektive schneller aus der jeweils anderen gelesen wird (sofern man davon ausgeht, dass zwei Relationen miteinander verknüpft werden, die je aus einer anderen Datenquelle stammen) [4, S. 304; 5, S. 22]. Bei experimentellen Messungen am Tukwila-System hat sich bestätigt, dass der Double- Pipelined-Hash-Join eine der besten Implementierungen im gegebenen Zusammenhang darstellt [4, S. 306].

11 10. The Tukwila Data Integration System (Jan Engelkamp) Adaptive Data-Partitioning Nach Ansicht der Entwickler des Tukwila-Systems stellen die zahlreichen adaptiven Techniken und Strategien, die in Data-Integration-Systems und auch im Tukwila-System zur Anwendung kommen, in ihrer Gesamtheit betrachtet ein unverbundenes Sammelsurium von Lösungsansätzen dar, die jeweils an einem konkreten Problem ansetzen (z.b. Verzögerungen beim Datentransport oder unsicheren Kardinalitätsschätzungen). Ein einheitlicher theoretischer Überbau, eine methodologische Zusammenfassung dieser Techniken fehlte lange Zeit. Aus diesem Grunde wird ein solcher umfassender Ansatz unter dem Begriff Adaptive Data-Partitioning von den Entwicklern des Tukwila-Systems entworfen, das Gesamtproblem der adaptiven Anfrageausführung in Data-Integration-Systems formalisiert sowie in Problemklassen unterteilt und eine Umsetzung dieses Ansatzes in eine konkrete Implementierung im Rahmen des Tukwila-Systems vorgenommen [6, S. 395]. Kerngedanke des Adaptive Data-Partitioning ist es, bei der Anfrageausführung dynamisch auf mehrere unterschiedliche Auswertungspläne zurückzugreifen, welche sowohl parallel als auch sequentiell nacheinander ausgeführt werden können [6, S. 396]. Einschränkend muss angemerkt werden, dass sich das Adaptive Data-Partitioning ausschließlich auf eine anfrageninterne Adaptivität (Intra-Query-Adaptivity) respektive Optimierung konzentriert und anfragenübergreifende Ansätze (Inter-Query-Adaptivity) weitgehend außen vor gelassen werden [6, S. 396]. Anfragenübergreifende Ansätze sind seit jeher auch in klassischen Datenbankmanagementsystemen zu finden. So werden etwa einmal erzeugte Auswertungspläne gemeinsam mit den ursprünglich formulierten Anfragen und dem letztendlich erzeugten Programmcode im Systemkatalog eines Datenbankmanagementsystems abgelegt, um bei einer erneuten äquivalenten (oder ähnlichen) Anfrage auf einmal bereits geleistete Arbeit zurückgreifen zu können [10, S. 199f; vgl. auch 3, S. 4] Arten des Adaptive Data-Partitioning Wurden z.b. die Kardinalitäten der im Rahmen einer Datenbankoperation zu verarbeitenden Relationen falsch abgeschätzt bzw. lieferte eine Datenquelle falsche Angaben zur Größe einer Relation, so kann dies dazu führen, dass eine Implementierung dieser Datenbankoperation für den auszuführenden Auswertungsplan gewählt wurde, die hinter der Effizienz einer alternativen Implementierung zurückbleibt. Es ist auch vorstellbar, dass ein ganz anderer Auswertungsplan aufgestellt worden wäre, hätten die korrekten Kardinalitäten zur Verfügung gestanden. Es erscheint somit u.u. sinnvoll, einen bereits zur Ausführung gebrachten Auswertungsplan abzubrechen, sobald die ihm zugrundeliegende Fehleinschätzung bemerkt wird, und im Weiteren einen alternativen Auswertungsplan zu verwenden. Jedoch sollten bereits berechnete Ergebnisse nicht verworfen und neu berechnet werden müssen, schließlich wäre dies ineffizient, sondern sie sollten einen Teil des insgesamt zu berechnenden Ergebnisses bilden [6, S. 396f]. Das eben beschriebene Vorgehen ist nicht nur einsetzbar, um die Anfrageausführung ein einziges Mal zu korrigieren, sondern es ist durchaus möglich, dies mehrfach zu tun, d.h. mehrfach die Ausführung eines Auswertungsplans abzubrechen und auf einen neuen, aufgrund der zur Verfügung stehenden Informationen effizienter erscheinenden Auswertungsplan umzuschalten. Dies führt dazu, dass die Anfrageausführung in mehreren Phasen erfolgt, in welcher je ein anderer Auswertungsplan zum Einsatz kommt. Zu beachten ist, dass das Endergebnis jedoch nicht durch eine einfache Vereinigung der in jeder Phase erzeugten Teilergebnisse gebildet werden kann, sondern es muss im Rahmen einer speziellen

12 10. The Tukwila Data Integration System (Jan Engelkamp) 12 abschließenden Vereinigungsphase, der sogenannten Stitch-up-Phase (to stitch up = nähen, zunähen, zusammennähen) korrigiert und ergänzt werden [6, S. 397]. Die obige Darstellung soll an einem konkreten Beispiel verdeutlicht werden [vgl. 6, S. 396f]. Angenommen, drei Relationen sollen folgendermaßen miteinander verknüpft werden: Personen [Personen.PersonenID = PKW.HalterID] PKW [PKW.LackID = Lacke.LackID] Lacke Eine derartige Verknüpfung (die Darstellung des Joins folgt 8, S. 2.15) kann etwa im Rahmen einer Anfrage verwandt werden, die alle Fahrzeughalter liefert, deren PKW eine bestimmte Lackierung aufweist. Je nach Kardinalität der Relationen Personen, PKW und Lacke bietet es sich an, aus Effizienzüberlegungen zuerst die Relationen PKW und Lacke anstelle der Relationen Personen und PKW zu verknüpfen, also den obigen Ausdruck umzuformen in : Lacke [PKW.LackID = Lacke.LackID] PKW [Personen.PersonenID = PKW.HalterID] Personen Wird jedoch erst nach einer gewissen Zeit entdeckt, dass die zunächst gewählte Reihenfolge weniger effizient ist als die letztere, wird also die Auswertung erst nach einer gewissen Zeit auf einen neuen Auswertungsplan umgestellt, so wurden zahlreiche Tupel der drei Relationen bereits vor der Umstellung erfolgreich miteinander zu Ergebnistupeln verknüpft. Angenommen, aus der Relation Personen wurden die ersten n Tupel und aus der Relation Lacke die ersten m Tupel vor der Umstellung auf einen neuen Auswertungsplan verarbeitet; danach werden die Tupel ab der Position n+1 der Relation Personen respektive ab der Position m+1 der Relation Lacke verarbeitet. Würden nun die derart produzierten Ergebnistupel einfach zu einem Endergebnis vereinigt werden, so würde dieses Endergebnis unvollständig sein, da keine Ergebnistupel gebildet wurden, in denen Tupel aus der Relation Personen mit den Positionen 1 bis n mit Tupeln aus der Relation Lacke mit den Positionen m+1 bis maximal verknüpft wurden, sowie Tupel aus der Relation Personen mit den Positionen n+1 bis maximal mit Tupeln aus der Relation Lacke mit den Positionen 1 bis m. Es müssen also ergänzend zu den beschriebenen Auswertungsphasen in der oben bereits genannten Stitch-up-Phase noch phasenübergreifende Relationen- Verknüpfungen erfolgen. Abbildung 2: Die Verarbeitung von unterschiedlichen Tupeln einer Relation durch verschiedene Auswertungspläne erfordert eine nachfolgende Stitch-Up-Phase [vgl. 6, S. 397]. Das eben beschriebene Beispiel verdeutlich den grundsätzlichen Ablauf des Adaptive Data- Partitioning sehr gut: Die Anfrageausführung erfolgt in mehreren Phasen, wobei jede Phase beendet wird, falls sich herausstellt, dass die Anfrageausführung mit einem anderen Auswertungsplan, als dem bislang verwandten, effizienter als bisher erfolgen kann. Den Abschluss der Ergebnisberechnung bildet eine spezielle abschließende Vereinigungsphase, die Stitch-up-Phase [6, S. 397]. Zu ermitteln, welche Berechnungen in der Stitch-up-Phase im Einzelnen auszuführen sind, stellt sicherlich eine der komplexesten Aufgaben des Adaptive Data-Partitioning dar, müssen doch Daten miteinander verknüpft werden, die im Rahmen u.u. ganz unterschiedlicher Auswertungspläne bereits zum Teil verarbeitet wurden. Zu beachten ist

13 10. The Tukwila Data Integration System (Jan Engelkamp) 13 auch, dass eine erneute Übertragung von Daten aus den verschiedenen Datenquellen des Data- Integration-System zur Ausführungskomponente im Rahmen der Stitch-up-Phase unbedingt zu vermeiden ist, da sich dies im Allgemeinen deutlich negativ auf die Effizienz der Anfrageausführung auswirkt; stattdessen müssen die in den verschiedenen Phasen verarbeiteten Daten für einen ggf. notwendigen erneuten Zugriff darauf im Rahmen der Stitch-up-Phase so zwischengespeichert werden, dass der erneute Zugriff möglichst effizient erfolgen kann [6, S. 399]. Auf detaillierte Implementierungen von Operationen der Stitch-up-Phase, wie etwa den Stitch-up-Join soll im Rahmen der vorliegenden Arbeit nicht weiter eingegangen werden (vgl. dazu 6, S. 399f). In der bisherigen Darstellung wurden die Phasen des Adaptive Data-Partitioning sequentiell nacheinander ausgeführt. Ein anderer Ansatz ist es, sie zu parallelisieren: Die zu verarbeitenden Daten werden überschneidungsfrei (disjunkt) partitioniert und jede Partition von einem anderen, alternativen Auswertungsplan verarbeitet. Nach einiger Zeit wird die Effizienz der Auswertungspläne verglichen und sodann alle bis dahin noch nicht verarbeiteten Daten ausschließlich durch den effizientesten verarbeitet. Am Ende erfolgt wiederum die notwendige Stitch-up-Phase [6, S. 397]. Dieser Ansatz ist nicht zu verwechseln mit den weiter oben vorgestellten Redundant-Computation-Methods. Dort wurden dieselben Daten parallel im Rahmen unterschiedlicher Auswertungspläne verarbeitet und nach einiger Zeit evaluiert, welcher Auswertungsplan dabei bislang am effizientesten war; dieser wird weiter ausgeführt, die übrigen werden abgebrochen und die von ihnen erzeugten (redundanten) Ergebnisse verworfen. Beim vorliegenden Ansatz des Adaptive Data-Partitioning bearbeiten verschiedene Auswertungspläne unterschiedliche (!) Daten, so dass keine redundanten Ergebnisse produziert werden und auch die in letztendlich abgebrochenen Auswertungsplänen erzeugten Ergebnisdaten verwandt werden. Redundante Berechnungen werden so vermieden. Eine weitere Art des Adaptive Data-Partitioning ergibt sich aus der Beobachtung, dass es häufig von den Eigenschaften der zu verarbeitenden Daten abhängig ist, welche mehrerer alternativer Implementierungen für eine Datenbankoperation die effizienteste ist. Es ist also u.u. sinnvoll, Datensätze, die unterschiedliche Eigenschaften besitzen, auch durch unterschiedliche Auswertungspläne verarbeiten zu lassen. Unmittelbar ersichtlich dürfte sein, dass auch in solch einem Fall eine Stitch-up-Phase obligatorisch ist [6, S. 397]. Ein Beispiel soll das Gesagte verdeutlichen: Angenommen, zwei Relationen sollen miteinander durch einen Join verknüpft werden, welche weitgehend, aber nicht vollständig sortiert sind. Dies kann etwa der Fall sein, wenn die Relationen vor einiger Zeit sortiert wurden, seitdem aber neue Datensätze bereits in der Form zugefügt wurden, dass sie entweder einfach an das Ende der zugrundeliegenden Datenstruktur angehängt oder in durch vorangegangene Datensatzlöschungen frei gewordene Speicherplätze geschrieben worden sind. Für die sortiert vorliegenden Datensätze kann eine diese Eigenschaft speziell ausnutzende Join-Implementierung wie etwa der Sort-Merge-Join [vgl. 10, S. 191ff] gewählt werden. Alle Datensätze, die die Sortierung der Relation verletzen, werden einem anderen Auswertungsplan zugeführt. In der Stitch-up-Phase schließlich werden die sortiert bei der Ausführungskomponente eingetroffenen mit den die Sortierung verletzenden Datensätzen Join-verknüpft. Da der eben genannte Sort-Merge-Join effizienter ist als der weiter oben vorgestellte Double- Pipelined-Hash-Join, wenn die beteiligten Relationen sortiert sind, bietet es sich an, auf die zuletzt angesprochene Art des Adaptive Data-Partition immer dann zurückzugreifen, wenn Anhaltspunkte dafür sprechen, dass die zu verknüpfenden Relationen sortiert vorliegen, sobald dies also vermutet wird [6, S. 403]. Die Join-Implementierungen Double-Pipelined-Hash-Join und Sort-Merge-Join können also dauerhaft zu einer gemeinsamen, quasi übergeordneten Join- Implementierung zusammengefasst werden, zum sogenannten Complementary-Join-Pair : Datensätze werden entgegengenommen, mit einer der beiden Implementierungsvarianten verarbeitet, eine quasi interne Stitch-up-Phase wird durchgeführt und ein vollständiges Ergebnis

14 10. The Tukwila Data Integration System (Jan Engelkamp) 14 des Joins ausgegeben. Da das Complementary-Join-Pair als spezielle Join-Implementierung in Auswertungsplänen verwandt werden kann, wurde das Adaptive Data-Partitioning quasi von der Ebene der Auswertungspläne in die Implementierung von Datenbankoperatoren verlagert. Man benötigt nun keine alternativen Auswertungspläne mehr [6, S. 404]. Abbildung 3: Beispiel eines Complementary-Join-Pair [vgl. 6, S. 404] 5.2. Adaptive Data-Partitioning im Tukwila-System Alle bisher angesprochenen adaptiven Techniken und Methoden sind im Tukwila-System realisiert. Dies sind insbesondere die im Kapitel 4 genannten Ansätze, die Reihenfolge von Operatoren innerhalb von Auswertungsplänen zur Ausführungszeit umzustellen (Scheduling- Based-Methods), aus alternativen Auswertungsplänen zur Laufzeit einen besten auszuwählen (Redundant-Computation-Methods), Auswertungspläne zur Ausführungszeit zu modifizieren (Plan-Partitioning-Methods), sowie zur Ausführungszeit zu entscheiden, welche Daten wie verarbeitet werden (Data-Partitioning-Methods). Des weiteren sind spezielle adaptive Operatoren, wie dynamische Datenkollektoren und der Double-Pipelined-Hash-Join, aber auch das beschriebene Complementary-Join-Pair in Tukwila realisiert [6, S. 398]. Neuere Entwicklungen konzentrieren sich auf eine Umsetzung der verschiedenen Arten des Adaptive Data-Partitioning: Zum einen werden Daten parallel in alternativen Auswertungsplan- Fragmenten verarbeitet, wenn die Datenmenge gemäß einer Eigenschaft, die erfüllt oder nicht erfüllt ist, disjunkt partitioniert werden kann; die Fragmente werden in je eigenen Threads abgearbeitet. Zum anderen wird die Abarbeitung eines Auswertungsplans abgebrochen, wenn sich herausstellt, dass seine Effizienz mangelhaft ist, ohne jedoch die bereits berechneten Ergebnisse zu verwerfen [6, S. 398f]. Um die Aufteilung der Datenmenge auf mehrere Auswertungspläne vorzunehmen, wird in Tukwila ein spezieller Operator verwendet, ebenso, um aus Einzelergebnissen ein Gesamtergebnis zu konstruierten. Bedeutender jedoch ist die Implementierung der Operationen, die in Stitch-up-Phasen verwandt werden, sowie der Aufbau von Datenstrukturen, die es ermöglichen, in Stitch-up-Phasen auf ein Neulesen bereits verarbeiteter Daten zu verzichten. Darauf genauer einzugehen, würde jedoch den Rahmen der vorliegenden Arbeit sprengen. (Daher sei verwiesen auf 6, S. 398f.)

15 10. The Tukwila Data Integration System (Jan Engelkamp) Zusammenfassung und Diskussion Nachdem zu Beginn dieser Arbeit grundsätzliche Anforderungen beschrieben wurden, die an ein Data-Integration-System gestellt werden, wurden die Architektur und die Systemkomponenten das Data-Integration-System Tukwila eingehender vorgestellt. Dabei wurden bewusst die neuesten Entwicklungen zur Realisierung eines Adaptive Data-Partitioning zunächst ausgeblendet. Darauf wurde erst in Kapitel 5 eingegangen, nachdem zuvor einige zentrale adaptive Techniken detailliert diskutiert wurden. Es dürfte deutlich geworden sein, dass eine zunehmende Adaptivität bei der Anfrageausführung zu einer Zunahme der Komplexität sowohl einzelner Berechnungen, als auch des Gesamtsystems führt. Ein wichtiges und immer wieder genanntes Argument für die Entwicklung und Implementierung adaptiver Techniken ist die Feststellung, dass Data-Integration-Systems nur wenige, ungenaue und unzuverlässige Informationen über die Inhalte von Datenquellen wie etwa Relationen- Kardinalitäten oder Werteverteilungen in Relationen zur Verfügung stehen und dass deren Abschätzungen häufig fehlerhaft sind. Tukwila ist ein experimentelles System, das im Rahmen von Forschungsarbeiten entstanden ist und kontinuierlich weiterentwickelt wird. Tukwila ist nicht für einen konkreten Anwendungszusammenhang entworfen und enthält Implementierungen für allerlei adaptive Techniken. Intensive Messungen der Systemperformance sind Bestandteil der Veröffentlichungen über Tukwila [vgl. 4; 5; 6]. Fraglich scheint, inwieweit adaptive Techniken in konkreten Anwendungszusammenhängen angewandt werden und in welchen Bereichen ihnen welche (potentielle) Bedeutung zukommt. Fraglich scheint des weiteren, in welchen Anwendungszusammenhängen eine Verbesserung der Datenquellen hinsichtlich der Verlässlichkeit der von ihnen zur Verfügung gestellten Metadaten möglich ist und grob gesagt mit wie viel Aufwand dies verbunden wäre. Dies könnte u.u. eine kostengünstige und die Systemperformance geringer belastende Alternative zur Implementierung von Adaptivität in Data-Integration-Systems sein. Nach Ansicht des Autors stellen diese Überlegungen interessante Fragen an eine anwendungsnahe Wirtschaftsinformatik dar.

16 10. The Tukwila Data Integration System (Jan Engelkamp) 16 Literaturverzeichnis [1] Brian Babcock, Shivnath Babu, Mayur Datar, Rajeev Motwani, and Jennifer Widom. Models and Issues in Data Stream Systems. Proceedings of the 2002 ACM Symposium on Principles of Database Systems, ACM Press, [2] Volker Claus, Andreas Schwill. Duden Informatik. Ein Fachlexikon für Studium und Praxis. Dudenverlag, [3] Joseph M. Hellerstein, Michael J. Franklin. Sirish Chandrasekaran, Amol Deshpande, Kris Hildrum, Sam Madden, Vijayshankar Raman, and Mehul A. Schah. Adaptive Query Processing: Technology in Evolution. Bulletin of the IEEE Computer Society Technical Commitee on Data Engineering, 23(2): 7-18, [4] Zachary G. Ives, Daniela Florescu, Marc Friedmann, Alon Levy, and Daniel S. Weld. An adaptive query execution system for data integration. Proceedings of the 1999 ACM SIGMOD international conference on Management of data, ACM Press, [5] Zachary G. Ives, Alon Y. Levy, Daniel S. Weld, Daniela Florescu, and Marc Friedmann. Adaptive query processing for internet applications. Bulletin of the IEEE Computer Society Technical Commitee on Data Engineering, 23(2): 19-26, ftp://ftp.research-microsoft.com/pub/debull/a00jun-cd.pdf [6] Zachary G. Ives, Alon Y Halevy, and Daniel S. Weld. Adapting to source properties in processing data integration queries. Proceedings of the 2004 ACM SIGMOD international conference on Management of data, ACM Press, [7] Zachary G. Ives, Alon Y Halevy, and Daniel S. Weld. The Tukwila Data Integration System. [8] Gunter Schlageter. Datenbanken I. Grundlagen, Anwendungen und Konzepte. Studienmaterial der FernUniversität, Gesamthochschule Hagen, [9] Gunter Schlageter, Friedrich Kemper, Thomas Berkel, Wolfgang Wilkes und Michael Balzer. Datenbanken II. Fortgeschrittene Konzepte und Realisierungsaspekte. Studienmaterial der FernUniversität, Gesamthochschule Hagen, [10] Markus Schneider. Implementierungskonzepte für Datenbanksysteme. Studienmaterial der FernUniversität, Gesamthochschule Hagen, 1999.