Interoperable Informationssysteme - 1 Klemens Böhm Systeme 4: Query Processing in heterogenen Umgebungen.

Präsentation zum Thema: "Interoperable Informationssysteme - 1 Klemens Böhm Systeme 4: Query Processing in heterogenen Umgebungen."—  Präsentation transkript:

1 Interoperable Informationssysteme - 1 Klemens Böhm Systeme 4: Query Processing in heterogenen Umgebungen

2 Interoperable Informationssysteme - 2 Klemens Böhm Einleitung l Gliederung: u Implementierung, u Infrastruktur. Einleitung Implement. Infrastruktur

3 Interoperable Informationssysteme - 3 Klemens Böhm Adaptives Query Processing - Motivation l Queryoptimierung, wie bisher vorgestellt, erfordert genaue Kosteninformation. l Derartige Information ist, insbesondere in verteilten Systemen, oft nicht verfügbar, bzw. können die Werte sich im Laufe der Zeit ändern. l Noch genauere Kostenbetrachtung: schwierig, löst das zweite Problem nicht. l Alternatives Paradigma: Adaptivität, d.h. Queryplan passt sich zur Laufzeit an veränderte Gegebenheiten an. l Implementierung der Query-Operatoren muss erweitert werden. Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

4 Interoperable Informationssysteme - 4 Klemens Böhm First-Few Queries, Top-n Queries l Top-n Query – man ist nur an den ersten n Tupeln interessiert. l Oft merkt man erst während Queryevaluierung, nach Inspektion der ersten Tupel, dass man den Rest nicht sehen will. l Nicht nur Antwortzeit, auch Zeit bis zur Ausgabe der ersten Tupel – wichtiges Kriterium für Query Planning. Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

5 Interoperable Informationssysteme - 5 Klemens Böhm Eigenschaften des Join-Operators l Tupel von zwei Streams werden miteinander verknüpft, z.B. Equijoin. l Varianten (auf Ebene der Implementierung): u Nested-Loop, u Sort-Merge, u Hash-basiert. Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

6 Interoperable Informationssysteme - 6 Klemens Böhm Illustration Nested-Loop Join, Equijoin Relation A Relation B Join-Attribute 28 Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

7 Interoperable Informationssysteme - 7 Klemens Böhm Beispiel l Queryplan: l Ist unter den gegebenen Umständen möglicherweise nicht gut, besser wäre vielleicht l Ziel: Umschalten auf besseren Plan, sobald klar, dass aktueller Plan nicht optimal. l Im folgenden zunächst: Vertauschung Operatorreihenfolge eines Joins. A B C B C A Situation: Alles wartet auf A. B C liefert vielleicht mit ähnlicher Rate wie A Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

8 Interoperable Informationssysteme - 8 Klemens Böhm Vertauschen der Operatorreihenfolge beim (Nested Loop-)Join Illustration: l Moments of Symmetry – Join-Operatoren können vertauscht werden. l Äusserer Loop beginnt an Position in der Relation. 28 Relation A Relation B Rela- tion A Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

9 Interoperable Informationssysteme - 9 Klemens Böhm Vertauschung Operatorreihenfolge l Man stellt fest, dass Lesen von B teurer als erwartet. l First-Few Queries. Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

10 Interoperable Informationssysteme - 10 Klemens Böhm Hash Join l Standardvariante hat keine Moments of Symmetry. l Aufbauen der Hash-Tabelle nicht nur für eine Relation, sondern für beide. l Illustration: Zwei Massnahmen bei neuem Tupel: 1. Vergleich mit Hash-Tabelle für andere Relation, 2. Eintrag in Hash-Tabelle (für diese Relation). l Mögliches Problem: Speicherplatz reicht nicht für beide Hash-Tabellen. 28 Relation A Relation B Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

11 Interoperable Informationssysteme - 11 Klemens Böhm Umschalten auf anderen Plan l Ist zu jedem Moment of Symmetry möglich. l Illustration für drei Relationen: C B A Einleitung Implement. - Motivation - Join- Implement. Infrastruktur

