(ZU DIESEM FORUM) Nochmal als eigener Thread: Archivsuche erweitern um SelfHTML und Forum-Auslese

[Michael Schröpl]

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 ...