Datenintegration am Beispiel der Bioinformatik. IBM DiscoveryLink. Manuel Klatt

Transkript

1 Datenintegration am Beispiel der Bioinformatik IBM DiscoveryLink Manuel Klatt Humboldt-Universität zu Berlin

2 Inhaltsverzeichnis 1 Datenintegration in der Bioinformatik IBM DiscoveryLink Grundlagen Wrapper Grundfunktionen eines Wrappers Daten-Einbindung Verhältnis Wrapper - DataSource - Tabelle Spezielle Funktionen der Datenquelle (UDFs) Anfrage-Ablauf Optimierung Dynamische Programmierung Einfache Optimierung in DiscoveryLink Genauere Optimierung in DiscoveryLink Joins in DiscoveryLink Join-Bearbeitung Join in der Datenquelle Join in DiscoveryLink Join zwischen zwei Datenquellen Planerstellung und Joins Geschwindigkeitsvergleich Zusammenfassung Ausblick IBM DiscoveryLink 2 von 22 Manuel Klatt

3 Abbildungsverzeichnis Abbildung 1: Aufbau DiscoveryLink [HKS+01]... 5 Abbildung 2: Database-Engine-Aufbau... 6 Abbildung 3: Verhältnis Wrapper:Datasource:Tabelle... 8 Abbildung 4: Dynamische Programmierung Abbildung 5: Ein Abarbeitungsmöglichkeit Abbildung 6: Eine weitere mögliche Abarbeitung Abbildung 7: Eine dritte Bearbeitungsmöglichkteit Abbildung 8: Plan Operators für Abarbeitung nach Abbildung Abbildung 9: Join in einer Datasource Abbildung 10: Join in DiscoveryLink zwischen zwei Datasourcen Abbildung 11: Bind-Join zwischen zwei Datensourcen Abbildung 12: Geschwindigkeitsvergleiche [HKS+01] IBM DiscoveryLink 3 von 22 Manuel Klatt

4 1 Datenintegration in der Bioinformatik Traditionell gibt es in der Biologie verschiedenste Datenbanken. Insbesondere in den letzten Jahren wurden im Bereich der Genforschung große Fortschritte, wie die Entschlüsselung des menschlichen Genoms, erzielt. Diese neuen Erkenntnisse haben zu einer großen Menge an Daten geführt, die in unterschiedlichsten Datenbanken und -formaten gespeichert wurden und werden. Beispiele hierfür sind die Datenbanken SWISSPROT und EMBL. Die Aufgabe der Bioinformatik ist es, Strukturen und Algorithmen zu schaffen, mit denen diese Datenmengen sinnvoll genutzt und Querbeziehungen zwischen ihnen hergestellt werden können. Dabei sollen zum Beispiel Anfragen wie: Gegeben sei ein Gen. Welche Lebewesen weisen dieses Gen auf? Zu welchen Aminosäuren und Proteinen wird es synthetisiert? Welche Bedeutung hat dieses Gen? beantwortet werden. Um Anfragen wie diese auszuführen, müssen die unterschiedlichen Quellen in Beziehung gesetzt werden. Als problematisch erweisen sich dabei die unterschiedlichen Formate der Quellen. Die meisten Daten liegen in Form von Textdateien vor, beziehungsweise in anderen nicht relationalen Formaten und sind deshalb ohne entsprechende Ergänzungen nicht mit heute gebräuchlichen relationalen Datenbanksystemen zu bearbeiten. Die Zugriffsschnittstellen sind sehr verschieden, zum Beispiel kann man auf wichtige Datenbanken wie SwissProt direkt über Webinterfaces zugreifen, für andere muss man SQL-Anfragen formulieren. Für eine Vereinfachung muss also ein allgemeines Interface entworfen werden, welches den zentralen Zugriff auf die verschiedensten Quellen gewährleistet, leichte Abfragemöglichkeiten bietet und, wenn möglich, eventuelle Duplikate entfernt. Aus diesem Grund wurden mehrere Systeme entwickelt, unter anderem das in dieser Arbeit näher betrachtete IBM DiscoveryLink. IBM DiscoveryLink 4 von 22 Manuel Klatt

