CORBA - web

Werbung
Systeme 4:
Query Processing in
heterogenen Umgebungen
Klemens Böhm
Interoperable Informationssysteme - 1
Einleitung

Einleitung
Implement.
Infrastruktur
Gliederung:
 Implementierung,
 Infrastruktur.
Klemens Böhm
Interoperable Informationssysteme - 2
Adaptives Query Processing Motivation

Einleitung
Implement.
- Motivation

- JoinImplement.
Infrastruktur



Queryoptimierung, wie bisher vorgestellt,
erfordert genaue Kosteninformation.
Derartige Information ist, insbesondere
in verteilten Systemen, oft nicht verfügbar,
bzw. können die Werte sich
im Laufe der Zeit ändern.
Noch genauere Kostenbetrachtung:
schwierig,
löst das zweite Problem nicht.
Alternatives Paradigma: Adaptivität,
d.h. Queryplan passt sich zur Laufzeit
an veränderte Gegebenheiten an.
Implementierung der Query-Operatoren
muss erweitert werden.
Klemens Böhm
Interoperable Informationssysteme - 3
First-Few Queries, Top-n Queries

Einleitung
Implement.

- Motivation
- JoinImplement.
Infrastruktur

Top-n Query – man ist nur
an den ersten n Tupeln interessiert.
Oft merkt man erst während Queryevaluierung,
nach Inspektion der ersten Tupel, dass man
den Rest nicht sehen will.
Nicht nur Antwortzeit, auch Zeit bis zur Ausgabe
der ersten Tupel – wichtiges Kriterium für Query
Planning.
Klemens Böhm
Interoperable Informationssysteme - 4
Eigenschaften des Join-Operators

Einleitung
Implement.
- Motivation
- JoinImplement.
Infrastruktur

Tupel von zwei Streams
werden miteinander verknüpft, z.B. Equijoin.
Varianten (auf Ebene der Implementierung):
 Nested-Loop,
 Sort-Merge,
 Hash-basiert.
Klemens Böhm
Interoperable Informationssysteme - 5
Illustration
Nested-Loop Join, Equijoin
Einleitung
Relation B
Relation A
Implement.
- Motivation
28
- JoinImplement.
28
Infrastruktur
28
Join-Attribute
Klemens Böhm
Interoperable Informationssysteme - 6
Beispiel

Queryplan:
Einleitung
C
Implement.
A
- Motivation
- JoinImplement.

Infrastruktur
B
Ist unter den gegebenen Umständen
möglicherweise nicht gut, besser wäre vielleicht
„B C liefert vielleicht
mit ähnlicher Rate wie A“


Situation:
„Alles wartet
auf A.“
A
B
C
Ziel: ‘Umschalten’ auf besseren Plan,
sobald klar, dass aktueller Plan nicht optimal.
Im folgenden zunächst:
Vertauschung Operatorreihenfolge eines Joins.
Klemens Böhm
Interoperable Informationssysteme - 7
Vertauschen der Operatorreihenfolge
beim (Nested Loop-)Join
Einleitung
Implement.
- Motivation
Illustration:
Relation B
Relation A
Relation B
28
- JoinImplement.
28
Infrastruktur
28


Relation
A
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
+
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
+
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
“Moments of Symmetry” –
Join-Operatoren können vertauscht werden.
Äusserer Loop beginnt an Position in der Relation.
Klemens Böhm
Interoperable Informationssysteme - 8
Vertauschung Operatorreihenfolge

Einleitung
Implement.
- Motivation

Man stellt fest, dass Lesen von B
teurer als erwartet.
First-Few Queries.
- JoinImplement.
Infrastruktur
Klemens Böhm
Interoperable Informationssysteme - 9
Hash Join

Einleitung
Implement.

- Motivation
- JoinImplement.

Standardvariante hat keine
“Moments of Symmetry”.
Aufbauen der Hash-Tabelle nicht nur
für eine Relation, sondern für beide.
Relation B
Relation A
Illustration:
28
28
Infrastruktur
28

