Gruppe Webis2

Vorstellung des Projektes „MagicMediaSearch“

Sven Bittner, Moritz Blöcker, Valerie Bures, Heiko Kahmann, Mariusz Kukulski, Kilian Lenz, Olaf Licht, Fabian Wiesel, Thomas Zahn

24.01.2001

www.mms.de.vu

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 mp3-Files 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

Kilian, Thomas und Valerie:Index und den Indexer

Fabian und Olaf:Searcher

Moritz:Ranker

Sven:GUI und den GUI-Parser

Dieses Diagramm gibt einen groben Anhaltspunkt und nicht die eigentliche Klassenaufteilung wieder!

List von URLs

Crawler Web Parser

Indexer

Internet

Index

GUI Parser Search

RankerGUI

CrawlerGliederung

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

CrawlerFunktion 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

CrawlerFeatures 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.

- Nachteil : -> der aussenstehende Prozess (z.B. SeriellWebParser) wartet die Zeit des Ladevorganges auf das Weiterarbeiten - Vorteil : -> einfacher Einsatz, einfache Kommunikation

Beliebiger Prozessz.B.

SeriellWebParser HTMLCrawler Ladevorgang

CrawlerFeatures 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.

- Nachteil : -> komplizierte Kommunikation (siehe später Stichwort CrawlerQueue)

- Vorteil : -> kein Zeitverlust für aussenstehenden Prozess, z.B

ParallelWebParser

Beliebiger Prozessz.B.

ParallelWebParser HTMLCrawler LadevorgangWeitere Arbeit

des Prozesses

CrawlerFeatures 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)

- Nachteil : -> Zeitverlust durch Vergleich aktueller URL mit allen schon geladenen URL´s

- Vorteil : -> Verhindern von Schleifen, die durch gegenseitige Referenzierung von HTML-Seiten entstehen

Prozess, z.B.

SeriellWebParser HTMLCrawler

URL

URLList

Accumulator

checkURL(URL url)

URLFoundException

CrawlerFeatures 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

- 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

Prozess, z.B.

SeriellWebParser HTMLCrawler

URL

Robot.txt

Accumulator

Vergleich

True / False

CrawlerFeatures 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)

CrawlerSinnvolle 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.

- Nachteil : -> TimeOut musste selbst entwickelt werden, da die URLConnection dies nicht als Standard unterstützt

- Vorteil : -> Schnelligkeitssteigerung des Indexierungssystems, durch vorzeitiges Trennen „langer Leitungen“

TimeOutist eigener

Thread

Prozess, z.B.

SeriellWebParser HTMLCrawler

URL

Accumulator /CrawlerException

Start

disconnect()

CrawlerSinnvolle 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 :

- 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.

Prozess, z.B.

ParallelWebParserCrawlerQueue

setURL(URL)

getNextCrawlerContent()

Parallelladender

HTMLCrawler

Parallelladender

HTMLCrawler

Parallelladender

HTMLCrawler

isReady()

Accumulator

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 .mp3-Dateien 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?

Web-Parser

Crawler Indexer

Einlesen derInternet-Seiten

(.htm, .html,.shtml u.s.w.)

Eintragen derrelevanten

Informationen

MP3-CrawlerBei .mp3-Dateienzum Auslesendes MP3-Tags

Web-Parser Wie arbeitet der Web-Parser?

Web-Parser

ScriptAndStylesheetDeleter()

linkParser()

neue Internet-Seite

Seite ohne Scripteund Stylesheets

tagIdentifier()

URLVectorMüll

Entscheidungdurch

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.

removeStopwords()

Spracherkennung

mediaIndexParser()

bei Bedarf MP3-

Crawler

indexieren im Medienindex

htmlIndexParser()

indexieren im Textindex

removeStopwords()

Stemmer

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 Internet-Dateien, 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 IndexGliederung

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 IndexAnforderungen 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 IndexImplementation

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

Daten

ank peicher

nwend-ung ystem edium

b

a s

s

m

Postingliste mit drei gamma-codiertenBitSets für die Doc-IDs, die Gewichte

und die Termpositionen zu jedem Term

0100111101111010011010011010...

0111010101101001110100101010...

1101001101011111001010101101...

Verkettete Liste mit genaueren Informa-tionen zu den Dokumenten

URL AHTML

...

URL BMP3

...

URL CHTML

...

2 Prefix-Trees (1x Text-Index, 1x Medien-Index)

0100111101111010...1001110100101010...1111001010101101...

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: 19096– im TextIndex: 15727

Größe der Dokumentenliste: 7100– davon deutsche Dokumente 101– englische Dokumente 6999– Anzahl verschiedener Dokumenttypen:

• HTML/ASCII 211• MP3 6880• MPEG 1• AVI 1• WAV 0• RAM 0• MPG 2• MOV 5

Speicherverbrauch:– File: 10.5 MB– RAM: 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

Für den ersten Test des Indexers/Indexes wurde die Man-Page-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 Term-Indexierung waren bis zu einer bestimmten Indexgröße nicht meßbar.)

Zeitwachstum mit O(n*log(n)). – Durch gesonderte Test konnte

gezeigt werden, daß die Lauf-Zeit hauptsächlich von den Posting-Listen bestimmt ist. Da diese häufig codiert/decodiert werden müssen und des Gammacodes wegen nur sequentiellen Zugriff erlauben.

Zeit: ca. 1 h für man-page-Index

Längenverteilung der Posting-Listen

1

10

100

1000

10000

100000

1 2 3 4 5

6-10

11-2

0

21-3

0

31-4

0

41-5

0

51-6

0

61-7

0

71-8

0

81-9

0

91-1

00

101-

150

151-

200

201-

300

301-

1000

1001

-200

0

Listenlänge

Anz

ahl d

er T

erm

e

Text-IndexMedien-Index

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 UND, &ANDNOT BUT, UNDNICHT, AUSSER, &!OR ODER, |

GUI und GUI-Parser•verwendete Klassen:

•GUIServlet - das Servlet•GUIWorker - Verbinden aller benötigten Komponenten•GUIParser - 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

RankerAnforderungen

schnelles Ranking

sinnvolles Ranking

RankerAnbindung

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()

RankerInterna

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

RankerSchwachpunkte / 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