5 2 IBM DiscoveryLink Grundlagen DiscoveryLink ist ein Produkt der Firma IBM, was speziell auf die Integration von Life Science - Daten ausgelegt ist. Es ist ein föderiertes System, das heißt, es stellt eine einheitliche Zugriffsstruktur für dem System bekannte Daten bereit. Die Daten bleiben dabei an ihrem ursprünglichen Ort, sie werden also nicht wie bei einem Datawarehouse in eine einzelne Datenbank integriert. Auch bleiben die Schemata unverändert, eventuelle semantische Unterschiede werden von DiscoveryLink nicht zusammengeführt. DiscoveryLink stellt somit nur ein System dar, was eine einheitliche Schnittstelle auf verteilte Datenquellen, die unterschiedlichste Formate und Interfaces haben können, bietet. Es ist modular aufgebaut und lässt sich mit geringem Aufwand für jede Datenquelle anpassen. Hervorgegangen ist DiscoveryLink aus mehreren Produkten und Projekten der IBM, zum einen aus dem IBM DB2 DataJoiner, welches Zugriffe auf unterschiedlichste relationale Datenbankmanagementsysteme erlaubt und zum anderen aus dem Forschungsprojekt Garlic. Garlic gab es als Researchprojekt seit In diesem Projekt sollte erforscht werden, wie Abfragen beliebiger Datenbanken gehandhabt werden können. Im Jahr 1997 wurden auf der Very Large Database Conference die Forschungsergebnisse veröffentlicht und parallel implementiert. Im Jahr 1999 wurde dann die erste Version von IBM DiscoveryLink vorgestellt, was jetzt ein Teil der IBM Produkte für Live Sciences ist. DiscoveryLink selbst ist ein Middleware-System. Es stellt eine Schicht zwischen der Anwendung, der Application, und den Datenquellen, den DataSources dar. Datasources sind dabei die verschiedensten Datenbanken, Textdateien und Webseiten. Jede dieser Sourcen ist durch spezielle Programme, die Wrapper, an die Middleware angebunden. Abbildung 1 verdeutlicht dies. Abbildung 1: Aufbau DiscoveryLink [HKS+01] IBM DiscoveryLink 5 von 22 Manuel Klatt

6 Das DiscoveryLink-System ist dabei ähnlich dem IBM DB2 System aufgebaut. Es enthält eine komplette Datenbank-Engine, Query Compiler, Execution Engine, System Catalog, Data Manager, Transaktions- und Buffermanager. Anfragen werden also syntaktisch und semantisch geprüft. Es wird geschaut wie und wo diese ausgeführt werden können, und anschließend werden sie realisiert. Wichtig hierbei sind die Anfrageoptimierungen und die dazu notwendige Kostenbetrachtung sowie die Verteilte Ausführung. Einen Grobaufbau der Middleware zeigt Abbildung 2. S y n tax und S em antik V iew B earbeitu n g Q uery O p tim ieru n g T ransak tio n - M anager A ccess M anager B u fferm anager Abbildung 2: Database-Engine-Aufbau Da die Middleware eine komplette DB-Engine enthält, kann diese natürlich auch mit Selektionen, Joins und Sortierungen umgehen und diese Funktionen in Abfragen nutzen, falls genutzte, darunter liegende Datenquellen diese nicht bereitstellen können. Ein denkbarer Fall sind einfache Textdateien. 3 Wrapper Wrapper sind die Bindeglieder zwischen der Middleware und den darunter liegenden DataSourcen. Sie stellen auf der einen Seite zur Middleware eine generische Schnittstelle bereit und kennen auf der anderen Seite die Spezifika der Datenquelle, wie spezielle Suchalgorithmen oder Zugriffsstrukturen. Ein Beispiel für einen solchen speziellen Suchalgorithmus ist: Eine vergleichende Suche, die spezielle Moleküle oder Radikale in chemischen Verbindungen finden kann. Dieser kann ähnlich einem LIKE in SQL angesehen werden. IBM DiscoveryLink 6 von 22 Manuel Klatt

7 3.1 Grundfunktionen eines Wrappers Jeder Wrapper muss dabei vier Grundfunktionen bereitstellen. Er muss die Daten zwischen dem DiscoveryLink-System und der Datasource mappen können. Das heißt, er muss die spezifischen Datenfelder und Datensätze liefern und auch die Datenformate konvertieren (zum Beispiel von Little-Endian auf Big-Endian). Eine weitere Aufgabe ist, dass er seine eigenen Fähigkeiten, beziehungsweise die der Datasource dem System bekannt macht. Wenn er Joins und ORDER- Statements ausführen kann, sollte DiscoveryLink dies wissen, um die Anfragepläne entsprechend zu optimieren. Für die eigentliche Anfrageausführung muss er die an ihn gestellten Anfragen (query fragments) in Anfragen an die Datasource umwandeln können. Soll eine Anfrage ausgeführt werden, muss er die Ausführung veranlassen und die entsprechenden Werte im entsprechenden Format zurückliefern. 3.2 Daten-Einbindung Wie funktioniert die Zusammenarbeit zwischen Datasource, Wrapper und DiscoveryLink? DiscoveryLink kann nur auf Datasourcen zugreifen, für die ihm explizit Wrapper angegeben werden. Dem System werden von IBM mehrere Wrapper mitgeliefert, beziehungsweise man kann diese gesondert erwerben. Diese werden aber nur nach entsprechender vorheriger Deklaration verwendet. Anhand der unten stehenden Aufgabe soll die Einbindung in das System gezeigt werden. Beispiel: Proteindatenbank proteindb befindet sich dem Server Port 1234, in der Version 1.0. Für diese Datenbank existiert auch ein passender Wrapper proteindb.a Um obige Beispieldatenbank in das System zu integrieren sind mehrere Schritte notwendig. Der erste ist, den Wrapper bei DiscoveryLink anzumelden. Dazu wurde die Sprache SQL um den Befehl CREATE WRAPPER erweitert. Die komplette Syntax dieses Befehls ist CREATE WRAPPER wrappername LIBRARY codebibliothek. Der Name des Wrappers kann beliebig gewählt werden, muss aber eindeutig sein. Codebibliothek gibt den Namen der Bibliothek an, die den Wrapper- Code enthält. Wrapper werden allgemein als dynamisch ladbare Bibliothekten geschrieben, die auf dem DiscoveyLink-Server im dortigen Speicherbereich des Programms ausgeführt werden. Damit wird der Overhead für den Aufruf der Wrapperfunktionen gering gehalten. Für das obige Beispiel ergibt sich zum Beispiel folgender Befehl: CREATE WRAPPER proteindbwrapper LIBRARY proteindb.a. Nach dem Ausführen dieses Befehls kennt DiscoveryLink zwar den Wrapper, hat jedoch noch keine Datenquelle assoziiert. IBM DiscoveryLink 7 von 22 Manuel Klatt

