Seminar Service Aspects in ad-hoc and P2P networks Database functionality in P2P-networks von Thorsten Weiberg.

Präsentation zum Thema: "Seminar Service Aspects in ad-hoc and P2P networks Database functionality in P2P-networks von Thorsten Weiberg."—  Präsentation transkript:

1 Seminar Service Aspects in ad-hoc and P2P networks Database functionality in P2P-networks von Thorsten Weiberg

2 2 Überblick Motivation und Einleitung DHT-Systeme Query Vorgänge in P2P Netzen(PIER) Mögliche allgemeine Architektur und Architektur von PIER Operatoren bei Suchanfragen (Bsp.: Join) Performance von PIER Robustheit von PIER Zusammenfassung und Ausblick

3 3 1. Einleitung und Motivation Peer-to-Peer(P2P) v.a. bekannt durch Filesharing Programme Verteilte Datenbanken sind bisher in ihrer Verteilung beschränkt. Traditionelle Datenbanken werden bisher zentral verwaltet. Versuch Prinzip von P2P auf Datenbanken anzusetzen (Bsp.: PIER)

4 4 Einleitung und Motivation(2) Näherung von der Datenbankseite durch Lockerung der Designprinzipien: 1.Konsistenz 2.Anpassende Skalierung 3.Natürliche Umgebung von Daten 4.Standardisierte Schemas über eine populäre Software

5 5 2. DHT-Systeme Aufbau: Eine(!) Hashtable, deren Daten sich auf allen Knoten verteilt befinden. Jeder Knoten kann Daten speichern. Jedes Datum hat einen eindeutigen Schlüssel. Herzstück: overlay-Routing Ein DHT-System ist skalierbar und braucht für einen Lookup O(log n) Hops bei n Knoten. Nur exaktes Matching! Bsp. für ein DHT-System: CAN

6 6 3. Query Vorgänge in P2P(Bsp.: PIER) Query Engine: - weit verbreitet, praktisch nutzbar - API der dazu verwendet DHT dünn, portabel und allgemein PIER (P2P Information Exchange and Retrieval) ist eine Query Engine, die Anzahl der teilnehmenden Knoten vergrößert, ohne dass die Skalierbarkeit darunter leidet.

7 7 4. Eine allgemeine Architektur Drei-Schichten Modell: DHT-Schicht Data Storage Schicht QP-Schicht P2P Netzwerk

8 8 5. Architektur von PIER

9 9 6. Operatoren bei Suchanfragen Operatoren für Selektion, Projektion, Join, Grouping, Aggregation und Sortieren Zur Vereinfachung wird nur das JOIN betrachtet: 1.Symmertric hash join 2.Fetch Matches 3.Symmetric semi join 4.Bloom Filter

10 10 6.1 Symmetric Hash Join Join (Equi-Join) über Relationen S und R Nutzt DHT-Struktur zum Routen und Speichern von Tupeln Rehashing von R und S jeder Knoten lokalen scan in seinem Namesspace N R und N S ein, um alle R und S Tupel zu lokalisieren. jedes Tupel, das alle lokalen Selektionsprädikate erfüllt, wird in den eindeutigen Namespace NQ kopiert. Die Werte für die Join-Attribute werden konkateniert und bilden so die resourceID der Kopie.

11 11 6.1 Symmetric Hash Join(2) Das Prüfen der Hashtable ist eine lokale Operation in N Q, die parallel beim Bilden geschieht. Jeder Knoten registriert sich in der DHT, um ein newData Callback zu bekommen. Wenn nun ein Tupel eingefügt wird, dann wird in N Q geprüft, ob sich eine Übereinstimmung mit der anderen Tabelle ergibt. Übereinstimmungen werden an das Prüftupel angehängt, um Ergebnistupel zu generieren. Sie werden dann in zur nächsten Station der Anfrage (ein anderer DHT Namespace) oder falls sie schon Ergebnistupel sind, zum Ausgangspunkt der Anfrage geschickt.

12 12 6.2 Fetch Matches Variation eines traditionellen Join-Algorithmus Eine Tabelle ist schon gehashed(hier S)! auf N R ein lscan durchgeführt Für jedes Tupel von R wird nun in S auf Übereinstimmungen durchsucht. Bei Übereinstimmung wird nun wie beim symmetric hash join verfahren.

13 13 6.3 Symmetrisches Semi Join beide Tabellen (R und S) neu gehashed Braucht dafür große Bandbreite Deshalb: Projektion von R und S auf ihre resourceID und Join Schlüssel Auf diese Projektion wird ein normales symmetrisches Join ausgeführt.

14 14 6.4 Bloom Join Generieren von Bloom Filtern für alle Knoten für jedes S und R Fragment Diese Filter werden in einer temporären DHT mit den Namespaces für jede Tabelle gespeichert. Filter werden nun alle verodert Multicast zu allen Knoten, die die entgegensetzte Tabelle speichern Ein Knoten scannt nun sein korrespondierendes Fragment und rehashed nur Tupel, die mit den Bloom Filter übereinstimmen.

15 15 7. Performance von PIER Traditionellen Datenbanken Skalierbarkeit in der Netzwerkgröße gemessen Beim Internet: Anzahl der Knoten und Netzwerkcharakteristik Erhöhung #Knoten Erhöhung der Ressourcen Latenz steigt Flaschenhälse: Latenz und Bandbreite

16 16 7.1 unendliche Bandbreite Unendliche Bandbreite (Messergebnisse bis zum Erhalt des letzten Tupel), Vergleich der Join- Algorithmen: Symmetrischer Hash Fetch MatchesSym. Semi-JoinBloom Filter 3,73 s3,78 s4,47 s6,85 s durchschnittliche Latenz von 0,57 s Latenz zwischen zwei Knoten beträgt 0,1 s ein Multicast braucht hier etwa 3 s n = 1024 Knoten

17 17 7.2 begrenzte Bandbreite Sinkt die Selektivität von den Prädikaten unter 40% dann ist die Kapazität der Berechnungsknoten der Flaschenhals. Steigt sie über 40%, dann ist die inbound Kapazität auf der Anfrageseite der Flaschenhals.

18 18 8. Robustheit Bemerken von Knotenausfällen mit Hilfe von Lebenszeichen Bemerken eines Knotenausfalls dauert gewisse Zeit Knoten müssen also refreshed werden Je höher die Refreshrate desto schneller wird ein Ausfall bemerkt, doch desto höher ist die Netzlast.

19 19 Zusammenfassung/Ausblick PIER schlägt den richtigen Weg ein Allerdings noch nicht fürs Internet geeignet, aber schon eher für verteilte Datenbanken. Aufteilung der Schichten lassen möglichst allgemeine DHTs zu Selektion: alle Tupel von R durchsucht (DHT-Schicht), Query Processor von PIER nicht die Möglichkeit diese Tupel von S zu filtern. Rationalisierungsbedarf für die Zukunft Es können keine Selektionen von nicht-DHT Attributen in der DHT gespeichert werden. Anwendungsgebiete: z.B. Netzwerkmonitorapplikationen und weit verteilte Systeme (Datenbanken)