Fragestellungen im P2P-Projekt

Transkript

1 Fragestellungen im P2P-Projekt Block 0: Auswahl einer Simulationsumgebung Discrete Event Simulation (DES) Parallel Discrete Event Simulation (PDES) Block 1: Simulationsparameter Verteilungen Strategien Evaluationsszenarien Block 2: Texttechnologien Neue Herausforderungen und Lösungsansätze

2 Auswahl einer Simulationsumgebung Warum Discrete Event Simulation? Ist ressourcenfreundlich: Knoten des Netzwerks werden nicht als Threads oder Prozesse modelliert, sondern ihre Aktionen werden in einer Schleife (bzw. FES = Future Event Set) abgearbeitet. Abläufe sind vorhersehbar, deterministisch und wiederholbar (d.h. gut zu debuggen)

3 Discrete Event Simulation (1/2) Grundlegendes: Event = Zustandsänderung, braucht 0 Zeiteinheiten (Simulationszeit). Zwischen 2 Events passiert nichts (Interessantes), d.h. keine Zustandsänderung. Events sind oft (nur) Nachrichten (d.h. es gibt keine andere Form von Event) Das Event ereignet sich dort, wo die Nachricht ankommt. Simulationszeit bei Eintreten des Events ist die Ankunftszeit der Nachricht.

4 Discrete Event Simulation (2/2) Ablauf: Jeder Netzwerkknoten hat die Möglichkeit, Events (d.h. Nachrichten) mit einer bestimmten Timestamp t in das FES einzuordnen. Events werden in strikter Timestamp-Reihenfolge abgearbeitet. Erst wenn kein Event mit Timestamp t mehr vorliegt, bricht der Simulationszeitpunkt t+1 an. Default: Senden ohne Delays: schickt jemand eine Nachricht, so wird noch im gleichen Simulationsschritt beim Empfänger der Nachricht ein Event ausgelöst, so daß dieser die Nachricht verarbeiten kann. (Auch das Verarbeiten der Nachricht kostet keine Simulationszeit!) Senden mit Delays: Kann Nachrichten verzögert senden (d.h. mit Timestamp simtime() + x), z.b. so, daß eine Nachricht immer eine Zeiteinheit vom Sender zum Empfänger braucht (x=1). Will ein Knoten zu einer bestimmten Zeit von sich aus aktiv werden, so muß er sich eine Self Message schicken.

5 Parallel Discrete Event Simulation (1/7) Simulation soll verteilt ausgeführt werden (z.b. wegen Ressourcenknappheit) Problem: Weiterhin sollen Nachrichten in strikter Timestamp-Reihenfolge bearbeitet werden. Insbesondere muß verhindert werden, daß ein logischer Prozeß (LP) zum Zeitpunkt t eine Nachricht mit Timestamp < t verarbeitet (die er z.b. von einem anderen LP erhalten hat).

6 Parallel Discrete Event Simulation (2/7) Konservative Algorithmen: ein LP darf eine Nachricht mit Timestamp t erst verarbeiten, wenn er sicher sein kann, nicht später noch eine Nachricht mit Timestamp < t zu erhalten. Das bedeutet meist: Simulationszeit in den einzelnen LPs schreitet synchron voran. Optimistische Algorithmen: Zunächst ist alles erlaubt; kommt dann eine Nachricht mit zu kleiner Timestamp an, gibt es Rollbacks nur selten verwendet; eignen sich nur bei spärlicher Komm. zwischen LPs

7 Parallel Discrete Event Simulation (3/7) Begriffe: EIT = Earliest Input Time = untere Schranke für Timestamp eingehender Nachrichten, zunächst als geg. angenommen. lookahead = untere Schranke für die Dauer, nach der Nachrichten gesendet werden können (entspricht meist der Verarbeitungszeit einer Nachricht) EOT = Earliest Output Time = untere Schranke für Timestamp der nächsten ausgehenden Nachricht. ECOT = Earliest Conditional Output Time = untere Schranke für Timestamp ausgehender Nachricht, unter der Voraussetzung, daß keine weiteren Nachrichten ankommen. Algorithmen unterscheiden sich in der Art der Berechnung bzw. Abschätzung von EIT