8 Datenquellen werden dem System mit dem CREATE SERVER Konstrukt bekannt gemacht. Die vollständige Syntax ist: CREATE SERVER datenquelle WRAPPER wrapper_fuer_datenquelle OPTIONS (NODE adresse, PORT port, VERSION version). Datenquelle ist der Name der Datenquelle, unter dem diese später im System angesprochen werden kann. Er kann beliebig, aber eindeutig gewählt werden. Wrapper_fuer_datenquelle bezeichnet den zu verwendenden Wrapper für diese Datenquelle. Es muss ein schon dem System bekannter Wrapper sein. Adresse gibt die Netzwerkadresse der Datenquelle an, zum Beispiel eine IP-Adresse oder ein entsprechender DNS-Name. Port ist der Port, unter dem die Datenquelle an Adresse angesprochen werden kann. Version gibt eine Versionsnummer an und kann für interne Abgrenzungszwecke gebraucht werden. Für das obige Beispiel könnte der folgende Befehl verwendet werden: CREATE SERVER proteinserver WRAPPER proteinwrapper OPTIONS (NODE PORT 1234 VERSION 1.0 ). Mit diesem Befehl wird die Datenquelle im System angemeldet. Es handelt sich um eine reine Datenquellen-Anmeldung, die Daten müssen explizit bekannt gemacht werden. Dies geschieht mit der CREATE NICKNAME Anweisung, die ähnlich dem CREATE TABLE Konstrukt aufgebaut ist. Die Syntax dieses Befehl ist: CREATE NICKNAME tablename (tabellen_struktur) SERVER datenquelle. Tablename ist der Name der Tabelle, der in SQL-Abfragen in der FROM - Klausel aufgeführt wird. Tabellen_Struktur ist eine Liste aus Spaltennamen und -typ, die diese Tabelle beschreibt. Datenquelle gibt an, von welchem Server diese Tabelle stammt. Mit diesen drei notwendigen Schritten ist eine Tabelle in DiscoveryLink registriert und kann dann in eigenen Abfragen genutzt werden. 3.3 Verhältnis Wrapper - DataSource - Tabelle Wrapper Datasource Datasource Table A Table B Table C Abbildung 3: Verhältnis Wrapper:Datasource:Tabelle IBM DiscoveryLink 8 von 22 Manuel Klatt

9 Das Verhältnis Wrapper : DataSource : Tabelle kann man kurz auf 1 : n : m zusammenfassen. Wrapper sind sehr spezifisch, jedoch können diese durchaus mehr als nur eine Datenquelle unter der Voraussetzung ansprechen, dass diese Datenquellen ähnlich in dem Sinne sind, dass sie die gleichen Interfaces verwenden. Zum Beispiel benötigt man nur einen Wrapper für alle Oracle Datenbanken, jedoch unterschiedliche für verschiedene Textdateiformate. Die meisten Datenquellen, insbesondere viele relationale Datenbanksysteme, enthalten mehr als eine Tabelle. Diese Tabellen können auch alle genutzt werden, sie müssen allerdings alle explizit einzeln eingebunden werden. 3.4 Spezielle Funktionen der Datenquelle (UDFs) Die Datenquellen in der Bioinformatik werden oft schon seit Jahren gepflegt. Zur einfacheren Handhabung und Effizienzsteigerung existieren häufig spezielle Suchalgorithmen oder Vergleichsoperatoren. Damit deren Funktionalität in Discovery- Link genutzt werden kann, müssen diese als Funktion eingebunden werden. Gleiches betrifft in anderen Systemen definierte USER DEFINED FUNCTIONS. Diese können durch den CREATE FUNCTION MAPPING Befehl DiscoveryLink bekannt gemacht werden. Die komplette Syntax dieses Befehls ist: CREATE FUNCTION MAPPING FOR spezial_function(type, type,...) RETURNS type SERVER servername. Spezial_function ist der Funktionsname, der gemappt wird, type sind die Datentypen, die als Argumente und als Resultat erwartet werden und servername ist die Datenquelle, in der diese Funktion ausgeführt wird. Nach dieser Einbindung können diese Funktionen in SQL-Select-Befehlen verwendet werden. 4 Anfrage-Ablauf IBM DiscoveryLink stellt als föderales System eine einheitliche Schnittstelle nach außen hin bereit. Man stellt an DiscoveryLink eine Anfrage und das System versucht dann, diese auszuwerten. Dabei werden die Anfragen zuerst vom Parser syntaktisch geprüft und auf semantische Eindeutigkeit untersucht. Hierzu schaut das System in seinem Systemkatalog nach, ob die angegebenen Tabellen angemeldet sind und ob die gewünschten Spalten existieren. Die angegebenen Tabellen können in einer Datenquelle existieren, aber sie werden nur gefunden, wenn sie, wie unter Punkt 3.2 beschrieben, angemeldet sind. In einem normalen relationalen Datenbankmanagementsystem werden danach die als korrekt eingestuften Anfragen durch einen Optimierer optimiert. DiscoveryLink besitzt auch einen Optimierer, muss allerdings anders als ein normaler Optimierer auf die verteilten Daten und die unterschiedlichen Eigenschaften der Quellen ein- IBM DiscoveryLink 9 von 22 Manuel Klatt