12 Interoperable Informationssysteme - 12 Klemens Böhm Infrastruktur für Information Integration l Ziel: Implementierung unserer Referenzarchitektur unter Verwendung von Standard-Werkzeugen. l CORBA und die Common Object Services Specification, insbesondere der CORBA Object Query Service (OQS), bieten sich an. l Gliederung im folgenden: u Alternativen für den Zugriff auf persistente Daten mit CORBA (auch OQS) u CORBA Performance-Flaschenhälse u Harmony: Unsere Implementierung des CORBA Object Query Service u Evaluierung u Schlussbemerkungen Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

13 Interoperable Informationssysteme - 13 Klemens Böhm Three-Tier Architektur: Client/Server/Middleware l Middleware: u Software Layer zwischen Client und Server u Versteckt Verteilung und Heterogenität: Location und Implementation Transparency, u Services auf Systemebene. l Wichtige Standards: u CORBA u DCOM Middleware Client Program Server Program Server Program Server Program(s) Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

14 Interoperable Informationssysteme - 14 Klemens Böhm CORBA – Beispiel für Interface interface Customer { readonly attribute long Key; readonly attribute string Name; readonly attribute string Address; readonly attribute nation Nation; readonly attribute string Phone; readonly attribute float AccountBalance; readonly attribute market MSegmnt; readonly attribute string Comment; sequence orders(); }; interface CIS { Customer access(in string name); sequence addrs (in string mseg); }; Schnittstellendefinition enum nation { Algeria, Argentina,... }; enum market { Automobile, Building,... }; struct Order { long OrderId; string Date; float Price; string Priority; char Status; string Clerk; string Comment; }; Datentypdefinition Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

15 Interoperable Informationssysteme - 15 Klemens Böhm CORBA - Konzepte/Konstrukte/Primitive l Anwender spezifiziert Signatur der Objekte in sog. Interface Definition Language (IDL); IDL ist CORBA-spezifische Sprache, keine Programmiersprache. l Compiler generiert Skeletons und Stubs: u Skeletons: Methodensignatur in der Programmiersprache, in der die Methoden implementiert werden, u Stubs: Proxies in Client-Programmiersprache. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

16 Interoperable Informationssysteme - 16 Klemens Böhm CORBA - Architektur Server Source Client Server Source Server Source ORB Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

17 Interoperable Informationssysteme - 17 Klemens Böhm Verwandte Arbeiten Query Processing in heterogenen Umgebungen: l DISCO, Verso (INRIA) l Garlic (IBM Almaden) l TSIMMIS (Stanford) l OLE/db (Redmond) Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

18 Interoperable Informationssysteme - 18 Klemens Böhm Zugriff auf persistente Daten in einer CORBA Umgebung Wie greift man über CORBA auf persistente Daten zu? 1. Enkapsulierung als CORBA Objekt, Persistenz via u Object-Oriented Database Adapter (OODA) –Grundidee: OODB-Objekte über CORBA ansprechen, –kompliziert, ineffizient (zuviele Aufrufe für ein Objekt), u Persistent Object Service (POS) oder u ORB-spezifische Mechanismen. 2. Deklarativer Zugriff, Object Query Service (OQS) Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

19 Interoperable Informationssysteme - 19 Klemens Böhm CORBA Object Query Service Objekttypen des OQS gemäss der CORBA Common Object Service Specification CORBA OQS spezifiziert im wesentlichen Interface und Struktur der Ergebnisse sowie die Tatsache, dass Queryevaluierung mit Iteratorkonzept. Harmony hat diese Definitionen intern wiederverwendet, leichte Abweichungen von der OQS-Spezifikation. QueryEvaluator ql_type : QLType evaluate() Collection cardinality : long create_iterator() Iterator next() reset() iterates CollectionFactory create() creates QueryableCollectionFactory creates QueryManager create() Query prepare() execute() get_result() QueryableCollection create() Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

20 Interoperable Informationssysteme - 20 Klemens Böhm CORBA Object Query Service QueryEvaluator ql_type : QLType evaluate() Collection cardinality : long create_iterator() Iterator next() reset() iterates CollectionFactory create() creates QueryableCollectionFactory creates QueryManager create() Query prepare() execute() get_result() QueryableCollection create() Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss QueryFactory z.B. Parsen der Query, Queryverarb. kein Query- Processing

