nicht angemeldet
(ZU DIESEM FORUM) Nochmal als eigener Thread: Archivsuche erweitern um SelfHTML und Forum-Auslese
(ZU DIESEM FORUM) Nochmal als eigener Thread: Archivsuche erweitern um SelfHTML und Forum-Auslese
Allerdings halte ich diesen schon aus allen
Fugen platzenden Thread nicht fuer den
geeigneten Ort, um das zu diskutieren.
Vielleicht machst du mal einen neuen deswegen
auf!
cut & waste archive space?
(hmmmmpffff, das reimt sich ja auch noch ... ;-)
Na, dann doch lieber nur einen Verweis auf das Original: </selfaktuell/self_forum/51131.html>.
Reicht das? ;-)
-
Hallo Michael
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?
Ich stelle mir eher ein Arbeits-Script vor, dass vom Schwanzabschneider getrennt ist und bei Bedarf den Inhalt der Verzeichnisse von SELFHTML und der Forumsauslese indexiert.Die indexierten Daten wuerde ich auch nicht an die vorhandene Suchindexdatei des Forumsarchivs anhaengen, sondern in eine eigene, vergleichbare Suchindexdatei mit eigenem Aufbau schreiben. Wenn dann jemand nur im Feld "Verfasser" sucht, findet er halt nur Forumsnachrichten und nichts aus SELFHTML oder Auslese.
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.
Wie fein soll geindext werden?
Volltext. Drunter kommt finde ich nichts in Frage. Die bisherigen, auf Meta-Daten beruhenden Suchen sind einfach zu wenig.
Und was die Linkzuordnung betrifft: bis auf die Zwischenüberschriften genau. Also #a1, #a2 usw. - entsprechend in der Forumsauslese. Bei letzterer koennte man auch noch die dort fuer Suchzwecke eingefuehrten hidden-Formularfelder am Anfang jeder Zwischenueberschrift mit indexieren.
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.
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? Vielleicht bitte nicht gleich die Fireball-Datenbank-Loesung fuer ein paar hundert Tausend Mark. 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.
viele Gruesse
Stefan Muenz-
Moin Stefan,
(...) den existierenden Schwanzabschneider zu nehmen und seine Eingabeschnittstelle so anzupassen, daß er eben nicht Forumspostings einliest, sondern Selfhtml- oder Auslese-Dateien
kleine Ergänzung - falls du es nicht eh schon so gemeint hast: Auch die Rubriken "Beiträge" und "Links" gehören IMHO dazu.
Any ideas? Vielleicht bitte nicht gleich die Fireball-Datenbank-Loesung fuer ein paar hundert Tausend Mark.
Mal ganz naiv gefragt: Wenn die (oder andere) schon eine haben, könnten die vielleicht (Eigen)interesse haben, dass für selfhtml gleich mitzumachen ? Oder wäre das der erste Schritt zur Kommerzialisierung ?
Swen
-
Hallo Swen
Mal ganz naiv gefragt: Wenn die (oder andere) schon eine haben, könnten die vielleicht (Eigen)interesse haben, dass für selfhtml gleich mitzumachen ? Oder wäre das der erste Schritt zur Kommerzialisierung ?
Ja, das waere es. Zwar koennten sicher die meisten damit leben, aber solange es auch realisierbare Loesungen gibt, bei denen man sich von niemandem abhaengig macht, sollten diese Vorrang haben.
viele Gruesse
Stefan Muenz
-
-
Hallo Stefan und Michael,
wo ist mein Posting von heute morgen hin ? *gmpf* Habe ich das alles in die Luft geschrieben ???
Also noch mal:
Ich denke, und das wißt ihr sicher auch selber :-), eine Erweiterung der Suche auf Selfhtml und die Forumsauslese würde riesige Indexdateien bedeuten.
Eine Aufteilung der Dateien nach Jahren mag kurzfristig Abbhilfe schaffen, ist aber eine zusammengemauschelte Lösung. Wenn ich mir die Tendenz dieses Forums ansehe, wird dieses Jahr alleine vermutlich so viel Aufkommen bringen, wie 1998 und 1999 zusammen. Bald teilen wir die Indexfiles dann nach Halbjahren, und dann nach ...
Auch müßten die Indices über Selfhtml wohl nach Themengebiet geteilt werden. Und wenn ich dann mal über die gesamte Site suchen möchte ? ... Die Antwortzeiten mag ich mir gar nicht ausmalen.Bei dem Umfang kommt man an einer Datenbank gar nicht vorbei. Es muß nicht gleich eine 100.000 DM Lösung sein. Erst einmal sollte man ein Konzept entwickeln und DANN wird die passende DB und notfalls auch der passende Provider dazu gesucht.
Damit es nicht heißt 'Ist ja alles ganz schön und gut, aber ...' hier gleich eine erste Überlegung für ein solges Konzept.
Fangen wir mal mit der Volltextsuche an. Der umfangreichste Teil. Bisher enthält der Index die Referenz, Datum, Autor, Titel, Text, ...
Mit jedem Posting nimmt der Umfang des Indix-Files um eben die Menge geposteter Daten zu. Zu viel!Eine Datenbank könnte folgendermaßen aufgebaut sein:
Tabelle Files - Spalten Fileindex, Pfad und Datei
Tabelle Struktur - Spalten Titel, Datum, Topic, Autor, Fileindex, ...
wobei einige Spalten durchaus nullable sind.
Tabelle Schlagworte - Spalten Begriff, IndexlisteSelfhtml, die Auslese und das Archiv bleiben erhalten wie sie sind. Was ersetzt würde, wären die Indexdateien. Jede Datei wird mit einem Index versehen und in Tabelle Files eingetragen. Die Tabelle Struktur ist denke ich klar.
In Schlagworte werden alle Begriffe abzüglich allgemeiner Worte, wie 'der', 'die', 'das', 'dem', 'und', 'aber' usw. eingetragen - inklusive Varianten. Jedoch jeder Begriff nur einmal.
In der Spalte Indexliste werden alle Fileindices eingetragen, in denen der Begriff auftaucht. Wer mit Datenbanken vertrut ist, weiß, worauf ich hinauswill. Nicht nur, daß die Indices deutlich kleiner würden, die Struktur läßt auch eine beliebige Tiefe der Referenzierung zu. Thread, Posting, Thema, Unterthema, Anker ...
einziges Manko: eine Volltextsuche nach Phrasen ist nicht mehr möglich. Doch kann man die Features auch zu weit treiben. Immerhin kann man nach allen Wörtern gleichzeitig suchen. Aus diesem Grund werden auch die Titel nicht in die Tabelle Schlagworte eingefügt, sondern in die Tabelle Struktur. An eine Wortkombination im Titel erinnert man sich viel leichter.Die Datenbank könnte jederzeit aus den bestehenden Files neu aufgebaut werden oder eben nur um weitere Forumsbeiträge erweitert werden.
Die Suche kann alternativ nach Titel, Thema, Autor usw. oder/und als Volltextsuche erfolgen. Habe ich etwas vergessen ?
Um das aufzubauen, brauchen wir bei den hier vorhandenen Kenntnissen doch sicher keinen kostenpflichtigen Support ... ?
Viele Grüße
Kess-
Hallo Kess!
Bei dem Umfang kommt man an einer Datenbank gar nicht vorbei.
Genau ins Schwarze getroffen! Nur beim Thema Volltextsuche bin ich mir nicht ganz schluessig. Was soll da indiziert werden? Wenn die Fuellworte und allgem Floskeln entfernt werden, sind eh nur Stichpunkte da. Und Floskeln in eine Datenbank zu packen finde ich auch Muell, da dann die Datenbank zu groß wird. Aber vielleicht kann man ja einen Kompromiss schliessen. Schlagworte, Themen etc. in Datenbank, Volltext ueber die Originaldateien??
Leider habe ich keinerlei Kenntnis ueber die im Forum verwendeten Scripts aber fuer den Entwurf und die Erstellung der Datenbank waere ich zu begeistern.
Gruß
Thomas-
Hi Kess und Thomas!
Genau ins Schwarze getroffen! Nur beim Thema Volltextsuche bin ich mir nicht ganz schluessig. Was soll da indiziert werden? Wenn die Fuellworte und allgem Floskeln entfernt werden, sind eh nur Stichpunkte da. Und Floskeln in eine Datenbank zu packen finde ich auch Muell, da dann die Datenbank zu groß wird. Aber vielleicht kann man ja einen Kompromiss schliessen. Schlagworte, Themen etc. in Datenbank, Volltext ueber die Originaldateien??
Schließe mich deiner meinung voll an, nur möchte ich nur anmerken das die DB-Lösung beim indexieren der einzelnen Beiträge viel länger braucht als die bisherige lösung - dem gegenüber steht aber die benutzerfreundlichkeit und damit würde ich diese lösung preferenzieren
CU Roman
-
Hallo Thomas und Roman.
Nur beim Thema Volltextsuche bin ich mir nicht ganz schluessig. Was soll da indiziert werden? Wenn die Fuellworte und allgem Floskeln entfernt werden, sind eh nur Stichpunkte da.
Ok, am besten ein Bespiel:
Suche mir alle Threads und Artikel zu den Themen Javascript, in denen von Resolution und Netsape und resize die Rede ist.Das würde folgende Abfrage bedeuten:
Select a.datei
from files a, Struktur b
where a.dileindex = b.fileindex
and b.thema = 'Javascript'
and exists (
Select 1 from schlagworte c
where c.begriff Like 'Resolution%'
and pos(c.indexliste,b.fileindex)> 0 )
and exists (
Select 1 from schlagworte c
where c.begriff Like 'resize%'
and pos(c.indexliste,b.fileindex)> 0 )
and exists (
Select 1 from schlagworte c
where c.begriff Like 'Netscape%'
and pos(c.indexliste,b.fileindex)> 0 )
Ist das Beispiel selbstredend ?Schließe mich deiner meinung voll an, nur möchte ich nur anmerken das die DB-Lösung beim indexieren der einzelnen Beiträge viel länger braucht als die bisherige lösung - dem gegenüber steht aber die benutzerfreundlichkeit und damit würde ich diese lösung preferenzieren
Jein, sehr wahrscheinlich würden sie etwas länger brauchen, aber nicht zwangsläufig. Wenn man jeden einzelnben Beitrag beim Archivieren einzeln indiziert, dauert das sicherlich. Schneller würde es gehen, wenn man ausschließlich aus den hinzuzufügenden Dateien einen eigenen kleinen Index aufbaut und diesen dann anschließend in den existierenden Index einfügt.
Viele Grüße
Kess
-
-
-
Hallo Kess
Tabelle Files - Spalten Fileindex, Pfad und Datei
Tabelle Struktur - Spalten Titel, Datum, Topic, Autor, Fileindex, ...
wobei einige Spalten durchaus nullable sind.
Tabelle Schlagworte - Spalten Begriff, IndexlisteDas relationale Konzept dahinter finde ich auf jeden Fall sinnvoll. Bei wachsendem Datenbestand ist man damit einfach flexibler als mit den bisherigen, "flachen" Datensaetzen. Trotz der genannten Einschraenkung bezueglich Phrasensuche.
Die Frage ist halt nur, ob man dafuer ein Datenbank-Produkt braucht, oder ob es nicht moeglich ist, das auch mit reinem Perl zu bauen - immerhin gibt es auch DB-Module fuer Perl. Denn was auf jeden Fall entfaellt, ist das haeufige Editieren und Aendern des Datenbestands - ueblicherweise ein wichtiges Argument fuer den Einsatz eines Datenbanksystems. Das einzige, was die Loesung erreichen muss, ist ein moeglichst optimiertes Laufzeitverhalten beim Durchsuchen, auch bei stark weiter wachsenden Datenbestaenden.
Was dann noch kommen koennte, sind speziell aufgeruestete Rechner, die extrem viel RAM spendiert bekommen und so konfiguriert werden, dass moeglichst grosse Teile des Datenbestands im Arbeitsspeicher gelagert werden koennen, um schnell durchsuchbar zu sein. Aber bis dahin duerfen noch ein paar Jahre Forum ins Land gehen ... ;-)
viele *..*-Gruesse
Stefan Muenz-
Die Frage ist halt nur, ob man dafuer ein Datenbank-Produkt braucht, oder ob es nicht moeglich ist, das auch mit reinem Perl zu bauen - immerhin gibt es auch DB-Module fuer Perl. Denn was auf jeden Fall entfaellt, ist das haeufige Editieren und Aendern des Datenbestands - ueblicherweise ein wichtiges Argument fuer den Einsatz eines Datenbanksystems.
Weit gefehlt! Wenn Du mit einem Datenbanksystem konkurrieren willst, dann ist der Knackpunkt der baumartige Aufbau des Indexes. Und macht Du mal eine inkrementelle Neuaufnahme von Archiveinträgen, ohne in diesem Baum ständig Einfügen zu müssen!
Und wenn er anfängt, durch die ständigen Einfügungen an immer wieder derselben Stelle zu degenerieren, wer balanciert ihn dann wieder, damit die schöne log-Eigenschaft beim Suchen nicht verloren geht? *Das* kann eine richtige Datenbank halt prima, ohne daß der Anwender sich darüber den Kopf zerbrechen muß (B*-Bäume hieß das Thema damals in der Vorlesung). Einmal CREATE INDEX und den Rest macht dann die RDBMS-Engine - einem INSERT INTO TABLE sieht man in keinster Weise an, was datenbankintern noch alles für Seiteneffekte ausgelöst werden.
Für den Anwendungsprogrammierer ist das eine (erfreuliche) black box (solange der Optimierer nachher bei den Queries nicht falsch rät).Das einzige, was die Loesung erreichen muss, ist ein moeglichst optimiertes Laufzeitverhalten beim Durchsuchen, auch bei stark weiter wachsenden Datenbestaenden.
Und genau das ist es, weshalb man Bäume verwendet: Durch fortgesetzten Vergleich und Halbierung des restlichen Search Space bekommt man die Position eines Treffers (oder auch die Lokation eines Teilbaums voller Treffer!) in logarithmischer statt linearer Zeit aus dem Datenbestand heraus.
Das Problem der Perl-Lösung für eine solche Suchfunktion wäre es, entweder die gesamte Baum-Wartung selbst vorzunehmen oder den Index nicht inkrementell, sondern in einem Schlag anzulegen.
(Was ich in meiner Datenbank übrigens bevorzuge, denn *dann* ist er erst mal optimal balanciert! Eine gepflegte Datenbank mit der Wachstumsgeschwindigkeit Deines Forums will alle paar Monate mal reorganisiert werden - also dann ein Wochenende Pause für den BuildIndex-Lauf? ;-)Auch die Speicheroptimierung bei der Suche in diesem Baum (wenn man nicht annehmen kann, daß er komplett in den Hauptspeicher paßt - und wenn man das tut, *dann* ist es wieder so langsam wie das bisherige Skript!) möchte ich in Perl ungern selbst programmieren. Da müßten diese Module schon einiges taugen, damit sie weder zuviele noch zu wenige Plattenzugriffe machen.
Das ist ein weiterer Vorteil einer wirklich guten Datenbank: Firmen wie IBM oder Oracle haben über solche Probleme halt schon etwa 20 Jahre lang nachgedacht und Lösungen geschaffen, die selbst unter wesentlich spartanischeren Voraussetzungen als unseren zu hervorragenden Ergebnissen führen.Was eine Datenbank dem bisherigen CGI-Skript noch voraus hat, ist, daß sie aus daemons besteht. Bisher kratzt sfasuch.pl die ganzen 40 MB von der Platte, findet eine Handvoll Treffer - und vergißt dann alles wieder. Der nächste Suchende darf erst mal wieder alles einlesen.
Richtig gut wird es erst, wenn man einen Suchmaschinendaemon hat, der dann wirklich den Index komplett (oder wenigstens soviel wie möglich davon, unter Anwendung von LRU etc.) im Arbeitsspeicher hält und mit dem die einzelnen Suchvorgänge eine Client-Server-Kommunikation aufbauen (beispielsweise über Pipes oder Sockets). Die ganzen Standardprobleme wie Synchronisation etc. führen dazu, daß die Lösung zwar schnell in der Ausführung, aber nicht gerade kurz in der Codemenge werden dürfte. Eine richtige Datenbank kann nicht nur dies, sondern sie schafft es vermutlich sogar, daß mehrere Suchprozesse quasi-gleichzeitig auf die Ressourcen des daemons zugreifen können ...Ich denke, ich habe damit einen Eindruck geschaffen, was eine Datenbank (und ich meine damit eine *richtige* Datenbank, *nicht* M$ Access!) für eine Suchmaschine zu leisten imstande wäre.
Aus betriebswirtschaftlicher Sicht erscheint mir der Versuch, mit einer Perl-Lösung dagegen antreten zu wollen, unvernünftig. Die Frage ist höchstens, ob die bestehende Lösung nicht einfach reicht, wenn auch die Rechner schneller werden.-
Hallo Michael,
*APPLAUS, APPLAUS* Wirklich, das ist nicht nur treffend, sondern auch ganz locker und für jeden - hoffentlich - verständlich erklärt.
Die Frage ist höchstens, ob die bestehende Lösung nicht einfach reicht, wenn auch die Rechner schneller werden.
Stopp ! an der Stelle kann ich nicht mehr zustimmen.
Wenn es auschließlich um das Archiv ginge, könnte man es vielleicht noch einige Monate aushalten. Obwohl die Antwortzeiten inzwischen wirklich Geduld erfordern.
Damit meine ich die Antwortzeiten der Suche. Zum Schwanzabschneider müßte Stefan sich äußern.
Jetzt beziehe die geplanten Zugänge auch noch in die Suche ein und rechne die dann zu erwartenden Zeiten aus. Das ist für meine Begriffe nicht mehr zumutbar.Viele Grüße
Kess-
*APPLAUS, APPLAUS* Wirklich, das ist nicht nur treffend, sondern auch ganz locker und für jeden - hoffentlich - verständlich erklärt.
Hmpf, irgendwann wollte ich doch mal einen Artikel über die "Suchmaschine" schreiben ...
Jetzt beziehe die geplanten Zugänge auch noch in die Suche ein und rechne die dann zu erwartenden Zeiten aus. Das ist für meine Begriffe nicht mehr zumutbar.
-
-
Hallo Michael
Ich denke, ich habe damit einen Eindruck geschaffen, was eine Datenbank (und ich meine damit eine *richtige* Datenbank, *nicht* M$ Access!) für eine Suchmaschine zu leisten imstande wäre.
Uff, ja, das ist ja ein richtig ausgewachsener Datenbank-Einfuehrungskurs geworden, dieser Thread ;-)
Danke!Aus betriebswirtschaftlicher Sicht erscheint mir der Versuch, mit einer Perl-Lösung dagegen antreten zu wollen, unvernünftig. Die Frage ist höchstens, ob die bestehende Lösung nicht einfach reicht, wenn auch die Rechner schneller werden.
Was mir auch noch sehr am Herzen liegt, ist, dass das Forumsarchiv nicht nur in eine Datenbank wandert, sondern dass nach wie vor auch statische HTML-Dateien als Archivdateien erzeugt werden, so wie jetzt. Denn diese werden auch von Robots grosser Internet-Suchdienste indexiert, und daran ist mir durchaus gelegen.
Ferner duerfen wir auch nicht die Schnittstelle zwischen Forum und Archiv vergessen - den Schwanzabschneider. Egal wie die Loesung am Ende aussehen wird - der Schwanzabschneider muss die Daten, die er abschneidet, ins Archiv reinkriegen und ebenso in die Datenbasis fuer die Suche.Ich denke, es wuerde sich fuer alles eine Loesung finden. Ich moechte hier nur noch einen technisch/organisatorischen Aspekt anfuehren:
teamone.de gehoert nicht mir, sondern der Agenturleiterin von TeamOne. Die ist nicht bereit, wegen unserer Spaesschen hier mehr Geld im Monat fuer die Unterhaltung der Domain zu zahlen (wenn man den Vertrag aendern wollte und z.B. eigenes Server-Hosting oder Erweiterungen wie Datenbankzugriff usw. wollte). Den Provider wollen wir derzeit auch nicht wechseln - wer sich jetzt also mit "Angeboten" an diesen Thread haengen will, bitte nicht!
Das Archiv und seine Loesung zur Durchsuchbarkeit sollten im Falle einer professionellen Datenbankloesung auf einen andern Server abwandern, den finanzieren will wer mag <g>, und der Schwanzabschneider wird ebenfalls von dort aus gestartet, kann sich via LWP-Modul und HTTP-get hier die aktuellen Forumsdaten holen, und der Rest passiert dort.viele Gruesse
Stefan Muenz-
Was mir auch noch sehr am Herzen liegt, ist, dass das Forumsarchiv nicht nur in eine Datenbank wandert, sondern dass nach wie vor auch statische HTML-Dateien als Archivdateien erzeugt werden, so wie jetzt. Denn diese werden auch von Robots grosser Internet-Suchdienste indexiert, und daran ist mir durchaus gelegen.
Im bisherigen Index stehen relative URLs. Daran würde sich nichts ändern, wenn er in einer Datenbank aufbewahrt würde. Das Trefferdokument würde weiterhin Links auf Archivdateien enthalten.
Ferner duerfen wir auch nicht die Schnittstelle zwischen Forum und Archiv vergessen - den Schwanzabschneider. Egal wie die Loesung am Ende aussehen wird - der Schwanzabschneider muss die Daten, die er abschneidet, ins Archiv reinkriegen und ebenso in die Datenbasis fuer die Suche.
Was bisher das Anhängen einer Zeile am Ende der Indexdatei war, das wird dann der Aufruf einer Funktion "forumDBinterface::insert (...)".
(Gekapselte Funktionalitäten und saubere APIs sind unbezahlbar.)und der Schwanzabschneider wird ebenfalls von dort aus gestartet, kann sich via LWP-Modul und HTTP-get hier die aktuellen Forumsdaten holen, und der Rest passiert dort.
Und wie läuft das dann mit der Synchronisation, wenn gerade jemand postet?
Also wenn schon weiterhin die Bahnschranke heruntergelassen werden muß, damit der Schwanzabschneider auf einer konsistenten Basis arbeiten kann, dann kannst Du auch
1. das Forum-Verzeichnis mit tar und compress zusammenpacken,
2. es via FTP zum dicken Server hinüberschicken,
3. dort wird dann archiviert und
4. zurück (FTP) kommt das Archiv mit dem neuen reduzierten Forums-Zustand,
5. auspacken und die Schranke geht wieder hoch.
Abgesehen davon, daß man das irgendwie synchronisieren muß, werden das ganz kurze, knackige Skripte. (Egal, ob Perl oder Shell.) Du kannst die beiden FTPs natürlich auch manuell machen ...-
Hallo Michael
Also wenn schon weiterhin die Bahnschranke heruntergelassen werden muß, damit der Schwanzabschneider auf einer konsistenten Basis arbeiten kann, dann kannst Du auch...
Also gut, dann programmierst du mal die Bahnschranke und den unbezahlbaren DB_Insert in den Schwanzabschneider rein (was der auf seine alten Tage alles noch erleben darf <g>), und der Rest wandert auf einen flotten Server mit 10 Gigabyte RAM und eigener RAM-Partition fuer fuer eine richtig _kesse_ Archiv-Datenbank, den irgendein noch unbekannter Goenner uns finanziert - ;-)
viele Gruesse
Stefan Muenz-
Also gut, dann programmierst du mal die Bahnschranke
Ich denke, die gibt es bereits?
Irgendwie machst Du doch das Forum mal kurz zu, bevor der Schwanzabschneider über seinen Inhalt herfallen darf, oder? Mehr braucht's nicht.
und den unbezahlbaren DB_Insert
... welchen zu entwerfen erst dann Sinn macht, wenn alles andere feststeht (Datenbanksystem, API für den Zugriff, Datenmodell usw.) ...
in den Schwanzabschneider rein (was der auf seine alten Tage alles noch erleben darf <g>), und der Rest wandert auf einen flotten Server mit 10 Gigabyte RAM und eigener RAM-Partition
Aber nein!
Der Punkt ist doch, daß eine "richtige" Datenbank eben genau *nicht* solch irrsinnige Ressourcen braucht, weil in ihr intelligente Algorithmen zur "Mängelverwaltung" implementiert sind.
Wie anders könnte ich denn meine Datenbank (jeden Morgen ein Produktionslauf mit 15000 INSERTs in eine 1-GB-Tabelle mit 20 Mio Datensätzen plus zwei Indexbäume innerhalb von 5 Minuten, und das auf einem ca. Pentium 150 mit 64 MB RAM!) heute noch betreiben?fuer fuer eine richtig _kesse_ Archiv-Datenbank, den irgendein noch unbekannter Goenner uns finanziert - ;-)
Eben. Insofern steht das Projekt nicht unter extremem Zeitdruck. ;-)
-
-
-
-
-
-
Ich denke, und das wißt ihr sicher auch selber :-), eine Erweiterung der Suche auf Selfhtml und die Forumsauslese würde riesige Indexdateien bedeuten.
Hoppla - wie kommst Du denn auf diese absurde Idee? Ich merke, Du hast überhaupt keine Vorstellung, davon, wie ungeheuer riesig das Archiv inzwischen ist! (Ich schon - ich habe die Indexdatei in TextPad geladen und Laufzeitmessungen für die Suche damit gemacht ... letzteres dann mit einem auf 5% reduzierten Index, mein UNIX-Server ist nicht mehr ganz taufrisch.)
Man nehme also den Dateimanager und lasse sich die Platzbelegung der folgenden Verzeichnisse anzeigen:
Auslese : 0,55 MB
SelfHTML7 : 5,10 MB
1998_3 : 5,08 MB
1998_4 : 8,88 MB
1999_1 : 13,36 MB
Und die beiden folgenden Quartale sind laut Download-Seite (komprimiert) um Faktor 1.5 bzw. 2 größer als 1999_1! (*Den* Download tue ich mir bestimmt nicht mehr an.)So viel zur Untermauerung von Stefans ständiger Aussage, daß im Forum überwiegend Luft gepostet wird: Sie ist so was von wahr! Ich denke nicht, daß das gesamte Archiv den intellektuellen Wert von SelfHTML auch nur erreichen kann - und das bei einem erschreckendem Vielfachen an reinem Volumen!
Andererseits habe ich nicht die geringste Angst, daß die Aufnahme von SelfHTML und Auslese den Index in signifikanter Weise aufblähen könnte. Nein, nein - *das* können nur wir selbst ... :-(
-
Hoppla - wie kommst Du denn auf diese absurde Idee? Ich merke, Du hast überhaupt keine Vorstellung, davon, wie ungeheuer riesig das Archiv inzwischen ist!
Aktueller Stand zur Zeit dieses Postings: 39.163.715 Bytes *fg*
Man nehme also den Dateimanager und lasse sich die Platzbelegung der folgenden Verzeichnisse anzeigen:
»» Auslese : 0,55 MB
»» SelfHTML7 : 5,10 MB1998_3 : 5,08 MB
1998_4 : 8,88 MB
1999_1 : 13,36 MBOkok. Soweit hast du wohl recht. Aber im Gegensatz zum Archiv, wo viel Platz durch eine Filter-Liste eingespart
werden könnte, beinhalten Selfhtml und Auslese wirklich geballte Ladung Information. Aber dennoch wird das Forumsarchiv den Vogel abschießen. :-)Viele Grüße
Kess-
Aber im Gegensatz zum Archiv, wo viel Platz durch eine Filter-Liste eingespart
werden könnteDas interessiert mich: Wie filterst Du nach Semantik? Wenn wir *das* könnten, würde ich es sofort in den Schwanzabschneider einbauen!
Denn syntaktisch sehe ich kaum mehr Redundanz in der Indexdatei. HTML-Tags stehen schon mal keine mehr drin (der Schwanzabschneider ist gut!), hier würden alle genannten Dokumentklassen m. E. ähnlich gut gefiltert werden.
-
Das interessiert mich: Wie filterst Du nach Semantik? Wenn wir *das* könnten, würde ich es sofort in den Schwanzabschneider einbauen!
Das ist ein Mißverständnis. Die Antwort gibts du dir jedoch teilweise schon selbst.
<cite>
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. ....
(<OT>: Deshalb: Vorsicht bei der Verwendung von LIKE und % in SQL - für die Performance kann das Zehnerpotenzen kosten.</OT>)
</cite>Mit dem *deutlich größer* hast du allerdings völlig recht. Mit der Verwendung von LIKE überigens auch. '%xxyz' z.B. müßte verboten sein. *g*
Bei einem Treffer liegen sofort alle zugehörigen Quellen vor. Ein kompletter Tablescan ist nicht nötig. Ausgehend von der Baumstruktur des Index erwarte ich hier eben den Performancegewinn.
Viele Grüße
Kess-
Bei einem Treffer liegen sofort alle zugehörigen Quellen vor. Ein kompletter Tablescan ist nicht nötig. Ausgehend von der Baumstruktur des Index erwarte ich hier eben den Performancegewinn.
Ich auch - aber nur dann, wenn es gelingt, zu verhindern, daß er dafür vollständig eingelesen werden muß. Denn das ist das Langsame an der bisherigen Lösung, nicht das Vergleichen.
Und um das zu schaffen, müßte man eine Cacheing-Strategie programmieren (entweder den Index aufteilen in einen Baum von Dateien inklusive vollständig neuem Schwanzabschneider oder die erwähnte Client-Server-Lösung), und dazu habe ich irgendwie nur begrenzt viel Lust - das liegt einfach ein paar Abstraktionsebenen unterhalb des eigentlichen Themas.
Außerdem: Hier den etablierten Datenbankherstellern Konkurrenz machen zu wollen (sowohl in Sachen Performance als auch Stabilität bei parallelen Zugriffen), fühle ich mich auch nicht annähernd fit genug, und das Ergebnis würde den Aufwand nicht rechtfertigen.-
Und um das zu schaffen, müßte man eine Cacheing-Strategie programmieren (entweder den Index aufteilen in einen Baum von Dateien inklusive vollständig neuem Schwanzabschneider oder die erwähnte Client-Server-Lösung), und dazu habe ich irgendwie nur begrenzt viel Lust - das liegt einfach ein paar Abstraktionsebenen unterhalb des eigentlichen Themas.
Außerdem: Hier den etablierten Datenbankherstellern Konkurrenz machen zu wollen (sowohl in Sachen Performance als auch Stabilität bei parallelen Zugriffen), fühle ich mich auch nicht annähernd fit genug, und das Ergebnis würde den Aufwand nicht rechtfertigen.Um Himmels Willen. Doch das bloß nicht. Entweder können wir auf eine ausgereifte Technologie zurückgreifen, oder wir lassen es besser so, wie es ist. Mir war nie in den Sinn gekommen, du wolltest vielleicht eine eigene DB-Engine schreiben oder nachbilden.
-
Und um das zu schaffen, müßte man eine Cacheing-Strategie programmieren (entweder den Index aufteilen in einen Baum von Dateien inklusive vollständig neuem Schwanzabschneider oder die erwähnte Client-Server-Lösung) ...
Um Himmels Willen. Doch das bloß nicht. Entweder können wir auf eine ausgereifte Technologie zurückgreifen, oder wir lassen es besser so, wie es ist. Mir war nie in den Sinn gekommen, du wolltest vielleicht eine eigene DB-Engine schreiben oder nachbilden.
Stefan fragte, wie weit man mit Perl-Skripts kommen könnte; meine Antwort darauf lautet: Je mehr Aufwand man zu treiben gewillt ist, umso weiter. ;-)
Ich denke auch, daß eine solche Lösung zwar vielleicht implementierbar, aber nicht mehr wartbar wäre.
-
-
-
-
-
-
-
Fangen wir mal mit der Volltextsuche an. Der umfangreichste Teil. Bisher enthält der Index die Referenz, Datum, Autor, Titel, Text, ...
Mit jedem Posting nimmt der Umfang des Indix-Files um eben die Menge geposteter Daten zu. Zu viel!Hm. Hier geht es los.
Du kritisierst die bestehende Lösung, ohne die Aufgabenstellung zu formulieren. Und die lautet bisher einfach "Volltextsuche", nach beliebigen Phrasen. Deshalb wird ja auch der Volltext geindext.
Also schlage ich vor, daß wir die Diskussion damit beginnen, ob wir dies weiterhin wollen oder bereit sind, eine reduzierte Suchfunktion um der lieben Performance Willen in Kauf zu nehmen.Eine Forums-Suche nach einem Suchbegriff über den Archiv-Volltext läuft derzeit ca. 15 Sekunden auf dem Server (das wird im Ergebnis der Suche angezeigt, um regelmäßigen Suchern anzuzeigen, ob ihnen die Wartezeit nur so lang vorkam oder ob es wirklich schlimmer geworden ist). Komplexere Suchbegriffe werden *nicht* viel schlimmer, weil der AND-Operator dazu führt, daß nach dem ersten Suchdurchgang abgebrochen werden kann, wenn kein Treffer erzielt wurde.
(<OT>Merke also: Der erste angegebene Suchbegriff sollte also der am seltensten vorkommende sein ... hm, diese Anordnung könnte man im Skript vielleicht auch mal invertieren, denn es ist nicht sooo intuitiv für den Anwender ... es macht aber in keinem Fall wirklich viel aus, case-insensitive Suche ist *wesentlich* schlimmer!</OT>)
Über die Leistungsfähigkeit des Servers kann ich mich nicht äußern, aber angesichts der dabei zu durchsuchenden ca. 40 MB (wenn man im Posting-Inhalt sucht - kann er sooo schlecht wohl gar nicht sein. Ich weiß nicht, wie lange das Archiv noch auf der bestehenden Hardware laufen wird; auf die Dauer bleibt die Frage, ob das Posting-Volumen wirklich signifikant schneller zunimmt als die verfügbare Serverleistung. Das ist wahrscheinlich eine der ersten Fragen, die wir klären sollten - und *das* hat mit Geld zu tun.
Selfhtml, die Auslese und das Archiv bleiben erhalten wie sie sind. Was ersetzt würde, wären die Indexdateien. Jede Datei wird mit einem Index versehen und in Tabelle Files eingetragen. Die Tabelle Struktur ist denke ich klar.
Du bist mir zwei Stufen zu tief in der Technik drin. Diese Diskussion möchte ich erst führen, wenn ich weiß, wonach gesucht wird und was gefunden werden soll. Erst die Spezifikation, dann die Datentypen, zuletzt die Algorithmen.
In Schlagworte werden alle Begriffe abzüglich allgemeiner Worte, wie 'der', 'die', 'das', 'dem', 'und', 'aber' usw. eingetragen - inklusive Varianten. Jedoch jeder Begriff nur einmal.
Es gibt eine Aussage von Stefan zu diesem Thema: Auch der bisherige Indexer konnte das schon mal, und die Ersparnis war nicht signifikant.
In der Spalte Indexliste werden alle Fileindices eingetragen, in denen der Begriff auftaucht. Wer mit Datenbanken vertrut ist, weiß, worauf ich hinauswill. Nicht nur, daß die Indices deutlich kleiner würden, die Struktur läßt auch eine beliebige Tiefe der Referenzierung zu. Thread, Posting, Thema, Unterthema, Anker ...
Eben, das ist das Problem: Du implementierst damit eine Suchmethode, für die überhaupt keine Eingabedaten vorhanden sind.
Das Forum ist in Postings strukturiert, und auf Postings-Ebene funktioniert die Suche schon heute.
Eine Abbildung des SelfHTML-Formats auf das semantische Konzept des Postings hat Stefan geliefert. An dieser Stelle gewinnen wir also nichts im Ergebnis.Auf den Hauptvorteil bist Du allerdings gar nicht eingegangen: Der Index wird nicht nur kleiner, sondern vor allem ein Baum! Das bedeutet, daß eine gute Datenbank darin mit logarithmischem Aufwand suchen kann, während das bisherige Such-Skript linearen Aufwand relativ zur Indexgröße leisten muß. *Dadurch* würde die Suche selbst bei unverändertem Indexvolumen rasant schneller werden - wenn man den bei einer Datenbank nun mal vorhandenen Overhead vernachlässigt.
Das bisherige Suchskript macht nämlich einen primitiven full table scan und keine impliziten UNION- bzw. INTERSECT-Operationen, welche die Datenbank bei der Auflösung komplexer Ausdrücke intern möglicherweise macht und dabei sämtliche Zwischenergebnismengen im Speicher halten will. Da ist dann nix mehr mit rechtzeitig abbrechen ... und bezüglich des erforderlichen Arbeitsspeichers ist "sfasuch.pl" das gutmütigste Skript des Universums. Datenbanken sind speicherhungrig, weil sie die knappe Ressource Zeit oftmals durch die andere knappe Ressource Arbeitsspeicher zu kompensieren versuchen.einziges Manko: eine Volltextsuche nach Phrasen ist nicht mehr möglich. Doch kann man die Features auch zu weit treiben. Immerhin kann man nach allen Wörtern gleichzeitig suchen.
Und was macht wohl der AND-Operator im aktuellen Such-Skript, bitte sehr? Wieso habe ich den eingebaut, wenn Du das nicht mal bemerkt hast? Gnlpfts ...
Die Datenbank könnte jederzeit aus den bestehenden Files neu aufgebaut werden oder eben nur um weitere Forumsbeiträge erweitert werden.
Mit den Forumdateien ist es genauso. Ein Vollindexlauf wäre lästig, aber machbar.
Die Suche kann alternativ nach Titel, Thema, Autor usw. oder/und als Volltextsuche erfolgen.
Nichts davon wäre eine Verbesserung gegenüber der aktuellen Situation - im Gegenteil: Das aktuelle Suchskript kann viel mehr! (Reguläre Ausdrücke, intelligente Umlaute, ...)
Irgendwie sehe ich im Moment keinen zwingenden Grund für den Datenbankansatz ... nicht, daß er mir keinen Spaß machen würde, weit gefehlt ...
-
Eine Forums-Suche nach einem Suchbegriff über den Archiv-Volltext läuft derzeit ca. 15 Sekunden auf dem Server.
Nachtrag: Eine Suche nach demselben Begriff nur immerhalb des Verfassers dauerte trotz erheblich kleinerer zu vergleichender Textmenge ... 14,5 Sekunden! (Obwohl es fast dieselbe Treffermenge produzierte, jeweils ca. 1300 Zeilen und ein HTML-Dokument knapp 300 kb.)
Der Flaschenhals ist also meiner Meinung nach gar nicht das Suchen in dem riesigen Index, sondern es ist das Lesen der 40 MB von der Festplatte.
Perl ist bei seinen Vergleichen für einfache Suchbegriffe derartig rasend schnell, daß dieser Teil der Berechnung gar nicht ins Gewicht fällt - solange Begriffe ohne Varianten gesucht werden.
(Bei komplexen regulären Ausdrücken und bei case-insensitiver Suche, wo etwa doppelt so viele Vergleiche vorgenommen werden müssen und die lineare Suche beim Scheitern eines "match" weniger gut vorwärts positionieren kann, sieht das etwas anders aus.) -
Hallo Michael.
Du kritisierst die bestehende Lösung, ohne die Aufgabenstellung zu formulieren. Und die lautet bisher einfach "Volltextsuche", nach beliebigen Phrasen. Deshalb wird ja auch der Volltext geindext.
Bitte beruhige Dich. Es lag mir fern, das bestehende - und super laufende - Script oder Dich zu kritisieren. So möchte ich diese Diskussion nicht verstandenen haben.
Jede Software unterliegt einem Lebenszyklus. Und da ohnehin über das Thema diskutiert wird, kann man auch gleich darüber nachdenken, ob das Script auch künftig den Anforderungen genügt. Es sollte ein Vorschlag sein. Mehr nicht.Bei der Menge der Daten aus Selfhtml habe ich mich verschätzt. Aber bei der Menge der künftig zu erwartenden Forumsbeiträge denke ich nicht, daß sie zurückgehen werden. So sehe ich schon, daß bald Handlungsbedarf entstehen wird. Mit bald meine ich nicht heute oder morgen oder nächste Woche aber doch einen absehbaren Zeitraum.
Den Volltextindex wollte ich nicht angegriffen wissen. Mein Vorschlag sollte eine Altermative zur Diskussion (!) stellen.
Es gibt eine Aussage von Stefan zu diesem Thema: Auch der bisherige Indexer konnte das schon mal, und die Ersparnis war nicht signifikant.
Jepp. Wobei Stefan von einem Volltextindex ausging und ich von einem Schlagwortindex. Ein kleiner Unterschied :-)
Eben, das ist das Problem: Du implementierst damit eine Suchmethode, für die überhaupt keine Eingabedaten vorhanden sind.
Nein. Ich wollte damit ein Konzept aufzeigen in einer solchen DB beide Strukturen, Doku unbd Forum zu vereinen. die Referenzen zu Selfhtml brauchen z.B. weder Autor noch Datum jeweils mitzuführen.
Eine Abbildung des SelfHTML-Formats auf das semantische Konzept des Postings hat Stefan geliefert. An dieser Stelle gewinnen wir also nichts im Ergebnis.
Verlieren aber auch nichts.
Oder gewinnen wir doch ? *grübel* So fit bin ich jetzt mit der jetzigen Suche nicht. Ist es möglich zu fragen nach Autor Muenz und Titel enthält 'Frame' und Text enthält 'Resolution' ?
ich glaube nicht. Mit einer DB im Hintergrund wäre das kein Problem.Auf den Hauptvorteil bist Du allerdings gar nicht eingegangen: Der Index wird nicht nur kleiner, sondern vor allem ein Baum!
Sorry, wenn ich von einer DB spreche, dann spreche ich von einer rightigen DB, z.B. Oracle. Das habe ich einfach vorausgesetzt. Das ist Teil meiner täglichen Arbeit und damit für mich vielleicht schon allzu selbstverständlich geworden.
Da ist dann nix mehr mit rechtzeitig abbrechen ...
Jein. Je nach DB kann man Row- und Runtimebeschränkungen vorgeben :-)
Und was macht wohl der AND-Operator im aktuellen Such-Skript, bitte sehr? Wieso habe ich den eingebaut, wenn Du das nicht mal bemerkt hast? Gnlpfts ...
Calm down. ;-)
Ich sprach von echten Phrasen. Also 'Vorschlag zum Forum' und nicht 'Vorschlag' AND 'zum' AND 'Forum'. Die Jetzige Suche beherrscht so etwas, mein Vorschlag würde solche Phrasen nicht beherrschen.Mit den Forumdateien ist es genauso. Ein Vollindexlauf wäre lästig, aber machbar.
Das ist mir klar. Noch einmal. Es geht mir nicht darum, das bestehende Script schlecht zu machen. Ich wolte eine DB-basierte Alternative aufzeigen. Eben weil die Antwortzeiten langsam aber deutlich ansteigen.
Irgendwie sehe ich im Moment keinen zwingenden Grund für den Datenbankansatz ... nicht, daß er mir keinen Spaß machen würde, weit gefehlt ...
Well, endlich sind wir bei der Diskussion. :-)
Das ist letzlich nämlich die Frage: Macht es Sinn oder nicht. Imho ist es momentan vielleicht noch nicht unbedingt zwingend aber es macht Sinn.Viele Grüße
Kess-
Bitte beruhige Dich. Es lag mir fern, das bestehende - und super laufende - Script oder Dich zu kritisieren. So möchte ich diese Diskussion nicht verstandenen haben.
No problem - ich fühlte mich nicht "angegriffen". Ich meinte nur, Du machst den zweiten Schritt vor dem ersten. "Kritik" kann ja auch konstruktiv sein (Deine ist es), aber dennoch das eigentliche Thema verfehlt haben.
Jede Software unterliegt einem Lebenszyklus. Und da ohnehin über das Thema diskutiert wird, kann man auch gleich darüber nachdenken, ob das Script auch künftig den Anforderungen genügt. Es sollte ein Vorschlag sein. Mehr nicht.
Yep. Allerdings hast Du in den unendlichen Weiten des Universums argumentiert, während Stefan und ich in der Kenntnis der vorliegenden Dokumentformate dachten.
So sehe ich schon, daß bald Handlungsbedarf entstehen wird. Mit bald meine ich nicht heute oder morgen oder nächste Woche aber doch einen absehbaren Zeitraum.
Zustimmung - deshalb diskutiere ich ja auch mit. Und seitdem Stefan eine Aufrüstung des Servers (nicht *wegen* dem Archiv, sondern vielleicht einfach wegen anderer Kunden des Providers!) auszuschließen scheint ...
Den Volltextindex wollte ich nicht angegriffen wissen. Mein Vorschlag sollte eine Altermative zur Diskussion (!) stellen.
Aber der erste Schritt wäre gewesen: Was *genau* wollen wir überhaupt erreichen (aus Sicht des Benutzers)? Den hast Du irgendwie wegoptimiert. (cc -O4 ;-)
Es gibt eine Aussage von Stefan zu diesem Thema: Auch der bisherige Indexer konnte das schon mal, und die Ersparnis war nicht signifikant.
Jepp. Wobei Stefan von einem Volltextindex ausging und ich von einem Schlagwortindex. Ein kleiner Unterschied :-)Ganz genau.
Denn woher nehmen wir eine Verschlagwortung eines derartig heterogenen Archivinhaltes? Auf dieser semantischen Ebene möchte ich die Diskussion führen, bevor ich über ein Modell zur Implementierung nachdenke.
Wir haben einfach die Daten nicht, auf denen Du aufsetzen möchtest. (Ich würde auch gerne eine Schlagwortsuche machen!)
Voraussetzung ist, daß Stefan den SelfHTML-Source nicht ändern möchte; es wäre auch eine Schweinearbeit ... und vor allem: Für das Archiv - und darum geht es ja vor allem - macht garantiert niemand nie nicht diese Arbeit. Jedenfalls nicht manuell. Also ... ?Halt, Kutscher: Mir fällt gerade ein, daß SelfHTML in gewisser rudimentärer Weise ja doch verschlagwortet ist, und zwar über das Stichwortverzeichnis. Nur braucht man dafür dann keine Suchmaschine, sondern kann einfach diese Seite laden und darin positionieren ... was ich bisher auch immer getan habe, wenn ich eine Suchstrategie in Deinem Sinne anwenden wollte.
Nein. Ich wollte damit ein Konzept aufzeigen in einer solchen DB beide Strukturen, Doku und Forum zu vereinen. die Referenzen zu Selfhtml brauchen z.B. weder Autor noch Datum jeweils mitzuführen.
Letzteres halte ich für kein Problem. Der Autor kann wie von Stefan vorgeschlagen leer bleiben, ein Datum aus dem Verzeichniseintrag der Datei zu gewinnen ist ein Fünfzeiler oder so.
Für mich ist das bereits dieselbe Struktur - mit kleinen semantischen Sondereffekten, mit denen das Suchverfahren fertig werden wird.Oder gewinnen wir doch ? *grübel* So fit bin ich jetzt mit der jetzigen Suche nicht.
Üben ... ;-))) Oder Fragen stellen, die in ein Handbuch münden könnten.
Ist es möglich zu fragen nach Autor Muenz und Titel enthält 'Frame' und Text enthält 'Resolution' ?
ich glaube nicht. Mit einer DB im Hintergrund wäre das kein Problem.Hervorragende Frage! Die Antwort lautet: Nein, aber ...
Calocybe hat das bereits in der Diskussion zum Entwurf der heutigen Version des Suchskripts vorgeschlagen. Und wenn Du Dir das Format des Suchindexes verinnerlichst, dann wirst Du sofort sehen, daß so etwas zu implementieren gar kein Problem wäre: Die erforderlichen Informationen sind vorhanden.
Es fehlen derzeit lediglich
1. eine Syntax für das Formulareingabefeld ("+autor:Muenz +titel:Frame +text:Resolution" - wäre Dir das so recht? "autor" oder "verfasser"? Schlüsselworte case-sensitiv oder nicht? usw. - *das* ist der Teil der Arbeit, den ich nicht alleine machen kann, denn *Du* mußt es nachher bedienen können und *wollen*),
2. eine minimale Erweiterung im Parser (der legt bisher eine Liste von Suchbegriffen ab und bräuchte dann eine Liste von Paaren aus Suchbegriff und Suchraum) und
3. eine minimale Erweiterung im Vergleicher (der bisher den Suchraum global aus den CGI-Parametern bestimmt und ihn nun aus der Liste nehmen muß).
Wenn Du mich davon überzeugen kannst, daß Du selbst solche Abfragen benutzen würdest (außer Calocybe und ggf. mir selbst hatte es niemand haben wollen, und wir kennen halt die Sources des Forums), baue ich es ein - im Entwurf meiner Datenstrukturen habe ich eine solche Erweiterung prinzipiell bereits berücksichtigt.Es liegt also nicht an der fehlenden Datenbank, sondern an der dadurch noch weiter komplizierten Eingabesyntax für die DAUs - und meiner Unfähigkeit, die schon jetzt vorhandenen Möglichkeiten der Forumssuche didaktisch an die Frau zu bringen. ;-) Denn wer mit der Sucherei schon jetzt nichts findet, der wird auch zukünftige Verbesserungen kaum nutzen können.
Stefan hatte mal eine Statistik der Suchbegriffe gemacht - gibt es dafür ein Skript? Wie hoch ist die Prozentrate der Suchvorgänge, die mehr als einen Suchbegriff innerhalb einer Anfrage verwenden? (Bei mir sind mindestens 2-3 pro Suche - nach nur *einem* Begriff suche ich höchstens mal zu Testzwecken oder um Postings einer bestimmten Sorte zu zählen, nicht aber, um gezielt etwas zu finden.)Da ist dann nix mehr mit rechtzeitig abbrechen ...
Jein. Je nach DB kann man Row- und Runtimebeschränkungen vorgeben :-)Das ist nicht der Punkt, den ich meinte. (<OT>rownum kenne ich, runtime habe ich noch nicht gesehen - das wäre dann aber auch lastabhängig und damit das Ergebnis einer Query ggf. nicht reproduzierbar?!!?</OT>)
Wenn die Datenbank einen JOIN macht und die erste Projektion macht 100 Treffer, die zweite aber 10000, dann berechnet die Engine in vielen Fällen alle 10100 Zwischentreffer und JOINt erst danach (wenn der Optimizer das nicht vorher erkannt hat). Mein Suchskript würde in *diesem* Falle die zweite Projektion nur für die 100 Treffer der ersten durchführen - das *kann* besser sein.
Der Optimizer rät gemäß seiner Fähigkeiten und Informationen - siehe ANALYZE TABLE -, das Suchskript beschränkt sich auf eine einfache Strategie mit geschachtelten Vergleichen und wird im *Schnitt* schlechter liegen, braucht dafür aber keine Infrastruktur.Calm down. ;-)
?!!? ;-)))
Ich sprach von echten Phrasen. Also 'Vorschlag zum Forum' und nicht 'Vorschlag' AND 'zum' AND 'Forum'. Die Jetzige Suche beherrscht so etwas, mein Vorschlag würde solche Phrasen nicht beherrschen.
Das kommt darauf an, wie Deine Schlagworte bestimmt werden sollen.
Gäbe es im SelfHTML-Source Metainformationen zur Schlagwortbeschreibung, dann könnten diese auch Phrasen enthalten. Es müßte sie nur jemand erfassen ...
Meines Wissens ist die Technologie des Automatischen Verstehens von Dokumenten noch nicht annähernd perfekt, auch wenn Firmen wie SER System mit ihrer Knowledge Base schon reichlich Fernsehwerbung dazu machen. (Benutzt einer der werten Leser so etwas bereits? Wie wäre es mit einem kurzen Erfahrungsbericht? Das würde mich interessieren ...)Das ist mir klar. Noch einmal. Es geht mir nicht darum, das bestehende Script schlecht zu machen.
Hatte ich nie so verstanden.
Irgendwie sehe ich im Moment keinen zwingenden Grund für den Datenbankansatz ... nicht, daß er mir keinen Spaß machen würde, weit gefehlt ...
Well, endlich sind wir bei der Diskussion. :-)Waren wir die ganze Zeit - nur mit verschiedenen Weltbildern. ;-)
Das ist letzlich nämlich die Frage: Macht es Sinn oder nicht. Imho ist es momentan vielleicht noch nicht unbedingt zwingend aber es macht Sinn.
Nach Stefans Angaben gibt es halt noch Randbedingungen technischer und finanzieller Art.
Zeige mir den Weg zum Oracle-Server für umsonst, dann können wir Deine eierlegende Wollmilchsau vielleicht zusammen basteln ...
-
-
Hallo,
case-insensitive Suche ist *wesentlich* schlimmer!
Dieser Hinweis ist mir schon einmal aufgefallen. Ich wollte deshalb schon
lange fragen, wieso eigentlich?Oliver
-
case-insensitive Suche ist *wesentlich* schlimmer!
Dieser Hinweis ist mir schon einmal aufgefallen. Ich wollte deshalb schon
lange fragen, wieso eigentlich?Wenn Du "HTML" case-insensitiv suchst, dann könnte die regular expression engine von Perl das ziemlich stupide machen (ich weiß *nicht*, wie sie es genau macht):
Suche zunächst einmal die Position eines "H", und vergleiche, ob das nächste Zeichen ein "T" ist, das übernächste ein "M", ... beim ersten Unterschied wird abgebrochen und das nächste "H" gesucht usw.
Falls bekannt ist, daß der String kein Zeichen doppelt enthält, kann die Suche sogar an der aktuellen Stelle fortgesetzt werden - würdest Du dagegen "HAHa" in "HAHAHa suchen, müßtest Du nach dem Unterschied an Position 4 das nächste H als Startzeichen wieder ab Position 2 zu suchen beginnen, um den Treffer an Position 3-6 zu finden.Suchst Du aber case-insensitiv, dann fallen die Operationen an allen Positionen doppelt aus. Du suchst also ein H" *oder* ein "h", was intern eben zwei Vergleiche sind; dasselbe für jedes weitere Zeichen.
Und der oben beschriebene lookahead muß jetzt "H" und "h" als gleiche Zeichen behandeln, was die Chance erhöht, daß er nicht angewendet werden darf und dadurch Zeichen im zu durchsuchenden Text mehrfach verglichen werden müssen ...-
Hallo Michael,
Suchst Du aber case-insensitiv, dann fallen die Operationen an allen Positionen doppelt aus. Du suchst also ein H" *oder* ein "h", was intern eben zwei
kleine Anmerkung am Rande: case-sensitiv meint 'unter Beachtung von großen und kleinen Buchstaben'. Was du meinst ist 'not case-sensitive'.
Viele
-
Suchst Du aber case-insensitiv, dann fallen die Operationen an allen Positionen doppelt aus. Du suchst also ein H" *oder* ein "h", was intern eben zwei Vergleiche sind; dasselbe für jedes weitere Zeichen.
Und der oben beschriebene lookahead muß jetzt "H" und "h" als gleiche Zeichen behandeln, was die Chance erhöht, daß er nicht angewendet werden darf und dadurch Zeichen im zu durchsuchenden Text mehrfach verglichen werden müssen ...Du realisierst die Unterscheidung also mit dem Schalter "/i".
Wenn die Perl-Suchroutine aber so arbeitet, wie Du beschreibst, dann ist das doch Wahnsinn, es so zu machen.
Wieso konvertierst Du nicht den Suchbegriff als erstes in Kleinbuchstaben und konvertierst dann die jeweils zu vergleichenden Zeilen ebenfalls in Kleinbuchstaben. Satt dem exponentialen Arbeitsaufwand, den Du beschreibst, ist es nur ein einfacher zusätzlicher Arbeitsschritt pro zu durchsuchender Zeile (und außerdem dürfte die Umsetzung in Kleinbuchstaben - oder auch Großbuchstaben - sowieso ein zügigerer Vorgang sein als die Prüfung regulärer Ausdrücke).Gruß,
Oliver
-
Du realisierst die Unterscheidung also mit dem Schalter "/i".
Stefans Skript machte das so, ich habe es nicht geändert. ;-)
Wieso konvertierst Du nicht den Suchbegriff als erstes in Kleinbuchstaben und konvertierst dann die jeweils zu vergleichenden Zeilen ebenfalls in Kleinbuchstaben.
Weil ich dafür mit $suchbereich = uc (suchbereich) eben auch über den gesamten Suchbereich drüber gehen müßte - und ob *das* so viel schneller geht?
Statt dem exponentialen Arbeitsaufwand, den Du beschreibst,
Das tue ich gar nicht. Es ist nur Faktor 2, weil der Vergleich intern immer noch auf Zeichenbasis erfolgt.
Wäre Deine Aussage korrekt, dann würde das Verhältnis der Laufzeiten zwischen case-sensitiv und nicht case-sensitiv von der Länge des Suchterms abhängen - dies ist aber nicht feststellbar.ist es nur ein einfacher zusätzlicher Arbeitsschritt pro zu durchsuchender Zeile (und außerdem dürfte die Umsetzung in Kleinbuchstaben - oder auch Großbuchstaben - sowieso ein zügigerer Vorgang sein als die Prüfung regulärer Ausdrücke).
Ich werde es auszuprobieren.
Bedenke aber, daß "Zeile" das gesamte Sucharchiv bedeutet! Denn wir haben einen Volltextindex ...-
Ich werde es auszuprobieren.
Bedenke aber, daß "Zeile" das gesamte Sucharchiv bedeutet! Denn wir haben einen Volltextindex ...Deine Idee ist in der Tat ausgezeichnet!
Gemessene Zeiten:
Case (alt) 4.27 + 0.46 Sekunden
noCase (alt) 8.90 + 0.44 Sekunden
noCase (neu) 5.02 + 0.45 Sekunden
(Suchbegriff "Apache", Forum-Indexdatei mit 25 MB, Pentium III 500, 128 MB, Apache 1.3.9, jeweils Mittelwert aus mehreren Versuchen)Bravo - und das Forum wird es Dir danken! (Sobald Version 2.5 von Stefan installiert ist ...)
Ganz nebenbei sehen wir daran, daß der Teamone-Server, der bei 40 MB Archiv-Volumen für Case ungefähr 10,68 + 3,66 Sekunden braucht, mit einem Pentium 500 kaum noch mithalten kann ...
-
Ich werde es auszuprobieren.
Bedenke aber, daß "Zeile" das gesamte Sucharchiv bedeutet! Denn wir haben einen Volltextindex ...Das ist interessant und wohl die Antwort auf die zweite Frage, die ich stellen wollte: Du schreibst, daß die Bearbeitung einer Suchanfrage durch das Skript 15 sec dauert. Als Benutzer muß ich aber 1 min oder mehr auf die Ergebnisse warten. Woher rührt die Differenz? Ich verstehe Dich jetzt so, daß der gesamte Index (40 MB) vor Ausführung des Skripts in den Arbeitsspeicher geladen wird. Ist das richtig? Und wenn ja, ist das wirklich nötig? Was spricht dagegen, daß das Skript die Datei öffnet und zeilenweise abarbeitet (wie es ja z.B. auch so einfache Dienstprogramme wie "grep" tun)?
Ich gebe zu, daß diese Vorgehensweise wahrscheinlich keinen Geschwindigkeitsgewinn bringen würde, denn so oder so muß sich das Skript
bis zum Ende durcharbeiten, aber mich interessiert das technische Konzept dahinter.In diesem Zusammenhang noch etwas zu der "Datenbank"-Lösung, die diskutiert wurde. Ich bin mit der Terminologie nicht ganz vertraut. Ich selbst habe bislang eine Lösung, die darauf beruht, nicht im Volltext selbst, sondern in vorgefertigten Zuordnungslisten mit den im Text vorkommenden Wörtern zu suchen, als "Indexsuche" bezeichnet. Eine indexbasierende Volltextsuchmaschine in diesem Sinne (also wohl eine "Datenbank"-Lösung im hier besprochenen Sinne) habe ich vor kurzem programmiert.
Ich habe sie im Zuge der Entwicklung probeweise auf einige verschieden strukturierte Datensätze angewandt, darunter auch auf das Selfhtml-Forumsarchiv.Die Lösung ist sehr befriedigend: typische Suchanfragen werden in der Regel in ein, zwei Sekunden beantwortet. Phrasensuchen dauern dafür länger.
Das vielleicht interessanteste einer solchen Datenbanklösung ist die Genügsamkeit im Dateizugriff (was offenbar, wie Du es sagst, der Flaschenhals der bisherigen Lösung ist): denn es müssen immer nur ein paar KB an Daten in den Arbeitsspeicher geladen und abgeglichen werden.Wie ist es übrigens mit der von Dir erwähnten Software Glimpse? Handelt es sich da um ein Datenbankkonzept und wie schnell ist die Suche in den Archivdateien? Was spricht dagegen, diese Software zum Einsatz kommen zu lassen?
Gruß,
Oliver
-
-
-
-
-
-
-
-
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.
-