10 gehen. Dazu berücksichtigt das System bestimmte Parameter der Datenquellen, wie Prädikatsbehandlungen, CPU-Belastung, IO-Dauer und Join-Fähigkeiten. Unter Hinzuziehung dieser Parameter erstellt es Teilpläne, die von den Wrappern ü- bersetzt und ausgeführt werden können, beziehungsweise zu denen die Wrapper eine Kostenschätzung abgeben. Insgesamt wird die Aufteilung gewählt, die den kostenoptimalen Plan hat. Wie diese Pläne erstellt werden, ist unter Punkt 5 näher erläutert. 5 Optimierung 5.1 Dynamische Programmierung Allgemein funktioniert die Optimierung in Datenbanken nach dem Prinzip der dynamischen Programmierung, die ein Traversieren eines Baumes von den Blättern zur Wurzel darstellt. Dabei werden Anfragen in kleine Teile aufgespalten (das sind die Blätter), diese ausgeführt und die Kosten dafür ermittelt. Die Kosten sind in der Regel die IO-Kosten, da IO-Zugriffe wesentlich länger dauern, als Berechnungen der CPU. So erhält jeder Teilplan eine Kostenzuordnung. Im nächsten Schritt werden die im vorhergehenden Schritt berechneten Teilpläne zusammengefasst und die Kosten dafür ermittelt. Der kostenoptimale Plan wird behalten und die anderen Pläne werden verworfen. Diese Zusammenfassung wiederholt sich so oft, bis man die Wurzel erreicht hat. Die Wurzel stellt einen kompletten Anfrageplan dar, der entsprechend der Schrittfolge kostenoptimal ist. Abbildung 4 verdeutlicht diesen Vorgang. ABCD Endergebnis ABC BCD AB BC CD A B C D DataSourcen Abbildung 4: Dynamische Programmierung IBM DiscoveryLink 10 von 22 Manuel Klatt

11 5.2 Einfache Optimierung in DiscoveryLink Zu einer möglichen Anfrage gibt es mehrere ausführbare Pläne, welche dieselben Resultate liefern. Diese Vielfalt an Plänen entsteht durch die unterschiedlichen Kombinationsmöglichkeiten von Joins, der Reihenfolge der Filterungen, etc. In verteilten Systemen kann die Anzahl an möglichen Plänen noch größer sein, da jede Quelle unterschiedliche Anfragebearbeitungseigenschaften besitzt. Über diese muss die Middleware möglichst genau informiert werden, damit sie diese Eigenschaften bei der Planaufstellung berücksichtigen kann. Aus diesem Grund gibt es in DiscoveryLink zu jeder DataSource eine Server Attribute Table, in der die wichtigsten Eigenschaften der Quelle vermerkt sind. Dazu gehören PUSHDOWN, MAX_TABS, BASIC_PRED, CPU_RACIO und andere. PUSHDOWN steht dabei für die Möglichkeit, komplexere Anfragen an den Wrapper und damit an die DataSource weiterzureichen. Standardmäßig muss die Source die Daten nur liefern, aber keine Selektionen ausführen. Die Eigenschaft der Selektionsbehandlung wird über BASIC_PRED eingestellt. BASIC_PRED besagt, wie genau WHERE -Klauseln ausgeführt werden können. MAX_TABS impliziert die Anzahl an Joins, die die Source bearbeiten kann. Angegeben wird die maximale Anzahl an Tabellennamen (Nicknames), die die DataSource gleichzeitig in einer Teilanfrage abarbeiten kann. Der Standardwert ist 1, die Source kann also nur auf eine Tabelle gleichzeitig zugreifen und somit keine Joins durchführen. CPU_RACIO ist wichtig für die Kostenplanung. Damit wird die notwendige Bearbeitungszeit pro Datensatz angegeben. CPU_RACIO multipliziert mit der Kardinalität ergibt also die Kosten (unter Berücksichtigung der Netzwerkkosten). Bearbeitungszeiten können auch explizit zu User Defined Functions angegeben werden, wobei hier ein einfacher Wert nur als grobe Schätzung dienen kann. Eine weitere wichtige Optimierungshilfe ist der Systemkatalog, in dem für jede Tabelle auch statistische Daten abgelegt werden können. Über diese Daten kann dann zum Beispiel mittels Histogrammen eine Verteilung der Daten geprüft und die zu erwartende Kardinalität ermittelt werden. Anhand dieser Einstellungen kann das System grob Abschätzungen über die Fähigkeiten der darunter liegenden Schichten durchführen, entsprechende Kosten kalkulieren und günstige Anfragepläne entwickeln. Diese Aussage gilt insbesondere für RDBMS, jedoch nicht unbedingt für spezifischere Datenquellen, wie sie in der Bioinformatik anzutreffen sind. 5.3 Genauere Optimierung in DiscoveryLink Problematisch ist die Mannigfaltigkeit der Datenquellen. Bestimmte Datenquellen erlauben zum Beispiel Suchen nur auf einigen ihrer Attribute (Spalten), oder die Kosten basieren auf einem bestimmten Funktionswert, der vorher nicht geschätzt werden kann. Diese Kosten und Eigenschaften sind schlecht mit fixen Parametern ausdrückbar. IBM DiscoveryLink 11 von 22 Manuel Klatt

