nicht angemeldet
Hi Andreas,
Also im Falle einer indexdatei, wie bei der
Forumssuche. Vom prinzip, wie würdet Ihr/habt
Ihr die Index DAtei aufgebaut und wie genau
durrchsucht Ihr die Datei?
die Indexdatei besteht aus knapp 10 Feldern,
die durch ein Sonderzeichen ("|") getrennt sind.
Das Such-Skript liest diese Datei sequentiell,
trennt die Felder mit "split()" voneinander und
führt dann den Vergleich mit einzelnen Such-Termen
über regular expressions durch. (Damit werden dann
auch Dinge wie case-Sensitivität oder Wortgrenzen
gleich mit erschlagen.)
Auf diese Weise sind insbesondere auch beliebige
Phrasen auffindbar, nicht nur Worte.
Und diese Anforderung hat lange Zeit (Jahre ...)
verhindert, einen indexbasierten Ansatz ernsthaft
in Erwägung zu ziehen. (Inzwischen wird aber an
einem solchen gearbeitet, wobei Phrasen dadurch
realisiert werden sollen, daß zuerst ein AND über
alle darin enthaltenen Worte via Index und dann
für alle so bestimmten Treffer eine Volltextsuche
nach der exakten Phrase gemacht wird, um die echten
von den unechten Treffern zu trennen.)
Die Index-Datei mit den durchsuchbaren Daten
kann ruhig eine gewisse Groesse bekommen.
Ein paar Megabyte sind voellig unkritisch und
lassen sich auf modernen Rechnern in Bruchteilen
von Sekunden sequentiell durchsuchen.
Das stimmt, aber auch nur solange man weiß wie man
schnell sucht, es gibt ja bestimmt schnelle und
langsame reguläre Ausdrücke bzw. Strukturen für
einen solchen Index, oder?
Kaum. Ein Großteil der Arbeit ist wirklich das
Einlesen der kompletten Indexdateien - wie groß
die sind (und wie schnell das trotzdem geht!),
zeigen Dir die Ausgaben im Suchformular (bzw. in
der Ergebnisseite).
Vor allem: Wenn Du mehrere Suchterme verwendest
und diese mit AND verknüpfst, dann wird jeder
dieser Terme nur eine relativ kleine Teilmenge
aller Dokumente matchen. Laß es mal 10% sein.
Dann wird der erste Term für 10% aller Dokumente
matchen, der zweite aber nur noch in diesen 10%
aller Fälle überhaupt geprüft werden müssen und
dann wieder nur für 10% aller Fälle matchen, dann
sind wir bei 11%. Der dritte erhöht die Zahl der
Vergleiche wieder nur um ein Zehntel des Vorgän-
gers ... jeder weitere Term wird immer bedeutungs-
loser, weil er immer seltener geprüft wird.
Gleichzeitig machen weitere Terme aber die Treffer-
menge kleiner und reduzieren damit den Aufwand bei
der Ausgaben.
Im Ergebnis ist eine Suche nach einem AND aus vielen
Termen also sogar eher schneller als eine Suche nach
nur einem Term!
Ich denke aber, eine DB wird auch bei 100 Seiten
schon schneller sein, oder?
Nicht spürbar. Bei 10000 Dateien schon eher.
Viele Grüße
Michael