Webis2 Performance

Gruppe Webis2
Vorstellung des Projektes
„MagicMediaSearch“
www.mms.de.vu
Sven Bittner, Moritz Blöcker, Valerie Bures, Heiko
Kahmann, Mariusz Kukulski, Kilian Lenz, Olaf Licht,
Fabian Wiesel, Thomas Zahn
24.01.2001
Gliederung
 Einleitung und Aufgabenstellung
 Gruppenübersicht und Verteilung der Aufgaben
 Vorstellung der Teilaufgaben:
–
–
–
–
–
–
Crawler (Heiko)
Web-Parser (Mariusz)
Indexer und Index (Thomas)
Searcher (Fabian)
Ranker (Moritz)
GUI und GUI-Parser (Sven)
 Testszenarien
 Probleme und Verbesserungsmöglichkeiten
 Onlinepräsentation des kompletten Systems
Einleitung und
Aufgabenstellung
 Es soll eine Suchmaschine für Medien-Dateien (insbesondere mp3Files etc.) in JAVA programmiert werden, die über ein Web-Interface
abgefragt werden kann.
 Die in der VL vorgestellten Verfahren und Algorithmen sollen
angewendet werden.
 Das System soll aus Crawler, Parser, Index, Retrieval-Einheit bestehen.
 Zu indexieren ist/sind:
–
–
HTML oder ASCII-Text (sog. „Textseiten“)
Dateien mit Musik bzw. Video (sog. „Mediendateien“)
 Lexikographische Vorverarbeitung:
–
–
–
Stemming (deutsch und englisch)
Stoppwortentfernung (deutsch und englisch)
Einbindung eines Thesaurus (wenn möglich)
 Anfragesprache:
–
–
–
Anfragen auf Titel (matching) und Wortanfänge mit geranktem Ergebnis
Phrasensuche
Proximity-Operatoren (nearby ...)
Verteilung der Aufgaben

Mariusz, Heiko und Sven:
Crawler, WebParser und URL-Liste

Dieses Diagramm gibt einen groben Anhaltspunkt
und nicht die eigentliche Klassenaufteilung wieder!
Kilian, Thomas und Valerie:
List von
URLs
Index und den Indexer

Fabian und Olaf:
Searcher

Internet
Web
Parser
Index
Indexer
Moritz:
Ranker

Crawler
Sven:
GUI und den GUI-Parser
GUI
Parser
Search
GUI
Ranker
Crawler
Gliederung
 1.Was ist der Crawler ?
 2. Wie ist der HTMLCrawler standardmässig aufgebaut ?
 3. Welche weiteren Features besitzt unser HTMLCrawler
–
–
–
–
–
3.1 Serielles Laden
3.2 Paralleles Laden
3.3 Arbeiten mit einer „URLList“
3.4 Beachtung von „Robot.txt“
3.5 Laden von MP3-Attributen
 4. Sinnvolle Erweiterungen