12 Aus diesem Grund müssen diese Daten in variableren Parametern stehen. Das Garlic Forschungsteam nutzte dazu einen Ansatz, der schon in IBM DB2 zur Anwendung kommt: STARs und POPs. STARs sind Strategy Alternative Rules, also Regelalternativen, die strategisch angewandt werden, um optimale Anfragepläne zu erstellen. Dabei bedient man sich der Plan Operators (POPs). Die Plan Operators sind die einzelnen Operatoren und stellen in der dynamischen Programmierung (skizziert unter Punkt 5.1) die Knoten dar. Es gibt insgesamt 6 verschiedene POPs: Project, Join, Sort, Filter, Fetch und PushDown. Ein Project- POP bearbeitet Projektionen, also das beschränken auf bestimmte Attribute (entspricht dem SELECT attributname). Ein Join-POP dient der Join-Bearbeitung, Sort dem Sortieren der Attribut-Werte (entspricht dem ORDER BY aus SQL) und Filter dem Selektieren und anwenden einzelner Prädikate (entspricht WHERE attributname = wert). Fetch dient dem Holen von Daten aus Datenquellen und PushDown dem Pushen von Anfragen in die DataSource. Jeder POP hat ein bestimmte Grundstruktur, die im wesentlichen aus mehreren Parametern besteht. Konkret sind dies Table, Columns, Preds, Source, Order, Cost und Cardinality. Die Parameter sind Listen, sie können auch mehr als einen Wert enthalten. Über das Setzen dieser Parameter wird dem Wrapper und damit der DataSource mitgeteilt, welche Teilanfrage bearbeitet werden soll. Der Wrapper übergibt auf dem selben Weg seine Planerstellungsergebnisse zurück an DiscoveryLink. In Source wird gespeichert, woher die entsprechenden Daten stammen, beziehungsweise wer diesen POP ausführt. In Table werden die in der Anfrage verwendeten Tabellen aufgeführt. Da es sich bei den Parametern um Listen handelt, können also auch mehrere Tabellen aufgeführt werden. Columns sind die zu projizierenden Spalten, beziehungsweise die Werte, die benötigt werden. Preds sind die anzuwendenden Filter und Order die mögliche einzuhaltende Sortierung. Cost und Cardinality werden hauptsächlich vom Wrapper zurückgegeben. In diesen gibt der Wrapper seine Abschätzung der Datensatzanzahl und der dafür notwendigen Kosten an. Diese Kosten sind wesentlich genauer als die vorher geschätzten Kosten, da der Wrapper so direkt, die von ihm gelieferte Menge an Datensätzen und auch die dafür notwendigen Kosten angibt. STARs sind die Regeln, nach denen die POPs angeordnet werden. Ein STAR gibt zum Beispiel an, dass ein Join und eine Selektion getauscht werden können, wenn dabei nicht Tupel entfallen, die für den jeweiligen anderen POP noch notwendig sind. Ein STAR besagt auch, dass wenn auf einem Attribut einen Join ausgeführt werden soll, muss dieses auch geladen sein. Ein Beispiel eines so erstellten Plans aus Plan Operators soll dies verdeutlichen. Gegeben sei folgende Anfrage: Welches Protein aus proteindb enthält das Gen g aus gendb und ist ein Gen der Spezien sp1 und sp2? Proteindb.genIndex enthält den entsprechenden Verweis auf Gendb und Gendb.speciesIndex den Verweis auf die SpeciesDb. Die Anfrage in SQL ist: IBM DiscoveryLink 12 von 22 Manuel Klatt