21 Interoperable Informationssysteme - 21 Klemens Böhm CORBA Object Query Service l Methode evaluate() ist zentral. l Implizite vs. explizite Kollektionen (implizite Kollektionen materialisieren ihre Elemente). Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

22 Interoperable Informationssysteme - 22 Klemens Böhm CORBA - Factories l CORBA-Factories: Objekte, die Konstruktor-Methode für eine Klasse implementieren. l Konvention bei Namensgebung: Factory Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

23 Interoperable Informationssysteme - 23 Klemens Böhm Probleme beim Datenaustausch mit CORBA Methodenaufrufen l Synchrones Kommunikationsmodell – ist Standard mit CORBA, l Alternative wäre: Message-basiertes Interface. Aufwendig (Antwortschnittstelle publizieren). l Marshalling/Demarshalling mit jedem Methodenaufruf, l Hohe Latency, d.h. hohe Fixkosten unabhängig vom Datenvolumen; l Folgerung: Transport vieler Datenobjekte teuer. Object Request Broker Request Answer Client CIS->get_customer(Ebner) Proxy Object Server get_customer(char* n) { … } CIS Object Skeleton Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

24 Interoperable Informationssysteme - 24 Klemens Böhm Illustration des Problems CORBA ClientCORBA ServerStorage System get_customer(Ebner) EXEC SQL FETCH … INTO …;... Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

25 Interoperable Informationssysteme - 25 Klemens Böhm Harmony: Unsere Implementierung des CORBA OQS l Verteilte Query Engine basierend auf der CORBA OQS Spezifikation, d.h. Schnittstellen von OQS l Deklarativer Zugriff auf Datenmengen, l Ermöglicht Queries über mehrere Kollektionen, l Kann auf heterogene Repositories zugreifen, l Ergänzt CORBA so, dass o.g. Features möglich sind. Im folgenden: l Querypläne in verteilter, heterogener Umgebung (weitgehend unabhängig von Harmony; vier Folien) l Lösung der CORBA-Performance-Probleme mit Harmony (eine Folie) l Rolle der OQS-Schnittstellenspezifikation, l Architektur (eine Folie), l Nicht: Queryplanerzeugung. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

26 Interoperable Informationssysteme - 26 Klemens Böhm Beispiel-Query Query über mehrere heterogene Repositories: SELECT customer.Name FROM line IN OrderFile, customer IN Customers, order IN Orders WHERE line.Num[0] = order.OrderKey AND customer.CustKey = order.CustKey Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

27 Interoperable Informationssysteme - 27 Klemens Böhm Möglicher Plan OrdersCustomers OrderFil e l Query Algebra u Projektion, u Selektion, u Sortierung, u Join, u Union, … l Ausführung: Pipelining zwischen den Operatoren Dieser Plan legt nicht fest, wo (von welcher Komponente) welcher Operator ausgeführt wird. Diese Information muss in verteilter Umgebung Teil des Plans sein. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

28 Interoperable Informationssysteme - 28 Klemens Böhm Erweiterung der Query Algebra l Nicht speziell für Harmony/CORBA, andere Infrastrukturen funktionieren genauso, z.B. Garlic. l Meta-Operatoren: Modifizieren den Data Stream nicht, haben aber irgendeine Kontrollfunktion. Zugriff auf heterogene Repositories: wrap Meta-Operator ( ) u Abstrahiert von zugrundeliegenden Storage Systemen, u stellt einfaches scan/iterator Interface zur Verfügung, übersetzt Subquery in lokale Querysprache (wenn entsprechende Queryevaluierungskapazitäten vorhanden), d.h. hat als Parameter ID einer Source, u übersetzt das Resultat in das Typsystem von Harmony, u heisst push-down in Garlic. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

29 Interoperable Informationssysteme - 29 Klemens Böhm Erweiterter Execution Plan OrdersCustomersOrderFil e FileSys RDBMS OQS RDBMS File System Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

