nicht angemeldet
Methode der Wahl für Teaser-Text bei invertierter Suche?
Hallo liebe Forumleser!
Ich habe mir vor ca. 1/2 Jahr mit Perl eine Suchmaschine für meine Web-Site zusammengebastelt und bin gerade dabei, sie Schritt für Schritt zu verbessern (so wie das vor ein paar Jahren hier im Forum vorgeschlagen wurde. Danke dafür :-). Eigentlich macht sie schon so ziemlich alles, was ich mir vorstelle, allerdings blieb mir ein Wunsch - der auch in besagtem Forumsbeitrag erwähnt wurde - bis jetzt unerfüllt: 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.
Weil die Grösse meiner Website mittlerweile auf über 50 MB angewachsen ist, 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. Genau da hakt's jetzt: Ich weiss nicht, wie ich am besten zu Text aus dem jeweiligen Dokument komme.
Mir sind bisher zwei Möglichkeiten eingefallen:
1.) Ich speichere die ersten Zeilen Text zusammen mit den übrigen Informationen (wie Titel, Adresse, Datum) über das jeweilige Dokument in dem Index-File. 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?)
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. Dafür würde diese Alternative die Suche mit Sicherheit verlangsamen.
Ich bin mir nun nicht sicher, welche dieser Alternativen besser 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. Für Meinungen und Anregungen wäre ich deshalb überaus dankbar. Vielleicht weiß sogar jemand, wie "Profis" dieses Problem angehen?
Vielen Dank (zunächst mal für's Lesen :-)
Tobi H.
-
Hi,
Ich weiss nicht, wie ich am besten zu Text aus dem jeweiligen Dokument komme.
<meta name="description"> auslesen? Da das _selbstverständlich_ sinnvoll gefüllt ist, wäre dies doch am einfachsten, oder? ;-)
Cheatah
-
Hallo Cheatah,
erst mal schönen Dank für die Antwort.
<meta name="description"> auslesen? Da das _selbstverständlich_ sinnvoll gefüllt ist, wäre dies doch am einfachsten, oder? ;-)
Du hast recht (... natürlich !-)). Meine Seiten haben aber leider keine "description". Es handelt sich um die Online-Ausgabe einer regionalen Wochenzeitschrift. Das macht pro Woche ca. 20- 30 Artikel. Und um mir zu jedem Artikel eine _sinnvolle_ Beschreibung einfallen zu lassen, müsste ich die Dinger erst mal lesen :-o (Zeit ist Geld, hehe). Mir persönlich wäre es, wie schon geschrieben, eh am liebsten, wenn ich den unmittelbaren Kontext des gefundenen Begriffs ausgeben könnte. Google macht das zum Beispiel so.
Trotzdem danke für die Anregung.
Tobi H.
-
-
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-
Hi Michael!
Wow. Erst mal Danke für die ausführliche Antwort. Ich habe mich schon entschieden.
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.Also, ich denke ich will das Feature. Aber wie gesagt, ich war mir nicht sicher ob es nicht vielleicht noch einen "Königsweg" gibt, der mir vom Prinzip her nicht eingefallen ist. Ich glaube, dass das Feature eine Reduzierung der Geschwindigkeit durchaus wert ist, zumal sich diese nach genauerer Überlegung (dank Deiner Ausführungen) in Grenzen halten dürfte, denn:
1. Bei durchschnittlich 700 Suchanfragen pro Monat war keine einzige dabei, die über 80 Treffer erzielte und
2. werden wahlweise 10 oder 20 Treffer auf einer Seite ausgegeben. Die weiteren Ergebnisseiten können von dort aus aufgerufen werden. Wenn ich das "live"-Auslesen an diese Funktion kopple, müssen eben nur 10 bzw. 20 Seiten durchsucht werden.
3. Liegen meine Suchzeiten, je nach Anzahl und Verknüpfung der Suchbegriffe deutlich unter denen die Du genannt hast. (0.09 bis 0.90 Sekunden; ist ja bei 50 MB Rohdaten - wie Du Dir vorstellen kannst - auch ein sehr schlanker Index)
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?Ich habe derzeit die Limitierungsfunktion noch deaktiviert, sie wird aber bei dem momentanen Wachstum der Seite in naher Zukunft nötig sein. Da wird sich dann auch die Frage des Rankings neu stellen, denn zur Zeit sortiere ich die Treffer nach Erscheinungsdatum der Artikel, da die Statistiken gezeigt haben, dass die aktuellsten Suchergebnisse für den User am interessantesten sind. Mal schauen ob das so bleibt.
So jetzt ich muss ich mir nur noch überlegen, wie ich das Feature am besten programmiere (das dürfte die schwierigste Aufgabe sein, da ich leider _noch_ kein richtiger "Perl-Freak" bin!), aber ein bißchen Basteln macht auch mal wieder Spaß.
Nochmal vielen Dank für die Denkanstöße.
Viele Grüße
Tobi H.
-