–
–
4.1 Setzen eines TimeOuts für die URLConnection
4.2 Einsatz einer CrawlerQueue
Crawler
Funktion und Aufbau
1. Was ist der Crawler ?
• Crawler bedeutet „Kriecher“, „Kriechtier“ oder auch „Laufkette“
• Der Crawler „kriecht“ durch das Internet und sammelt Informationen
• Crawler.java ist unser Interface für den HTMLCrawler.java
2. Wie ist der Crawler standardmässig aufgebaut ?
• Er besitzt die Funktion „Accumulator loadWebSite(URL url)“
• Auf dem URL-Object nutzt er die Funktion openConnection()
-> erhalten eines URLConnection-Objects
-> Auslesen benötigter Informationen über einen InputStream
der URLConnection (Siehe Vortrag über Internetverbindung über Java)
• Rückgabewert ist ein Object vom Typ Accumulator mit Inhalt
„WebSite als String“, „LastModified als Date“, und die URL der Seite
Crawler
Features des HTML-Crawlers
3.1 Serielles Laden
- ein aussenstehender Prozess (SeriellWebParser) übergibt dem
HTMLCrawler eine zu ladende URL und wartet, bis die Funktion
loadWebSite() das Ergebnis zurückliefert.
Beliebiger Prozess
z.B.
SeriellWebParser
HTMLCrawler
Ladevorgang
- Nachteil :
-> der aussenstehende Prozess (z.B. SeriellWebParser)
wartet die Zeit des Ladevorganges auf das Weiterarbeiten
- Vorteil :
-> einfacher Einsatz, einfache Kommunikation
Crawler
Features des HTML-Crawlers
3.2 Paralleles Laden
- ein aussenstehender Prozess (SeriellWebParser) übergibt dem
HTMLCrawler eine zu ladende URL. Der aussenstehende
Prozess kann weiter arbeiten, in der Zeit, in der der
HTMLCrawler die Informationen lädt.
Beliebiger Prozess
z.B.
ParallelWebParser
Weitere Arbeit
des Prozesses
HTMLCrawler
- Nachteil :
-> komplizierte Kommunikation
(siehe später Stichwort CrawlerQueue)
- Vorteil :
-> kein Zeitverlust für aussenstehenden Prozess, z.B
ParallelWebParser
Ladevorgang
Crawler
Features des HTML-Crawlers
3.3 Arbeiten mit einer URLList
- Die URLList ist nicht die Liste der zu besuchenden URL´s
- Die URLList ist ein Object zum Testen, ob eine URL schon
geladen wurde. (Beim Testen wird die URL abgespeichert)
URL
checkURL(URL url)
Prozess,
z.B.
HTMLCrawler
SeriellWebParser
Accumulator
URLFoundException
- Nachteil :
-> Zeitverlust durch Vergleich aktueller URL mit allen schon
geladenen URL´s
- Vorteil :
-> Verhindern von Schleifen, die durch gegenseitige
Referenzierung von HTML-Seiten entstehen
URLList
Crawler
Features des HTML-Crawlers
3.4 Beachtung von Robot.txt - Dateien
- Robot.txt - Dateien liegen auf den HTTP-Servern
- Robot.txt - enthält alle URL´s, die nicht vom Server
geladen werden können
- Pro zu ladender URL wird die Robot.txt - Datei angefordert
und mit der aktuellen URL verglichen
URL
Prozess,
z.B.
SeriellWebParser
Vergleich
HTMLCrawler
Accumulator
Robot.txt
True / False
- Nachteil :
-> Zeitverlust durch Vergleich aktueller URL mit den
Robot.txt - URL´s
- Vorteil :
-> Verhindern eines Hängenbleibens des Systems,
verursacht durch eine „hängende“ URLConnection
Crawler
Features des HTML-Crawlers
3.5 Auslesen von MP3 - Attributen
- MP3´s enthalten neben dem Lied auch Meta-Infomationen,
wie z.B. Autor, Komponist, Band, Album, LastModified, ...
- Crawler besitzt dazu die seriell arbeitende Funktion
Accumulator loadMP3File(URL url)
-> Accumulator enthält alle Informationen, die das MP3-File
auszeichnen
- Nachteil :
-> Zeitverlust durch öffnen einer neuen Verbindung
zum MP3-File
- Vorteil :
-> Starke qualitative Steigerung der SearchEngine, da das
MP3-File die genauesten Informationen über sich selbst
besitzt (besser als Linktext, Umgebungstext, Link selbst)
Crawler
Sinnvolle Erweiterungen
4.1 Setzen eines TimeOuts für die URLConnection
- TimeOut ist ein parallel laufender Prozess (eigener Thread)
- einem Crawler (HTMLCrawler) kann ein TimeOutObject
gesetzt werden.
- Dem TimeOutObject wird eine Zeit mitgegeben, nach der
es die URLConnection eines Crawlers schliesst.
URL
Prozess,
z.B.
SeriellWebParser
Start
HTMLCrawler
Accumulator /
CrawlerException
disconnect()
- Nachteil :
-> TimeOut musste selbst entwickelt werden, da die
URLConnection dies nicht als Standard unterstützt
- Vorteil :
-> Schnelligkeitssteigerung des Indexierungssystems,
durch vorzeitiges Trennen „langer Leitungen“
TimeOut
ist eigener
Thread
Crawler
Sinnvolle Erweiterungen
4.2 Nutzen einer Crawler-Queue
- Crawler-Queue ist eine Prioritäts-Schlange von n parallel
arbeitenden HTML-Crawlern
- Crawler-Queue kapselt die Kommunikationsaufwand, den
parallel arbeitende HTML-Crawler verursachen
- Arbeitsweise :
Parallel
ladender
HTMLCrawler
setURL(URL)
Prozess,
z.B.
ParallelWebParser
CrawlerQueue
getNextCrawlerContent()
isReady()
Accumulator
Parallel
ladender
HTMLCrawler
Parallel
ladender
HTMLCrawler
- Nachteil :
-> Synchronisation aller parallel arbeitenden HTMLCrawler
ist sehr kompliziert (JavaThreads arbeiten nicht wirklich
parallel)
- Vorteil :
-> Im Prinzip keine Wartezeiten für den ParallelWebParser in
Bezug auf den HTMLCrawler
-> sehr hoher Datendurchsatz erreichbar.
Web-Parser
 Was wird vom Web-Parser verlangt?
 Wie arbeitet der Web-Parser?
 Besonderheiten des Web-Parsers
 Probleme und mögliche Ergänzungen