8 Parallel Discrete Event Simulation (4/7) Beispiel: FIFO-Server, Bearbeitungszeit pro Nachricht: 1 Zeiteinheit. Grau: schon bearbeitete Nachrichten.

9 Parallel Discrete Event Simulation (5/7) Null Message Algorithmus (NMA): Jedesmal, wenn sich die EOT eines LPs ändert, schickt dieser eine Null-Message an alle anderen LPs und teilt diesen seine neue EOT mit. Ist L die Menge aller LPs, so berechnet ein LP y seine EIT als: min x L \{ y}( EOT( x)) wird EIT erreicht, muß der LP blockieren, bis EIT heraufgesetzt wird! ich brauche also möglichst großen lookahead der einzelnen LPs, um effizient arbeiten zu können

10 Parallel Discrete Event Simulation (6/7) Ein Beispiel: Verbinde alle LPs mit Leitungen, die Delays von 1 haben Dann gilt: Der lookahead eines LPs gegenüber allen anderen beträgt 1. Zum Zeitpunkt t hat jeder LP EIT = EOT = t+1. Er kann also gefahrlos alle Nachrichten mit Timestamp t verarbeiten. Dann schickt er allen anderen eine Null Message und teilt ihnen seine neue EOT (t+2) mit. Erst wenn er von allen anderen LPs eine ebensolche Nachricht erhalten hat, beginnt er mit Schritt t+1. Der Algorithmus reduziert sich also darauf, daß immer alle auf den Langsamsten warten und dann gemeinsam weitermachen.

11 Parallel Discrete Event Simulation (7/7) Diese Strategie ist im Netzwerksimulator OMNeT++ implementiert. Probleme: stirbt ein LP, so blockieren alle anderen für immer (da sie auf Null Messages von diesem warten) Wir können Peers nur simulieren, nicht emulieren. Mögliche Abhilfe: Simulationstool (selbstgeschrieben) verwenden, welches Zentral die Synchronisationszeit vorgibt (dann darf nur der LP, der die zentrale Kontrolle hat, nicht sterben). Reale Peers integrieren kann.

12 Modell-Parameter: Allgemeines Ziel: Definition eines allgemeinen Simulationsmodells, in dem möglichst viele Dinge parametrisiert sind, so daß man verschiedene Szenarien ausprobieren kann. Idealisierungen: Annahme endlich vieler Interessengebiete (IG), repräsentiert jeweils durch eine Menge von (künstlichen) Keywords. Man kann sich IG als Farben vorstellen. Jedes Keyword hat dann genau eine Farbe. Dokumentvektoren bestehen aus Keywords, die aber zu unterschiedlichen IG gehören dürfen (d.h. Dokumente können mehrfarbig sein) Wir wollen zunächst abstrahieren von Netzwerkfaktoren wie: Bandbreite und Rechenleistung der Peers Online-Zeit von Peers

13 Modell-Parameter: Liste möglicher Parameter Anzahl Peers Anzahl Dokumente (Types/Tokens, d.h. Anzahl replizierte Versionen) Anzahl Keywords Anzahl möglicher Interessengebiete Anzahl Keywords pro Dokument (Länge der Dokumentvektoren) Größe des Warehouses Mischungsverhältnis für Strategien (Anteil Warehouseitems für soziale bzw. Intergroupstrategie) Anzahl Queries, die ein Peer pro Zeiteinheit schickt TTL für Queries

14 Modell-Parameter: Verteilungen (1/3) Folgende Verteilungen müssen berücksichtigt werden: Verteilung von Keywords auf Dokumente Verteilung von Dokumenten auf Peers Verteilung von Interessengebieten auf Peers Außerdem: Selbstbeschreibungen von Peers

15 Modell-Parameter: Verteilungen (2/3) Verteilung von Keywords auf Dokumente: Es soll Zipf gelten für IG, d.h. einige wenige Dokumente haben sehr viele Themen, die meisten nur eines Verteilung von Dokumenten auf Peers: Es soll Zipf gelten für die Anzahl Dokumente pro Peer, sonst keine Vorgaben. Algorithmus: würfle Anzahl Dokumente x für einen Peer P nach Zipf würfle x Dokumente für Peer P zufällig aus der Liste stelle dabei irgendwie sicher, daß am Ende jedes Dokument einmal gewählt wurde...