Zwei Massnahmen bei neuem Tupel:
1. Vergleich mit Hash-Tabelle
für andere Relation,
2. Eintrag in Hash-Tabelle (für diese Relation).
Mögliches Problem: Speicherplatz reicht nicht
für beide Hash-Tabellen.
Klemens Böhm
Interoperable Informationssysteme - 10
‘Umschalten’ auf anderen Plan

Einleitung

Ist zu jedem ‘Moment of Symmetry’ möglich.
Illustration für drei Relationen:
Implement.
- Motivation
C
- JoinImplement.
B
A
Infrastruktur
Klemens Böhm
Interoperable Informationssysteme - 11
Infrastruktur
für Information Integration

Einleitung
Implement.

Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss

Ziel: Implementierung unserer
Referenzarchitektur unter Verwendung
von Standard-Werkzeugen.
CORBA und die Common Object Services
Specification, insbesondere der CORBA Object
Query Service (OQS), bieten sich an.
Gliederung im folgenden:
 Alternativen für den Zugriff
auf persistente Daten mit CORBA (auch OQS)
 CORBA Performance-Flaschenhälse
 Harmony: Unsere Implementierung
des CORBA Object Query Service
 Evaluierung
 Schlussbemerkungen
Klemens Böhm
Interoperable Informationssysteme - 12
Three-Tier Architektur:
Client/Server/Middleware
Client
Program
Einleitung
Middleware
Server
Server
Server
Program
Program
Program(s)
Implement.
Infrastruktur
- Einleitung

- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss

Middleware:
 Software Layer zwischen Client und Server
 Versteckt Verteilung und Heterogenität:
Location und Implementation Transparency,
 Services auf Systemebene.
Wichtige Standards:
 CORBA
 DCOM
Klemens Böhm
Interoperable Informationssysteme - 13
CORBA – Beispiel für Interface
enum nation { Algeria, Argentina, ... };
enum market { Automobile,
Building, ... };
struct Order {
Einleitung
long OrderId;
Implement.
string Date;
Infrastruktur
float Price;
- Einleitung
string Priority;
char Status;
- CORBA &
Persistenz
string Clerk;
string Comment; };
- CORBA –
Probleme
- Harmony
Datentypdefinition
- Eval.
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<Order> orders();
};
interface CIS {
Customer
access(in string name);
sequence<string> addrs (in string mseg);
};
- Schluss
Schnittstellendefinition
Klemens Böhm
Interoperable Informationssysteme - 14
CORBA Konzepte/Konstrukte/Primitive

Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.

Anwender spezifiziert Signatur der Objekte
in sog. ‘Interface Definition Language’ (IDL);
IDL ist CORBA-spezifische Sprache,
keine Programmiersprache.
Compiler generiert Skeletons und Stubs:
 Skeletons: Methodensignatur
in der Programmiersprache,
in der die Methoden implementiert werden,
 Stubs: Proxies in Client-Programmiersprache.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 15
CORBA - Architektur
Client
Einleitung
Implement.
ORB
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
Server
Server
Server
Source
Source
Source
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 16
Verwandte Arbeiten
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
Query Processing
in heterogenen Umgebungen:
 DISCO, Verso (INRIA)
 Garlic
(IBM Almaden)
 TSIMMIS
(Stanford)
 OLE/db
(Redmond)
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 17
Zugriff auf persistente Daten
in einer CORBA Umgebung
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Wie greift man über CORBA
auf persistente Daten zu?
1. Enkapsulierung als CORBA Objekt,
Persistenz via
 Object-Oriented Database Adapter (OODA)
– Grundidee: OODB-Objekte
über CORBA ansprechen,
– kompliziert, ineffizient
(zuviele Aufrufe für ein Objekt),
 Persistent Object Service (POS) oder
 ORB-spezifische Mechanismen.