Web-Parser
 Was wird vom Web-Parser verlangt (1/3)?
Der Web-Parser soll aus den vom Crawler geladenen Seiten schnell
die wichtigsten Informationen filtern.
 Was sind für unsere Suchmaschine wichtige Informationen?
Verweise auf andere Internet-Seiten.
Internet-Seiten die Mediendateien enthalten.
Mediendateien mit Link-Text, Link-Umgebung und URL (bei .mp3Dateien auch der Inhalt der mp3-Tags)
Web-Parser
 Was wird noch vom Web-Parser verlangt (2/3)?
Der Web-Parser soll den Indexaufbau managen (d.h. Crawler, URLList,
URLVector und den Indexer mit Index verwalten).
 Warum soll diese Aufgabe der Web-Parser übernehmen?
Das Design ist mehr aus der Not entstanden.
Der Web-Parser ist das Bindeglied zwischen Crawler und Indexer und
und ruft beide bei Bedarf auf.
Web-Parser
 Was wird noch vom Web-Parser verlangt (3/3)?
Der Web-Parser soll entscheiden in welchen Index eingetragen wird
und sendet „entsprechende Pakete“ an den Indexer.
 Was heißt hier „entsprechende Pakete“?
Für Einträge im
- Medienindex :(Word, MediaURL, Datum, MediaType, SeitenURL,
Sprache, Gewichtung, Position, Überschrift).
- Textindex
:Word(LowerCase), URL, Datum, Type, "", Sprache, 0,
0, Überschrift).
Web-Parser
 Wie arbeitet der Web-Parser?
Bei .mp3-Dateien
zum Auslesen
des MP3-Tags
Einlesen der
Internet-Seiten
(.htm, .html,
.shtml u.s.w.)
Crawler
Web-Parser
MP3-Crawler
Eintragen der
relevanten
Informationen
Indexer
Web-Parser
 Wie arbeitet der Web-Parser?
Web-Parser
Müll
removeStopwords()
URLVector
Spracherkennung
Entscheidung
durch
URLListe
Hat der tagIdentifier() Mediendateien
erkannt, werden diese markiert und der
Indexierungsvorgang wird begonnen.
Falls nicht wird die nächste URL aus dem
URLVector über den Crawler angefragt.
bei Bedarf
MP3Crawler
tagIdentifier()
mediaIndexParser()
linkParser()
Seite ohne Scripte
und Stylesheets
removeStopwords()
htmlIndexParser()
ScriptAndStylesheetDeleter()
Stemmer
neue Internet-Seite
indexieren im
Medienindex
indexieren im
Textindex
Web-Parser
 Besonderheiten des Web-Parsers
Möglichkeiten der Modifizierung in der .properties-Datei:





mediaIndexLinkArea(int) gibt die Umgebung des Links an, der in den
Medienindex eingetragen wird.
maxvectorsize(int) gibt die maximale URLVectorgröße an.
saveDataAfterNParsedSites(int) gibt an, nach wie vielen geparsten
Seiten der Index, der URLVector und die URLList gespeichert
werden sollen.
textFileTypes(String) enthält die Endungen der lesbaren InternetDateien, die vom Crawler geladen werden sollen (aktuell : „html
shtml htm“ ).
mediaFileTypes(String) enthält die Endungen aller Mediendateien, die
indexiert werden sollen (aktuell : „mp3 mpeg avi wav ram mpg
mov“ ).
Web-Parser
 Probleme und mögliche Ergänzungen
Leider zu wenig Zeit für die Planung des Web-Parsers, durch sehr
späten Wegfall der zuständigen Gruppe.
Der sprach-spezifische Stemmer benötigt für eine Seite, die in den
Textindex eingetragen wird sehr viel Zeit (ca. 4/5 des gesamten
Parsingprozesses).
Die Entfernung des Stemmers würde das Parsen stark beschleunigen,
den Index jedoch wesentlich vergrößern (und somit auch die
Wartezeit, von der Seite der GUI aus, erhöhen).
Anfangs wird Breitensuche betrieben. Wenn allerdings der URLVector
seine Maximalgröße erlangt, werden viele, möglicherweise wertvolle,
URL´s ignoriert. Die Breitensuche wird zur Tiefensuche.
Indexer und Index
Gliederung









Anforderungen an den Index
Implementation
Datenstruktur des Index
UML
Indexierungsvorgang
Aktuelle Indexdaten und -größe
Testmöglichkeiten
Indexierungszeiten
Probleme und mögliche Ergänzungen
Indexer und Index
Anforderungen an den Index
 Der Index ist das "Gedächtnis" der Suchmaschine. Hier müssen die
Daten der geparsten Dokumente effizient gespeichert werden, um
schnelles Suchen zu gewährleisten.
 Der Index soll sowohl Wörter aus HTML-Dokumenten als auch Wörter
bzgl. Mediendateien (z.B. Filename, MP3-tag etc.) enthalten. Ferner soll
eine Unterscheidung nach Medienart, Sprache, Alter etc. möglich sein.
–
–
Medienterme sollen nicht gestemmt werden (Phrasensuche!)
Textterme werden gestemmt
 Die Indexstruktur muß folgende Suchanfragen unterstützen:
–
–
–
–
nach einzelnen Wörtern
Wortanfänge
Phrasen (nur im Medienindex)
Near-By
 Optimierung der Suchgeschwindigkeit
 Die Indexierungszeit ist weniger relevant
 Optimierung des Speicherverbrauches durch Kompression
Indexer und Index
Implementation
 Es gibt zwei identische Index-Strukturen. Eine für die Medien-Terme
und eine für die Text-Terme, (damit im Medien-Index die Phrasensuche
möglich ist, müssen die Positionen der Wörter gespeichert werden).
 Für die Zuordnung Term -> Dokument werden Inverslisten benutzt
–
–
–
Beim Text-Index wird zusätzlich die jeweilige Termfrequenz gespeichert.
Im Medien-Index stattdessen ein Rankingfaktor und die Position des Wortes
im Dokument
Die Inverslisten sind gammacodiert.
 Die dokumentspezifischen Daten werden in einer Liste verwaltet:
–
–
–
–
–
–
URL
Medientyp (0=html, 1=ascii, 2=mp3, 3=mpeg, 4=avi usw.)
Sprache (0=deutsch, 1=englisch...)
Kurzer Ausschnitt (Headline o. ä.)
Datum der letzten Änderung
bei Mediendateien auch die URL der Seite, die auf diese Datei zeigt
 Als Grundgerüst für die beiden Indexe wird ein Prefix-Tree verwendet,
der sowohl in den Knoten als auch in den Kanten je einen Verweis zu
einer Inversliste enthalten kann.
 Die Klasse „Index“ enthält sowohl beide Prefix-Trees als auch die
