nicht angemeldet
Hi Andreas,
- für die Größe des "projektes" einen
verhältnismäßig "kleinen" Server
naja, inzwischen geht es einigermaßen. Das war früher mal viel schlimmer.
- die Art der Suche, es wird jedesmal über 100MB
an Textfiles durchsucht.
Nur dann, wenn jedesmal das komplette Archiv durchsucht wird. Das muß aber nicht sein! Warum, glaubst Du, habe ich das Archiv in einzelne Indexdateien zerlegt, die im Such-Formular separat auswählbar sind?
(Hm, man könnte mal darüber nachdenken, das Jahr 2002 in zwei Teile zu schneiden ...)
Das ist vermutlich deutlich recourcenverschwendender
und langsamer als eine Datenbank, die dafür optimiert
wurde!
Richtig. Aber für die Aufgabenstellung, welche von der Self-Suche _derzeit_ erfüllt wird, eine Datenbank zu optimieren, das ist keine einfache Angelegenheit.
Aber es ist wird schon seit längerem an einer
MySQL-Datenbank für die Suche gebastelt, ich weiß
nicht wo genau das Problem liegt, aber es müssen
schließlich alle Daten vernünftig strukuriert hier
rein geschrieben werden, also schon ein größerer
Akt, vermutlich noch größer als ich es mir jetzt
vorstelle.
Definiere "suchen" - das ist das Problem.
Eine Such-Funktion, die lediglich Worte einer bestimmten Mindestlänge (sagen wir mal: 4 Zeichen) finden kann, liefert mySQL bereits fertig mit (FULLTEXT-Index).
Aber die ist nicht verwendbar, um all das nachzubauen, was die bisherige Suche kann.
Die kann nämlich
1.) reguläre Ausdrücke in Suchbegriffen und
2.) Phrasensuche,
also eben gerade _nicht_ beschränkt auf Worte arbeiten.
Eine Datenbank, die alle Worte eines Postings in einem entsprechend sortieren Indexbaum ablegt, findet natürlich Postings aufgrund von Worten sehr schnell.
Du könntest damit nach "Internet" + "Explorer" suchen - Du würdest allerdings auch alle Dokumente finden, die diese beiden Worte ohne jeden Zusammenhang enthalten.
Nach der Phrase "Internet Explorer" könntest Du damit jedoch nicht suchen - weil 'Phrase' kein von dieser Suche unterstütztes Konzept wäre.
Wenn Du aber den gesamten Inhalt aller Postings durchsuchen mußt, um Phrasen zu finden, was nützt Dir dann noch eine Datenbank? Da ist die bisherige reine Perl-Implementierung sicherlich schneller.
Es gibt ein Gedankenmodell, welches darauf beruht, die Suche nach einer Phase wie "Internet Explorer" abzubilden durch
a) eine Suche nach Internet AND Explorer (beides ist mit einem Wort-Index realisierbar) _und_
b) einer nachgeschalteten Volltextsuche durch sämtliche in Schritt a) gefundenen Treffer (in der Hoffnung, daß das dann signifikant weniger als alle sind).
Das _ist_ sehr schnell - ich selbst setze ein solches System (unter Verwendung von mySQL-FULLTEXT) beruflich ein und kann die Idee daher nur unterstützen.
Es sind allerdings noch ein paar zusätzliche Verfeinerungen notwendig - beispielsweise eignet sich "Internet" nicht gerade toll als Suchbegriff, weil es viele tausend Treffer produzieren würde.
Man bräuchte also eine Art "Bewertungsfunktion" für die eingegebenen Suchbegriffe, um erkennen zu können, daß etwa bei einer Suche nach "Internet hype" die beste Strategie _nicht_ darin besteht, nach "Internet" AND "hype" zu suchen, sondern einfach nur nach "hype" und _dann_ den Volltextfilter dahinter zu schalten.
Das ist eine Erfahrungssache und erfordert ausgiebige Analysen des Inhalts (ich habe alleine dafür mehrere Programme geschrieben und mich eine ganze Weile damit beschäftigt, eine Stopwortliste für diesen Zweck zu bauen - und was tun, wenn _alle_ Worte der Phrase auf dieser Stopwortliste stehen? "Internet Explorer" wäre ein guter Kandidat dafür).
Auch ist die mySQL-spezifische Einschränkung auf eine Mindestlänge von 4 Zeichen pro Wort ein Problem. Da findet man schon mal nicht mehr "WWW" oder die gängigen Kürzel wie MS, NS, JS usw.
Man _kann_ den C-Quelltext von mySQL so anpassen, daß diese Einschränkung wegfällt (die Mindestlänge steht dort als Konstante drin). Hier in der Firma habe ich das gemacht, mySQL neu übersetzt und alle Indexe neu gebaut (die werden dann natürlich größer, aber nicht erheblich) - und es funktioniert prima. Mit einem mySQL in der Standardauslieferung geht so etwas natürlich nicht.
Der Punkt dabei ist allerdings letzten Endes nicht, daß eine neue Suche unbedingt den kompletten Funktionsumfang der bisherigen Suche abdecken muß. Es wäre aber schön, wenn sie es täte. Leider ist eine solche "Entscheidungslage" (nämlich eben _keine_ Aufgabenstellung, sondern ein "mach mal" ...) völlig unbrauchbar für den Beginn einer Implementierung.
Man _könnte_ sehr wohl ein Konzept aufstellen, welches darin bestünde, _neben_ der bisherigen Volltextsuche eine wortbasierte Suche anzubieten und die mächtigere Suche quasi als "Experten-Modus" darin nur zu verlinken. Mit einem gepatchten mySQL wäre diese Wort-Suche relativ schnell implementierbar.
Was in meinen Augen fehlt, das ist also eher ein ganzheitliches Betriebskonzept, welches sich dann auch mit der Usability dieser beiden Suchfunktionen und ihrer Einbindung in das gesamte Self-Portal befassen müßte ... nicht so sehr irgendwelche programmiertechnischen Skills im Detail.
Und außerdem ist natürlich zu bedenken, daß Daniela die Reimplementierung der Suche in ihrer Freizeit macht - und wieviel oder wie wenig sie davon zu opfern bereit ist, vermag ich nicht zu beurteilen.
Meine Nachrichtensuche, die auf dem oben beschriebenen Prinzip des nachgeschalteten Volltextfilters basiert, hat knapp _ein_Jahr_ Entwicklung vom ersten Entwurf bis zum produktiven Einsatz (der vor drei Wochen war) erlebt ... der Funktionsumfang ist natürlich nicht exakt vergleichbar (meine Lösung muß sich mit etlichen zusätzlichen Problemen herumschlagen, beispielsweise Authentifizierung, Entitlement und Accounting), aber ein paar Monate full-time-Entwicklung und Test kann man für ein derartig ausgereiftes System durchaus veranschlagen, wenn man sich das erste Mal an so etwas heran wagt.
Viele Grüße
Michael