2. Deklarativer Zugriff,
Object Query Service (OQS)
Klemens Böhm
Interoperable Informationssysteme - 18
CORBA Object Query Service
CollectionFactory creates
create()
Collection
cardinality : long
iterates
Iterator
next()
reset()
create_iterator()
QueryEvaluator
ql_type : QLType
evaluate()
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
QueryableCollectionFactory
- Eval.
- Schluss
QueryableCollection
create()
- CORBA –
Probleme
- Harmony
creates
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.
Klemens Böhm
QueryManager
create()
creates
Query
prepare()
execute()
get_result()
Interoperable Informationssysteme - 19
CORBA Object Query Service
z.B. Parsen
der Query,
Queryverarb.
kein QueryProcessing
Einleitung
Implement.
CollectionFactory creates
create()
Collection
cardinality : long
iterates
Iterator
next()
reset()
create_iterator()
Infrastruktur
QueryEvaluator
ql_type : QLType
evaluate()
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
‚QueryFactory‘
QueryableCollectionFactory
creates
QueryableCollection
create()
- Eval.
QueryManager
create()
- Schluss
creates
Query
prepare()
execute()
get_result()
Klemens Böhm
Interoperable Informationssysteme - 20
CORBA Object Query Service


Einleitung
Implement.
Infrastruktur
Methode evaluate() ist zentral.
Implizite vs. explizite Kollektionen
(implizite Kollektionen
materialisieren ihre Elemente).
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 21
CORBA - Factories

Einleitung
Implement.
Infrastruktur
- Einleitung

CORBA-Factories: Objekte, die
Konstruktor-Methode
für eine Klasse implementieren.
Konvention bei Namensgebung:
“<Klassenname>Factory”
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 22
Probleme beim Datenaustausch
mit CORBA Methodenaufrufen

Einleitung
Implement.
Infrastruktur


- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme


Synchrones Kommunikationsmodell
– ist Standard mit CORBA,
Alternative wäre: Message-basiertes Interface.
Aufwendig (Antwortschnittstelle publizieren).
Marshalling/Demarshalling
mit jedem Methodenaufruf,
Hohe Latency, d.h. hohe Fixkosten
unabhängig vom Datenvolumen;
Folgerung: Transport vieler Datenobjekte teuer.
- Harmony
- Eval.
- Schluss
Server
Client
CIS
CIS->get_customer(“Ebner”)
Proxy
Object
Object
Skeleton
get_customer(char* n)
{
…
}
Request
Object Request Broker
Klemens Böhm
Answer
Interoperable Informationssysteme - 23
Illustration des Problems
CORBA Client
CORBA Server
Storage System
Einleitung
get_customer(“Ebner”)
Implement.
Infrastruktur
EXEC SQL FETCH … INTO …;
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
...
Klemens Böhm
...
...
Interoperable Informationssysteme - 24
Harmony: Unsere Implementierung
des CORBA OQS

Verteilte Query Engine
basierend auf der CORBA OQS Spezifikation,
d.h. Schnittstellen von OQS
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Deklarativer Zugriff auf Datenmengen,
 Ermöglicht Queries über mehrere Kollektionen,
 Kann auf heterogene Repositories zugreifen,
 Ergänzt CORBA so,
dass o.g. Features möglich sind.
Im folgenden:
 Querypläne in verteilter, heterogener Umgebung
(weitgehend unabhängig von Harmony; vier Folien)
 Lösung der CORBA-Performance-Probleme
mit Harmony (eine Folie)
 Rolle der OQS-Schnittstellenspezifikation,
 Architektur (eine Folie),
 Nicht: Queryplanerzeugung.

Klemens Böhm
Interoperable Informationssysteme - 25
Beispiel-Query
Query über mehrere heterogene
Repositories:
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
SELECT customer.Name
FROM
line
IN OrderFile,
customer IN Customers,
order
IN Orders
WHERE line.Num[0]
= order.OrderKey
AND customer.CustKey = order.CustKey
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 26
Möglicher Plan

Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme

