nicht angemeldet
Hi Tobi,
bei den Suchergebnissen sollten neben Titel und Adresse der Seite
auch einige Zeilen Text aus dem gefundenen Dokument erscheinen,
damit der User sich in etwa den Kontext des Hits vorstellen kann.
also können wir
http://selfsuche.teamone.de/cgi-bin/such.pl
als inhaltlich verwandt betrachten, ja?
Weil die Grösse meiner Website mittlerweile auf über 50 MB angewachsen
ist,
Die Self-Suchmaschine hat derzeit 133 MB Indexdaten.
verwende ich die invertierte Suchmethode, d.h. von einem
Indexer-Script werden Stichworte vorab aus den Dokumenten
gefischt, diesen zugewiesen und in einer Index-Datei gespeichert.
Dieser Index wird vom eigentlichen Such-Script durchsucht.
So soll die Suche hier wohl in der nächsten Version funktionieren.
1.) Ich speichere die ersten Zeilen Text zusammen mit den übrigen
Informationen (wie Titel, Adresse, Datum) über das jeweilige
Dokument in dem Index-File.
Warum nur die ersten Zeilen? In denen kommt der Suchbegriff vielleicht
gar nicht vor.
Das wird zwar die Datei deutlich vergrößern, dürfte die Suche
aber nicht erheblich langsamer machen, da dieser Teil des Files
ja nicht wirklich durchsucht wird.
(Liege ich mit dieser Einschätzung richtig?)
Das Lesen der Indexdatei machte bei der Self-Suche auf dem alten Server
(wo die Laufzeit 20-30 Sekunden pro Suche durch das gesamte Archiv betrug)
Version so um die 30% aus - auch wenn nur nach einem Autor gesucht wurde.
(Entsprechende benchmarks über die relativen Anteile der CPU-Belastung
sind in der Dokumentation hinterlegt.)
Auf der aktuellen Plattform dauert eine Suche nach "ratzelfatz" über
sämtliche Indexdateien (mit 0 Treffern, damit ich die Zeit für eventuelle
Ausgaberoutinen nicht auch noch in der Rechnung habe) 6.39 Sekunden
system time, eine Reduzierung der Suche auf das Feld "Category" (nur
wenige Prozent des gesamten Posting-Inhalts) reduziert die Suchdauer
auf 4.02 Sekunden. Das Lesen der 130 MB kostet also in jedem Fall etwas,
auch wenn der größte Teil davon nicht verglichen wird.
2.) Das Suchskript holt sich den Text nachdem es die Dateien gefunden
hat, "live" aus den einzelnen Dokumenten. Das würde meiner Meinung
nach die Möglichkeit eröffnen, Text aus der unmittelbaren Umgebung
des gefundenen Wortes zu präsentieren, wie man das bei manchen
Suchmaschinen sieht.
Genau - Du könntest ein zusätzliches Feature anbieten.
Dafür würde diese Alternative die Suche mit Sicherheit verlangsamen.
Wieviel wäre Dir das Feature wert?
Ich bin mir nun nicht sicher, welche dieser Alternativen besser ist;
Keine. Du hast einen trade-off - da gibt es kein "besser".
Nur eine klare Aufgabenstellung. Entweder Du willst das feature,
oder Du willst es nicht, weil Dir Geschwindigkeit wichtiger ist.
ich bin mir noch nicht mal sicher, ob ich überhaupt auf dem richtigen
Weg bin oder ob es andere, deutlich bessere Ansätze gibt.
Hast Du eine Vorstellung darüber, wie das Verhältnis zwischen gespeicherter
Textmenge und erzielten Treffern ist?
Stell Dir mal vor, eine Suche produziert im Mittel 20% der Einträge als
Treffer. Wenn Du dann diese 20% der Texte durchsuchen müßtest, um gute
Kontexte für das Preview anzuzeigen, dann würde in der Tat einiges an
Zeit dabei drauf gehen.
Allerdings immer noch nur ein Fünftel der Zeit, welche die Self-Suche
für eine Volltextsuche durch das gesamte Archiv zu bezahlen bereit ist.
Andererseits: Laß es mal weniger als 1% Treffer sein. Dann wird der
Aufwand zur Berechnung der Kontexte schon sehr viel preisgünstiger.
Und gleichzeitig wollen Deine Anwender ja lieber wenige gute als viele
schlechte Treffer sehen.
Gibst Du eine beliebig lange Trefferliste aus, oder brichst Du nach
einer Limitierung ab? Bei der Self-Suche kann der Benutzer das selbst
entscheiden, wobei aber ein "defensiver" Default-Wert von 100 Treffern
eingestellt ist.
Und hast Du eine gute ranking-Funktion, so daß bei einem vorzeitigen
Abbruch nicht die besten Treffer ausgeblendet werden?
Je weniger Treffer Du anzeigst, desto mehr darfst Du in diese Anzeige
investieren, ohne daß es in der Gesamtkostenrechnung lästig wird.
Viele Grüße
Michael