16 Modell-Parameter: Verteilungen (3/3) Verteilung Interessengebiete auf Peers: Algorithmus: jeder Peer betrachtet alle Interessengebiete (Farben), die in seinen Dokumenten vorkommen aus diesen wählt er zufällig 1-3 aus, das sind seine IG Am Anfang repräsentieren die Dokumente eines Peers also nicht besonders gut dessen IG. Es soll aber trotzdem funktionieren! Selbstbeschreibungen von Peers: Werden immer aus dem aktuellen Dokumentenbestand errechnet Sollen irgendwie die IG eines Peers im richtigen Mischungsverhältnis wiedergeben Wählt ein Peer am Anfang die IG, rot und blau, so ist seine Selbstbeschreibung z.b.: <(rot, 0.6); (blau, 0.4)>, wobei die Zahlen angeben, wie stark ein IG in seinen Dokumenten repräsentiert ist.

17 Modell-Parameter: Strategien (1/3) Zum Modell gehören auch verschiedene Such- und Strukturbildungsstrategien: Warehousestrategien Umfang mitgeschickter / auswertbarer Informationen Replikation von Dokumenten Suchverhalten

18 Modell-Parameter: Strategien (2/3) Warehousestrategien: Sozial: suche Nachbarn, deren Content meinem ähnlich ist. Intergroup: suche Nachbarn, deren Content meinem möglichst unähnlich ist. Kombination von beiden: Small World-Struktur Umfang mitgeschickter / auswertbarer Informationen: Nur das Profil des auf eine Query antwortenden Peers ist bekannt und wird ausgewertet. sämtliche Profile im Log einer beantworteten Query werden analysiert und die zugehörigen Peers können ins Warehouse aufgenommen werden sämtliche Profile im Log beliebiger eintreffender Nachrichten werden ausgewertet...

19 Modell-Parameter: Strategien (3/3) Replikation von Dokumenten: Sollen gefundene Dokumente heruntergeladen, d.h. vom anfragenden Peer repliziert werden dürfen? Wenn ja, wann soll das geschehen? (Wenn es immer passiert, haben wir vielleicht irgendwann alle Dokumente auf allen Peers) Möglicher Algorithmus: Speicherplatz = Anfangszahl Dokumente mal x Anfangsdokumente dürfen nicht gelöscht werden, neue schon gelöscht wird, was meinen Interessengebieten bzw. Dokumenten am unähnlichsten ist Suchverhalten: zunächst nehmen wir an, daß Peers Queries nur aus ihren eigenen Keywords generieren (da sie ja keine anderen kennen)

20 Modell-Parameter: Evaluationsszenarien Expertenmodus: Man sucht nur nach eigenen IG (Default) Interessant ist hier der Recall, d.h.: finde ich alles, was zu meinen IG gehört? Bzw.: Wie gut funktioniert die Clusterbildung? Funktioniert vermutlich gut bei rein sozialer Strategie Zufallsmodus: Suche irgendetwas (z.b. von außen vorgegebenes) Interessant: wie kurz sind die Wege im Graphen? Braucht vermutlich gewissen Anteil Intergroup-Strategie Vergleich mit anderen Algorithmen (z.b. Flooding) Idealisierungen wegnehmen: insbesondere ideale Keywords/Dokumente ersetzen durch reale Dies ist eine Art Benchmark für Texttechnologien: sie müssen sich an den idealisierten Keywords messen lassen...

21 Texttechnologien: Aufgaben Beschlagwortung und Ähnlichkeitsberechnung: Dokumente werden durch einige wenige Keywords beschrieben (Vektor) Die Dokumentvektoren eines Peers werden zu einem Peervektor zusammengefaßt. Querys werden im selben Format dargestellt (klasssisches Vector Space Modell) Ähnlichkeit wird über ein einfaches Kosinusmaß (bzw. Skalarprodukt) berechnet. Ähnlichkeiten müssen berechnet werden für folgende Arten von Paaren: (Query, Peer) (Peer, Peer) (Query, Dokument)

