Das MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Informatik Forsch. Entw. (2005) 20: 152–166
DOI 10.1007/s00450-005-0205-9
REGULÄRE BEITRÄGE
Matthias Bender • Sebastian Michel • Gerhard Weikum • Christian Zimmer
Das MINERVA-Projekt:
Datenbankselektion für Peer-to-Peer-Websuche
Eingegangen am 20. September 2004 / Angenommen am 12. Mai 2005 / Online publiziert am 26. August 2005
© Springer-Verlag 2005
Zusammenfassung In diesem Artikel wird MINERVA1 prä- tem model and identify the problem of efficiently select-
sentiert, eine prototypische Implementierung einer verteil- ing promising peers for a query as a pivotal issue. We re-
ten Suchmaschine basierend auf einer Peer-to-Peer (P2P)- visit existing approaches to the database selection problem
Architektur. MINERVA setzt auf die in der P2P-Welt verbrei- and adapt them to our system environment. Measurements
tete Technik verteilter Hash-Tabellen auf und benutzt diese are performed to compare different selection strategies us-
zum Aufbau eines verteilten Verzeichnisses. Peers in unse- ing real-world data. The experiments show significant per-
rem Ansatz entsprechen völlig autonomen Benutzern mit ih- formance differences between the strategies and prove the
ren lokalen Suchmöglichkeiten, die bereit sind, ihr lokales importance of a judicious peer selection strategy. The ex-
Wissen und ihre lokalen Suchmöglichkeiten im Rahmen ei- periments also present first evidence that a small number of
ner Kollaboration zur Verfügung zu stellen. Wir formalisieren carefully selected peers already provide the vast majority of
unsere Systemarchitektur und beschreiben das zentrale Pro- all relevant results.
blem einer effizienten Suche nach vielversprechenden Peers Keywords Peer-to-Peer · Query Routing · Web Search
für eine konkrete Anfrage innerhalb des Verbundes2 . Wir
greifen dabei auf existierende Methoden zurück and passen CR Subject Classification H.4 · H.3.3 · H3.4
diese an unseren Systemkontext an. Wir präsentieren Expe-
rimente auf realen Daten, die verschiedene dieser Ansätze
vergleichen. Diese Experimente zeigen, dass die Qualität der 1 Einführung
Ansätze variiert und untermauern damit die Wichtigkeit und
den Einfluss einer leistungsstarken Methode zur Auswahl gu- Peer-to-Peer (P2P)-Architekturen sind insbesondere im Kon-
ter Datenbanken. Unsere Experimente deuten an, dass eine text von Musiktauschbörsen wie Napster oder Kazaa bekannt
geringe Anzahl sorgfältig ausgewählter Datenbanken typi- geworden. Sie erlauben den Umgang mit großen Datenmen-
scherweise bereits einen Großteil aller relevanten Ergebnisse gen in einer verteilten und selbstorganisierenden Weise. In
des Gesamtsystems liefert. einem solchen kollaborativen System sind alle Peers völlig
Schlüsselwörter Peer-to-Peer · Datenbankselektion · autonom und die gesamte Funktionalität wird über alle Peers
Websuche verteilt. Somit wird die Systemlast über alle Teilnehmer ver-
teilt, und der Ausfall eines beliebigen Peers kann niemals
Abstract This paper presents the MINERVA1 project that zum Ausfall des Systems führen. Diese Eigenschaften bieten
protoypes a distributed search engine based on P2P tech- ein enormes Potenzial für skalierbare, effiziente, fehlerresi-
niques. MINERVA is layered on top of a Chord-style overlay stente und dynamische verteilte Systeme. Zusätzlich kann ein
network and uses a powerful crawling, indexing, and search solches System vom „intellekuellen“ Input einer großen Teil-
engine on every autonomous peer. We formalize our sys- nehmerzahl profitieren, z.B. in Form von Lesezeichen (Book-
marks) oder Click-Streams der Benutzer. Eines der zentralen
Diese Arbeit wurde teilweise gefördert durch das integierte EU-Projekt Probleme ist jedoch das Auffinden guter Peers für ein kon-
DELIS (Dynamically Evolving, Large Scale Information System). kretes Informationsbedürfnis.
M. Bender · S. Michel · G. Weikum · C. Zimmer Obwohl die Peer-to-Peer-Technologie vergleichsweise
Max-Planck-Institut für Informatik, Stuhlsatzenhausweg 85, 66123 noch jung ist, so zeigen sich deutliche Berührungspunkte
Saarbrücken mit der „traditionellen“ Forschung im Information-Retrieval
1 http://www.minerva-project.org und Datenbankbereich; Peer-to-Peer-Technologie kann da-
2 Wir verwenden die Begriffe Kollaboration, Verbund und P2P- her von bestehenden Vorarbeiten profitieren. Die Besonder-
System synonym. heiten einer verteilten Architektur erfordern jedoch einenDas MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche 153
neuen Blickwinkel auf bestimmte Aspekte. Das Fehlen einer von Resultatslisten ein. Abschnitt 11 schließt mit einem Aus-
zentralen Indexierung beispielsweise behindert den Einsatz blick auf zukünftige Forschungsaspekte diesen Artikel ab.
bewährter Methoden zur Auswahl von Datenbanken, insbe-
sondere auch durch die Schwierigkeiten, globale Maße für
solch einen großen und dynamischen Verbund zu berechnen.
2 Verwandte Arbeiten
Dieser Artikel stellt die Architektur des Forschungspro-
totyps MINERVA vor und zeigt verschiedene Verfahren, mit Die aktuelle Forschung auf dem Gebiet von P2P-Systemen
deren Hilfe Anfragen an ausgewählte Peers delegiert wer- (z.B. Chord [38], CAN [35], Pastry [34], P2P-Net [4] oder P-
den können. Jeder Peer ist autonom und besitzt eine eige- Grid [3]) baut zumeist auf verteilten Hash-Tabellen auf, die
ne lokale Suchmaschine mit dem dazugehörigen lokalen In- eine Zuordnung von Schlüsseln (z.B. Titeln oder Autoren)
dex. Die Peers teilen ihr Wissen (oder eine selbstgewählte zu Peers in einer verteilten Weise erlauben und gleichzei-
Teilmenge davon), indem sie Meta-Informationen publizie- tig gut mit der Gesamtgröße des Verbundes skalieren. Die
ren. Als Meta-Informationen wählen wir kompakte Statisti- Suche nach den jeweils zuständigen Peers für einen solchen
ken sowie Quality-of-Service-Informationen und formen so Schlüssel in einem Verbund aus n Peers kann typischerwei-
ein konzeptionell globales Verzeichnis. Dieses Verzeichnis se in O(log n) Schritten ausgeführt werden, während gleich-
wird jedoch in einer vollständig dezentralisierten und wei- zeitig kein Peer mehr als O(log n) Verwaltungsinformatio-
testgehend selbstorganisierenden Weise implementiert. Wir nen speichern muss. Diese Systeme können auch mit einer
benutzen dazu die Technik verteilter Hash-Tabellen am Bei- hohen Dynamik umgehen, d.h. mit dem häufigen Kommen
spiel des Chord-Protokolls [38], das wir für unsere Zwecke und Gehen von Peers in unvorhersehbarer Weise und ohne
angepasst und re-implementiert haben. MINERVA benutzt Vorankündigung. Allerdings sind diese Ansätze auf exakte
dieses konzeptionell globale Verzeichnis, um solche Peers zu Anfragen nach einzelnen Schlüsseln beschränkt. Dies ist un-
identifizieren, die mit höchster Wahrscheinlichkeit die qua- zureichend für Websuche, bei der Anfragen nach Relevanz
litativ hochwertigsten Ergebnisse zu einer Anfrage liefern. sortierte Listen von Ergebnissen liefern sollen [11].
Eine Anfrage wird dabei standardmäßig zunächst mit der Im Folgenden gehen wir kurz auf bestehende Ansätze
lokalen Suchmaschine des Anfragenden ausgewertet, kann im Bereich P2P-Websuche ein. Galanx [42] ist eine P2P-
danach aber zur Verbesserung der Resultatsgüte an andere Suchmaschine, die auf dem Webserver Apache sowie auf
Peers weitergeleitet werden. Die jeweiligen Resultate dieser der Datenbank BerkeleyDB aufsetzt. Dabei werden Anfragen
Peers werden vom Anfragenden letztlich zu einem gemein- ähnlich wie in unserem Ansatz zu potenziell relevanten Peers
samen Resultat zusammengeführt. weitergeleitet. Da Webserver jedoch typischerweise weniger
volatil sind als autonome Peers, treten die Aspekte der Dy-
Der wissenschaftliche Beitrag unserer Arbeit liegt in der namik innerhalb des Verbundes in den Hintergrund.
systemorientierten Herangehensweise an Websuche im Kon-
PlanetP [7] ist eine Publish-Subscribe-Architektur für
text von P2P-Systemen. Wir präsentieren Messergebnisse un-
P2P-Communities und die erste ihrer Art, die eine Suche
seres vollständig lauffähigen Systems auf realen Daten und
mit Ranking nach Relevanz der Inhalte unterstützt. Dabei
berücksichtigen dabei sowohl die Resultatsgüte als auch die
unterscheidet PlanetP lokale Indexe und ein globales Ver-
Effizienz und den Overhead unserer Architektur. Zu den neu-
zeichnis, das alle Peers und ihre verfügbaren Informationen
en Aspekten gehören die Art und Weise, wie wir die zugrunde
beschreibt. Zur Verbreitung dieses Verzeichnisses wird ein
liegende Chord-artige Basisarchitektur zum effizienten Um-
Gossiping-Algorithmus verwendet, d.h. jeder Peer verbrei-
gang mit den Meta-Informationen der einzelnen Peers nutzen
tet seine Informationen großflächig und unstrukturiert über
und darauf die Güte verschiedenster Verfahren zur Auswahl
das gesamte Netzwerk. Das System skaliert daher nur bis zu
geeigneter Datenbanken evaluieren. Im Gegensatz zu frü-
einer Größe von wenigen tausend Peers.
heren Arbeiten auf dem Gebiet des verteilten Information-
Odissea [39] benutzt eine zweischichtige Architektur, bei
Retrieval (z.B. [13, 19, 31]) wurde unsere Architektur von
der globale Indexlisten über die Peers verteilt werden. Die An-
Beginn an konsequent und explizit für die Größenmaßstäbe
frageausführung benutzt eine verteilte Variante des Schwell-
und die Dynamik eines P2P-Verbundes entworfen.
wertalgorithmus, der u.a. von Fagin [16] eingeführt wur-
Nach einer Übersicht über verwandte Arbeiten in Ab- de. Das System erzeugt jedoch eine hohe Netzwerkauslas-
schn. 2 stellt Abschn. 3 den Chord-Algoritmus vor. Ab- tung, insbesondere beim Verteilen der Indexlisten. Außerdem
schnitt 4 liefert eine kurze Einführung in die Grundlagen scheinen Anfragen derzeit auf maximal zwei Suchterme be-
des Information-Retrievals, die für den weiteren Verlauf des schränkt zu sein.
Artikels benötigt werden. Abschnitt 5 stellt die Systemarchi- Das in [36] beschriebene System benutzt einen inver-
tektur vor; Abschnitt 6 formalisiert diese. Abschnitt 7 skiz- tierten Index, der über die Peers verteilt wird. Besonderes
ziert die Implementierung von MINERVA, die als Grundlage Augenmerk wird dabei auf Techniken zur Verringerung der
der Evaluation der verschiedenen Strategien zur Auswahl der benötigten Bandbreite bei der Ausführung von Anfragen ge-
Datenbanken dient, die Abschn. 8 vorstellt. Abschnitt 9 zeigt legt. [25] betrachtet hybride P2P-Systeme, in denen ein Peer
erste Messergebnisse, die mit der prototypischen Implemen- entweder ein einfacher Knoten oder ein Verzeichnisknoten
tierung auf realen Daten erzielt wurden. Abschnitt 10 geht sein kann. Die Verzeichnisknoten arbeiten dabei als soge-
kurz auf das Problemfeld bezüglich der Zusammenführung nannte Super-Peers, was möglicherweise die Skalierbarkeit154 Matthias Bender et al.
und die Fähigkeit zur Selbstorganisation des Gesamtsystems Chord [38] ist ein verteiltes Lookup-Protokoll, das dieses
einschränkt. Die Auswahl geeigneter Datenbanken basiert Problem angeht. Es stellt die Funktionalität einer verteilten
auf der Kullback-Leibler-Divergenz zwischen den Termver- Hash-Tabelle (Distributed Hash Table, DHT) zur Verfügung,
teilungen der einzelnen Peers. indem es Schlüssel jeweils eindeutig bestimmten Knoten in-
Verschiedene Strategien zur Verteilung von Anfragen über nerhalb des Netzwerkes zuweist. Zu diesem Zweck benutzt
einfache Schlüsselwortsuchen hinaus wurden vielfach dis- Chord konsistentes Hashing [24]. Konsistentes Hashing ver-
kutiert [8, 9, 45], unterstützen aber kein Ranking nach Rele- teilt mit hoher Wahrscheinlichkeit die Last gleichmäßig über
vanz und sind daher für unsere Zwecke nicht geeignet. Die das Netzwerk, da jeder Knoten in etwa für die gleiche Anzahl
Konstruktion semantischer virtueller Netzwerke (Semantic von Schlüsseln verantwortlich ist. Diese Lastbalancierung
Overlay Networks) mit Hilfe von Clustering- bzw. Klassi- arbeitet insbesondere auch bei einer sich dynamisch verän-
fikationstechniken wird in [10, 26] betrachtet und ist ortho- dernden Zielmenge an Peers, d.h. wenn Knoten den Verbund
gonal zu unserem Ansatz. [2] diskutiert den Aufbau skalier- verlassen oder ihm beitreten.
barer Formen von semantischen virtuellen Netzen und iden- Chord kann nicht nur garantieren, den für einen bestimm-
tifiziert Strategien zu ihrer Nutzung bei der Anfrageausfüh- ten Schlüssel zuständigen Knoten zu finden, sondern tut dies
rung. [41] verteilt einen auf LSI-Techniken (Latent Semantic auch sehr effizient. In einem stabilen Verbund aus N Knoten
Indexing) beruhenden globalen Index auf die Peers, indem speichert jeder Knoten nur Informationen über O(log N ) an-
LSI-Dimensionen mit Hilfe der verteilten Hash-Tabelle CAN dere Knoten, und jede beliebige Anfrage kann durch O(log N )
verteilt werden. In diesem Ansatz geben die Peers ihre Au- Nachrichten innerhalb des Verbundes beantwortet werden.
tonomie auf und sind zur Zusammenarbeit verpflichtet. Diese Eigenschaften erlauben potenziell hochgradig skalie-
Neben der aktuellen Forschung im Bereich der P2P-Web- rende Anwendungen.
suche sind auch frühere Arbeiten zu verteilter Informati- Das Konzept hinter Chord lässt sich einfach veranschau-
onssuche und Meta-Suchmaschinen relevant. [6] gibt einen lichen: Alle Knoten pi und alle Schlüssel ki werden mit Hil-
Überblick über Methoden zur Kombination verteilter Anfra- fe einer Hashfunktion auf denselben Bereich eindeutiger nu-
geergebnisse. [19] stellt ein formales Entscheidungsmodell merischer Bezeichner abgebildet. Da alle Operationen modu-
für die Auswahl von Datenbanken im Kontext verteilter In- lo einer fest vorgegebenen großen Konstante (der maximalen
formationssuche vor. [32] untersucht verschiedene Qualitäts- Anzahl von Peers) durchgeführt werden, ergibt sich ein zykli-
maße für die Auswahl von Datenbanken. [21,29] untersuchen scher Raum von Bezeichnern, der sogenannte Chord-Ring.
die Skalierbarkeit verteilter Indexe. Im Folgenden verwenden wir diese numerischen Bezeichner
Einen guten Überblick über existierende Techniken von synonym zu ihren ursprünglichen Knoten bzw. Schlüsseln,
Meta-Suchmaschinen gibt [31]. [43] evaluiert Strategien zur d.h. wir verzichten aus Gründen der Übersichtlichkeit auf die
effizienten Bestimmung guter Suchmaschinen für eine kon- explizite Darstellung der Hashfunktion. Jeder Schlüssel ki
krete Anfrage. Ungeachtet der Relevanz dieser früheren Ar- wird seinem nächsten nachfolgenden Knoten auf dem Chord-
beiten stellt die kollaborative Suche in P2P-Netzwerken aller- Ring zugeordnet, d.h. ein Knoten ist zuständig für den Bereich
dings eine noch größere Herausforderung dar, da die vorheri- zwischen seinem Vorgängerknoten und sich selbst. In Abb. 1
gen Arbeiten sich typischerweise auf einen stabilen Verbund verteilen sich 10 Knoten über den Chord-Ring. Für den
von recht wenigen Suchmaschinen beziehen – im Gegensatz Schlüssel k54 , zum Beispiel, ist der Knoten p56 zuständig, da
zur gewünschten Skalierbarkeit und Dynamik in P2P-Netz- er der nächste folgende Knoten auf dem Chord-Ring ist.
werken.
3 Chord – Ein skalierbares Lookup-Protokoll
für P2P-Systeme
Das effiziente Auffinden von Knoten in einer P2P-Architek-
tur ist ein fundamentales Problem, das von verschiedensten
Seiten angegangen worden ist. Frühe (aber nichtsdestotrotz
verbreitete) Systeme wie Gnutella verlassen sich dabei auf ei-
ne unstrukturierte Topologie, in der ein Peer alle Nachrichten
an alle ihm bekannten Nachbarn (oder eine zufällige Aus-
wahl von Nachbarn) weiterleitet. Typischerweise enthalten
diese Nachrichten einen Zähler, der bei jeder Weiterleitung
um eins vermindert wird. Auch wenn experimentelle Ergeb-
nisse zeigen, dass dieses Message Flooding (oder Gossiping)
in den meisten Fällen erstaunlich gut funktioniert, gibt es kei-
ne Garantien, dass alle betroffenen Knoten letztlich die Nach-
richt erhalten. Außerdem widerspricht die Vielzahl unnötiger
Nachrichten unserem Ziel einer effizienten Architektur. Abb. 1 Chord-ArchitekturDas MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche 155
Abbildung 1 illustriert auch ein naives Verfahren zum Chord kann seine Lookup-Operation den verschiedensten
Auffinden des für einen Schlüssel zuständigen Knotens. Wenn Anwendungen zur Verfügung stellen, z.B. verteilten Dateisy-
jeder Knoten seinen Nachfolger auf dem Chord-Ring kennt, stemen. Chord alleine ist jedoch noch keine Suchmaschine,
kann eine Anfrage nach k54 solange um den Ring herum wei- da es nur exakte Anfragen auf einzelnen Schlüsseln erlaubt
tergeleitet werden, bis ein Paar von Knoten gefunden wird, und kein Ranking von Ergebnissen unterstützt.
zwischen denen sich der Schlüssel k54 befindet. Der zweite
Knoten dieses Paares ( p56 ) ist der derzeit zuständige Kno-
ten für diesen Schlüssel. Dieses Verfahren ähnelt der Suche 4 Kurze Einführung in Information-Retrieval
in einer linearen Liste, welche den zuständigen Knoten in
erwarteten O(N ) Schritten finden kann, wobei jeder Knoten In diesem Abschnitt geben wir einen sehr kurzen Überblick
lediglich O(1) Informationen über andere Knoten (nämlich über Information-Retrieval-Techniken, auf denen die weite-
über seinen Nachfolger) benötigt. ren Abschnitte dieses Artikels aufbauen.
Um die Suche zu beschleunigen bedient sich Chord zu- Information-Retrieval-Systeme speichern große Mengen
sätzlicher Informationen über die aktuelle Netzwerk-Topo- an schwach struktrierten oder unstrukturierten Daten, wie
logie. Jeder Knoten pi unterhält eine sogenannte Fingerta- z.B. Textdokumente oder Webseiten in HTML. Sie stellen
belle. Der m-te Eintrag der Fingertabelle eines Knotens pi Suchfunktionen zur Verfügung, mit deren Hilfe sich relevan-
enthält einen Zeiger auf den ersten Knoten p j , der von pi te Dokumente zu einer Anfrage berechnen lassen. Typische
auf dem Chord-Ring mindestens 2m−1 entfernt liegt. Dieses Vertreter solcher Systeme sind Websuchmaschinen oder Di-
Schema besitzt folgende wichtige Eigenschaften: Jeder Kno- gitale Bibliotheken. In der jüngsten Vergangenheit integrie-
ten speichert nur wenige Zeiger und kennt dabei seine eige- ren auch immer mehr relationale Datenbanksysteme solche
ne Umgebung besser als entfernte Bereiche auf dem Chord- Funktionen.
Ring. Gleichzeitig enthält die Fingertabelle jedoch typischer- Die Suchfunktionalität wird durch Ähnlichkeitsmaße im-
weise nicht genug Informationen, um den zuständigen Kno- plementiert, die die Ähnlichkeit von Anfragen zu den Doku-
ten für einen beliebigen Schlüssel direkt bestimmen zu kön- menten berechnen. Im Rahmen von textbasierter Informati-
nen. Da jedoch jeder Knoten diese Zeiger in Zweierpotenz- onssuche mit einfachen Schlüsselwortanfragen repräsentie-
Intervallen um den Chord-Ring herum unterhält, kann eine ren diese Ähnlichkeitsmaße typischerweise die Häufigkeit
Nachricht mit jeder Weiterleitung mindestens die Hälfte der des Auftretens der Suchterme in einem Dokument sowie die
verbleibenden Distanz überbrücken. Diese Eigenschaft ist in relative Lage der Suchterme zueinander innerhalb eines Do-
Abb. 2 für Knoten p8 dargestellt. Es folgt unmittelbar, dass kuments. Abschnitt 4.1 stellt das Konzept der invertierten
die erwartete Zahl der Nachrichten, um den zuständigen Kno- Indexlisten vor, welche eine effiziente Anfrageausführung er-
ten für einen beliebigen Schlüssel in einem Netzwerk aus N möglichen. Abschnitt 4.2 gibt eine kurze Einführung in das
Knoten zu finden, O(log N ) beträgt. populärste Ähnlichkeitsmaß, das sogenannte TF*IDF-Maß.
Chord beinhaltet ein Stabilisierungsprotokoll, das jeder Für nähere Details verweisen wir den Leser auf [11, 30].
Knoten periodisch im Hintergrund ausführt. Es aktualisiert
die Einträge der Fingertabelle sowie die Zeiger auf die direk-
ten Nachfolger, so dass Chord die Korrektheit seiner Lookup- 4.1 Invertierte Indexlisten
Operation auch bei einem sich dynamisch ändernden Ver-
bund garantieren kann. Insbesondere lässt sich zeigen, dass Das Konzept invertierter Indexlisten wurde entwickelt, um
selbst mit veralteten Einträgen in der Fingertabelle die Lei- effizient solche Dokumente innerhalb einer Dokumentmenge
stung des System nur sehr langsam nachlässt. zu identifizieren, die einen konkreten Suchterm enthalten.
Zu diesem Zweck bilden alle Terme, die innerhalb der Do-
kumentmenge vorkommen, eine indexartige Baumstruktur
(oftmals einen B*-Baum), bei der die Blätter jeweils eine
Liste von eindeutigen Bezeichnern genau jener Dokumen-
te beinhalten, die einen Term enthalten (vgl. Abb. 3). Über
die Listen aller Terme einer Anfrage wird konzeptionell ein
Schnitt oder eine Vereinigung gebildet, um mögliche Treffer
für die Anfrage zu identifizieren. In Abhängigkeit von der
konkreten Ausführungsstrategie werden die Dokumente in-
nerhalb der Listen nach ihren Bezeichnern oder nach ihrer
Ähnlichkeit zum jeweiligen Term geordnet, was eine noch
effizientere Abarbeitung der Indexlisten ermöglicht.
4.2 TF*IDF-Maß
Die Häufigkeit des Vorkommens eines Terms t in einem Do-
Abb. 2 Skalierbare Lookup-Operationen mit Hilfe von Finger-Tabellen kument d wird als Termhäufigkeit (tft,d ) bezeichnet. Intuitiv156 Matthias Bender et al.
Abb. 3 B*-Baum mit invertierten Indexlisten
steigt die Relevanz eines Dokumentes mit steigender Term- zuvor noch nicht gesehene Dokument d benutzt TA einen
häufigkeit für einen Suchterm. Die Anzahl der Dokumen- Direktzugriff auf die übrigen Indexlisten, um die endgütige
te innerhalb einer Dokumentmenge, die den Term t enthal- Relevanz des Dokumentes zu bestimmen. Diese Informati-
ten, wird als Dokumenthäufigkeit (dft ) bezeichnet; die in- onen werden in einer Kandidatenmenge gespeichert. Zusätz-
verse Dokumenthäufigkeit (idft ) eines Terms ist das Verhält- lich berechnet der Algorithmus eine obere Schranke für das
nis der Gesamtzahl aller Dokumente zur Dokumenthäufig- maximale Gesamtgewicht noch nicht gesehener Dokumente
keit. Intuitiv gesprochen sinkt die relative Wichtigkeit eines und kann daher das Traversieren der Indexlisten abbrechen,
Suchterms innerhalb einer Anfrage, je mehr Dokumente die- sobald keines dieser unbekannten Dokumente mehr seinen
sen Term enthalten, d.h. der Suchterm bietet ein geringeres Weg in die Kandidatenmenge finden kann. Probabilistische
Unterscheidungspotential zwischen den Dokumenten. In der Methoden, die dieses Verfahren noch weiter beschleunigen
Praxis werden diese beiden Maße normalisiert (z.B. auf das können, werden in [40] vorgestellt.
Intervall (0,1]) und/oder logarithmisch gedämpft. Ein typi-
scher Vertreter dieser Familie von TF*IDF-Maßen berechnet
das Gewicht wi, f des i-ten Suchterms im j-ten Dokument
5 Systemdesign
wie folgt:
tfi, j N Abbildung 4 illustriert unseren Ansatz, der auf Chord auf-
wi, j := × log (1) baut und einer Publish-Subscribe-Architektur ähnelt. Wir set-
maxt {tfi, j } dfi
zen eigene lokale Indexe voraus, welche von externen Craw-
wobei N die Gesamtanzahl der Dokumente in der Dokumen- lern importiert werden können. Ein konzeptionell zentrales,
tensammlung ist. aber physisch verteiltes Verzeichnis speichert kompakte, ag-
In jüngerer Zeit haben weitere Relevanzmaße basierend gregierte Meta-Informationen über diese lokalen Indexe der
auf statistischen Sprachmodellen und probabilistischer Infor- Peers (bzw. über von den Peers selbst gewählte Teilmengen
mationssuche sehr große Beachtung gefunden [12, 19]. Im davon). Wir benutzen eine verteilte Hash-Tabelle zur Ver-
Rahmen dieses Artikels beschränken wir uns jedoch auf das teilung der Terme, so dass jeder Peer für eine randomisierte
verbreitete TF*IDF-Maß. Teilmenge aller Terme innerhalb des Verzeichnisses verant-
wortlich ist.
Jeder Peer veröffentlicht nun eine Zusammenfassung
4.3 Top-k Anfrageausführung (Post) zu jedem Term in seinem lokalen Index (Abb. 4,
Schritt 0). Diese wird jeweils an denjenigen Peer weiterge-
Ein guter Algorithmus zur Anfrageausführung sollte es ver- leitet, der gerade für diesen Term verantwortlich ist. Dieser
meiden, die Indexlisten für alle Suchterme komplett zu le- Peer verwaltet eine PeerListe aller Posts zu diesem Term aus
sen; vielmehr sollte er idealerweise die investierte Arbeit dem gesamten Verbund. Zur Erhöhung der Ausfallsicherheit
auf O(k) begrenzen, wobei k die Anzahl der gewünschten können diese Listen auch über mehrere Peers repliziert wer-
Resultate beschreibt. In der Literatur wurden verschiedene den. Posts enthalten Kontaktinformationen des absendenden
Algorithmen vorgeschlagen, die diesem Ziel nahekommen. Peers sowie statistische Angaben über den Term innerhalb
Der bekannteste seiner Art ist der sogenannte Schwellwert- des lokalen Indexes.
Algorithmus (Threshold Algorithm, TA) von Fagin [18], der Der Ablauf einer Anfrage mit mehreren Suchtermen sieht
unabhängig auch von Nepal et al. [33] sowie von Güntzer et wie folgt aus. Zunächst besorgt sich der anfragende Peer die
al. [20] entwickelt wurde. Er benutzt absteigend nach Term- PeerListen für alle Suchterme (Abb. 4, Schritt 1). Durch die
gewicht sortierte invertierte Indexlisten unter der zusätzli- Anwendung von Methoden zur Auswahl geeigneter Daten-
chen Annahme, dass die endgültige Relevanz des Dokuments banken ermittelt er die vielversprechendsten Peers für die
mit Hilfe einer monotonen Aggregationsfunktion (z.B. einer Anfrage (Datenbankselektion)3 . Danach wird die Anfrage
gewichtete Summe) berechnet wird. TA traversiert alle inver- an die ausgewählten Peers weitergeleitet, die die Anfrage auf
tierten Indexlisten abwechselnd, d.h. die Listen werden in der
Regel durch (schnelle) sortierte Zugriffe gelesen. Für jedes 3 Abschnitt 8 erläutert nähere Details zur DatenbankselektionDas MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche 157
Abb. 4 P2P-Anfrage-Routing
der Basis ihrer lokalen Indexe ausführen (Abb. 4, Schritt 2). lokale Index enthält Statistiken st ∈ S für jeden Term t aus
Diese Kommunikation findet in dieser Phase durch Punkt-zu- der Menge der indexierten Dokumente Di ⊆ D (gewöhnlich
Punkt-Verbindungen statt. Dies erlaubt eine effiziente Nach- gilt |Di | |D|).
richtenübermittlung und verringert die Last auf dem verteil- Eine Hash-Funktion hash : T → Id wird benutzt, um die
ten Verzeichnis. Schließlich werden die Resultate der ver- Terme auf die verfügbaren Peers zu verteilen. Dies geschieht
schiedenen Peers zu einer gemeinsamen Resultatsliste zu- durch die Zuordnung eines Bezeichners (id ) pro Term. Die
sammengeführt (Query Result Merging4 ). zugrunde liegende Hash-Tabelle besitzt eine Funktion look-
Das Ziel, qualitativ hochwertige Ergebnisse in Bezug auf up : Id → P, die denjenigen Peer pi zurückliefert, der
Präzision und Ausbeute zu erzielen, lässt sich nur schwer momentan für einen Bezeichner zuständig ist.
mit dem Wunsch nach a priori unbegrenzter Skalierbarkeit Ein PeerListRequest ( plr) an einen Peer pi bezüglich
in Einklang bringen, da die besten Methoden zur Informa- eines Terms t ist wie folgt definiert: Die Funktion plr : T ×
tionssuche umfangreiche Statistiken und globale Indexe be- P → 2 P×S liefert diejenigen Tupel ( p j , st ) für alle p j , die
nötigen. Durch die Beschränkung auf kompakte, aggregierte zuvor lokale Statistiken zu dem Term t an pi gesendet haben.
Zusammenfassungen und durch die Begrenzung der tatsäch- Ein Funktionsaufruf lookup(hash(t)) wird benutzt, um den
lich an der Anfrageausführung beteiligten Peers durch die derzeit zuständigen Peer für Statistiken bezüglich des Terms
Datenbankselektion halten wir die Größe des globalen Ver- t ∈ T zu bestimmen.
zeichnisses und den auftretenden Netzwerkverkehr gering. Zum Aufbau des globalen Verzeichnisses publiziert jeder
Gleichzeitig können wir bei der eigentlichen Anfrageausfüh- Peer pi Statistiken st für alle t ∈ Ti ⊆ Ti (Ti ist dabei
rung von den lokalen Indexen profitieren. Dieser Ansatz lässt diejenige selbstgewählte Teilmenge von Ti , über die Peer pi
eine gute Skalierbarkeit des Gesamtsystems erwarten. Informationen veröffentlichen möchte), die das Verzeichnis
Unser Ansatz lässt sich leicht durch zusätzliche Verzeich- wie folgt erzeugen:
nisse erweitern, die neben den statistischen Zusammenfas-
sungen weitere Daten bereithalten, z.B. lokale Lesezeichen systerms : T → 2 P×S
(Bookmarks) der Peers [5], Informationen über vorherige Su- systerms(t) := plr(t, lookup(hash(t)))
chen in Form von Query-Logs und Click-Streams [28], oder
explizite Dokumentbewertungen von Benutzern. Diese In- Das Verzeichnis stellt also eine Abbildung von Termen
formationen lassen sich zur weiteren Verbesserung der Da- nach PeerListen zur Verfügung.
tenbankselektion nutzen. Wir betrachten eine Anfrage q als eine Menge von (Term,
Termgewicht)-Paaren und folglich die Menge aller mögli-
chen Anfragen als Q := 2T ×R . Um nun eine Anfrage q aus-
6 Formalisiertes Systemmodell zuführen muss im Schritt der Datenbankselektion zunächst
eine Menge vielversprechender Peers identifiziert werden.
In diesem Abschnitt formalisieren wir unsere Systemarchi- Dies geschieht mit Hilfe einer Funktion
tektur. Sei P := { pi |1 ≤ i ≤ r } die Menge der aktuell selection : Q → 2 P
im System befindlichen Peers. Sei D := {di |1 ≤ i ≤ n}
die Menge aller im System indexierten Dokumente und sei selection(q) := comb( systerms(t), q)
T := {ti |1 ≤ i ≤ m} dazu analog die Menge aller Terme. (t,w)∈q
Jeder Peer pi besitzt einen lokalen Index für eine Teil-
menge Ti aller Terme (üblicherweise ist |Ti | |T |). Dieser die eine Teilmenge aller Peers dadurch bestimmt, dass sie die
Resultate von systerms mit Hilfe einer geeigneten Funktion
4 siehe auch Abschn. 10 comb : 2 P×S × Q → 2 P verknüpft.158 Matthias Bender et al.
Abb. 5 Systemarchitektur
Die Ausführung einer Anfrage q beschreibt die Funktion MINERVA benutzt eine Java-basierte Re-Implementie-
exec : Q × 2 P → D (D ist eine Liste von Elementen rung von Chord als verteilte Hash-Tabelle, kann jedoch auch
d ∈ D), die die Anfrage an die zuvor durch selection(q) generell mit jeder beliebigen verteilten Hash-Tabelle benutzt
ausgewählten Peers weiterleitet und schließlich die jeweili- werden, die eine lookup(key)-Methode unterstützt. Die Kom-
gen lokalen Resultate zu einer gemeinsamen Resultatsliste munikation unserer Implementierung basiert auf Sockets,
zusammenführt. Schließlich definieren wir die Funktion zur aber andere Kommunikationsformen (z.B. Web-Services [1])
globalen Ausführung einer Anfrage q als result : Q → D könnten einfach integriert werden. Abbildung 6 zeigt die gra-
wie folgt: fische Benutzeroberfläche unseres Prototyps. Der Benutzer
startet das System, indem er entweder einen neuen Chord-
result(q) := exec(q, selection(q))
Ring erzeugt oder einem bestehenden Chord-Ring beitritt.
Beide Operationen benötigen die Angabe eines lokalen Ports
7 Implementierung für die Chord-orientierte Kommunikation sowie eines wei-
teren Ports für die applikations-orientierte Kommunikation.
Abbildung 5 zeigt den Aufbau eines Peers. Er basiert auf einer Das Beitreten zu einem bestehenden Chord-Ring erfordert
verteilten Hash-Tabelle, die das globale Verzeichnis imple- die Kenntnis eines beliebigen vorhandenen Peers, der sich
mentiert. Dieses Verzeichnis liefert eine Beschreibung des bereits im Chord-Ring befindet. Statusinformationen über
zuständigen Peers für einen Term zurück, einen sogenann- den Chord-Ring werden angezeigt und kontinuierlich aktua-
ten PeerDescriptor. Ein Communicator wird instanziiert, um lisiert. Der Bereich Posts zeigt Informationen über die Ter-
Nachrichten an andere Peers zu verschicken. Auf der Gegen- me, für die der Peer derzeit zuständig ist, d.h. für die er Posts
seite besitzt jeder Peer einen EventHandler, der eingehende von anderen Peers empfangen hat. Die Schaltfläche Post star-
Nachrichten empfängt und an die jeweilige lokale Kompo- tet das Publizieren der Zusammenfassungen über den loka-
nente weitergibt. len Index an das verteilte Verzeichnis. Der Bereich Queries
Jeder Peer besitzt einen lokalen Index. Dieser wird von startet Anfragen mit beliebig vielen Suchtermen, die in ein
der eigenen Suchkomponente (Local QueryProcessor) be- Formularfeld eingegeben werden können. Die endgültigen
nutzt, um Anfragen lokal zu bearbeiten, sowie vom Poster, Resultate werden sortiert nach ihrer Relevanz ausgegeben.
der für das Versenden der aggregierten und termspezifischen
Zusammenfassungen an das globale Verzeichnis zuständig
ist. Dazu benutzt der Poster wiederum die verteilte Hash- 8 Methoden zur Datenbankselektion
Tabelle zum Auffinden des derzeit für einen Term zustän-
digen Peers. Der PeerListProcessor jenes Peers verwaltet Datenbankselektion ist das Problem, Peers zu finden, die An-
die eingehenden Posts für diesen Term aus dem gesamten fragen eines gegebenen Peers mit hoher Resultatsgüte bei ge-
Verbund. Stellt ein Benutzer eine Anfrage, dann benutzt die ringen Kosten ausführen können. Unser Ansatz besteht dabei
Komponente zur globalen Suche (Global QueryProcessor) aus zwei Schritten:
erneut die verteilte Hash-Tabelle, um mit Hilfe einer In-
– Die Identifizierung möglicher Kandidaten
stanz des Communicators für jeden Suchterm die derzeiti- – Die Ermittlung der vielversprechendsten Kandidaten
ge PeerListe zu erhalten. Nach der Datenbankselektion leitet
durch Berechnung eines Gütemaßes, das die erwartete
der GlobalQueryProcessor die Anfrage an die ausgewählten Resultatsgüte in Zusammenhang mit den zu erwartenden
Peers weiter, die wiederum die Anfrage mit Hilfe ihrer Lo-
Kosten bringt
calQueryProcessors ausführen. Schließlich führt der Global-
QueryProcessor diese Ergebnisse zusammen und präsentiert Der erste Schritt wird erreicht, indem alle veröffentlich-
sie dem Benutzer. ten Posts zu den Suchtermen vom Verzeichnis angefordertDas MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche 159
Abb. 6 Benutzeroberfläche des MINERVA-Prototyps
werden. Aus Effizienzgründen kann die Anzahl der zurück- als kollektions-spezifisch; in unserem Kontext ist dabei eine
gelieferten Posts begrenzt werden, so dass nur die besten Kollektion der lokale Index eines Peers. Weiterhin betrach-
Posts (basierend auf einem beliebigen Gütemaß) zurückge- ten wir im Folgenden nur Anfragen mit gleichgewichteten
liefert werden. Im zweiten Schritt werden alle Posts eines Termen, d.h. die Anfragen sind Mengen von Termen.
Peers kombiniert, um die erwartete Resultatsgüte des Peers
für diese konkrete Anfrage abzuschätzen (Datenbankselek-
tion). Das eingangs erwähnte Gütemaß beschreibt dabei den 8.1 cdf − ctf max Ansatz
erhofften Beitrag dieses Peers zu den endgültigen Resulta-
ten, während die erwarteten Kosten den Ressourcenbedarf, Dieser einfache ad-hoc Ansatz kombiniert die Dokument-
die aktuelle Lastsituation des Peers oder seine Netzwerkan- häufigkeit innerhalb einer Kollektion (cdf ) mit der maxima-
bindung berücksichtigen. Für diese dynamische Kostenab- len Termhäufigkeit einer Kollektion (ctf max ) (der maximalen
schätzung gibt es diverse Ansätze in der Literatur (siehe Häufigkeit des Terms in einem Dokument in der Kollektion)
z.B. [27]). Die einfachste Herangehensweise ist es, die spe- und summiert diese Werte für alle Suchterme. cdf ist also für
zifischen Kapazitäten und Auslastungen der Peers sowie des einen Term t bzgl. eines Peers pi die Anzahl der Dokumente
Netzwerkes zu ignorieren und statt dessen anzunehmen, dass im lokalen Index von pi , die den Term t enthalten; ctf max
die gesamten Kosten der Anfrageausführung proportional ist für einen Term t bzgl. eines Peers pi die Termhäufigkeit
mit der Anzahl der beteiligten Peers steigen. In diesem Ar- (tf ) von t in genau jenem Dokument d des lokalen Indexes
tikel wählen wir diese vereinfachte Herangehensweise und von pi , welches die höchste tf für diesen Term t unter allen
konzentrieren uns auf die Betrachtung der erwarteten Dokumenten von pi besitzt.
Resultatsgüte. Die Ähnlichkeit si des i-ten Peers bzgl. einer Anfrage q
In den folgenden Abschnitten werden verschiedene Stra- wird demnach wie folgt berechnet:
tegien vorgestellt, die sich zur Datenbankselektion eignen.
si = α · log cdfi,t + (1 − α) · log ctfi,t
max
Weitere Strategien wurden in der Literatur vorgeschlagen; zu
t∈Q
nennen ist hier insbesondere auch der entscheidungstheoreti-
sche Ansatz von Fuhr [19]. In Analogie zur bestehenden Li- Der Parameter α kann dabei Werte zwischen 0 und 1 an-
teratur bezeichnen wir die verschiedenen statistischen Maße nehmen und bestimmt den relativen Einfluss von cdf bzw.160 Matthias Bender et al.
ctf max . Die Werte si werden für alle betrachteten Kollektionen 8.3 GlOSS-artiger Ansatz
berechnet; in absteigender Reihenfolge sortiert ergibt sich so
die mit diesem Ansatz berechnete Kollektionsrangfolge. Diese Strategie basiert auf der Arbeit über das GlOSS-Sys-
tem [22]; wir bezeichnen diesen Ansatz als GlOSS-artig. Zu-
nächst werden die Suchterme aufsteigend nach ihren cdf-
8.2 CORI-artige Ansätze Werten sortiert (der Einfachheit wegen nummerieren wir die
Terme t1 , t2 , . . . , tq entsprechend dieser Sortierung), d.h. für
In diesem Abschnitt betrachten wir zwei Ansätze, die auf jedes Paar tt , tt+1 gilt cdft ≤ cdft+1 .
den Arbeiten über das CORI-System [6, 13] basieren. Wir In einem zweiten Schritt wird die durchschnittliche Term-
avg
bezeichnen diese Ansätze als CORI1 bzw. CORI2. häufigkeit (ctft ) pro Dokument innerhalb einer Kollektion
berechnet, indem die Häufigkeit eines Terms in einer Kol-
lektion (ctf ) in Verhältnis zur Dokumenthäufigkeit innerhalb
CORI1 einer Kollektion (cdft ) gesetzt wird:
Dieser Ansatz berechnet die Ähnlichkeit si des i-ten Peers avg ctft
bzgl. einer Anfrage q wie folgt: ctft =
cdft
si,t
si = Nun berechnet sich das Ähnlichkeitsmaß des i-ten Peers
t∈q
|q| bzgl. einer Anfrage q wie folgt:
si,t = α + (1 − α) · Ti,t · Ii,t
q
q
avg |Ci |
Die Berechnungen von Ti,t und Ii,t benutzen dabei die si = cdfi,t − cdfi,t−1 · ctfi,u · log
u=t
cdfi,u
maximale Größe des Chord-Rings als obere Schranke zur t=1
Abschätzung der Anzahl der Peers im System (np), die Do-
kumenthäufigkeit innerhalb einer Kollektion (cdf ) und die mit cdfi,0 := 0, wobei |Ci | die Anzahl der Dokumente in der
maximale Termhäufigkeit einer Kollektion (cdf max ): i-ten Kollektion darstellt.
log(cdfi,t + 0.5)
Ti,t = β + (1 − β) · max
log(cdfi,t + 1.0) 8.4 Ansätze basierend auf statistischen Sprachmodellen
log(np + 0.5)
cft Die beiden nächsten Ansätze beruhen auf statistischen Sprach-
Ii,t =
log(np + 1) modellen (Language Models, LM).
wobei die Kollektionshäufigkeit cft die Anzahl der Kollektio-
nen beschreibt, die den Term t enthalten. Wir schätzen diesen LM nach Callan
Wert durch die Länge der entsprechenden PeerListe für die-
sen Term t ab. Die Parameter α und β werden analog zu [13] Basierend auf [37] berechnen wir das Ähnlichkeitsmaß einer
als α = β = 0.4 gewählt. Kollektion wie folgt:
si = log(λ · si,t + (1 − λ) · sGE,t )
CORI2 t∈Q
Dieser Ansatz beruht auf der in [6] vorgestellten Methode wobei sGE,t das statistische Modell der englischen Sprache
und unterscheidet sich von CORI1 durch die Berechnung (General English) darstellt und λ einen Parameter zur Ka-
von Ti,t . Wir betrachten die Größe Vi des Termraums einer librierung. Wir approximieren dieses Modell dadurch, dass
Kollektion (d.h. die Anzahl verschiedener Terme innerhalb wir die Häufigkeit eines Terms t innerhalb einer Kollektion
ihres Indexes) und bilden den Durchschnitt V avg über alle durch die Gesamtanzahl der verschiedenen Terme in der Kol-
Kollektionen, die diesen Term t enthalten: lektion teilen. Weiterhin wählen wir λ = 0.7 und berechnen
das Ähnlichkeitsmaß si,t wie folgt:
cdfi,t
Ti,t = |Vi |
cdfi,t + 50 + 150 · |V avg | ctfi,t
si,t =
csi
In der Praxis ist es schwierig, den Wert V avg exakt zu
bestimmen. Wir wählen daher als Abschätzung den Durch- wobei csi die Größe der i-ten Kollektion als Summe der
schnitt über alle Kollektionen, die wir bei der Ausführung Termhäufigkeiten (nicht: die Anzahl verschiedener Terme!)
einer Datenbankselektion in den PeerListen vorfinden. darstellt.Das MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche 161
LM nach Xu & Croft welche wir von http:/www.wordtracker.com über-
nommen haben, sowie 3 weitere ausgewählte Anfragen. Ta-
Der zweite Ansatz basiert auf [44]. Wir berechnen die Distanz belle 2 zeigt alle Anfragen.
zwischen einer Anfrage und einer Kollektion wie folgt: Für jede Anfrage berechnen wir zunächst eine ideale Kol-
lektionsrangfolge wie folgt: Die Anfrage wird zunächst auf
1 1 der Referenzkollektion unter Anwendung der in Abschn. 4
disti = · log vorgestellten Methoden ausgeführt und liefert ein Referenz-
|q| |q| · si,t
t∈Q resultat. Anschließend wird die Anfrage auf jeder Kollek-
ctfi,t + 0.01 tion einzeln unter Anwendung der gleichen Strategie aus-
wobei si,t = geführt. Diese Ergebnisse werden jeweils mit Hilfe des in
cs,i + 0.01 · |Vi |
Abschn. 9.2 vorzustellenden Distanzmaßes mit dem Refe-
Die Kollektionsrangfolge ergibt aus der Sortierung der renzergebnis verglichen. Die Kollektionen werden zur Er-
Kollektionen in aufsteigender Reihenfolge dieser Distanzen. langung der idealen Kollektionsrangfolge aufsteigend nach
ihrer Distanz zum Referenzergebnis sortiert.
Wir evaluieren die Methoden zur Datenbankselektion, in-
dem wir ihre Kollektionsrangfolgen mit dieser idealen Kol-
9 Experimente lektionsrangfolge vergleichen (erneut durch Anwendung des
Distanzmaßes aus Abschn. 9.2). Abbildung 7 illustriert den
9.1 Aufbau Versuchsaufbau.
Es gibt eine Reihe von Parametern, die die Ergebnisse der
Für unsere Experimente werden 10 thematisch fokussierte Experimente beeinflussen: Die Anzahl der Kollektionen in
Kollektionen benutzt, die aus Webcrawls ausgehend von ma- der idealen Kollektionsrangfolge, die Anzahl der Kollektio-
nuell ausgewählten Startseiten zu den Themen Sport, Infor- nen, die die Methoden zur Datenbankselektion zurückliefern,
matik, Unterhaltung und Gemischtes entstanden sind. Jede die Anzahl der Dokumente, die von der Referenzkollektion
dieser Kollektionen wird im Rahmen der Experimente je- zurückgeliefert werden, oder die Anzahl der Dokumente, die
weils genau einem Peer zugeordnet. Zusätzlich wird eine von den einzelnen Kollektionen zurückgeliefert werden.
Referenzkollektion erstellt, indem die einzelnen Kollektio- In allen Experimenten werden 10 Peers (entsprechend der
nen vereinigt (und Duplikate eliminiert) werden. Tabelle 1 10 Kollektionen) als separate Prozesse auf einem Notebook
zeigt Details der Kollektionen, insbesondere auch den Grad mit einem Pentium M 1,6 GHz Prozessor und 1 GB Haupt-
ihrer Überlappung. speicher gestartet. Alle Peers greifen auf eine gemeinsame
Als Anfragen dienen uns die 7 häufigsten Anfragen der Oracle 10g Datenbank zurück, die auf einem separaten Ser-
Websuchmaschine AltaVista für den 21. September 2004, ver (Dual-Xenon, 3 GHz, 4 GB Hauptspeicher) installiert ist.
Die Peers sind durch ein lokales 100 Mbit/s Netzwerk mit
dem Server verbunden.
Tabelle 1 Statistiken zu den verwendeten Kollektionen
Kollektion # Dokumente Größe der
Kollektionen 9.2 Distanzmaß
in MB
Informatik 1 10459 137 Formal betrachtet ist eine Rangfolge σ eine Bijektion von
Gemischtes 2 12400 144 einer Definitionsmenge Dσ nach [k], wobei |Dσ | = k und
Unterhaltung 2 11878 134 [k] := {1, . . . , k}. Metriken zum Vergleich solcher Rangfol-
Sport 1 12536 190 gen sind schon lange Gegenstand intensiver Forschung [15,
Informatik 2 11493 223
Informatik 3 13703 239
23]. Eine der bekanntesten Metriken ist Spearman’s footrule
Informatik 4 7453 695 metric [14, 15], die die Differenz zwischen zwei Rangfolgen
Sport 2 33856 1086 σ1 und σ2 mit D = Dσ1 = Dσ2 wie folgt berechnet:
Gemischtes 2 16874 809
Unterhaltung 2 18301 687 F(σ1 , σ2 ) := |σ2 (i) − σ1 (i)| (2)
168953 4348 i∈D
Referenzkollektion 142206 3808
Wir benötigen ein Distanzmaß zum einen beim (i) Ver-
gleich der Resultatslisten der einzelnen Kollektionen jeweils
Tabelle 2 Verwendete Anfragen (* kennzeichnet Anfragen, die nicht mit der Resultatsliste der Referenzkollektion (zur Berech-
von WordTracker übernommen wurden) nung der idealen Kollektionsrangfolge) und zum anderen
Max Planck Light Wave Particle* Einstein Relativity Theory* beim (ii) Vergleich verschiedener Kollektionsrangfolgen mit
Lauren Bacall Nasa Genesis der idealen Kollektionsrangfolge. In unserem Fall sind die
Hainan Island Carmen Electra Definitionsmengen Dσ1 und Dσ2 also nicht notwendigerwei-
National Weather Service Search Engines se identisch; bezeichnen wir mit σ1 jeweils die idealen Rang-
John Kerry George Bush Iraq*
folgen, so ist im Fall (ii) Dσ1 eine Obermenge von Dσ2 . Im162 Matthias Bender et al.
Abb. 7 Schematischer Aufbau der
Experimente
Fall (i) kommt erschwerend hinzu, dass in der begrenzten nur über die Elemente aus Dσ2 summieren. Daher ist F nicht
Resultatsliste der Referenzkollektion nicht notwendigerwei- symmetrisch.
se alle Dokumente vorkommen, die von einzelnen Kollektio- Ein weiteres Problem ergibt sich, wenn unterschiedlich
nen in deren Resultatslisten geliefert werden. Daher können große Rangfolgen mit einer Referenzrangfolge verglichen
wir weder Spearman’s footrule metric (2) noch andere be- werden sollen. Um Ungerechtigkeiten beim Vergleich von
kannte Metriken (z.B. Kendall’s Tau [23]) unmittelbar ein- kurzen Rangfolgen (mit guten Resultaten) gegenüber lan-
setzen. [17] liefert einen Überblick über Metriken, die Top-k- gen Rangfolgen (mit weniger guten Resultaten im hinteren
Listen als unvollständige Rangfolgen betrachten und Modifi- Bereich der Rangfolge) zu vermeiden, setzen wir eine Min-
kationen verbreiteter Metriken vorstellen, die eine sinnvolle destlänge für jede Rangfolge σ2 voraus und füllen kürzere
Anwendung erlauben. Eine Möglichkeit zur Anwendung der Rangfolgen entsprechend mit künstlichen Elementen auf, die
bekannten Metriken auf Top-k-Listen ist es, die Listen kon- dem Rang |Dσ1 | + 1 in der Referenzrangfolge entsprechen.
zeptionell zu Listen über der vereinigten Definitionsmenge
der beiden Rangfolgen zu erweitern.
Wir schlagen analog die folgende Formel zur Berechnung 9.3 Experimentelle Ergebnisse
der Distanz zwischen zwei Rangfolgen σ1 und σ2 vor:
Abbildung 8 stellt die Distanzen zwischen den von den ver-
F (σ1 , σ2 ) := |σ2 (i) − σ1 (i)| (3) schiedenen Methoden zur Datenbankselektion ergebenen
i∈Dσ2 Kollektionsrangfolgen und der idealen Kollektionsrangfolge
dar. Die Distanzen basieren auf dem in Abschn. 9.2 vorge-
Auch wenn diese Formel auf den ersten Blick Spearman’s stellten Distanzmaß und sind über unsere 10 Anfragen gemit-
footrule metric sehr ähnelt, so summiert sie im Unterschied zu telt. Für unsere Menge an Anfragen lieferte CORI2 die besten
ihr über alle Elemente aus Dσ2 . Allerdings ist (3) nur gültig, Ergebnisse und distanziert damit das GlOSS-artige Verfahren
falls Dσ1 eine Obermenge von Dσ2 ist, da σ1 (i) anderenfalls sowie die Ansätze basierend auf statistischen Sprachmodel-
für alle i ∈ Dσ2 \ Dσ1 undefiniert wäre. Daher benötigen wir len. Das Ad-hoc-Maß cdf − ctf max hält sich erstaunlich gut.
die Definition einer Fortsetzung σ1 von σ1 wie folgt, um die Das schlechte Abschneiden der Sprachmodelle widerspricht
Obermengeneigenschaft herzustellen: den Ergebnissen aus [37]; wir untersuchen derzeit die ge-
nauen Ursachen hierfür. Erste Ergebnisse deuten darauf hin,
σ1 (i) i ∈ Dσ1 dass sich sowohl die von uns gewählten konkreten Anfragen
σ1 (i) :=
|Dσ1 | + 1 i∈/ Dσ1 als auch die zugrunde liegenden Kollektionen (durch ihre
Überlappung) als ungünstig für diese Ansätze herausgestellt
Die Intuition hinter dieser Fortsetzung ist, dass sich alle haben.
Elemente in den Rangfolgen der Referenzrangfolgen befin- Auf den gleichen Kollektionen beobachten wir die Aus-
den müssen. Wir wählen den kleinstmöglichen Rang |Dσ1 |+1 beute in Relation zu den Top-30-Dokumenten der Referenz-
als Approximation des tatsächlichen Rangs. Zu beachten ist kollektion. Dafür senden wir die Anfrage nacheinander an
auch, dass wir keine Erweiterung von σ2 benötigen, da wir alle Kollektionen in absteigender Reihenfolge der idealenDas MINERVA-Projekt: Datenbankselektion für Peer-to-Peer-Websuche 163
Abb. 10 Laufzeitverhalten
Abb. 8 Vergleich verschiedener Methoden zur Datenbankselektion
Abb. 11 Ausbeute (absolut und als Differenz) in Abhängigkeit von der
Anzahl befragter Peers
cen (CPU, Netzwerkverkehr) stehen in einem Missverhältnis
zur erreichbaren Verbesserung des Resultats.
In unserem Versuchsaufbau, der eine hohe Last auf dem
verwendeten Notebook erzeugt, dauert die Ausführung ei-
ner Anfrage etwa 2 Sekunden pro angefragtem Peer. Die
Abb. 9 Ausbeute (in %) in Abhängigkeit von der Anzahl befragter
Peers Ausführungszeit wird dabei klar dominiert von der Dau-
er der Anfrageausführung auf dem lokalen Index. Die von
MINERVA benötigte Zeit zur Datenbankselektion ist ver-
nachlässigbar. Abbildung 11 zeigt die Anzahl erhaltener re-
Kollektionsrangfolge. Abbildung 9 zeigt, dass bereits die be- levanter Dokumente als Funktion der angefragten Peers. Wie
ste Kollektion durchschnittlich etwa 60 % aller relevanten Er- erwartet tragen weniger relevante Kollektionen nur noch we-
gebnisse liefert, während die schlechteren Kollektionen typi- nige relevante Dokumente zum endgültigen Ergebnis bei.
scherweise nicht mehr viele relevante Dokumente beitragen. Wir betrachteten außerdem die Effizienz unseres Proto-
Dies bedeutet jedoch nicht, dass diese keine relevanten Do- typs zur Laufzeit. Dazu beobachteten wir die folgenden Ei-
kumente enthalten, sondern lediglich, dass ihre relevanten genschaften, die unabhängig von der gewählten Methode zur
Dokumente bereits zuvor von anderen Kollektionen beige- Datenbankselektion sind: Die Größe eines einzelnen Posts
steuert worden sind. Dies unterstreicht die Wichtigkeit, die für einen Term beträgt etwa 20 Bytes. Die Gesamtmenge an
Überlappung der einzelnen Kollektionen bei der Datenbank- Daten, die beim Publizieren der Posts über das Netzwerk ge-
selektion zu berücksichtigen. sendet werden muss, beläuft sich auf etwa 650 kB bei einer
Dies wird noch deutlicher, wenn man den Ressourcen- Kollektion mit 45 000 verschiedenen Termen. Dabei benut-
verbrauch der Anfragen in Abhängigkeit von der Anzahl der zen wir gzip zur Datenkompression.
erhaltenen relevanten Resultate bei steigender Anzahl an be- Die Anfrage nach einer PeerListe benötigt etwa 150 By-
fragten Peers betrachtet. Abbildung 10 zeigt, dass bei unse- tes. Die Größe der eigentlichen PeerListe ist abhängig von
rem Versuchsaufbau auf einem einzelnen Notebook die Aus- ihrer Länge und beträgt etwa 1000 Bytes für eine Liste von 10
führungszeit annähernd linear zur Anzahl der befragten Peers Peers (wobei wir die maximale Länge der zurückgegebenen
verläuft. In der Realität erwarten wir, dass die Ausführungs- PeerListen zur Verbesserung der Systemleistung begrenzen
zeit nahezu konstant bleibt, da sich die Last über eine An- können). Die eigentliche Suchanfrage (2 Suchterme) verur-
zahl von unabhängigen Prozessoren verteilt. Trotzdem sollte sacht lediglich etwa 100 Bytes Netzwerkverkehr, die Rückga-
es in der Praxis vermieden werden, Peers zu befragen, die be von 30 lokalen Resultaten jeweils etwa 2500 Bytes (darin
nur noch wenige neue Dokumente zur endgültigen Resul- sind allerdings noch umfangreiche Statistiken enthalten, die
tatsliste beitragen. Die dabei systemweit benutzen Ressour- der anfragende Peer zum sinnvollen Kombinieren der lokalen164 Matthias Bender et al.
Ergebnisse bzw. zum Ranking der endgültigen Resultatsliste folgendermaßen:
einsetzen kann). |Ci |
Die Komplexität der Methoden zur Datenbankselektion log cdf
kann grob mit O(nl + m log(m)) angegeben werden, wobei si, j = rtft, j · i,t
log |Ci |
m die Anzahl der Kollektionen darstellt, n die Anzahl der t∈Q
Suchterme in einer Anfrage und l die Länge der längsten
Die Dokumente aus den verschiedenen Resultatslisten
PeerListe. nl ist dann eine obere Schranke für die Anzahl zu
werden schließlich nach si, j absteigend sortiert ausgegeben.
bearbeitender Posts, bevor die Kollektionsrangfolge (höch-
Dieses Vorgehen erfordert eine weitergehende Koopera-
stens m Einträge) in O(m log(m)) sortiert werden kann.
tion der einzelnen Peers, da sie zu jedem Dokument um-
fangreichere Statistiken liefern müssen. Die Verwendung der
jeweiligen lokalen Statistiken (z.B. der Dokumenthäufigkeit
10 Zusammenführung der Resultatslisten
innerhalb einer Kollektion) führt allerdings immer noch nicht
notwendigerweise zu vergleichbaren Werten. Mögliche Lö-
Neben dem Problem der Datenbankselektion (vgl. Abschn. 8)
sungen dieses Problems bestehen darin, bei der Berechnung
ergibt sich bei der Architektur von MINERVA ein weiterer
auf (ggf. approximierte) globale Statistiken oder auf die loka-
wichtiger Aspekt, auf den in diesem Abschnitt kurz einge-
len Statistiken des anfragenden Peers zurückzugreifen. Letz-
gangen werden soll. Die einzelnen angefragten Peers liefern
terer Ansatz verspricht, beim Query Result Merging das In-
ihre lokalen Resultate an den anfragenden Peer zurück. Die-
teressenprofil des anfragenden Benutzers besonders zu be-
ser muss diese Listen zu einer gemeinsamen Resultatsliste
rücksichtigen. Zusätzlich können diese Werte noch durch die
zusammenführen. Dieser Vorgang wird auch als Query Re-
im Rahmen der Datenbankselektion gewonnenen Bewertun-
sult Merging bezeichnet. Beim Zusammenführen der Resul-
gen der einzelnen Peers angepasst werden.
tatslisten ergeben sich verschiedene Ansätze:
Die Evaluierung der verschiedenen Ansätze ist Gegen-
– Ansätze, die ausschließlich auf dokument- bzw. term- stand aktueller Forschung im Rahmen des MINERVA Pro-
spezifischen Statistiken der zurückgelieferten Dokumen- jekts, um auch in diesem Bereich Aussagen zur Qualität der
te aufbauen. verschiedenen Ansätze treffen zu können.
– Ansätze, die zusätzlich die im Rahmen der Datenbankse-
lektion berechneten Gütemaße (z.B. basierend auf CORI
oder statistischen Sprachmodellen) der einzelnen Kollek- 11 Zusammenfasung und Ausblick
tionen berücksichtigen [6, 37].
Wenn man voraussetzt, dass die einzelnen Peers im Rah- Dieser Artikel hat MINERVA vorgestellt, die prototypische
men der Anfrageausführung bereits ein (lokales) Gütemaß Implementierung einer P2P-Suchmaschine. Wir haben unse-
der von ihnen gelieferten Dokumente (z.B. basierend auf re neuartige Architektur illustriert, bekannte Methoden zur
Termhäufigkeiten, vgl. Abschn. 4) berechnet haben, so be- Datenbankselektion aufgegriffen und sie an unser Umfeld
steht eine naive Möglichkeit zum Query Result Merging dar- angepasst. Unsere vorläufigen Ergebnisse zeigen die quali-
in, alle Dokumente anhand dieses bereits vorhandenen Gü- tativen Unterschiede der verschiedenen Methoden sowohl in
temaßes zu sortieren. In der Praxis wirft dieses Verfahren Bezug auf die Kollektionsrangfolge als auch in Bezug auf die
jedoch einige Probleme auf. Damit die einzelnen Werte auch daraus resultierende Resultatsgüte. In unserem Versuchsauf-
über die Kollektionsgrenzen hinweg vergleichbar sind, würde bau überzeugte eine CORI-artige Methode zur Datenbankse-
dieses Verfahren eine systemweit einheitliche Strategie zur lektion und selbst eine einfach Ad-hoc-Methode schlug fort-
Berechnung der Gütemaße erfordern. Doch selbst dann wä- geschrittene Modelle. Unsere Experimente zeigen außerdem,
ren die Gütemaße aufgrund verschiedener kollektions-spe- dass MINERVA zur Laufzeit kaum zusätzliche Ressourcen
zifischer Statistiken innerhalb der Berechnung (z.B. lokaler erfordert und dass eine geringe Anzahl befragter Peers typi-
Dokumenthäufigkeiten) nicht untereinander vergleichbar. scherweise bereits einen Großteil der relevanten Dokumente
MINERVA bewertet Dokumente, indem es die Relevanz liefert. All diese Resultate beziehen sich jedoch ausdrücklich
der Dokumente mit Hilfe der mitgelieferten Statistiken neu derzeit nur auf unsere speziellen Versuchsbedingungen.
berechnet und sich nicht auf die von den Peers (u.U. mit Wir bereiten derzeit Experimente auf deutlich größeren
verschiedenen Methoden) lokal berechneten Werte verlässt. Dokumentsammlungen vor. Zusätzlich arbeiten wir an auto-
Wir erreichen somit eine übereinstimmende Berechnung des matisierten Techniken zur Expansion der Anfragen. Die Me-
Gütemaßes für alle Dokumente. Hierbei wird die relative thoden zur Datenbankselektion sollen außerdem durch Hin-
Termhäufigkeit (rtf ) eines Terms in einem Dokument mit der zunahme von Lesezeichen (Bookmarks) [5] sowie durch eine
Dokumenthäufigkeit innerhalb einer Kollektion (cdf) und der explizitere Betrachtung der Überlappung zwischen den ein-
Anzahl der Dokumente in der Kollektion (|C|) kombiniert. zelnen Kollektionen weiter verbessert werden. Idealerweise
Die relative Termhäufigkeit ist hierbei der Quotient aus der sollte eine Anfrage nur an solche Peers weitergeleitet werden,
Termhäufigkeit des Terms und der Gesamtzahl aller Wörter die ein Komplement zu den anderen befragten Peers darstel-
bezogen auf das jeweilige Dokument. MINERVA berechnet len (d.h., die eine geringe Überlappung untereinander aufwei-
die Ähnlichkeit eines Dokumentes j, welches in der Resul- sen). Falls nämlich der befragte Peer die gleichen qualitativ
tatsliste von Peer pi aufgeführt wird, zu einer Anfrage Q hochwertigen Dokumente liefern kann, die der anfragendeSie können auch lesen
