nicht angemeldet
(ZU DIESEM FORUM) Nochmal als eigener Thread: Archivsuche erweitern um SelfHTML und Forum-Auslese
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.