22 Texttechnologien: neue Probleme Fundamentales Problem: zu keinem Zeitpunkt ist die Menge aller Dokumente/Terme bekannt. Teilprobleme: Entscheidungen (wohin eine Query geforwardet werden soll) müssen aufgrund kurzer Keyword-Vektoren getroffen werden => fragt ein User nach Auto, so gibt es bestimmt viele Peers, die passende Dokumente haben, in deren Beschreibung aber das Wort Auto leider gerade nicht vorkommt... => brauche Abstraktionsmechanismus Ranking der gefundenen Dokumente: PageRank ist nicht anwendbar, da keine globale Sicht auf Linkstruktur Eine Entsprechung von PageRank in P2P wäre die Frage danach, wieviele Peers den antwortenden Peer kennen, d.h. wie beliebt ein Peer als Informationsquelle ist.

23 Texttechnologien: Ontologien (1/2) Einsatz von Ontologien als Abstraktionsmechanismus Eine Ontologie ist globales Wissen, das wir uns gestatten Ontologie soll unabhängig vom (gesamten) Dokumentenbestand sein Die Ontologie hilft zu generalisieren, d.h. Peers, Anfragen und Dokumente in einen globalen Kontext einzuordnen. Beispiele: Eine Anfrage nach Rennautos kann mit Hilfe einer Ontologie verallgemeinert werden zu einer Anfrage nach Autos Gefundene Dokumente können mit Hilfe einer Ontologie in semantische Klassen eingeteilt werden Peers können disambiguiert werden, d.h. zwei Peers, die beide Dokumente über Bank besitzen, können eingeteilt werden in Geldinstitute und Möbelhersteller.

24 Texttechnologien: Ontologien (2/2) Konkretes Vorgehen: Jeder Peer erstellt eine Beschlagwortung seiner Dokumente (z.b. mittels Terminologie-Extraktion) Alle gefundenen Schlagwörter werden in der Ontologie (z.b. WordNet) markiert. Aus Regionen, die besonders stark aktiviert sind, werden Oberbegriffe extrahiert und in einer Map mit den zugehörigen Schlagwörtern verknüpft. Diese Maps sind die Grundlage für alle weiteren Verarbeitungsschritte, die Ontologie-Wissen voraussetzen.

25 Texttechnologien: IR-Methoden (1/3) Methoden des klassischen IR, die hier Anwendung finden sollen bzw. verfeinert werden müssen: Query-Expansion Disambiguierung (von Peers, Queries, Dokumenten,...) Relevance Feedback Ranking

26 Texttechnologien: IR-Methoden (2/3) Query-Expansion: Geschieht z.b. unter Verwendung von Ontologie-Wissen (Maps) Fragt ein Peer nach einem Oberbegriff, so wird dieser mittels der lokalen Map um Unterbegriffe erweitert. Disambiguierung: Peers können mittels Oberbegriffen aus ihren Maps disambigiert werden. Gefundene Dokumente können (wenn die Maps mitgeliefert werden) nach Oberbegriffen sortiert werden.

27 Texttechnologien: IR-Methoden (3/3) Relevance Feedback: Wenn ein Benutzer sich entscheidet, ein Dokument zu behalten, so ist dies ein implizites Feedback: der Peer, der dieses Dokument geliefert hat, ist vertrauenswürdig. Somit ergibt sich irgendwann aus dem User Feedback ein lokales Peer-Ranking, eine Art zweites Warehouse Problem: Benutzerverhalten ist schwer simulierbar... Das heißt: in der Simulation ist das Peer-Ranking identisch mit dem Warehouse Ranking: Mögliche Faktoren: User Feedback: siehe oben Clustering der Ergebnismenge nach Oberbegriffen aus Ontologie Anzahl benötigte Hops bis zur Antwort Lokales PageRank: Wenn jeder Peer weiß, wieviele Peers ihn kennen (diese müssen ihm Bescheid geben!), kann er diese Information bei einer Antwort auf eine Query mitschicken. Problem: viele Nachrichten!