13 SELECT protein FROM proteindb JOIN gen ON protein.genindex = gen.id JOIN speciesdb ON gendb.speciesindex = species.id WHERE gen.name = g AND (species.name = sp1 OR species.name = sp2) Für diese Anfrage gibt es mehrere Abarbeitungsmöglichkeiten. Drei mögliche sind in Abbildung 5, Abbildung 6 und Abbildung 7 dargestellt. Ergebnis Selektion Join Join proteindb gendb speciesdb Abbildung 5: Ein Abarbeitungsmöglichkeit Ergebnis Unterschiede bestehen im Zeitpunkt der Selektion, also des Vergleichs WHERE species.name = sp1 OR species.name = sp2. Es können erst die Joins ausgeführt werden, oder erst selektiert werden. Eine frühere Selektion ist in der Regel günstiger, da dadurch die Anzahl an zu ü- bertragenden Tupeln reduziert wird. Eine Änderung der Join-Reihenfolge ist analog von Vorteil sein, wenn sich die Anzahl an zu übertragenden Tupeln reduziert. Join Join Selektion Selektion proteindb gendb speciesdb Abbildung 6: Eine weitere mögliche Abarbeitung Ergebnis Join Join Selektion Selektion proteindb gendb speciesdb Abbildung 7: Eine dritte Bearbeitungsmöglichkteit IBM DiscoveryLink 13 von 22 Manuel Klatt

14 Tables: Columns: Preds: Source: Order: Project {proteindb, gendb, speciesdb} {proteindb.protein} {proteindb.genindex=gendb.id, gendb.speciesindex=species.id, gen.name = g, species.name = sp1 or species.name = sp2 {DiscoveryLink} NIL Tables: Columns: Preds: Source: Order: Join {proteindb, gendb, speciesdb} {proteindb.protein, proteindb.genindex, gendb.id, gendb.name, species.name, species.id, gendb.speciesindex} {proteindb.genindex=gendb.id, gendb.speciesindex=species.id, gen.name = g, species.name = sp1 or species.name = sp2 {DiscoveryLink} NIL Tables: Columns: Preds: Source: Order: Join {proteindb, gendb} {proteindb.protein, proteindb.genindex, gendb.id, gendb.name, gendb.speciesindex} {proteindb.genindex=gendb.id, gen.name = g } {DiscoveryLink} NIL Tables: Columns: Preds: Source: Order: Filter {speciesdb} {species.name, species.id, gendb.speciesindex} {species.name = sp1 or species.name = sp2 {DiscoveryLink} NIL Filter Tables: {gendb} Columns: {gendb.id, gendb.name } Preds: {gendb.name = g} Source: {DiscoveryLink} Order: NIL PushDown Tables: {proteindb} Columns: {proteindb.protein, proteindb.genindex } Preds: { } Source: {proteindbsource} Order: NIL PushDown Tables: {gendb} Columns: {gendb.id, gendb.name, gendb.speciesindex } Preds: { } Source: {gendbsource} Order: NIL PushDown Tables: {speciesdb} Columns: {speciesdb.id, speciesid.name } Preds: { } Source: {speciesdbsource} Order: NIL Abbildung 8: Plan Operator Baum für Abarbeitung nach Abbildung 7 IBM DiscoveryLink 14 von 22 Manuel Klatt

15 6 Joins in DiscoveryLink 6.1 Join-Bearbeitung Nicht jede Datenquelle unterstützt Joins. Textdateien haben in der Regel nur begrenzte Anfragebearbeitungsmöglichkeiten - meist können diese nur sequentiell durch ihren Datenbestand gehen, aber keine Joins durchführen. Andere Datenbanksysteme, wie zum Beispiel RDBMS, hingegen können sehr gut mit Joins umgehen. Im hier aufgezeigten Kontext sind Joins essentiell, da nur über Joins ein In- Beziehung- Setzen der verschiedenen Datenquellen funktioniert. Das Ziel ist, unterschiedliche, sich ergänzende Daten zu verknüpfen und dadurch zu anderen Aussagen zu gelangen oder neue Kenntnisse zu gewinnen. Zum Beispiel können Proteindatenbanken mit Protein-3D-Struktur-Datenbanken und gleichzeitig mit den sie erzeugenden Gen-Sequenzen verknüpft sein. Für derartige Anfragen werden Joins benötigt. Wie bereits angeführt, stellt nicht jede Datenquelle Join- Funktionalität bereit. Aus diesem Grund enthält DiscoveryLink einen eigenen Joiner, der viele aus RDBMS bekannte Joins implementiert und diese demzufolge auch schnell ausführen kann. Das Problem dabei liegt jedoch in den verteilten Datenquellen, die zum Teil über langsame Netzwerke angebunden sind. Das Ziel ist daher, die Joins wenn möglich in den Datenquellen auszuführen und den Netzwerkverkehr zu minimieren. Prinzipiell gibt es drei Arten von Joins, die sich im Ort ihrer Ausführung unterscheiden: A) Join in der Datenquelle B) Join in DiscoveryLink C) Join zwischen 2 Datenquellen IBM DiscoveryLink 15 von 22 Manuel Klatt

