nicht angemeldetHi,
nachdem ich mich von der "Initiativstrafe" erholt und das Such-Skript vermutlich verstanden habe, möchte ich einen Thread aufmachen, um abzuklären, was die "nächste" Version der Archivsuche können soll und was nicht.
Es ist m. E. am allgemeinen Fall *nicht* möglich, beliebig inkrementell Features einzubauen, ohne Rücksicht auf verwendete interne Datenstrukturen zu nehmen. Deshalb würde ich mich wohler fühlen, wenn ich meine "Aufgabe" exakt spezifizieren und später darauf verweisen könnte, daß ein bestimmtes Feature absichtlich so und nicht anders realisiert wurde und daß es ggf. nicht trivial ist, das zu ändern.
Ich wünsche mir also erst einmal Postings, die beschreiben, welche Erweiterungen die Forum-Suche am dringendsten brauchen könnte. Falls keine kommen sollten, baue ich einfach das ein, was ich angesichts eines mir momentan vorschwebenden Datenmodells elegant realisieren kann und sonst nichts.
Insbesondere muß ich an einer Stelle "raten" und würde mich gerne von den Lesern - und späteren Benutzern dieser Funktion! - inspirieren lassen.
Für Details mache ich separate Postings innerhalb dieses Threads auf. Ich habe meine Vorstellung, wie ich was realisieren würde, bin aber überzeugt davon, nicht überall die beste Lösung schon zu kennen - daß andere Leser besser Perl können als ich, ist mir völlig klar.
Bisher werden einige spezielle Sonderzeichen in der Eingabe des Such-Strings auf HTML-Zeichen umgesetzt.
a) Beim großen "Ö" liegt ein Tippfehler vor, der
sofort repariert werden kann.
b) Ich glaube mich zu erinnern, daß diese
Umsetzung beim Abspeichern des Postings
nicht passiert, daß also Suche und Datenbestand
nicht zueinander passen. Dazu müßte man das
Posting-Skript anpassen - Stefan?
c) Irgendwelche weiteren umzusetzenden Zeichen?
(Derzeit sind es die Umlaute, scharf-s, á
und é - mit etwas Sklavenarbeit ginge
mehr.)
Realisierungsaufwand: Gering.
Abhängigkeit von anderen Änderungen: Nur beim Posting-Skript.
Bisher sucht die Suchfunktion nach der Eingabe im entsprechenden Formularfeld. Egal, was da drin steht - auch Leerzeichen werden als Teil des zu findenden Strings behandelt.
Wenn die Suchfunktion komplexe Ausdrücke verstehen soll, fallen mir spontan zwei Ansätze zur Realisierung ein:
a) Mehrere Eingabefelder (wie im Modus "Erweiterte Suche" bei manchen Suchmaschinen).
Dies aber limitiert die Möglichkeit, Suchbegriffe zu kombinieren, und ist nicht elegant bedienbar.
b) Meta-Zeichen innerhalb des Eingabefeldes. Bei AltaVista beispielsweise das "+" und das "-", aber auch das " " (Leerzeichen), welches dort den AND-Operator bildet. Um dann ein Leerzeichen zu suchen, muß es innerhalb eines in Gänsefüßchen oder Hochkommata zu notierenden Strings stehen.
Mir als AltaVista-Benutzer schwebt die Realisierungsform b) vor - ich kenne aber nicht genügend Suchmaschinen und Ausprägungen des Benutzerverhaltens, um mich schon festlegen zu wollen. Wer kennt eine schönere Alternative?
Hi Klaus,
Du könntest das dann ja auch schön formatieren;-)
oh - das sieht wirklich hübsch aus.
Allerdings will ich das Ding für Server mit hohem Traffic einsetzen können, und da sollte das access_log nicht signifikant größer werden als auch sonst schon.
Inzwischen habe ich allerdings ein anderes Zeichen mit einer besonderen Eigenschaft gefunden, nämlich das '#'.
Hmm, habs gerade lokal ausprobiert, und bei mir stehts drin (Apache 1.3.22 über Mozill 0.9.8), wenn auch nur im Referer.
Ich meinte wirklich nur im URL - der Referrer ist keines meiner acht Felder. (Außer %r und dem UserAgent habe ich nur 'unkomplizierte' Felder drin, überwiegend reine Integers, aber u. a. auch den MIME-Typ.)
Andererseits, wenn Du %r verwendest
Ja, tue ich (weil ich nichts 'Feineres' gefunden habe. ich brauche sowohl den URL als auch die HTTP-Version; die Methode könnte ich derzeit entbehren, obwohl sich das ggf. noch ändern könnte).
dann ist der URL auch eindeutig zwischen %m und %H eingeschlossen, womit das eigentlich immer klar sein müßte.
Eben nicht!
Man kann sehr wohl "GET / HTTP/1.1" als Bestandteil sowohl des URL als auch des UserAgent senden, weil der URL innerhalb des access_log sowohl Leerzeichen als auch Gänsebeine enthalten kann.
Viele Grüße
Michael
hi!
Ich habe mir dein Skript nicht näher angeschaut, sondern mal einen etwas anderen Ansatz versucht. Folgendes ist dabei rausgekommen:
=== cut ===
#!/usr/bin/perl
my (@must, @can, @not);
$text = 'hallo +"dies ist ein test" -selfhtml';
while ($text =~ /"(.+?) (.+?)"/)
{
$text =~ s/"(.+?) (.+?)"/"$1%20$2"/;
}
$text =~ s/"//g;
@text = split / /, $text;
&parser(@text);
sub parser
{
for (@_)
{
if (s/^+//)
{
push @must, $_;
} elsif (s/^-//) {
push @not, $_;
} else {
push @can, $_;
}
}
}
=== cut ===
Sollte eigentlich klar sein: @must enthält Begriffe, die enthalten sein müssen, @can-Begriffe können vorkommen (erhöhen zb. die Bewertung), @not-Begriffe dürfen nicht vorkommen.
Nach "-Zeichen selbst kann man damit nicht mehr suchen, aber braucht man das wirklich? Die %20-Zeichen sollten später natürlich wieder in Leerzeichen umgewandelt werden.
bye, Frank!
Ich habe mir dein Skript nicht näher angeschaut, sondern mal einen etwas anderen Ansatz versucht. Folgendes ist dabei rausgekommen:
=== cut ===
»» ...
=== cut ===
Viiiel besser und vor allem viel "perliger" als meine Lösung - gekauft!
(Ich habe noch schnell die Vorzeichen aus den Token rausgeschnitten, die ich beim Vergleichen nicht mehr drin haben will.)
Nach "-Zeichen selbst kann man damit nicht mehr suchen, aber braucht man das wirklich?
Hast recht. Notfalls kann man ja später noch ' als delimiter einbauen, dann wird es halt etwas "sperriger".
Die %20-Zeichen sollten später natürlich wieder in Leerzeichen umgewandelt werden.
Yep.
hi!
(Ich habe noch schnell die Vorzeichen aus den Token rausgeschnitten, die ich beim
Vergleichen nicht mehr drin haben will.)
Darf ich dich fragen, wie du die Vorzeichen der Tokens vergleichen willst, wenn du sie vorher rausschneidest? Bei meiner Version wurden sie automatisch direkt nach dem Vergleich rausgeschnitten und der Rest dann in das betreffende Array gepushed.
bye, Frank!
Darf ich dich fragen, wie du die Vorzeichen der Tokens vergleichen willst, wenn du sie vorher rausschneidest? Bei meiner Version wurden sie automatisch direkt nach dem Vergleich rausgeschnitten und der Rest dann in das betreffende Array gepushed.
Das habe ich beim vierten Lesen endlich auch begriffen (boah, war das kompakt!), aber ein Vergleich mit s//-Operator-Seiteneffekt (phhh ...) war mir denn doch *etwas* zu kryptisch, also habe ich ihn durch
foreach my $one_token (@Token)
{
# Jetzt die "%20"-Markierungen wieder die "inneren" Leerzeichen
# zurückverwandeln
$one_token =~ s/%20/ /g;
# Vorzeichen wegfiltern, Token auf den passenden Stapel legen
if ($one_token =~ /^+(.*)/)
{ push @Must, $1; }
elsif ($one_token =~ /^-(.*)/)
{ push @Not, $1; }
else { push @Can, $one_token; }
}
usw. ersetzt.
(Ich hoffe, das geht noch halbwegs als Perl durch; mit anonymem $_ kann ich mich auch nicht so recht anfreunden - ich dachte, die Zeiten der Maschinensprache mit Akkumulatur und Registern sind langsam vorbei? :-)
Hi Micheal
Zuerst einmal ein herzliches Dankeschön ! ! ! ! ! !
Du nimmst Dich eines Problems an, dass ich mir gerade in den letzten Tagen durch den Kopf spukte.
Meine Wunschvorstellungen für die Archivsuche sind:
Falls Du Unterstützung brauchst, um Teile davon (in Perl?) umzusetzen, melde Dich.
Ich werd mein Bestes geben ;-)
Grüsse
Tom
- Volltextsuche über den gesamten Forumsinhalt (alle Felder)
Geht doch jetzt schon - oder? (Titel, Verfasser, Inhalt und alles zusammen ...)
- Suchoperatoren wie + (Begriff muss vorhanden sein) und - (Begriff darf nicht vorhanden sein)
"+" ist der Default; "-" habe ich vor, einzubauen, grübele aber noch über die exakte Benutzerschnittstelle.
- Near-Operator: Es sollen mit "mailto: NEAR IE" nur die Dokumente ausgegeben werden, wo der Begriff 'mailto:' in der (relativen) Nähe vom Begriff 'IE' auftritt. Die relative Nähe könnte als Einflussgrösse für das Ranking verwendet werden.
Oh, jetzt wird es heftiger. An Ranking (also "Verstehen" des Dokuments) und NEAR (exakre Definition? Anordnung/Reihenfolge innerhalb des Dokuments?) hatte ist bisher nicht gedacht ... da bestände überhaupt noch Spezifikationsbedarf.
- Zusätzlich (optional) könnten auch Boolean-Operatoren wie AND, OR und NOT sowie Klammern implemmentiert werden. Da dies jedoch richtig Aufwand bedeutet, kann ich auch darauf verzichten.
Genau AND und NOT will ich unbedingt, und die beiden alleine sind m. E. nicht schlimm.
OR wird schlimm, weil ich dann zur flexiblen Kombination mit AND volle (rekursive) Expressions und damit praktisch auch Klammern brauche.
Habe ich nur NOT und AND, dann definiere ich einfach, daß NOT stärker bindet und implementiere keine Klammern - fertig ist die Laube ... (dann geht halt *nicht* "x AND NOT (Y AND Z)", aber wer braucht das?)
Falls Du Unterstützung brauchst, um Teile davon (in Perl?) umzusetzen, melde Dich.
Ich werd mein Bestes geben ;-)
Darüber reden wir nochmal, wenn die "Masse" wirklich Klammern "fordert" :-) ... ungefähr da wird die Sache nämlich schrecklich aufwendig, und womöglich wird hier dann auch die Performance ein Problem.
Hallo Michael
Es stellt sich für mich grundsätzlich die Frage, ob man nicht mit Volltextindexdateien arbeiten soll. Die Erzeugung dieser Indexdateien würde durch ein automatisiertes Skript jede Nacht durchgeführt. Damit fällt ein Teil der Sucharbeit bei der eigentlichen Suche weg, bzw. kann vorraus geleistet werden.
Ich mache mir gerade noch Gedanken, wie die Datenstruktur solcher Indexdateien aussehen müsste. Prinzipiell gibt es eine 1:n-Beziehung zwischen dem Suchbegriff und den Fundstellen.
Vielleicht ist auch das Arbeiten mit Hash-Funktionen sinnvoll. Ich hab da mal einen Artikel im c't gelesen und werde nochmals recherchieren.
Wenn jemand andere Quellen zum Thema Volltextindizies, Hash-Funktionen etc. kennt, dann soll er sich doch bitte melden :-)
Grüsse
Tom
Es stellt sich für mich grundsätzlich die Frage, ob man nicht mit Volltextindexdateien arbeiten soll. Die Erzeugung dieser Indexdateien würde durch ein automatisiertes Skript jede Nacht durchgeführt. Damit fällt ein Teil der Sucharbeit bei der eigentlichen Suche weg, bzw. kann voraus geleistet werden.
Schau Dir doch mal die Indexdatei <../../sfarchiv/src/idxbsp.txt> an, die das Suchskript bereits verwendet: Bisher nichts Gehashtes, sondern einfach ein laaaanger String pro Posting, der an Sollbruchstellen ("") per split() in die einzelnen Felder zerlegt werden kann. Die Suche läuft dann entweder ("alles") über die gesamte Zeile oder eines der Felder. Sofern die Abfragerei durch die Erweiterungen nicht wesentlich inperformanter wird, glaube ich mit der derzeitigen, sehr gut verständlichen Implementierung leben zu können (und andernfalls müßte ja auch jemand den bereits existierenden Indexgenerator anpassen).
Wenn ich "fertig" bin, werde ich mal einen kleinen Artikel darüber schreiben, wie diese Suche genau funktioniert (falls Stefan das "abnickt").
Bisher führt das Such-Skript genau *eine* Vergleichsoperation durch, und zwar zwischen einer Suchzeichenkette (ggf. inklusive Wortbegrenzungszeichen) und einem von vier möglichen "Inhalten" (Verfasser, Titel, Text, alles zusammen).
Für eine Suche nach mehreren Suchbegriffen bietet sich eine iterative Suchmethode an. Die Suchbegriffe könnten also z. B. in einer Liste gespeichert werden; pro Posting würde diese Liste sequentiell abgearbeitet, bis entweder ein Begriff nicht "paßt" oder alle Begriffe abgearbeitet wurden.
a) Eine solche Logik kann den AND-Operator in eleganter Weise realisieren.
b) Sie kann auch den NOT-Operator dadurch realisieren, daß der Trefferwert mit der Existenz eines (ggf. in einer separaten Tabelle zu haltenden) Flags für diesen Operator verglichen wird.
c) Sie kann allerdings *nicht* den OR-Operator realisieren, auf den ich persönlich derzeit keinen Wert lege.
d) Und sie kann ebenfalls nicht allfällige Klammerstrukturen auswerten, für deren Analyse eine Baumstruktur aufgebaut werden müßte.
Ist es akzeptabel, das von mir vorgeschlagene Datenmodell unter diesen Randbedingungen zu verwenden? Es wäre eine vergleichsweise kleine Änderung am bisherigen Skript, also ggf. leicht verständlich und wartbar usw.
Hat jemand ggf. eine performantere Lösung zu bieten, die beispielsweise auf einem einzigen, komplexen regular expression basiert? Hätte ich ein OR zu realisieren, dann würde ich genau dies versuchen, aber ein AND kriege ich mit einem einzigen regular expressen derzeit nicht hin, weil über die Reihenfolge der zu findenden Begriffe nichts ausgesagt ist ...
Hallo Michael
Frage:
Kann man nicht je Suchbegriff eine Liste (@Array) aufbauen und diese dann jeweils nach der Mengenlehre verarbeiten.
z.B.
$LeftItem OPERATOR $RightItem
wenn OPERATOR = OR:
@Result = @LeftResults;
push(@Result,@RightResult);
wenn OPERATOR = AND:
foreach @LeftResult
{
if($_ eq $RightResult[$i])
{ push(@Result,$_) }
$i++;
}
Die OPs NOT, -, + setzen ein bestehendes Resultset voraus.
Bei NOT, bzw. - werden die Einträge in @RightResult aus dem Resultset @LeftResult entfernt.
Der + Operator macht aber nur bei einer OR-Verknüpfung Sinn.
Dazu müsste das Leerzeichen aber als OR-Verknüpfung interpretiert werden und nicht als AND.
Für den Near-Operator müsste in jedem Eintrag jeweils eine Datenstruktur enthalten sein, die sowohl das Dokument und die Position des Suchbegriffs vom Textanfang (ermittelt über die Funktion index() ) enthält. Daraus lässt sich die relative Nähe ermitteln. Die Datenstruktur kann einerseits eine Referenz auf ein weiteres Array sein, kann aber auch ein Skalar mit definiertem Separator-Zeichen (z.B. '' ) sein.
Damit das Ganze richtig schnell wird könnte es sinnvoll sein, Indexdateien zu erzeugen, auf die dann für die Suche zugegriffen wird.
Hoffentlich rauben Dir meine Vorstellungen nicht gleich den Mut. Sie sind _wirklich_ nur als Diskusionsbeiträge gedacht und könen natürlich auch ignoriert werden.
Grüsse
Tom
Kann man nicht je Suchbegriff eine Liste (@Array) aufbauen und diese dann jeweils nach der Mengenlehre verarbeiten.
Ja, aber definiere das mal fertig, inklusive relativen Prioritäten für alle Operatoren und Klammernstrukturen. Irgendwann wird es heftig rekursiv.
Der + Operator macht aber nur bei einer OR-Verknüpfung Sinn.
Eben, und die hatte ich bisher nicht vor.
Dazu müsste das Leerzeichen aber als OR-Verknüpfung interpretiert werden und nicht als AND.
Die Syntax der Operatoren hat doch nichts mit ihrer Semantik zu tun?
Für den Near-Operator müsste in jedem Eintrag jeweils eine Datenstruktur enthalten sein, die sowohl das Dokument und die Position des Suchbegriffs vom Textanfang (ermittelt über die Funktion index() ) enthält. Daraus lässt sich die relative Nähe ermitteln.
Und zwar wie? Eine exakte Formel wäre hilfreich. Abstand in Bytes? Reihenfolge? Es tendiert dazu, uferlos und hochwissenschaftlich zu werden ... vor allem irrelevant für viele Anwender, denke ich.
Damit das Ganze richtig schnell wird könnte es sinnvoll sein, Indexdateien zu erzeugen, auf die dann für die Suche zugegriffen wird.
Das ist bereits der Fall - das Skript durchsucht nicht etwa die einzelnen Posting-Dateien!
Hoffentlich rauben Dir meine Vorstellungen nicht gleich den Mut. Sie sind _wirklich_ nur als Diskusionsbeiträge gedacht und könen natürlich auch ignoriert werden.
Keineswegs - und vielleicht baut ja auch erst mein Nachfolger volle expressions ein ... mein Ziel ist ein anderes.
hi!
Damit das Ganze richtig schnell wird könnte es sinnvoll sein, Indexdateien zu erzeugen,
auf die dann für die Suche zugegriffen wird.
Das ist bereits der Fall - das Skript durchsucht nicht etwa die einzelnen Posting-Dateien!
Wie wäre es damit, die Index-Dateien zu verkleinern? Kleinere Dateien sind schneller zu durchsuchen und belegen natürlich weniger Platz auf dem Server. Anfangen könnte man damit, indem man eine Liste mit Wörtern erstellt, die gar nicht mitindiziert werden sollen (beispielsweise "und", "er", "hi", "bye", etc.), die aber aufgrund häufiger Vorkommen den Index aufblähen können.
bye, Frank!
Wie wäre es damit, die Index-Dateien zu verkleinern? Kleinere Dateien sind schneller zu durchsuchen und belegen natürlich weniger Platz auf dem Server. Anfangen könnte man damit, indem man eine Liste mit Wörtern erstellt, die gar nicht mitindiziert werden sollen (beispielsweise "und", "er", "hi", "bye", etc.), die aber aufgrund häufiger Vorkommen den Index aufblähen können.
Die Idee finde ich ausgezeichnet - ich selbst habe aber momentan nur den "Sucher" in meinen Fingern, nicht den Indexer.
Beide sind aber unabhängig voneinander, d. h. dieses Tuning kann man einbauen, sobald die erweiterte Forum-Suche langsam zu werden droht.
Frank, magst Du mal schnell über meinen "tokenizer" drüberschauen (anderer Ast in diesem Thread)?
Hallo Frank
Wie wäre es damit, die Index-Dateien zu verkleinern? Kleinere Dateien sind schneller zu durchsuchen und belegen natürlich weniger Platz auf dem Server.
Anfangen könnte man damit, indem man eine Liste mit Wörtern erstellt, die gar nicht mitindiziert werden sollen (beispielsweise "und", "er", "hi", "bye", etc.), die aber aufgrund häufiger Vorkommen den Index aufblähen können.
Ich habe, als ich mit dem Schwanzabschneider, der die Indexdatei aktualisiert, zugange war, mit Stoppwortlisten gearbeitet und dabei festgestellt, dass die Platzersparnis viel geringer ausfaellt als vermutet (<5%). Deshalb hab ich jetzt keine drin, und wer nach "bye" oder "moin" suchen will, kann durchaus Interessantes finden <g> - auch fuer komplexe Ausdruecke wie "im Forum" im Gegensatz zu "Forum" koennen solche anscheinend ueberfluessigen Woerter Sinn machen.
viele Gruesse
Stefan Muenz
Anfangen könnte man damit, indem man eine Liste mit Wörtern erstellt, die gar nicht mitindiziert werden sollen (beispielsweise "und", "er", "hi", "bye", etc.), die aber aufgrund häufiger Vorkommen den Index aufblähen können.
Man könnte ja mal folgendes ausprobieren:
1. das Suchskript nehmen und 90% herauslöschen (übrig bleiben Dateianschluß und Zerlegung einer Indexzeile in Felder)
2. den Textinhalt jedes Indexeintrags in Worte zerlegen
3. die Häufigkeit dieser Worte über einen Hash speichern
4. eine Hitparade der Worte im Archiv-Index ausgeben lassen
Damit müßte man die mögliche Ersparnis einer solchen Operation messen können.
Hast Du Lust dazu, Frank? :-)
hi!
Man könnte ja mal folgendes ausprobieren:
- das Suchskript nehmen und 90% herauslöschen (übrig bleiben Dateianschluß und
Zerlegung einer Indexzeile in Felder)- den Textinhalt jedes Indexeintrags in Worte zerlegen
- die Häufigkeit dieser Worte über einen Hash speichern
- eine Hitparade der Worte im Archiv-Index ausgeben lassen
Damit müßte man die mögliche Ersparnis einer solchen Operation messen können.
Hast Du Lust dazu, Frank? :-)
So aufwendig ist das nicht:
open FILE, "index.dat";
for <FILE>
{
my ($url, $num, $subj, $author, $date, $text) = split //;
for (split / /, $text)
{
$count{$_}++;
}
}
close FILE;
Danach kannst du den Hash %count nach den jeweiligen Werten sortieren (siehe Forumsauslese) und die Hitliste ausgeben lassen.
bye, Frank!
Mehrere Beiträge haben neben dem "+" (MUST) und dem "-" (NOT) auch einen dritten Operator ohne Vorzeichen (CAN) vorgeschlagen.
Bei anderen Suchvorgängen dient dieser üblicherweise als Sortierkriterium für die Treffer: Das Auftreten eines mit (CAN) bezeichneten Terms im durchsuchten Text erhöht das "Rating" des Treffers, entscheidet aber nicht über Treffer oder Nicht-Treffer.
Wer einen solchen (CAN)-Operator haben will, sollte sich Gedanken darüber machen, wie eine entsprechende Rating-Funktion für die Treffer-Rangfolge aussehen sollte.
Zu bedenken gebe ich zudem, daß ich bisher bei limitierter Menge von anzuzeigenden Treffern die Suchoperation beim Erreichen der gewünschten Trefferzahl abbrechen kann, falls die Sortierung der Treffer nicht spezifiziert war oder mit der Sortierung des Index übereinstimmt.
Mit der Einführung einer Gewichtung der Treffer wird es jedoch zwingend erforderlich, alle Treffer zu bestimmen, zwischenzuspeichern und zu sortieren - mal sehen, wie lange dann eine Suche nach "HTML" dauert, wenn sie 20000 Treffer produziert, die dann sortiert werden wollen ...
Es ist nicht so, daß ich das nicht implementieren würde, wenn Ihr mir *genau* erklären könnt, was (CAN) genau bewirken soll ...
Hallo Michael
Mit der Einführung einer Gewichtung der Treffer wird es jedoch zwingend erforderlich, alle Treffer zu bestimmen, zwischenzuspeichern und zu sortieren - mal sehen, wie lange dann eine Suche nach "HTML" dauert, wenn sie 20000 Treffer produziert, die dann sortiert werden wollen ...
Ooch, das ist doch ganz einfach: dann schmeissen wir diesen ollen Linnux-Apache-Server weg, tun das Ganze auf so einen Rechner wie Altavista, mit 32 Gigabyte Arbeitsspeicher, einem Server, der 1000 Hits pro Sekunde verkraftet, und zur Finanzierung pflastern wir die einzelnen Seiten voll mit Werbebannern von Porno-Anbietern. Dann wird's wenigstens auch mal schoen bunt und animiert, und wir bekommen auch ein ganz anderes Publikum. Themenbereiche wie MENSCHELEI sind dann auch endlich ueberfluessig. Kurzum: WIR WERDEN PROFESSIONELL!
viele Gruesse
Stefan Muenz
hi!
Mit der Einführung einer Gewichtung der Treffer wird es jedoch zwingend erforderlich, alle
Treffer zu bestimmen, zwischenzuspeichern und zu sortieren - mal sehen, wie lange dann
eine Suche nach "HTML" dauert, wenn sie 20000 Treffer produziert, die dann sortiert
werden wollen ...
Eine Zwischenspeicherung der restlichen Ergebnisse ist IMHO nicht nötig. Da der gleiche Aufruf jedesmal das gleiche Ergebnis erzeugt, wird die Suche einfach neu gestartet, diesmal aber die Ergebnisse erst ab Nummer wasauchimmer ausgegeben. So würde ich das machen...
Stefan: hast du zufällig irgendwelche Statistiken darüber, wie oft die Suche zb. pro Minute aufgerufen wird?
bye, Frank!
Eine Zwischenspeicherung der restlichen Ergebnisse ist IMHO nicht nötig. Da der gleiche Aufruf jedesmal das gleiche Ergebnis erzeugt, wird die Suche einfach neu gestartet, diesmal aber die Ergebnisse erst ab Nummer wasauchimmer ausgegeben. So würde ich das machen...
Sorry, Frank:
Wenn ich Limitierung UND Sortierung nach einer rating-Funktion haben will (Stefan will mit "maximal 100 Treffer anzeigen" das erste, Du willst das zweite mit dem CAN-Operator), dann muß ich doch erst einmal alle 10000 Treffer berechnen, damit ich sie dann sortieren und davon dann die besten 100 ausgeben kann ... das ist das Problem, wenn man zuviel auf einmal versucht.
Will ich nur *irgendwelche* 100 Treffer, dann kann ich nach der Berechnung von 100 Treffern abbrechen. Das ist sogar performanter als die bisherige Lösung.
Will ich die letzten 100 Treffer, dann muß ich leider ebenfalls 10000 Treffer berechnen, weil ich die Indexdatei nicht von hinten lesen kann. (Oder???)
Deshalb wäre ich mit allem, was nach "intelligenter" Auswahl der Treffer aussieht, *sehr* vorsichtig - man kann das problemlos bauen, aber es kann furchtbar viel Leistung kosten (CPU-Zeit, RAM für die Sortierung von 10000 Treffern, ...).
Was haltet ihr davon, die Zahl der überhaupt zu berechnenden Treffer "hart" nach oben zu begrenzen? (Wer liest schon mehr als 500 Treffer durch, statt seine Suchbegriffe zu verfeinern, wenn man das endlich kann?)
Unter dieser Voraussetzung sehe ich eine *Chance*, über CAN und ggf. sogar NEAR (mehr oder weniger) ernsthaft nachzudenken. Sonst nicht - wir wollen ja den Server nicht lahmlegen.
Hallo Frank
Stefan: hast du zufällig irgendwelche Statistiken darüber, wie oft die Suche zb. pro Minute aufgerufen wird?
Nicht so wild: 4275 mal im August, macht 157 mal am Tag und 0,1 mal pro Minute.
viele Gruesse
Stefan Muenz
hi!
Stefan: hast du zufällig irgendwelche Statistiken darüber, wie oft die Suche zb. pro
Minute aufgerufen wird?
Nicht so wild: 4275 mal im August, macht 157 mal am Tag und 0,1 mal pro Minute.
Hm, dann sollte es doch nicht so schlimm sein. Angenommen, man setzt 50 bis 100 Ergebnisse auf jede Seite. Realisiert man das ganze mit einer Bewertung, stehen sowieso die besten Treffer ganz oben. Bis jemand diese Treffer erstmal durchgesehen hat und erneut die Suchmaschine anwirft - wenn er es überhaupt tut - vergeht erstmal einige Zeit. Es läuft also in den meisten Fällen sowieso nur eine oder selten zwei Instanzen der Suchmaschine - dürfte die Performance nicht zu sehr belasten.
Zur Bewertung undanschließenden Sortierung: so wie ich es Michael vorgeschlagen habe, würden für jeden Treffer gespeichert: Autor, Titel, Datum, URL und Beitragsnummer. Das macht vielleicht 100 Zeichen aus. Sortiert werden muss davon nur die Beitragsnummer, um ein Array daraus zu erstellen. Es werden also nicht massenweise Daten im Speicher hin und her geschoben. Die von Michael genannte Zahl (10.000) halte ich bei einer Gesamtzahl von gut 30.000 Nachrichten für übertrieben.
Zur Sortierung: wie gesagt muss nur ein Hash bestehend aus Zahlen sortiert werden. Perl benötigt bei mir zur Sortierung von 300.000 (Komma-)Zahlen im Bereich 0 - 30.000 weniger als 5 Sekunden. Soviel zur Performance der Sortierung.
Nach 100 Treffern die Suche abzubrechen, halte ich nicht für sinnvoll, wenn eine Sortierung nach Bewertung erfolgt, da dann evtl. bessere Treffer verloren gehen. Nachteile hat das für den Server kaum, nur für den Sucher, der - meiner Meinung nach - eher bereit ist, ein paar Sekunden länger zu warten, als bessere Treffer nicht zu erhalten.
bye, Frank!
Hi.
meine Version des Suchskripts hat gerade die ersten MUST- und NOT-Operatoren erfolgreich ausgewertet. Für Details siehe http://www.teamone.de/selfaktuell/self_forum/30722.html.
(Uuups: Stefan, was passiert mit dem link, wenn dieses Posting ins Archiv wandert? Paßt der Schwanzabschneider den irgendwie an?)
Die Auswertung war gar nicht schwer: Nachdem ich den Parser von Frank Schönmann praktisch unverändern übernommen habe, mußte der Matcher nur noch alle MUST- und alle NOT-Terme nacheinander bearbeiten, und das auch nur solange, bis einer "versagt". Der innere "Single-Matcher" führt einen "Vergleich" durch und berücksichtigt dabei die Parameter "auf Wortgrenze" und "case-sensitiv".
CAN-Parameter (solche, die weder ein "+" noch ein "-" als erstes Zeichen haben), sind in der Eingabe erlaubt, haben derzeit aber keine Wirkung. Mit einer Ausnahme: Wenn *kein* MUST-Term gefunden wird, dann wandele ich *alle CAN-Terme in MUST-Terme um, um der Schreibfaulheit der Anwender Rechnung zu tragen.
"Perl CGI" ist also gleichbedeutend mit "+Perl +CGI", während "Perl +CGI" *derzeit* gleichbedeutend mit "+CGI" ist (jaja, so ist das!)
Der eigentliche Abgleich ist immer noch der regular expression, wie der schon in der aktuellen Version realisiert ist.
Wer schon mal nach der Zeichenkette "+" oder "" gesucht hat (keine Angst, der Server stürzt dabei nicht ab :-). wird verstehen, daß dies nicht ganz unproblematisch ist.
Ich schlage vor, im eigentlichen Such-Term bestimmte Sonderzeichen zu "maskieren" (also etwa "+" in "+" umzuwandeln. Da ich aber sicher bin, dabei da eine oder andere Sonderzeichen zu übersehen, bitte ich um entsprechende Hilfestellung: Sollte überhaupt etwas "entschärft" werden, und wenn ja, dann was?
Vielleicht will der eine oder andere ja doch gerne richtige regular expressions eingeben und wäre traurig, wenn das nicht mehr gehen würde ...
Bisher sucht das Such-Skript strikt case-sensitiv. (Eine Archivsuche nach "aPaCHe" liefert 0 Treffer.)
Manchmal sind aber relevante Begriffe im Archiv nicht in der vom Sucher angegebenen Art und Weise geschrieben worden.
Deshalb möchte ich eine Möglichkeit zur case-insensitiven Suche vorsehen.
Aufwand:
a) ein zusätzliches Flag im Suchformular
b) im Skript dieses Flag abfragen und "i" hinter den regular expression beim Vergleich schreiben.
Anhängigkeiten: Nur vom zugehörigen Formular.
Bisher sucht das Such-Skript strikt case-sensitiv. (Eine Archivsuche nach "aPaCHe" liefert 0 Treffer.)
Aehhemm!
T'schuldigung, dass ich Dir widersprechen muss, aber die EIngabe von "(?i)aPaCHe" liefert derzeit 515 Treffer.
Gruesse
Wilhelm
Hallo
T'schuldigung, dass ich Dir widersprechen muss, aber die EIngabe von "(?i)aPaCHe" liefert derzeit 515 Treffer.
Es wäre aber wesentlich angenehmer, wenn unter dem Eingabefeld ein Häckchen für Gross/Kleinschreibung vorhanden wäre.
Darum ist Michaels Vorschlag zur Case-Sensitivtät meinerseits angenommen.
Grüsse
Tom
Es wäre aber wesentlich angenehmer, wenn unter dem Eingabefeld ein Häckchen für Gross/Kleinschreibung vorhanden wäre.
Unwidersprochen!
Meine Aussage bezog sich auch nur auf seine.
Wenn man es wusste, ging es auch bisher. Es waere IMHO noch besser, wenn (?i) automatisch vorangestellt wuerde.
Darum ist Michaels Vorschlag zur Case-Sensitivtät meinerseits angenommen.
ich schliesse mich an.
Wilhelm
Hi,
das Suchformular ist um ein zusätzliches anlreuzbares Feld für "Klein-/Großschreibung signifikant" erweitert.
Defaultwert ist "nicht ausgewählt".
Verbesserungsvorschläge für den Namen werden dankend angenommen.
Moin,
Verbesserungsvorschläge für den Namen werden dankend angenommen.
Meinst Du sowas: "Klein- oder Großschreibung beachten ?"
Swen
T'schuldigung, dass ich Dir widersprechen muss, aber die EIngabe von "(?i)aPaCHe" liefert derzeit 515 Treffer.
Wahr, aber nur für "Cracks" bedienbar und nicht für "Laufkundschaft".
Genau für die wollen wir die Sache aber doch attraktiver machen, oder?
Wenn es auf der Suchseite wenigstens einen Hilfetext gäbe, der (?i) erklären würde ... dann wäre es immer noch unkomfortabel.
Und wenn es "als eigenständiges Wort" als bereits implementiertes Flag gibt, kann man dessen Auswertung tendenziell duplizieren und anpassen.
Aufwand:
a) ein zusätzliches Flag im Suchformular
b) im Skript dieses Flag abfragen und "i" hinter den regular expression beim Vergleich schreiben.
Erster kleiner Erfolg: Das Such-Skript ist bei mir installiert und läuft.
Und das Auswahlfeld für case-Sensitivität ist eingebaut und funktioniert auch schon ("muenz" liefert 0 bzw. 11 Treffer mit der 50-Zeilen-Indexdatei).
hallo michael, hallo alle anderen forumsbesucher,
zuerst einmal, danke und viel glück, endlich wird diese thema angepackt, sehr schön :)
ich möchte nur mal fix etwas allgemeines loswerden, da ich von den technischen sachen einer solchen suchfunktion nichts verstehe :(
innerhalb dieses forums bewegen sich leute, die teilweise scripts innerhalb von sekunden/minuten schreiben, wo ich sicherlich schon verzweifeln würde (nach stunden sinnlosen rumprobierens ;)
da soll es doch eigentlich möglich sein, dass diese "highest level"-freaks (tw.) eine suchfunktion zusammenbauen, die ebenfalls am obersten niveau des machbaren/realistischen angesiedelt ist, ich denke, es ist schon eine notwendigkeit an sich, diesen anspruch zu erheben.
so, jetzt werde ich nochmal ausführlich diesen thread durchstöbern und dann auch einige sachen nennen, falls mir noch etwas bisher nichtgenanntes einfällt.
bitte, nikita
innerhalb dieses forums bewegen sich leute, die teilweise scripts innerhalb von sekunden/minuten schreiben, wo ich sicherlich schon verzweifeln würde (nach stunden sinnlosen rumprobierens ;)
da soll es doch eigentlich möglich sein, dass diese "highest level"-freaks (tw.) eine suchfunktion zusammenbauen, die ebenfalls am obersten niveau des machbaren/realistischen angesiedelt ist, ich denke, es ist schon eine notwendigkeit an sich, diesen anspruch zu erheben.
Puh - also so der wahnsinnige Perl-Experte bin ich nicht. (Deshalb frage ich ja, ob die Experten bessere Ansätze wüßten ...)
Was ich erst mal tun will, ist, das Skript zu strukturieren, zu dokumentieren und einige Dinge einzubauen, die mit geringem Aufwand einbaubar und für spätere Bearbeiter leicht verständlich sind - insbesondere mehr Optionen im Formular, damit man seine Anfrage genauer beschreiben kann.
Auch will ich den teamone-Server nicht mit hochkomplexen Berechnungen bremsen, die nur in wenigen Fällen etwas bringen werden.
Und vor allem soll die Suchoption ja auch nicht die künftigen Benutzer überfordern, sondern einfach bedienbar bleiben.
Moin,
bevor wir zu sehr ins Detail gehen, vielleicht ein allgemeiner Input, den ich ( nicht um Stefan Muenz ärgern zu wollen, sondern weil mir das Zitat schon immer gefallen hat) aus einem Frühwerk des Meisters <g> zitieren möchte:
<cite>
Bei Projekten mit riesigen Textbeständen kommt eine Realisierung mit lauter einzelnen, statisch abgespeicherten und aufrufbaren Texteinheiten nicht mehr in Frage. Bei solchen Datenbeständen erwartet der Anwender zu Recht eine "Search Engine", die den Datenbestand nach Suchkriterien durchforstet und die Suchergebnisse dynamisch "on demand" aufbereitet. Ein Beispiel im WWW, bei dem Sie die Grenze zwischen thematischer Suche und datenbankgesteuerter Stichwortsuche sehr gut vergleichen können, ist die Kochrezepte-Sammlung mit mehr als 16.000 Hypertext-Einheiten.
</cite>
16.000! Das ist schon lange her!
Wichtig erscheint mir den Blick auf den Durchschnittsbesucher der eben nicht - wie Michael zu Recht betont - die Kniffe und Tricks der jetzigen Suche kennt.
Da ich mich selbst zum den häufiger Suchenden zähle kommt jetzt meine Bitte an die Könnenden: Mir würde eine und/oder Verknüpfung schon ausreichen
Swen
Hi Michael,
auch mir würd im Grunde ein "einfaches" und/oder reichen, jedoch fände ich es sehr praktisch, wenn man, wie auch im Forum selbst, den Themenbereich ersehen könnte, oder sogar damit die Suche einschränken könnte.
Ich suche z.B. meißt nur Postings, die Javascript zum Thema haben.
Da ich nichts von Perl verstehe, weiß ich nicht, welch ein Aufwand da hinter steckt- ich will nichts unmögliches vorschlagen.
Danke für die Arbeit!
Wilm
auch mir würd im Grunde ein "einfaches" und/oder reichen, jedoch fände ich es sehr praktisch, wenn man, wie auch im Forum selbst, den Themenbereich ersehen könnte, oder sogar damit die Suche einschränken könnte.
"Sehen" kann man den Themenbereich bei den Treffern.
Ich suche z.B. meist nur Postings, die Javascript zum Thema haben.
Dann wird "+Javascript" ein häufiger Suchbegriff für Dich sein ... :-)
Da ich nichts von Perl verstehe, weiß ich nicht, welch ein Aufwand da hinter steckt- ich will nichts unmögliches vorschlagen.
Über den Aufwand reden wird, sobald die Aufgabe im Detail spezifiziert ist. Vorher höre ich mir alles an.
Wenn Du mehrere Eingabefelder haben willst, also z. B. separate für das Thema und den Text, dann mach doch mal einen Vorschlag, wie man das später als Anwender bedienen können soll.
Hallo Michael
"Sehen" kann man den Themenbereich bei den Treffern.
Tut mir leid, das war ein Trugschluss von mir, ich habe scheinbar immer nur alte Beiträge gelesen und Themenbereiche scheint es erst seit dem 24.3.1999 zu geben. Sorry!
Dann wird "+Javascript" ein häufiger Suchbegriff für Dich sein ... :-)
Themenbereich fänd ich einfacher ;-))
Wenn Du mehrere Eingabefelder haben willst, also z. B. separate für das Thema und den Text, dann mach doch mal einen Vorschlag, wie man das später als Anwender bedienen können soll.
Ist in Arbeit!
Gruß wilm
Hallo Michael
Hier mein versprochener Entwurf ;-)
http://www.wasser.de/test/suchevorschlag.htm
für Anregungen immer dankbar!
Wilm
Hier mein versprochener Entwurf ;-)
http://www.wasser.de/test/suchevorschlag.htm
Gefällt mir, im Prinzip (modulo Schreibfehler).
Allerdings ist an ein echtes "AND" bzw. "OR" derzeit nicht zu denken - dafür müßte jemand Prioritäten der Operatoren definieren (was bedeutet "a AND b OR C" genau?), was bisher nicht möglich ist, weil die Operatoren nur an ihre Terme gebunden sind, während AND / OR zwingend Beziehungen zwischen mehreren Termen erstellen.
Genau genommen ist MUST ja auch gar nicht der AND-Operator. Derzeit müßte der Text sinngemäß lauten: "+Wort" = Wort muß auftreten, "-Wort" = Wort darf nicht auftreten, "Wort" = Wort soll auftauchen, verbessert aber nur das Rating; falls *kein* "+" vorkommt, werden alle "soll" zu "muß".
Stefan, was meinst Du zum Layout?
Überhaupt ist es so, daß meine Syntax mit dem "+" und "-" natürlich auch von einem JavaScript-Formular aus entsprechend komfortablen Formularfeldern generiert und via CGI-URL an das Such-Skript übergeben werden könnte ... oder?
Will sagen: Niemand behauptet, daß es nur genau *ein* Frontend für eine erweiterte Suchfunktion geben muß! Theoretisch kann sich jeder selbst eine schreiben ... :-)
hi!
Genau genommen ist MUST ja auch gar nicht der AND-Operator. Derzeit müßte der Text
sinngemäß lauten: "+Wort" = Wort muß auftreten, "-Wort" = Wort darf nicht auftreten,
"Wort" = Wort soll auftauchen, verbessert aber nur das Rating; falls *kein* "+" vorkommt,
werden alle "soll" zu "muß".
Warum werden alle "soll" zu "muss"? Das bringt nicht besonders viel, vielleicht will wirklich einer eine OR-Suche starten, dann hindert ihn deine Umwandlung daran. Besser wäre eine ganz kurze Erklärung über der Eingabezeile, die die Verwendung von +, - bzw. keinem Zeichen vornedran erläutert.
Stefan, was meinst Du zum Layout?
Meine Meinung: Sucher, die nur mal schnell ein oder zwei Begriffe eintippen wollen, werden irgendwie "erschlagen" von der Vielzahl der Optionen. Lieber ein zweites Formular auf einer anderen Seite, das dann alle Optionen anbietet. Alle großen Suchmaschinen machen das genauso, und die werden ihre Gründe haben...
bye, Frank!
Moin!
Ich halte es fuer sinnvoll, die Suche auf bestimmte Zeitraeume beschraenken zu koennen. Erstens erinnere ich mich oft ungefaehr an die Zeit, in der ein Thema behandelt wurde, und kann dadurch die Ergebnismenge stark einschraenken, und zweitens waechst die Indexdatei Woche um Woche und eine Such dauert immer laenger. Noch geht's ja, aber irgendwann wird es unertraeglich.
Ich hab mir jetzt mal nicht alles in dem Thread durchgelesen, da ich etwas zu muede bin, um das zu kapieren. Und ueber's Wochenende bin ich offline. Aber dann wuerde ich Dich gerne unterstuetzen.
Ich faende ja sowas cool:
subject:perl+timeout/body:forki
Diesen Suchstring eingeben, um alles zu finden, was "perl" und "timeout" im Subject hat und "fork" im Nachrichtentext. Das ganze Case-insensitive, deswegen das i am Ende (obwohl man das wohl sowieso default machen sollte). Aber ich schaetze, das wird einiges an Performance kosten, und in der Praxis wird derartige Flexibilitaet wohl auch eher selten gebraucht. Naja.
Also dann
Calocybe
Ich halte es fuer sinnvoll, die Suche auf bestimmte Zeitraeume beschraenken zu koennen.
Kannst Du einen Entwurf angeben, wie man das als Anwender bedienen soll? (Eingabefelder für Start- und Enddatum, Defaultwerte, welche Syntax zur Datumseingabe, ggf. JavaScript-Funktionen
Aber dann wuerde ich Dich gerne unterstuetzen.
Dankend angenommen - fang gleich mal damit an, die Eingabe für die Datumswerte zu definieren ...
Und in JavaScript bin ich auch nicht so fit ... (Stefan, darf die Suchmaske überhaupt JavaScript für eine Syntaxprüfung enthalten?)
Ich faende ja sowas cool:
subject:perl+timeout/body:forki
Diesen Suchstring eingeben, um alles zu finden, was "perl" und "timeout" im Subject hat und "fork" im Nachrichtentext. Das ganze Case-insensitive, deswegen das i am Ende (obwohl man das wohl sowieso default machen sollte). Aber ich schaetze, das wird einiges an Performance kosten, und in der Praxis wird derartige Flexibilitaet wohl auch eher selten gebraucht.
Mehrere Suchvorgänge in mehreren Teilobjekten eines Postings sind nicht wirklich schlimm. Bisher speichert der "Tokenizer" eine Liste von Suchbegriffen mit Flag, die dann vom "Matcher" sequentiell bis zum Scheitern ausgewertet werden soll; jeweils auch noch das Suchobjekt abzuspeichern und auszuwerten ist keine besondere zusätzliche Schwierigkeit.
Ich glaube sogar, daß es dadurch *schneller* wird, wenn der "Matcher" nicht mehr für jeden Such-Term *alles* durchsuchen muß, sondern nur noch den relativ kurzen Titel bzw. Verfasser.
Wo ich noch unsicher bin, das ist die Benutzerschnittstelle: Deine Syntax "Bereich:Suchterm" gefällt *mir* (konsistent zu meinem Tokenizer würde ich "+subject:perl +subject:timeout +text:fork" vorschlagen - gefällt Dir das auch?) mag aber für andere Benutzer vielleicht (zu?) kryptisch aussehen.
Das zu parsen ist kein großes zusätzliches Problem, denke ich.
Man muß dem Benutzer allerdings beibringen, daß dann der ":" genau wie das Leerzeichen ein Meta-Charakter ist, der nur noch innerhalb eines Strings als Suchzeichen behandelt wird ... ist das vertretbar? Die *einfachen* Sucheingaben werden dann leider kryptischer ...
Hallo Michael
Kannst Du einen Entwurf angeben, wie man das als Anwender bedienen soll? (Eingabefelder für Start- und Enddatum, Defaultwerte, welche Syntax zur Datumseingabe, ggf. JavaScript-Funktionen
Default sollte bei allen Einschraenkungsmoeglichkeiten "alle" sein. Am einfachsten ist es, innerhalb des Formulars die Einstellmoeglichkeiten dem Anwender kurz zu erlaeutern. Bei den Zeitraumfeldern wuerden zwei einfache Eingabefelder von und bis genuegen, mit dem Satz untendrunter, dass die Eingaben in der Form XX.XX.XXXX erfolgen sollten und dass das Forum am 26.07.1998 startete.
viele Gruesse
Stefan Muenz
Hi!
Kannst Du einen Entwurf angeben, wie man das als Anwender bedienen soll? (Eingabefelder für Start- und Enddatum, Defaultwerte, welche Syntax zur Datumseingabe, ggf. JavaScript-Funktionen
Tja, wenn ich mir <../../sfarchiv/src/idxbsp.txt> so anschaue, ist das mit dem Datum gar nicht so einfach. Die einzige Zeitangabe, die dort steht, ist das Quartal im Dateipfad. Tja, was machen wir denn da? Wenn wir wirklich eine feinere Zeitraumbestimmung machen wollen, brauchen wir auf jeden Fall die Datums-Information. Also Indexdatei neu aufbauen? Moeglich, aber ungern. Schlage vor: Ich habe schonmal eine extra Thread Database aufgebaut (als ich die statistischen Auswertungen fuer http://www.atomic-eggs.com/selfspezial/ gemacht habe). Diese enthaelt diverse Informationen, unter anderem auch Datum eines jeden Postings. So muesste man erst diese DB durchlesen, um anhand des Datums ein zulaessiges Dateinamen/Ankernamen-Bereich herauszufinden, und danach wird dann in dem Bereich die eigentliche Suche durchgefuehrt.
Aber zurueck zu dem Bedienungsentwurf: Ich denk mal drueber nach. *g*
Mehrere Suchvorgänge in mehreren Teilobjekten eines Postings sind nicht wirklich schlimm. Bisher speichert der "Tokenizer" eine Liste von Suchbegriffen mit Flag, die dann vom "Matcher" sequentiell bis zum Scheitern ausgewertet werden soll; jeweils auch noch das Suchobjekt abzuspeichern und auszuwerten ist keine besondere zusätzliche Schwierigkeit.
Ok, ich nehm das mal so hin. Ich hab mir Deinen Tokenizer-Teilthread noch nicht durchgelesen. War mir gestern abend zu hoch und heute hab ich nicht soo viel Zeit (was zwangslaeufig unglaubwuerdig klingt, wenn man sich die Groesse diese Postings ansieht *g*).
(konsistent zu meinem Tokenizer würde ich "+subject:perl +subject:timeout +text:fork" vorschlagen - gefällt Dir das auch?)
Yepp, is ok fuer mich. :-)
mag aber für andere Benutzer vielleicht (zu?) kryptisch aussehen.
Ja, koennte sein.
Nun, eigentlich macht man das ja so: Die Search-Engine bekommt in jedem Fall einen String wie oben verabreicht, der dann geparst und verarbeitet wird. Dies stellt das Backend dar, auf das von unterschiedliche Stellen, aber immer auf die gleiche Weise zugegriffen werden kann. Diese unterschiedlichen Stellen sind de facto 1. ein Front-End in HTML und 2. der Query-String (so wie jetzt auch schon). Jetzt muss man nur irgendwie das Frontend so hinkriegen, dass das diesen String auch ordentlich zusammenbaut. Und da ist das Problem: So was geht in meiner humble-erster-blick-opinion nur mit JavaScript vernuenftig. Aber natuerlich muss das auch ohne JS bedienbar sein, oder besser voellig ohne JS auskommen. Also vielleicht als HTML-Frontend eine Seite, in der man wahlweise 1. selber den Requeststring reinhackt, oder 2. eben nur begrenzte Moeglichkeiten hat, die man in diversen Formularfelden nutzen kann, und deren Daten dann serverseitig zu dem String zusammengebastelt werden. Ok, das war dannn also meine humble-zweiter-blick-opinion. ;-)
Das zu parsen ist kein großes zusätzliches Problem, denke ich.
Man muß dem Benutzer allerdings beibringen, daß dann der ":" genau wie das Leerzeichen ein Meta-Charakter ist, der nur noch innerhalb eines Strings als Suchzeichen behandelt wird ... ist das vertretbar? Die *einfachen* Sucheingaben werden dann leider kryptischer ...
Darueber denk ich ein andermal nach. Muss jetzt erstmal weiterarbeiten...
Noch was: Die Indexdatei trennt die einzelnen Felder mit dem Pipe-Zeichen (). Wenn jetzt aber jemand in Text oder Titel oder sonstwo so ein Zeichen eingibt (so wie ich gerade), fliegt das split auf die Schnauze. Und tatsaechlich hatte schon mal irgendjemand ein in seinem Namen verwendet! Noch oefter kommt es im Body vor, wenn man in JS ueber die Oder-Verknuepfung redet. Genau das Problem hatte ich uebrigens auch, als ich fuer mein Statistikscript jene Database aehnlich dieser Indexdatei aufgebaut habe. Dort habe ich auch das als Trennzeichen verwendet, und deshalb bereits bestehende durch \p maskiert, und \ wiederum durch \. Bis jetzt hatte ich es aber noch nicht noetig, diese automatisch zurueckzukonvertieren, was mit RegExps imho nicht ganz einfach ist. (Man nehme als Beispiel nur mal eben diesen Absatz.)
Soweit erstmal
Calocybe
P.S. Den Rest dieses Threads muss ich mir dann wohl im Archiv angucken.
Hallo Calocybe
Tja, wenn ich mir <../../sfarchiv/src/idxbsp.txt> so anschaue, ist das mit dem Datum gar nicht so einfach. Die einzige Zeitangabe, die dort steht, ist das Quartal im Dateipfad. Tja, was machen wir denn da?
Noch mal genauer hinschauen tun wir da!
Ganz einfach ;-)
Noch was: Die Indexdatei trennt die einzelnen Felder mit dem Pipe-Zeichen (). Wenn jetzt aber jemand in Text oder Titel oder sonstwo so ein Zeichen eingibt (so wie ich gerade), fliegt das split auf die Schnauze.
Meine Predigt: haltet den Schwanzabschneider nicht fuer doof! Der schmeisst die natuerlich vorher raus.
viele Gruesse
Stefan Muenz
Hallo Michael
bevor wir hier weiterdiskutieren, sollten wir vielleicht erst noch mal alle Interessierten auf http://www.teamone.de/selfaktuell/self_forum/30472.html schicken. Offensichtlich entsteht hier naemlich der Eindruck, das ganze oder halbe Forum stehe zur Disposition. Dem ist nicht so. Es gibt eine Vorgabe, und das ist die bereits vorhandene Indexdatei fuer die Volltextsuche. Das Script soll diese Datei abarbeiten und Suchergebnisse daraus erzeugen, die genau so aussehen wie bisher. Nuetzliche Suchoptionen sollen eingebaut werden, aber immer in Ruecksicht auf die Tatsache, dass die abzuarbeitende Datei derzeit 23MB gross ist und auch nicht kleiner wird.
Nueztliche Suchoptionen aus meiner Sicht:
viele Gruesse
Stefan Muenz
Es gibt eine Vorgabe, und das ist die bereits vorhandene Indexdatei fuer die Volltextsuche. Das Script soll diese Datei abarbeiten und Suchergebnisse daraus erzeugen, die genau so aussehen wie bisher.
Nuetzliche Suchoptionen sollen eingebaut werden, aber immer in Ruecksicht auf die Tatsache, dass die abzuarbeitende Datei derzeit 23MB gross ist und auch nicht kleiner wird.
Absolute Zustimmung. So wenig Änderungen wie möglich - es soll ja beherrschbar bleiben.
Nuetzliche Suchoptionen aus meiner Sicht:
- Checkbox fuer Klein-/Gross-Unterscheidung ja/nein
Ist schon drin.
- Zeitraumsuche
Gekauft.
Gegenfrage: Hältst Du es für sinnvoll, die Anordnung der Treffer zu invertieren? Bisher sind die ältesten Postings vorne, wobei aber vielleicht die neuesten sachlich fortgeschrittenere Aussagen enthalten könnten.
Bei Ausgabe aller Treffer kann ich das im Such-Skript umsortieren; sobald aber eine *Begrenzung* von Treffern hinzukommt, wäre es geschickter, wenn der Index umgekehrt sortiert wäre (um die Suche dann abbrechen zu können) - ginge das? (Insgeheim fürchte ich, daß der Index nicht jedes Mal komplett neu berechnet, sondern vom Schwanzabschneider am Ende erweitert wird ...)
- einfache Verknuepfung mit +/- Operanden und komplexen Ausdruecken "..."
"+" und "-" sind m. E. kein Problem.
Der "Tokenzer" und der "Matcher" werden sauber abgetrennte Funktionen des Such-Skripts; wer später statt einer Liste von Suchbegriffen einen Baum für rekursive Ausdrücke einbauen will, wird hoffentlich wenig ändern müssen (allerdings in *beiden* Funktionen, weil die eine Funktion die Datenstruktur aufbaut und die andere sie abarbeitet).
- fuer Profis eventuell die Moeglichkeit, den Suchausdruck ungefiltert als regulaeren Ausdruck zu interpretieren
Hm, da überschaue ich momentan die Konsequenzen nicht, werde mich aber bemühen, das nicht zuzunageln.
Ich habe ein wenig Angst, daß dann bei fehlerhaft aufgebauten Ausdrücken das Suchskript abstürzen wird ... und die Korrektheit von regulären Ausdrücken zu prüfen erscheint mir nicht trivial. (Falls hier jemand eine Lösung anbieten könnte ...)
- Begrenzung der Suchtreffer per Auswahlliste auf alle,10,20,50,100,200,500,1000
Gekauft. (Gewünschter Defaultwert?)
Und soll man wie bei anderen Suchmaschinen auf die
nächsten <n> Treffer weiterblättern können, falls es zu wenig war? (Das wäre dann die nächst-höhere Ausbaustufe ...)
Hallo Michael
Gegenfrage: Hältst Du es für sinnvoll, die Anordnung der Treffer zu invertieren?
Sollte man vielleicht auch einstellbar machen. Denn "aelter" bedeutet nicht unbedingt "wertloser".
Bei Ausgabe aller Treffer kann ich das im Such-Skript umsortieren; sobald aber eine *Begrenzung* von Treffern hinzukommt, wäre es geschickter, wenn der Index umgekehrt sortiert wäre (um die Suche dann abbrechen zu können) - ginge das?
Du kannst ja alle Treffer sammeln und nur die letzten n Treffer in die Trefferliste uebernehmen, und diese dann meinetwegen noch invertieren.
- fuer Profis eventuell die Moeglichkeit, den Suchausdruck ungefiltert als regulaeren Ausdruck zu interpretieren
Hm, da überschaue ich momentan die Konsequenzen nicht, werde mich aber bemühen, das nicht zuzunageln.
Ist die Frage, wie das realisierbar ist. Du wirst kaum einen kompletten grep schreiben koennen. Aber gibt es eine Moeglichkeit, den Inhalt von /$Variable/ direkt regulaer zu interpretieren?
Ich habe ein wenig Angst, daß dann bei fehlerhaft aufgebauten Ausdrücken das Suchskript abstürzen wird
Eigentlich kann da nicht viel passieren. Entweder er findet, oder er findet nicht.
Und soll man wie bei anderen Suchmaschinen auf die
nächsten <n> Treffer weiterblättern können, falls es zu wenig war? (Das wäre dann die nächst-höhere Ausbaustufe ...)
Nee, der HTML-Output sollte das Formular ja eh erneut aufbauen, und zwar mit den zuletzt eingestellten values. Da kann der Anwender dann ja einfach einen hoeheren Trefferanzahlwert einstellen und das Ganze noch mal anstossen.
viele Gruesse
Stefan Muenz
Gegenfrage: Hältst Du es für sinnvoll, die Anordnung der Treffer zu invertieren?
Sollte man vielleicht auch einstellbar machen. Denn "aelter" bedeutet nicht unbedingt "wertloser".
Hm ... noch mehr Flags in der Oberfläche. (Version 2.0, schlage ich vor.)
sobald aber eine *Begrenzung* von Treffern hinzukommt, wäre es geschickter, wenn der Index umgekehrt sortiert wäre (um die Suche dann abbrechen zu können) - ginge das?
Du kannst ja alle Treffer sammeln und nur die letzten n Treffer in die Trefferliste uebernehmen, und diese dann meinetwegen noch invertieren.
Klar kann ich, aber es ist eine Performance-Frage, erst 10000 Treffer zu berechnen, um davon dann nur die letzten 100 auszugeben.
Hätte ich die Sortierung bereits so, wie ich sie brauche, wäre die Suchfunktion bei begrenzter Treffermenge wesentlich schneller. Und genau das soll die Trefferbegrenzung ja bringen: Weniger Last auf den Server, damit er seine Kraft z. B. für intelligentere Vergleichen einsetzen kann.
(Fast würde ich überlegen, zwei Instanzen des Index mit invertierter Sortierung vorzuhalten ... mal sehen, ob wir Performance-Probleme bekommen, dann kann man das noch nachrüsten.)
Aber gibt es eine Moeglichkeit, den Inhalt von /$Variable/ direkt regulaer zu interpretieren?
Ja. Meine Fileselect-Box in HTML basiert auf einer Perl-Funktion, die als Parameter ein Verzeichnis und eine Liste (!) von Endungen bekommt. Aus den Endungen baut sie mit "" einen regular expression zusammen, der die Obermenge dieser Dateinamen akzeptiert, und dann filtert sie den Verzeichnisinhalt ...
Ich habe ein wenig Angst, daß dann bei fehlerhaft aufgebauten Ausdrücken das Suchskript abstürzen wird
Eigentlich kann da nicht viel passieren. Entweder er findet, oder er findet nicht.
Wenn Syntaxfehler in einem regulären Expression drin sind, findet der Perl-Interpreter das gar nicht lustig, sondern steigt aus ... und dann haben wir einen Error 500 in der Suchmaschine.
Nee, der HTML-Output sollte das Formular ja eh erneut aufbauen, und zwar mit den zuletzt eingestellten values. Da kann der Anwender dann ja einfach einen hoeheren Trefferanzahlwert einstellen und das Ganze noch mal anstossen.
Verstanden und gekauft.
Hallo Michael
Klar kann ich, aber es ist eine Performance-Frage, erst 10000 Treffer zu berechnen, um davon dann nur die letzten 100 auszugeben.
Hätte ich die Sortierung bereits so, wie ich sie brauche, wäre die Suchfunktion bei begrenzter Treffermenge wesentlich schneller.
Und der arme Schwanzabschneider, der die Indexdatei aktualisiert, soll jedesmal die Riesendatei vorne aktualisieren? Nee, der ist schon kritisch genug, den lass ich nicht noch mehr machen <g>.
Wie gesagt, die Forumssuche steht zur Disposition, sonst nichts. Der Input muss so verarbeitet werden wie er nun mal ist.
viele Gruesse
Stefan Muenz
Hi nochmal
Ist die Frage, wie das realisierbar ist. Du wirst kaum einen kompletten grep schreiben koennen. Aber gibt es eine Moeglichkeit, den Inhalt von /$Variable/ direkt regulaer zu interpretieren?
Na genau das machst Du doch bisher schon. Erinnerst Du Dich an den 500er-Error von dem ich Dir mal erzaehlt habe? Tritt z.B. auf, wenn man am Anfang des Suchausdrucks einen * eingibt. Der ist in einem Regexp nur hinter einem anderen Zeichen zulaessig, aber nicht an erster Stelle. Siehe http://www.teamone.de/cgi-local/sfasuch.pl?* (Oh je, jetzt gibt's massenweise Eintraege in den Errorlogs auf teamone *g*). Ich hab jedenfalls schon oefter mit Regexps im Archiv gesucht (hat nur meistens auch nicht so viel gebracht).
Und soll man wie bei anderen Suchmaschinen auf die
nächsten <n> Treffer weiterblättern können, falls es zu wenig war? (Das wäre dann die nächst-höhere Ausbaustufe ...)
Halte ich dann doch fuer uebertrieben. Ist wohl auch nicht so ganz einfach zu realisieren, ausser man fuehrt die komplette Suche immer nochmal durch.
Calocybe
gibt es eine Moeglichkeit, den Inhalt von /$Variable/ direkt regulaer zu interpretieren?
Na genau das machst Du doch bisher schon.
Eben. Wollen wir das drin lassen? Ich könnte die Metazeichen natürlich escapen. Sagt was, Leute! Wer sucht mit regular expressions?
Und soll man wie bei anderen Suchmaschinen auf die
nächsten <n> Treffer weiterblättern können, falls es zu wenig war?
Halte ich dann doch fuer uebertrieben. Ist wohl auch nicht so ganz einfach zu realisieren, ausser man fuehrt die komplette Suche immer nochmal durch.
In der Tat, und Stefan hat es auch abgelehnt, weil er die Bedienungsmethode der Suche hier nicht geändert haben will. Was nur so eine Frage.
hallo
nachdem ich mich von der "Initiativstrafe"
Also ich wette mit Dir, dieser Begriff wird hier zum absoluten Renner mutieren. :-)
Aber jetzt mal im Ernst. Ich verfolge den Thread ja sehr aufmerksam, kann aber magels PERL-Kenntnissen nicht so recht mitdiskutieren, ich kenne jedoch die Problematik von anderen System her.
Meiner Meinung nach schiesst Ihr ueber das Ziel hinaus. Ihr wollt hier ein System konstruieren oder auf die Beine stellen, das voellig ueberdimensioniert ist. (wer schreibt eigentlich das notwendige Handbuch fuer die Enduser?.
Wenn ich mir die ganzen Vorschlaege so angucke, draengt sich mir die Erkenntnis auf, mann muesste fuer dies alles eine Oracle- oder Informix-Datenbank installieren.
Oder besser gleich die DB2 von IBM und zwar in der Hostkonfiguration. Dann koennte ich wenigstes ein paar REXX- oder SQL-Skripte beisteuern, inkl. dem passenden Rechner. ;-)
Als, nix fuer ungut, aber die Punkte case-sensitiv und AND/OR wuerden fuer die Zwecke hier voellig ausreichen. Aber noch ein Ranking und eine Naeherungssuche zu implementieren halte ich fuer voellig ueberdreht.
Wenn man fuer eine Suchmaschine eine Gebrauchsanweisung braucht, ist es keine gute Suchmaschine mehr.
Ich hoffe, dass als Alternative fuer die DAU's wie mich noch die jetzige, simple, Version erhalten bleibt. Ich bin eigentlich immer recht gut damit zurechtgekommen.
Gruesse und weiterhin frohes modellieren
Wilhelm
Als, nix fuer ungut, aber die Punkte case-sensitiv und AND/OR wuerden fuer die Zwecke hier voellig ausreichen. Aber noch ein Ranking und eine Naeherungssuche zu implementieren halte ich fuer voellig ueberdreht.
Ich gebe Dir völlig recht. Ich drücke mich derzeit ja sogar vor dem OR-Operator, weil ich dann rekursiv Ausdrücke mit Prioritäten auswerten müßte.
Ich hoffe, dass als Alternative fuer die DAU's wie mich noch die jetzige, simple, Version erhalten bleibt. Ich bin eigentlich immer recht gut damit zurechtgekommen.
Damit erlege ich Dir die Initiativstrafe auf :-), zu beurteilen, ob Du folgende Sucheingabe verstehst (gerade eben hat mein "Matcher" nämlich erstmals richtige Ergebnisse geliefert!).
Für eine Stichprobe von 48 Postings habe ich gerade folgende Suchbegriffe eingegeben:
"+Stefan" = 21 Treffer
"+Perl" = 7 Treffer
"+Perl +Stefan" = 3 Treffer
"+Perl -Stefan" = 4 Treffer
"-Perl +Stefan" = 18 Treffer
Ist das noch "DAU-tauglich"?
Die Reihenfolge der eingegebenen Begriffe ist beliebig.
In allen obigen Beispielen außer dem *dritten* darf man zudem die "+"-Zeichen weglassen - wenn *kein* Suchbegriff als "MUST" deklariert ist, wandele ich alle "CAN" in "MUST" um ...
In allen obigen Beispielen außer dem *dritten* darf man zudem die "+"-Zeichen weglassen - wenn *kein* Suchbegriff als "MUST" deklariert ist, wandele ich alle "CAN" in "MUST" um ...
Hoppla, das war zu schnell geschossen.
Auch bei "+Stefan +Perl" darf man *beide* "+"-Zeichen weglassen (dann werden *beide* Terme zu "MUST" promoted), aber *nicht* nur eines von beiden (dann würde dieser Term ignoriert, weil "CAN" derzeit noch keine Bedeutung für den "Matcher" hat).
Damit erlege ich Dir die Initiativstrafe auf :-), zu beurteilen, ob Du folgende Sucheingabe verstehst (gerade eben hat mein "Matcher" nämlich erstmals richtige Ergebnisse geliefert!).
Für eine Stichprobe von 48 Postings habe ich gerade folgende Suchbegriffe eingegeben:
"+Stefan" = 21 Treffer
"+Perl" = 7 Treffer
"+Perl +Stefan" = 3 Treffer
"+Perl -Stefan" = 4 Treffer
"-Perl +Stefan" = 18 Treffer
Ist das noch "DAU-tauglich"?
Im Prinzip ja, aber....
Was mich etwas irritiert, sind die NOT's. Das mag ja bei grossen Suchmaschinen mit ein paar mille Eintraegen ja noch einen Sinn ergeben. Aber hier? IMHO verkompliziert das nur das Skript (sprich Laufzeit). Ich kann halt hierfuer den Sinn und Zweck nicht erkennen, darum wuerde mich mal ein konkretes Anwendungsbeispiel interessieren, wo der Nutzen zu tragen kommt.
Aber vielleicht bin ich ja deswegen der DAU ;-)
Wilhelm
Im Prinzip ja, aber....
Fein, das wollte ich hören ... :-)
Was mich etwas irritiert, sind die NOT's. Das mag ja bei grossen Suchmaschinen mit ein paar mille Eintraegen ja noch einen Sinn ergeben. Aber hier? IMHO verkompliziert das nur das Skript (sprich Laufzeit). Ich kann halt hierfuer den Sinn und Zweck nicht erkennen, darum wuerde mich mal ein konkretes Anwendungsbeispiel interessieren, wo der Nutzen zu tragen kommt.
Naja, vielleicht "+webserver -apache" für jemanden, der nach einer Alternative sucht ... (unrealistisches Beispiel :-)
Oder "+browser -netscape -explorer", um Exoten zu finden ...
Der Punkt ist: Es kostet einfach nichts, und es hilft manchmal. Der Parser ist ohnehin rasend schnell (die paar Bytes sind leicht auszuwerten), und der Matcher wird durch *nicht* angegebene NOTs auch nicht langsamer. Durch *angegebene* NOTs wird er ebenfalls nur geringfügig langsamer: Nach Frank Schönmanns Verbesserungsvorschlag sind viele NOTs genauso schnell auswertbar wir ein einziger (!) AND-Term ...
Moin, Unermüdlicher,
eine Hinweis von Thomas J.S (<30791.html>) auf die Forumsauslese drängt bei mir die Frage auf, ob dieser Bereich nicht mit-durchsucht werden sollte.
Da ich von perl null Ahnung habe und deshalb nicht beurteilen kann, ob das ein Kraftakt ist: Ein Hinweis auf die Auslese im Suchformular bringt natürlich ähnlichen Nutzen
Swen