Dokumentenliste als Objekte.
Indexer und Index
Datenstruktur des Index
Postingliste mit drei gamma-codierten
BitSets für die Doc-IDs, die Gewichte
und die Termpositionen zu jedem Term
Daten
0100111101111010...
1001110100101010...
1111001010101101...
b
s
0100111101111010011010011010...
0111010101101001110100101010...
ank
a
nwendung
peicher
s
1101001101011111001010101101...
m
ystem
edium
2 Prefix-Trees
(1x Text-Index, 1x Medien-Index)
Verkettete Liste mit genaueren Informationen zu den Dokumenten
URL A
HTML
...
URL B
MP3
...
URL C
HTML
...
Indexer und Index
UML
Indexer und Index
Indexierungsvorgang
 Der Web-Parser ruft den Indexer auf und übergibt die notwendigen
Daten
 Der Indexer entscheidet anhand des Medientyps und des Aufrufs in
welchem Index der Term eingetragen werden soll (ein Term wird in
beide Indexe eingetragen, wenn er sich in der Link-Umgebung einer
Mediendatei befindet).
 Aufruf der Index-Klasse zum Speichern der dokumentspezifischen
Daten.
 Aufruf der Index-Klasse zum Speichern der termbezogenen Daten
–
Text-Index:
•
•
–
Gibt es den Term schon? Dann erhöhe die Termfrequenz um 1, falls Dokument-ID
schon bekannt, sonst ergänze die Inversliste mit neuer Dok-ID und Termfrequenz 1
Unbekannter Term? Speichere Term im Baum und setze neue Inversliste mit
Termfrequenz 1
Medien-Index:
•
•
Gibt es den Term schon? Ergänze Inversliste um neue Dok-ID, Ranking-Faktor und
Position
Sonst: Erzeuge vorher neuen Eintrag im Baum mit entsprechender Postingliste
 Der Indexer kann auch einen schon vorhandenen Index (File) laden,
ergänzen und wieder speichern.
Indexer und Index
Aktuelle Indexdaten und -größe
 Anzahl an Termen
–
–
im MedienIndex:
im TextIndex:
19096
15727
 Größe der Dokumentenliste:
–
–
–
7100
davon deutsche Dokumente
englische Dokumente
Anzahl verschiedener Dokumenttypen:
•
•
•
•
•
•
•
•
HTML/ASCII
MP3
MPEG
AVI
WAV
RAM
MPG
MOV
101
6999
211
6880
1
1
0
0
2
5
 Speicherverbrauch:
–
–
File:
RAM:
10.5 MB
ca. 37.5 MB
Indexer und Index
Testmöglichkeiten
 Mittels der Klasse „IndexStats“ kann der Inhalt des gesamten Indexes
in lesbarer Form in 3 Textdateien ausgegeben werden:
–
–
–
Alle Terme des Text-Indexes werden mit der Länge der zugehörigen
Inversliste ausgegeben
Alle Terme des Medien-Indexes werden mit der Inverslistenlänge
ausgegeben
Die Dokumentenliste wird mit allen Einträgen ausgegeben
 Die verschiedenen Medientypen werden ebenfalls gezählt.
 Anhand dieser Daten konnten in der Testphase etliche Fehler beseitigt
und Verbesserungen (Speicherverbrauch, Parser etc.) vorgenommen
werden.
 Die Suchzeiten liegen im Millisekundenbereich.
Indexer und Index
Indexierungszeiten
1000
Text-Index
Medien-Index
100
10
Listenlänge
1001-2000
201-300
301-1000
151-200
81-90
101-150
Zeit: ca. 1 h für man-page-Index
71-80
61-70
51-60
41-50
31-40
21-30
11-20
5
6-10
4
1
91-100

Durch gesonderte Test konnte
gezeigt werden, daß die Lauf-Zeit
hauptsächlich von den PostingListen bestimmt ist. Da diese häufig
codiert/decodiert werden müssen
und des Gammacodes wegen nur
sequentiellen Zugriff erlauben.
10000
3
–
100000
2

Längenverteilung der Posting-Listen
1

Für den ersten Test des
Indexers/Indexes wurde die ManPage-Sammlung aus 528 Dateien
genutzt und nur Wörter
aufgenommen, die länger als 3
Buchstaben waren.
Die Indexierungszeit wurde jeweils
für ein komplettes Dokument
gemessen und dann durch die
Anzahl der Terme dividiert. (Die
Zeiten für eine einzige TermIndexierung waren bis zu einer
bestimmten Indexgröße nicht
meßbar.)
Zeitwachstum mit O(n*log(n)).
Anzahl der Terme

