nicht angemeldet
Hi,
Ja, das wäre wohl eine deutlich elegantere Lösung gewesen..
Naja, wäre dann ja mal 'ne günstige Gelegenheit ;-)
Ja, wäre es, obwohl das eigentlich in diesem Fall nicht so wichtig wäre... Mal sehen...
Ich würd's schon machen, ist einfacher nachher. Das erworbene Wissen kannst Du auch später immer gebrauchen.
Um das Suchen von mehreren Wörtern habe ich mich noch nicht befasst. Daher würde mein Script auch die Kombination "ein Satz" nicht finden. Grund ist, das es erstmal schnell(er) werden muss, bevor ich auch soetwas zurückgreifen würde. auch logische Verknüpfungen "ein+satz" oder so gehen nicht...
Ja, das wird so, wie Du das jetzt implementiert hast nix, aber so weit warst Du ja schon selber ;-)
Das der Flaschenhals das Laden der Dateien und nicht das Durchsuchen ist, hast Du auch schon festgestellt. das heißt einerseits, das Du ruhig Deine Suche verfeinern kannst, denn das hat mit dem Problem "Lahmarschigkeit" erst mal nix zu tun und zum anderen, das Du es schlicht vermeiden muß Dateien überhaupt erst zu laden.
Das kannst Du, in dem Du die Dateien _vorher_ durchsuchst und das Ergebnis in die Suche direkt einbaust. Ene gute Methode dafür ist der beschriebene Inverted Index. Da ist einerseits sehr viel Information drin, andererseits aber auch kein Volltext.
Der Inverted Index der HTML-Seiten vom Selfhtml-8.1 Paketes hat bei mit rund 25.000 Einträge. Unbereinigt aber schon alles tolower() gesetzt. Ein rundes MiB an Daten. Das ist ziemlich viel, läßt sich aber sehr gut aufteilen, da bereits sortiert. Selbst bei Teilstringsuche oder gar RegEx bräuchtest Du nur runde 10-12 Dateien zu laden, je nachdem, wie Du aufgeteilt hast. Bei exakter Vollwortsuche bräuchtest Du sogar nur eine laden: wenn Du den I.I. z.B. nach dem Alphabet aufgeteilt hast, mußt Du nach dem Wort "Meningitis" natürlich nur in "m.js" suchen und nicht erst alle von a-n durchklappern.
Also im Höchstfall 12 Dateien laden mit rund 1 MiB Volumen anstatt 1446 Dateien mit über 10 MiB Volumen einzeln zu laden und zu durchsuchen.
Die Größe des Inverted Index steigt auch nur asymptotisch gegen die Grenze bei etwa 100.000*n, wobei "n" die Anzahl der natürlichen Sprachen des Datensatzes ist. Wenn Du also z.B. den deutschsprachigen Gutenbergmirror bei spiegel.de indizieren würdest, kämst Du auf maximal so um die 100.000 Einträge im Inverted Index, bei weit über einem GiB an Daten. Noch besser: indizierst Du auch noch den englischsprachigen Gutenbergmirror dazu kommst Du auf rund 200.000 Einträge bei einigen zig Gigabyte an Daten. Skaliert also gut, oder? ;-)
Um mehrere Suchbegriffe zu zulassen müsste ich die Trefferspeicherung wohl etwas anders gestalten. Die übergebenen Suchwörter würde ich dabei einfach in einem Array ablegen und mit Hilfe einer Schleife jeden einzelnen INDEX mit dem String prüfen.
Naja, ich glaube _das_ ist Dein kleinstes Problem ;-)
Dann steht für jeden einzelnen Treffer die Daten im Ergebnisfeld. Diese müsste ich erneut Prüfen. Habe ich bspw drei Wörter eingegeben, dann muss im TrefferArray auch dreimal die entsprechende HTML Datei drin stehen - wenn weniger, dann ist es kein Treffer usw...
Naja, das ist dann wieder eine Frage der Gewichtung, aber das kommt dann wirklich später.
Im Selfhtml-8.1 Paket gibt es 1446 HTML-Dateien, ist auch mein Testbed, viel Spaß damit ;-)
Hallo?! Die müsste ich von Hand zunächst eintragen ;-)
Keine ordentliche Shell zur Hand? Perl? Sonstwas an Skriptsprachen für'n Einzeiler?
Bist auf Windows, was? ;-)
Aber: ich habe mal die Ordner Quellen, Projekt, PHP, Navigation und deren Unterordner eingetragen - macht 56 Dateien. Als suchbegrig diente "html", da der immer vorkommt (<html>) das Ergebnis wurde in einem Bruchteil einer Sekunde ohne nennenswerte Verzögerung ausgegeben...
56 Dateien? In Worten: sechsundfünfzig? Bei insgesammt 1446, dem fast sechsundzwanzigfachen? Nene, Kollege, so wird das nix mit dem Benchmark ;-)
so short
Christoph Zurnieden