30 Interoperable Informationssysteme - 30 Klemens Böhm Harmony: Integration von Sourcen Wrapper - Aufgaben: l Verwalten der Verbindungen zum Repository, l Umwandlung von OQS-Queries in lokale Querysprache, l Konvertierung der Ergebnisse. Drei Objekte müssen implementiert werden: l WrapperFactory, l QueryableCollection: implementiert wrap, l Iterator: eigentlicher Datenzugriff. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

31 Interoperable Informationssysteme - 31 Klemens Böhm Send/Receive Meta-Operatoren FileSys RDBMS Client receive send... l Lösung der Performance Probleme: send /receive Meta- Operatoren u Bulk Transfer: Daten werden in Chunks ausgetauscht, kein wirklicher Dataflow, Granularität frei definierbar, u Intra-Query Parallelism: send generiert nächste Menge von Resultaten, während receive parallel arbeitet. u Output von send/receive sind explizite Kollektion, sonst sind Kollektionen implizit. OQS Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

32 Interoperable Informationssysteme - 32 Klemens Böhm Zusammenhang zwischen Query Operationen u. QueryableCollections Oracle OrderFil e Customers Orders Client Realisierung: Baum von Queryable Collections Projection QueryableCollection Bind-Join QueryableCollection FileSysWrapper QueryableCollection OracleWrapper QueryableCollection OQS Orders Customers OrderFile FileSys RDBMS Logische Sicht: Execution Plan Client OQS Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

33 Interoperable Informationssysteme - 33 Klemens Böhm Erläuterungen l Jedes Zwischenergebnis ist eine QueryableCollection, jeder Operator steht für eine entsprechende Query. l Wrapper ist Teil der Implementierung, er bildet entsprechende Teilquery z.B. auf SQL ab. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

34 Interoperable Informationssysteme - 34 Klemens Böhm Systemarchitektur Common Object Services... Meta Diction. OQS... Oracle OQS FileSys OQS Index OQS O2 OQS Name ORB Andere Dienste, z.B. Name Service Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

35 Interoperable Informationssysteme - 35 Klemens Böhm Evaluierung l Alternativen u Harmony (deklarative Anfragen) u CIS – spezifisches, mit CORBA implementiertes Customer Information System u ESQL/C Programm l Kriterien u Runtime Performance für ein Repository u Ressourcenverbrauch u Development Complexity u Heterogene Queryevaluierung (ob überhaupt möglich, und mit welcher Performance, da wir Joins i.a. selbst ausführen) Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

36 Interoperable Informationssysteme - 36 Klemens Böhm Klassifizierung des Datenzugriffs in Business Environments Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

37 Interoperable Informationssysteme - 37 Klemens Böhm Evaluierung - Runtime Performance l Point Data Access u ESQL/C am schnellsten u CIS besser als Harmony l Context Data Access u ESQL/C am schnellsten u Harmony schneller als CIS l Bulk Data Access u ESQL/C am schnellsten u Harmony schneller als CIS Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

38 Interoperable Informationssysteme - 38 Klemens Böhm Evaluation - Ressourcenverbrauch Memory Consumption #Value s MBytes l Konstante Memory- Auslastung mit ESQL/C und Harmony l CIS-spezifische CORBA Objekte: Memory- Auslastung steigt monoton mit der Ergebnisgrösse. l Folgerung: Marshalling verträgt sich nicht mit grossen Datenmengen. Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

39 Interoperable Informationssysteme - 39 Klemens Böhm Evaluation - Development Complexity Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss

40 Interoperable Informationssysteme - 40 Klemens Böhm Oracle Order File Customer s Orders Client Projection QueryableCollection Bind-Join QueryableCollection FileSysWrapper QueryableCollection OracleWrapper QueryableCollection OQS Schlussbemerkungen: Verbesserungen made in Harmony l Erhöhte Flexibilität u Queries über mehrere Kollektionen u Heterogene Repositories l Vermeidung der Latency Bulk Data Transfer l Asynchrone Methodenaufrufe Intra-Query Parallelism l Niedriger Ressourcenverbrauch Dataflow- Query Evaluierung Einleitung Implement. Infrastruktur - Einleitung - CORBA & Persistenz - CORBA – Probleme - Harmony - Eval. - Schluss