nicht angemeldet
Moin nochmal,
Das riecht nach exponentieller Größe (es wird ja einfach Zeit mit Platz erkauft), und das halten wir bei diesen Datenmengen nicht aus. Wir brechen ja schon unter einer linear wachsenden Datenmenge zusammen.
Wieviele Gigabytes darf unsere mSQL-Datenbank denn auf dem Server belegen?
daß die Archivsuche nicht prinzipiell an den technischen Möglichkeiten scheitert, bekommt man ja jederzeit deutlich von Altavista & Co. vorgeführt - dort wird eine um Größenordnungen größere Datenmenge in einem Bruchteil der Zeit durchsucht - und das von einer um Größenordnungen größeren Menge an Leuten - so daß es also nicht einzig an einem schnelleren Rechner oder so liegen kann.
Ich weiß nicht, wie die das genau machen, vermute aber mal, daß es mit Hash-Tabellen funktionieren könnte: Man definiere eine Funktion, die aus einem X-beliebigen Wort einen sog. "Hash-Wert" von z.B. 0-9999 generiert. Danach muß irgendein Skript das Archiv komplett durchforsten und eine Hash-Tabelle mit Einträgen der Form
{wort, Nummer_des_Archivbeitrages, Anker (Sprungmarke)}
generieren. Diese Tabelle könnte man dann auf 10000 Dateien verteilen, was zwar nach viel klingt, aber angesichts der Anzahl von mittlerweile >50000 Forumsbeiträgen auch nicht mehr ins Gewicht fällt <g>.
Eine Suche würde dann für jedes Suchwort wie folgt ablaufen:
1.) Hashfunktion des Suchwortes berechnen (geht schnell).
2.) Das Ergebnis wäre z.B. eine Zahl zwischen 0 und 9999.
Die entsprechende Indexdatei wird geöffnet.
3.) Alle Einträge (die in der oben erwähnten Form vorliegen) in dieser Datei
durchsuchen, ob sie mit dem Suchwort übereinstimmen und gegebenenfalls
die entsprechenden Archivlinks ausgeben.
Bei Und/Oder-Verknüpfungen müßte man diese Schritte mehrmals mit den einzelnen Wörtern durchführen und bei Suchbegriffen aus mehreren Wörtern hintereinander müßte man vielleicht erstmal nach den einzelnen Wörtern suchen und dann in der "Lösungsmenge" nochmals kontrollieren, ob die Worte auch hintereinander stehen - sollte immer noch deutlich schneller gehen als wie bisher.
Angenommen, ein Durchschnittsbeitrag hat ca. 500 Wörter (hat dieser hier in etwa), dann wären wir bis jetzt bei einer Gesamtzahl von ca. 30 Millionen Wörtern für alle Beiträge. Das heißt, in jeder Einzeldatei der Hashtabelle stehen durchschnittlich gut 3000 Einträge, was sich im Ggs. zu >25 MB relativ schnell durchsuchen lassen sollte. Wenn man gleiche Wörter in verschiedenen Beiträgen noch zusammenfaßt, so daß man Einträge der Form
{wort, Liste von Links auf Archivbeiträgen und Anker}
erhält, wird die zu durchsuchende Datenmenge weiter reduziert. Insbesondere wächst die Datenmenge linear und nicht exponentiell. Im Detail habe ich sowas noch nicht gesehen, vielleicht gibt's entsprechende Skripte ja auch schon irgendwo fertig zum Download - aber als Idee wollte ich das einfach mal anregen...
Bis dannundwann
Andreas