Query Algebra
 Projektion,
 Selektion,
 Sortierung,
 Join,
 Union, …
Ausführung:
Pipelining zwischen
den Operatoren
p
><
p
p
><
- Harmony
- Eval.
- Schluss
OrderFil
e
Customers
Orders
Dieser Plan legt nicht fest, wo (von welcher Komponente)
welcher Operator ausgeführt wird. Diese Information muss in
verteilter Umgebung Teil des Plans sein.
Klemens Böhm
Interoperable Informationssysteme - 27
Erweiterung der Query Algebra

Einleitung

Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss

Nicht speziell für Harmony/CORBA,
andere Infrastrukturen funktionieren genauso, z.B. Garlic.
Meta-Operatoren:
Modifizieren den Data Stream nicht,
haben aber irgendeine Kontrollfunktion.
Zugriff auf heterogene Repositories:
wrap Meta-Operator (w)
 Abstrahiert von zugrundeliegenden Storage Systemen,
 stellt einfaches scan/iterator Interface zur Verfügung,
 übersetzt Subquery in lokale Querysprache (wenn
entsprechende Queryevaluierungskapazitäten
vorhanden),
d.h. w hat als Parameter ID einer Source,
 übersetzt das Resultat in das Typsystem von Harmony,
 heisst push-down in Garlic.
Klemens Böhm
Interoperable Informationssysteme - 28
Erweiterter Execution Plan
p
OQS
><
Einleitung
Implement.
Infrastruktur
w FileSys
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
w RDBMS
RDBMS
p
- Harmony
- Eval.
- Schluss
File System
p
OrderFil
e
Klemens Böhm
><
Customers
Orders
Interoperable Informationssysteme - 29
Harmony: Integration von Sourcen
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
Wrapper - Aufgaben:
 Verwalten der Verbindungen zum
Repository,
 Umwandlung
von OQS-Queries in lokale Querysprache,
 Konvertierung der Ergebnisse.
- Harmony
- Eval.
- Schluss
Drei Objekte müssen implementiert werden:
 WrapperFactory,
 QueryableCollection: implementiert wrap,
 Iterator: eigentlicher Datenzugriff.
Klemens Böhm
Interoperable Informationssysteme - 30
Send/Receive Meta-Operatoren

Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Lösung der Performance
Probleme:
send /receive MetaOperatoren
 Bulk Transfer:
Daten werden in Chunks
ausgetauscht, kein
wirklicher Dataflow,
Granularität frei
definierbar,
 Intra-Query Parallelism:
send generiert nächste
Menge von Resultaten,
während receive parallel
arbeitet.
 Output von send/receive
sind explizite Kollektion,
sonst sind Kollektionen
implizit.
Klemens Böhm
Client
receive
OQS
send
p
><
w FileSys
w RDBMS
...
...
Interoperable Informationssysteme - 31
Zusammenhang zwischen Query
Operationen u. QueryableCollections
Logische Sicht: Execution Plan
Client
Einleitung
Implement.
Realisierung:
Baum von Queryable Collections
OQS
Infrastruktur
Client
p
Projection
QueryableCollection
><
Bind-Join
QueryableCollection
OQS
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
w FileSys
w RDBMS
FileSysWrapper
QueryableCollection
OracleWrapper
QueryableCollection
- Schluss
p
OrderFile
Klemens Böhm
p
Oracle
><
Customers
Orders
Customers Orders
OrderFil
e
Interoperable Informationssysteme - 32
Erläuterungen

Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz

Jedes Zwischenergebnis ist eine
QueryableCollection, jeder Operator steht
für eine entsprechende Query.
Wrapper ist Teil der Implementierung,
er bildet entsprechende Teilquery
z.B. auf SQL ab.
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 33
Systemarchitektur
Common Object Services
ORB
Einleitung
Name OQS
Implement.
...
Infrastruktur
...
OQS
- Einleitung
Andere Dienste,
z.B. Name Service
Meta
Diction.
- CORBA &
Persistenz
- CORBA –
Probleme
OQS
OQS
OQS
OQS
- Harmony
Oracle
Index
FileSys
O2
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 34
Evaluierung

Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss

Alternativen
 Harmony (deklarative Anfragen)
 CIS – spezifisches,
mit CORBA implementiertes
“Customer Information System”
 ESQL/C Programm
Kriterien
 Runtime Performance
für ein Repository
 Ressourcenverbrauch
 Development Complexity
 Heterogene Queryevaluierung
(ob überhaupt möglich, und mit welcher
Performance, da wir Joins i.a. selbst ausführen)
Klemens Böhm
Interoperable Informationssysteme - 35
Klassifizierung des Datenzugriffs
in Business Environments
Einleitung
Implement.
Infrastruktur
- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Horizontal
Market
(simple
objects)
Vertical
Market
(complex
objects)
Klemens Böhm
Point Data
Access
(single data
item)
product data
Context Data
Access
(small set of
items)
recent orders
Bulk Data
Access
(large data
set)
address list
CAD
multimedia
information
series of Xray images
medical
information of
all patients
Interoperable Informationssysteme - 36
Evaluierung - Runtime Performance

Einleitung
Implement.
Infrastruktur

- Einleitung
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss

Point Data Access
 ESQL/C am
schnellsten
 CIS besser als
Harmony
Context Data Access
 ESQL/C am
schnellsten
 Harmony schneller
als CIS
Bulk Data Access
 ESQL/C am
schnellsten
 Harmony schneller
als CIS
200%
150%
100%
50%
0%
ESQL/C
CIS
Harmony
ESQL/C
CIS
Harmony
ESQL/C
CIS
Harmony
200%
150%
100%
50%
0%
200%
150%
100%
50%
0%
Klemens Böhm
Interoperable Informationssysteme - 37
Evaluation - Ressourcenverbrauch

Einleitung
Implement.
Infrastruktur
- Einleitung

- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss

Konstante
MemoryAuslastung mit
ESQL/C und
Harmony
CIS-spezifische
CORBA Objekte:
MemoryAuslastung steigt
monoton mit der
Ergebnisgrösse.
Folgerung:
Marshalling
verträgt sich nicht
mit grossen
Datenmengen.
Klemens Böhm
Memory Consumption
MBytes
CIS
100
90
80
70
60
50
40
30
20
10
0
ESQL/C
Harmony
100.000
#Value
s
1.000.000
Interoperable Informationssysteme - 38
Evaluation - Development Complexity
Einleitung
Implement.
Infrastruktur
- Einleitung
Point Data
Access
Harmony Eine Query
CIS
81 LOC
ESQL/C 120 LOC
Context Data
Access
Eine Query
85 LOC
168 LOC
Bulk Data
Access
Eine Query
83 LOC
144 LOC
- CORBA &
Persistenz
- CORBA –
Probleme
- Harmony
- Eval.
- Schluss
Klemens Böhm
Interoperable Informationssysteme - 39
Schlussbemerkungen:
Verbesserungen made in Harmony

Einleitung
Implement.

Infrastruktur
- Einleitung
- CORBA &
Persistenz

- CORBA –
Probleme
- Harmony
Vermeidung der Latency
Bulk Data Transfer
Asynchrone
Methodenaufrufe
Intra-Query Parallelism
Niedriger
Ressourcenverbrauch
DataflowQuery Evaluierung
Client
OQS
Projection
QueryableCollection
Bind-Join
QueryableCollection
FileSysWrapper
QueryableCollection
OracleWrapper
QueryableCollection
- Eval.
- Schluss

Erhöhte Flexibilität
 Queries über
mehrere Kollektionen
 Heterogene
Repositories
Klemens Böhm
Oracle
Order
File
Customer
sOrders
Interoperable Informationssysteme - 40
Herunterladen