16 6.2 Join in der Datenquelle Die folgende Grafik veranschaulicht den Join in der Datenquelle. 100 Tupel Gejointe Daten Discovery- Link DS 1000 Tupel Tupel Table 1 Join Table 2 Angefragte Daten Abbildung 9: Join in einer Datasource Hierbei wird eine Anfrage über zwei Tabellen, die in der gleichen Quelle liegen, durchgeführt. Dabei liefert die eine Tabelle 1000 Tupel und die andere Diese Tupel werden entsprechend dem Join-Prädikat gejoint und das Ergebnis, 100 Tupel, wird an DiscoveryLink ausgegeben. Der verwendete Join-Algorithmus wird von der Datenquelle ausgewählt und kann von DiscoveryLink nicht bestimmt oder beeinflusst werden, was von Vorteil ist, da die Datenquelle die Datenverteilung und Kardinalität kennt und entsprechende angepasste Algorithmen wählen kann. Die Vorteile dieser Lösung sind, dass nur noch die gejointen Daten übertragen werden, was das Netzwerk entlastet und vor allem schneller ist, und optimierte Algorithmen in der Datenquelle verwendet werden. IBM DiscoveryLink 16 von 22 Manuel Klatt

17 6.3 Join in DiscoveryLink Wenn eine Datenquelle keine Joins ausführen kann, müssen diese von Discovery- Link durchgeführt werden. Die folgende Grafik schematisiert den Sachverhalt. Angefragte Daten Discovery- Link 1000 Tupel Join Tupel DS DS Table 1 Table 2 Abbildung 10: Join in DiscoveryLink zwischen zwei Datasourcen Hierbei wird eine Anfrage über zwei Tabellen, die in unterschiedlichen Quelle liegen, durchgeführt. Dies ist analog dem Fall, dass eine Quelle zwei Tabellen besitzt, aber keine Join- Funktionalität aufweist. Die eine Tabelle liefert wiederum 1000 Tupel und die andere Diese Tupel müssen an DiscoveryLink geschickt werden, dessen Join- Engine diese Tupel dann entsprechend dem Join- Prädikat joint und das Ergebnis, 100 Tupel, ausgibt. Der verwendete Join- Algorithmus wird dabei von DiscoveryLink gewählt und kann entsprechend den im Systemkatalog von DiscoveryLink gespeicherten Daten optimal ausgesucht werden. Dabei können diese Joins durch gute Algorithmenwahl auch schnell ausgeführt werden, insbesondere da DiscoveryLink Join-Algorithmen enthält, die zum Teil auch in älteren RDBMS noch nicht verfügbar sind. Der eindeutige Nachteil dieser Lösung ist der erhöhte Netzwerkverkehr. Es müssen Tupel übertragen werden, im Gegensatz zu den 100 im vorigen Fall. 6.4 Join zwischen zwei Datenquellen Die DiscoveryLink- Entwickler haben aus diesem Grund eine sich Bind- Join nennende Lösung entwickelt. Das Ziel dabei ist, Daten von einer Quelle zu einer anderen zu schicken, diese mit dem dortigen Join- Prädikat zu joinen und das Ergebnis auszugeben. IBM DiscoveryLink 17 von 22 Manuel Klatt

18 Die folgende Grafik veranschaulicht dies. Angefragte Daten 1000 Tupel 100 Tupel Discovery- Link 1000 Tupel 100 Tupel DS DS Join Table 1 Table 2 Abbildung 11: Bind-Join zwischen zwei Datensourcen Hierbei werden aus Table 1 wiederum 1000 Tupel gelesen und über das Netzwerk (mit oder ohne DiscoveryLink als Zwischenempfänger) an die zweite Datenquelle gesendet. Diese joint diese Daten anhand des Join- Prädikats mit ihren eigenen Daten und schickt das Ergebnis, 100 Tupel, an DiscoveryLink. Der große Vorteil ist, dass dabei nur 1100 Tupel übertragen werden müssen, das Netzwerk entlastet wird und geringe Übertragungskosten (zeitlich betrachtet) anfallen. Der Nachteil ist, dass dieser Bind-Join vielfältigste Anfragepläne hervorruft, da zum Beispiel auch die Daten aus Table 2 an Table 1 geschickt hätten werden können. Diese Art von Join muss auch explizit vom Wrapper unterstützt werden, was zusätzlichen, aber bei Bedarf lohnenswerten Implementationsaufwand bedeutet. 6.5 Planerstellung und Joins DiscoveryLink versucht, diese verschiedenen Join- Algorithmen in der Anfrageplanerstellung zu berücksichtigen. Strukturell funktioniert dies über die Plan Operators, die übersetzt und ausgeführt werden. Dabei kann ein Join-POP entsprechend den gegebenen Möglichkeiten in eine der drei prinzipiellen Join-Varianten umgesetzt werden. Wie schon angeführt, besitzen Wrapper dem DiscoveryLink- System gegenüber eine generische Schnittstelle. Für die Join- Behandlung bieten diese prinzipiell drei Funktionen: plan_access(), plan_join() und plan_bind(). Diese werden IBM DiscoveryLink 18 von 22 Manuel Klatt