Indexer und Index
Probleme und mögliche Ergänzungen
 Das Löschen bzw. Aktualisieren der Daten im Hinblick auf das
Entfernen von Dokumenteinträgen ist nicht vorgesehen.
 Es wäre möglich aber recht aufwendig, da alle Postinglisten zu jedem
Term durchsucht und dann die betreffenden Dokument-IDs gelöscht
werden müßten.
GUI und GUI-Parser
•Klasse GUIWorker:
•zentrale Methode Vector doWork( SuchString, Suchart, Sprache )
•Parsen der Eingabe mit Durchführung des entsprechenden
Stemmings (je nach Sprache)
•Suchen
•Ranken
•eine Instanz des Index als statisches Objekt und somit nur
einmaliges Laden der Indexdatei
•GUI Eingaben/Einstellungen:
•Suchstring
•Suchart (HTML-Seiten oder Mediendateien)
•Sprache (deutsch, englisch oder beide)
•Anzahl der Suchergebnisse pro Seite
GUI und GUI-Parser
•Aufgaben:
•Wandelung der Texteingabe in ein für den Searcher nutzbares Format
•Verarbeitung der getroffenen Einstellungen (Sprache etc)
•Ausführen der Suche, bestimmen einer Rangfolge
•Ausgabe der Ergebnisse
•Realisierung:
•Verwendung eines Servlets
•Vereinfachung der Ausgaben durch Einbindung des
Open-Source-Frameworks Webmacro
GUI und GUI-Parser
•Anfragesprache:
<EXPR>
= <TERM> <AND> <EXPR>
<TERM>
= {<WORD> | <PREFIX>} OR <TERM>
<AND>
= AND | ANDNOT
<CHAR>
= A | B | ... | Z | a | b | .. | z | 1 | 2 | ...
<WORD> = <CHAR>+ | ‘{<CHAR> | _}+' | (<EXPR>)
<PREFIX> = <CHAR>+<STAR>
<STAR>
=*
•Vertauschen der Bindungsstärke von UND/ODER
computer AND windows OR unix
==
computer AND ( windows OR unix )
•Synonyme:
AND
ANDNOT
OR
UND, &
BUT, UNDNICHT, AUSSER, &!
ODER, |
GUI und GUI-Parser
•verwendete Klassen:
•GUIServlet
•GUIWorker
•GUIParser
- das Servlet
- Verbinden aller benötigten Komponenten
- Parser für Eingaben
•Zusammenhang zwischen den einzelnen Komponenten:
Searcher
 Anforderungen
 Anbindung
 Interna
 Schwachpunkte/Alternativen
Searcher
 Ziel: Geparste Anfragen sollen in eine bewertbare Dokumentenmenge
umgesetzt werden
 Anfrageoperationen
–
–
–
–
–
AND
OR
BUT
Präfix
Phrase (Medienindex)
 Einschränkung auf bestimme Sprache
Searcher
 Anbindung an Index:
–
Rückgabe einer sortierten Liste (Iterator, welcher Ordnung garantiert)
–
Präfixsuche im Index
 Anbindung an Ranker:
–
Collection der DocumentIDs in den einzelnen Postinglisten
–
Information über ursprüngliche Größe der Postingliste und ihrer Terme
 Anfrage realisiert als Ausdrucksbaum
Searcher
 Zurückgegeben Postinglisten fehlt Information über Term und
ursprüngliche Größe
 Wie sollen die Informationen über die Rekursionsstufen
zurückgereicht werden
 Minimierung der Arbeit auf niedrigster Rekursionsstufe, da
ursprüngliche Postinglisten sehr groß sein können
Searcher
 Speichern zu jedem Term
–
Nachteil: Größerer Aufwand auf unterster Rekursionsebene
 Einmaliges Speichern in Postingliste und Akkumulation der
