nicht angemeldet
(ZU DIESEM FORUM) Nochmal als eigener Thread: Archivsuche erweitern um SelfHTML und Forum-Auslese
Technisch gesehen würde der Trick darin bestehen, den existierenden Schwanzabschneider zu nehmen und seine Eingabeschnittstelle so anzupassen, daß er eben nicht Forumspostings einliest, sondern Selfhtml- oder Auslese-Dateien
Warum sollte er bei jedem Lauf von neuem diese immer gleichen Dateien mit indexieren?
Sorry - das ist falsch herübergekommen: Auch ich will nicht den Schwanzabschneider selbst ändern, sondern einen Klon von ihm.
(An anderer Stelle schreibe ich ja auch über das Zusammenmischen von drei Indexdateien.)
Wenn dann jemand nur im Feld "Verfasser" sucht, findet er halt nur Forumsnachrichten und nichts aus SELFHTML oder Auslese.
Hm, das fände ich schade.
Der "Verfasser" von SelfHTML ergibt sich aus den Tatsachen ...
Die Suche muesste dann eben zwei Indexdateien durchsuchen statt nur eine. Kann man ja auch als Checkbox optional einstellbar machen, welche Bereiche durchsucht werden sollen.
Genau das möchte ich vermeiden. (Und sei es nur, weil es die Bedienung der Suchmaschine noch komplizierter macht.)
Nein - das Format der Artikel ist mir gleichförmig genug, um mit einem einzigen Suchskript arbeiten zu wollen. Deshalb war ja auch der erste Satz meines Startpostings: Am Suchskript ändert sich nix.
Wie fein soll geindext werden?
Volltext. Drunter kommt finde ich nichts in Frage. Die bisherigen, auf Meta-Daten beruhenden Suchen sind einfach zu wenig.
Aha - das war nicht das Ziel meiner Frage, aber bezüglich der Ausführungen von Kess ist es nicht ganz unwichtig.
Und was die Linkzuordnung betrifft: bis auf die Zwischenüberschriften genau. Also #a1, #a2 usw. - entsprechend in der Forumsauslese.
Oooookay. Und wie parst man nun ein SelfHTML-Dokument so, daß man es in solche "Postings" zerlegen kann - ist der Aufbau Deiner Dateien wirklich systematisch genug dafür?
Du willst ja das Original nicht umschreiben, aber was tun, wenn der Indexer an einigen Stellen auf die Nase fällt? (Sind das dann "bugs" in SelfHTML?)
Bei letzterer koennte man auch noch die dort fuer Suchzwecke eingefuehrten hidden-Formularfelder am Anfang jeder Zwischenueberschrift mit indexieren.
Ach, das gibt's schon? Oh - ein bißchen auf "human readable" optimiert - na, das gibt sich beim Bügeln.
Wie wäre es dann noch mit <SPAN CLASS="Author">Stefan Münz</SPAN> vor der jeweilgen E-Mail-Adresse?
(Das ist es, was XML uns sagen will ... ;-)
Vorschlag fuer den Zeilenaufbau der Indexdatei fuer SELFHTML und Auslese:
DateinameAnkernameUeberschriftentextResttext
So koennte man auch noch zwischen Ueberschrift und uebrigem Text gewichten in der Suche.
Siehe oben - mir wäre ein einziger Index zum darin Suchen wesentlich lieber. (Denke auch an die Wartbarkeit der Software ...)
Tja, und dann gibt es da noch was: die Suchindexdatei fuer's Forumsarchiv ist jetzt bei ca. 40 MB. Die Antwortzeiten werden doch allmaehlich laenger. Irgendwann wird wohl mal eine andere Loesung hermuessen als die selbstgestrickten Indexdateien. Any ideas?
Wenn Du Volltext willst, dann willst Du eben Volltext.
Würde man das Verfahren von Kess verwenden wollen, dann sollte man denselben Projektivitätstest, den Du für die Stopwortliste schon mal gemacht hast, für das gesamte Forum nochmal durchführen. Und weil es Volltext ist, rechne ich auch insgesamt mit einer geringen Quote an Redundanz.
Nimmt man die erforderliche Infrastruktur hinzu (25000 mal "HTML" wird ja nun ersetzt durch einmal "HTML" und 25000 Verweise auf die entsprechenden Dokumente!), dann wird der Index erst mal *deutlich größer* als bisher!
Das liegt daran, daß ein Indexeintrag eine relativ konstante Größe hat; je kleiner das indizierte Objekt (in unserem Falle ein Wort), desto ungünstiger wird das Verhältnis an Platzbedarf. (Ich habe eine Datenbank mit 20 Mio. Datensätzen der Länge ca. 50 Byte aus 8 ähnlich großen Feldern und dazu zwei Indexe auf eines bzw. zwei dieser Felder; beide Indexe haben zusammen fast dieselbe Größe wie die Tabelle, jeweils etwa 1 GB.)
Die einzige Hoffnung ist, daß dann nur noch kleine Teile von ihm durchsucht werden müssen (siehe anderes Posting). Aber je nachdem, wie die Suchanforderung formuliert ist (regexp!), kann der Index auch ziemlich wertlos sein - manchmal hilft eben doch nur ein full table scan.
(<OT>: Deshalb: Vorsicht bei der Verwendung von LIKE und % in SQL - für die Performance kann das Zehnerpotenzen kosten.</OT>)
Vielleicht bitte nicht gleich die Fireball-Datenbank-Loesung fuer ein paar hundert Tausend Mark.
Was hältst Du von einer Lösung mit Indexen für NULL Mark?
Schon vor Monaten hatte ich mal erwähnt, daß ich eine Suchmaschine im Intranet "einsetze" (naja, ich bin wahrscheinlich der einzige Benutzer, und seit dem Forumarchiv hat auch das nachgelassen), die es als C-Quelltext für UNIX gibt (oder wenigstens 1997 gab).
Die Wurzel des Ganzen sind
- "agrep", ein UNIX-grep-Kommando, das auch "ungefähre" Treffer machen kann (den "Abstand" kann man über Parameter einstellen), und
- "glimpse", ein UNIX-Kommando, das nicht in einer Datei, sondern in einem Index sucht. (Ein separater Full-Indexer ist dabei.)
Nimm beides zusammen, klebe ein bißchen CGI/Perl drum herum, und fertig ist die Suchmaschine! Diese heißt dann GlimpseHTTP.
All dies stammt aus einem Forschungsprojekt der Universität von Arizona. Der genaue Status von GlimpseHTTP ist mir nicht bekannt - ich hatte damals (1997?) eine E-Mail an den Autor geschrieben, um zu fragen, ab wann der Einsatz vielleicht doch etwas kosten könnte, aber nie eine Antwort erhalten.
Basierend auf GlimpseHTTP gibt es Erweiterungen, die dann kommerzielle Produkte sind - das hat mich dann nicht mehr arg interessiert. Ich fand einfach die Idee cool, eine kostenlose Suchmaschine zu haben, die mit Tippfehlern fertig wird ...
Es war allerdings eine nette Bastelei, das Ding zum Laufen zu bringen, damals gab es noch kein "configure" oder so - und die HTML-Umsetzung deutscher Umlaute im Suchformular mußte ich damals auch selbst einbauen, als ich noch kaum HTML und gar kein Perl konnte ... ja, damals in den Gründertagen, da hätte ich das Forum jeden Tag gebraucht ... ;-)
Und tendenziell eher eine Loesung, bei der nicht die Dateien des Forumsarchivs selber ersetzt werden. Denn ich mag es eigentlich ganz gerne so wie es jetzt ist, dass die Archivdateien als statische HTML-Dateien existieren, die auch von grossen Such-Robots indexiert werden usw.
Ich habe mit Glimpse meinen gesamten Web-Server geindext; der Indexerlauf ist irgendwann Sonntags via cron ... SelfHTML ist auch irgendwo mit dabei.
Dateiformate sind Schall und Rauch, wenn man in "grep" denkt - auch Binärdaten könnte man nach Strings durchsuchen, etwa Programmdateien nach eingebrannten Pfaden ...
Aber bevor Glimpse jetzt als Allheilmittel erscheint: Sooo wahnsinnig perfekt ist die mir vorliegende Uraltversion nun auch nicht. Es gibt immer mal wieder Suchprozesse, die sich im Hintergrund verselbständigen und tagelang ergebnislos die CPU belagern. Drum prüfe, wer sich ewig bindet ...
Um das wieder gegenzubalancieren: GlimpseHTTP hat ein nettes Konzept, wie man Treffer in Dokumenten anzeigen kann. Es wird nicht etwa ein Link auf das Zieldokument generiert, sondern ein Link auf ein kleines CGI-Skript, welches das Zieldokument einliest, an der Trefferstelle einen <A NAME> einfügt, das Trefferwort fett darstellt und das Ergebnis an den Browser schickt - der Link führt also zur exakten Trefferposition und der Treffer ist auch noch gehighlightet ... hübsch, nicht? Deshalb kann ein Dokument auch mehrere Treffer liefern; man kann sowohl die Menge der Trefferdokumente als auch die Menge der Treffer pro Dokument in der Suchmaske limitieren.