19 aufgerufen und erhalten als Funktionsparameter die Anfragefragmente, die dieser Join benötigt. Der Wrapper und über ihn DiscoveryLink oder die entsprechenden Datenquellen berechnen daraufhin ein Ergebnis, was der Abarbeitungsfähigkeit entspricht. Sie liefern den Wert 0 zurück wenn sie diese Anfrage so nicht ausführen können - dies kann bei plan_join() und plan_bind() der Fall sein, oder bei einer Zahl größer 0, welche die Anzahl der möglichen Pläne darstellt. Hierbei werden zuerst 2- Wege-Joins (ein Join zweier Daten) und danach eventuelle weitere Pläne mit 3- Wege-Joins (ein Join über drei Daten) berechnet. Auf diese Weise erhält der Optimierer eine große Anzahl an möglichen Joins, die sich insbesondere durch den Bind- Join und dessen vielfältige Zusammenstellung ergibt. Als Beispiel sei die Reihenfolge genannt: erst Datenquelle 1 mit Datenquelle 2 oder Datenquelle 2 mit Datenquelle 1, beziehungsweise bei 3-Wege-Joins erst Datenquelle 1 mit Datenquelle 2 und das Ergebnis mit Datenquelle 3, gleich Datenquelle 1 mit Datenquelle 2 und Datenquelle 3, oder Datenquelle 2 erst mit Datenquelle 3 und dann mit Datenquelle 1, etc. Dieses kurze Beispiel verdeutlicht die vielen verschiedenen Möglichkeiten, die dann auch noch durch die verschiedenen Join- Algorithmen erhöht werden. Aus diesem Grund sind Kardinalitätsabschätzungen und Kostenfunktionen sehr wichtig. Nur damit können schnell aus der großen Anzahl an Möglichkeiten die optimalen gefunden werden und auf der nächsthöheren Ebene mit nur einer oder wenigen Möglichkeiten gerechnet werden. Das Problem ist an diesem Punkt analog zu den Optimierungsproblemen im Standard-RDBMS zu sehen. IBM DiscoveryLink 19 von 22 Manuel Klatt

20 7 Geschwindigkeitsvergleich Untersuchungen von IBM [HKS+01] haben gezeigt, dass DiscoveryLink bei Anfragen auf lokale RDBMS nur geringfügig schlechter ist als eine Anfrage direkt auf diese Systeme. Es erzeugt also keinen größeren Overhead. In Einzelfällen sind die Abfragen, wahrscheinlich aufgrund eines eventuell besseren Cachings oder schnellerer Join- Algorithmen sogar schneller abgearbeitet als durch das Originalsystem direkt. Die folgende Tabelle, entnommen aus [HKS+01] zeigt diesen Vergleich anhand von 10 Skripten, die auf ein Standard RDBMS und auf DiscoveryLink ausgeführt wurden. Abbildung 12: Geschwindigkeitsvergleiche [HKS+01] 8 Zusammenfassung DiscoveryLink dient der Abfrage verteilter, heterogener Datenquellen. Das System ist modular aufgebaut, es können nahezu beliebige Datenquellen über entsprechende Wrapper hinzugefügt werden. Diese müssen entsprechend selbst angepasst werden, oder können bei IBM beziehungsweise Dritten käuflich erworben werden. Der Erstellungsaufwand eines Wrappers variiert je nach Anspruch. Bei hoch optimierten Wrappern treten beim Zugriff auf lokale, relationale DBMS keine Geschwindigkeitsverluste zu Tage, man hat aber den Vorteil, gleichzeitig auf entfernt liegende andere Datenquellen transparent zuzugreifen, wenn diese eingebunden sind. Vorhandene Applikationen, welche die bestehenden Datenquellen nutzen, werden nicht beeinträchtigt, da die Daten und deren Struktur nicht verändert werden. IBM DiscoveryLink 20 von 22 Manuel Klatt

21 9 Ausblick Im Forschungsprojekt Garlic wurden schon Eigenschaften eingebaut, die so im fertigen Produkt noch nicht implementiert sind. Dazu zählen insbesondere Update und Insert Anweisungen, sowie eine weitergehende Einbeziehung des Wrappers in die Anfrageplanerstellung. Diese Eigenschaften sollen in einer späteren Version von IBM DiscoveryLink eingebaut sein. Des weiteren bietet die Firma IBM noch zusätzliche Software zur Nutzung mit DiscoveryLink an, insbesondere vordefinierte Wrapper und Programme zur Datenübernahme nach DiscoveryLink. IBM DiscoveryLink 21 von 22 Manuel Klatt

22 Literaturverzeichnis [HKWY97] L.M. Haas, D. Kossmann, E.L. Wimmers and J. Yang. Optimizing Queries across Diverse Data Sources. 23rd Conference on Very Large Database Systems, Athens, Greece, 1997 [HSK+01] [RS97] L.M. Haas, P.M. Schwarz, P. Kodali, E. Kotlar, J. Rice and W.C. Swope. DiscoveryLink: A System for Integrated Access to Life Sciences Data Sources. IBM Systems Journal, 40 (2): , 2001 M.T. Roth, P. Schwarz. A Wrapper Architecture for Legacy Data Sources. Proc. VLDB Conference, 1997 IBM DiscoveryLink 22 von 22 Manuel Klatt