Postinglisten
–
Nachteil: Geringer sinkender Aufwand über Rekursionstufen, da über alle
Elemente aller Postinglisten iteratiert wird, auch wenn mehrfach vorhanden
sind
Searcher
 Vorverarbeitung des Operatorbaums
–
–
Operatorbaum -> Gerichteter Ausdrucksgraph
Logische Vorverabeitung der Anfrage zur besseren Schnittbildung
 Anbindung an Index
–
Direktes Arbeiten auf Index statt vorheriger Umwandlung
Ranker
 Anforderungen
 Anbindung
 Interna
 Schwachpunkte/Alternativen
Ranker
Anforderungen
 schnelles Ranking
 sinnvolles Ranking
Ranker
Anbindung
 Die Anbindung erfolgt über die Klasse ListTransformer.
 Bekommt eine DokumentListe
–
beinhalted:
•
DokumentFrequenzen
•
Termfrequenzen (bzgl. Der Indexmenge)
•
die Positionen + Gewichte der Positionen (bei MedienObjekten)
 Rückgabe sind DocId‘s , erfolgt mit den Methoden:
–
rank()
–
getnBestElements()
Ranker
Interna
 Der Ranker berechnet über alle Terme pro Dokument:
–
Dokumentfrequenz / Termfrequenz (bei Textanfragen)
–
Für die Summe der Vorkommen : Gewicht der Position / Termfrequenz
(bei Mediaanfragen)
 Kommentar:
–
zwar naiv gerangt, liefert aber vernünftige Ergebnisse
Ranker
Schwachpunkte / Alternativen
 Alternativen :
–
siehe Vorlesung
 Schwachpunkte :
–
Ranker liest immer gesamte Treffermenge => evtl. längere Verzögerung
 Verbesserungsmöglichkeiten:
–
Speicherung im Heap der nur die besten n Documente speichert
–
Andere Datenstrukturen (bessere als die JDK Klassen)
–
andere Ranker testen ?
–
andere Gewichtung der TextPositionen ?
Testszenarien 1
 Durchfuehren aller Testszenarien unter www.mms.de.vu/testszenarios
-> 32 Testszenarios
 Probleme :
–
–
–
Es muß getestet werden, was über die GUI angeboten wird
-> viele Testszenarien -> Zeitaufwand zum Testen zu groß
Möglichkeiten der Beschreibung der TestSzenarien sind zu gering
kaum Möglichkeit zum Projektvergleich mit anderem System, daher ist die
Bewertung der Ergebnisse sehr schwer.
 Folgerung :
–
–
wenig Testszenarien konnten durchgeführt werden
Viele Werte konnten fast „subjectiv“ bewertet werden.
 Verbesserung :
–
–
–
Früherer Abgleich mit anderer Projektgruppe über Strukturen und
Datenspeicherung
manuelle Datenausgabe ohne GUI
weniger „basteln an Kleinigkeiten“, dafür Tests besser planen und
durchführen
Testszenarien 2
 Anzahl der eingelesenen Indexeintraege nach 30 min.
–
Start auf www.sonymusic.de liefert schlechte Ergebnisse pro 30 min., weil
kaum Mediendateien vorhanden sind
–
Start auf www.audiofind.com, wegen sehr hoher Mediendichte
–
–
–
HTML-Index-Terme 7628/30 Min. (254/Min.)
Medien-Index-Terme 6148/30 Min. (205/Min.)
Indexgröße 4,228 MB/30 Min (141 kB/Min.)
 Quantität des Suchergebnisses
–
zu korrekten Anfragen werden immer Ergebnisse geliefert, wenn sie denn im
Index enthalten sind.
 Qualität des Suchergebnisses
–
Auslesen des Indexes (->DocListDump.txt ) und Vergleich mit
Suchergebnissen liefert eindeutig gleiche Ergebnisse, wie erwartet.
Probleme und globale
Verbesserungsmöglichkeiten
 Parallele Bearbeitung in der Crawler-Queue zur
Geschwindigkeitssteigerung
 Puffer zwischen Parser und Indexierer , weil der
WebParser wesentlich schneller als der indexer ist.
 Aktualisierung des Indexes (veraltete Daten löschen) ist
nur manuell möglich durch die Vectorliste
And Now :
Online - Test