Gruppe Webis2 Vorstellung des Projektes „MagicMediaSearch“

Präsentation zum Thema: "Gruppe Webis2 Vorstellung des Projektes „MagicMediaSearch“"—  Präsentation transkript:

1 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

2 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

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

4 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 Search Ranker

5 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

6 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

7 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. - Nachteil : -> der aussenstehende Prozess (z.B. SeriellWebParser) wartet die Zeit des Ladevorganges auf das Weiterarbeiten - Vorteil : -> einfacher Einsatz, einfache Kommunikation Beliebiger Prozess z.B. SeriellWebParser HTMLCrawler Ladevorgang

8 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. - Nachteil : -> komplizierte Kommunikation (siehe später Stichwort CrawlerQueue) - Vorteil : -> kein Zeitverlust für aussenstehenden Prozess, z.B ParallelWebParser Beliebiger Prozess z.B. ParallelWebParser HTMLCrawler Ladevorgang Weitere Arbeit des Prozesses

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

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

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

12 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. - 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 Prozess, z.B. SeriellWebParser HTMLCrawler URL Accumulator / CrawlerException Start disconnect()

13 getNextCrawlerContent()
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 : - 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. ParallelWebParser CrawlerQueue setURL(URL) getNextCrawlerContent() Parallel ladender HTMLCrawler isReady() Accumulator

14 Web-Parser Was wird vom Web-Parser verlangt?
Wie arbeitet der Web-Parser? Besonderheiten des Web-Parsers Probleme und mögliche Ergänzungen

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

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

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

18 Web-Parser Wie arbeitet der Web-Parser? Web-Parser Crawler Indexer
MP3-Crawler Bei .mp3-Dateien zum Auslesen des MP3-Tags Web-Parser Einlesen der Internet-Seiten (.htm, .html, .shtml u.s.w.) Eintragen der relevanten Informationen Crawler Indexer

19 Web-Parser Wie arbeitet der Web-Parser? Web-Parser removeStopwords()
Müll URLVector Spracherkennung 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. Entscheidung durch URLListe bei Bedarf MP3-Crawler tagIdentifier() mediaIndexParser() linkParser() indexieren im Medienindex Seite ohne Scripte und Stylesheets removeStopwords() htmlIndexParser() ScriptAndStylesheetDeleter() Stemmer indexieren im Textindex neue Internet-Seite

20 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“ ).

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

22 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

23 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

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

25 Indexer und Index Datenstruktur des Index
ank peicher nwend- ung ystem edium b a s m Postingliste mit drei gamma-codierten BitSets für die Doc-IDs, die Gewichte und die Termpositionen zu jedem Term Verkettete Liste mit genaueren Informa- tionen zu den Dokumenten URL A HTML ... URL B MP3 URL C 2 Prefix-Trees (1x Text-Index, 1x Medien-Index)

26 Indexer und Index UML

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

28 Indexer und Index Aktuelle Indexdaten und -größe
Anzahl an Termen im MedienIndex: im TextIndex: Größe der Dokumentenliste: davon deutsche Dokumente englische Dokumente Anzahl verschiedener Dokumenttypen: HTML/ASCII MP MPEG AVI WAV RAM MPG MOV Speicherverbrauch: File: MB RAM: ca MB

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

30 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

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

32 GUI und GUI-Parser Klasse GUIWorker: GUI Eingaben/Einstellungen:
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

33 GUI und GUI-Parser Aufgaben: Realisierung:
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

34 GUI und GUI-Parser Anfragesprache: AND UND, &
<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, |

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

36 Searcher Anforderungen Anbindung Interna Schwachpunkte/Alternativen

37 Searcher Ziel: Geparste Anfragen sollen in eine bewertbare Dokumentenmenge umgesetzt werden Anfrageoperationen AND OR BUT Präfix Phrase (Medienindex) Einschränkung auf bestimme Sprache

38 Searcher Anbindung an Index: Anbindung an Ranker:
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

39 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

40 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

41 Searcher Vorverarbeitung des Operatorbaums Anbindung an Index
Operatorbaum -> Gerichteter Ausdrucksgraph Logische Vorverabeitung der Anfrage zur besseren Schnittbildung Anbindung an Index Direktes Arbeiten auf Index statt vorheriger Umwandlung

42 Ranker Anforderungen Anbindung Interna Schwachpunkte/Alternativen

43 Ranker Anforderungen schnelles Ranking sinnvolles Ranking

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

45 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

46 Ranker Schwachpunkte / 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 ?

47 Testszenarien 1 Durchfuehren aller Testszenarien unter -> 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

48 Testszenarien 2 Anzahl der eingelesenen Indexeintraege nach 30 min.
Start auf liefert schlechte Ergebnisse pro 30 min., weil kaum Mediendateien vorhanden sind Start auf 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.

49 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

50 And Now : Online - Test