Hi Andreas,

Vermutlich könnt Ihr es euch nicht erlauben so einen großen Index im RAM zu halten, oder?
Keine Ahnung. Deshalb finde ich Deine Experimente mit mySQL ja so wertvoll. Denn das Prinzip ist ja problemlos auch ohne FULLTEXT verwendbar: Stell Dir einfach vor, Du hättest eine zusätzliche Tabelle mit der Abbildung von Wort auf Posting-ID und würdest über die Worte einen non-unique Index legen ... ich verwendet eine solche Implementierung, und ich habe etwa 20 Millionen Einträge in dieser Tabelle.
Sowas ähnliches habe ich zwischenzeitlich auch gehabt, halt für den Such-String-Sortierer, habe das aber nur kurz versucht, wäre da nicht eine Struktur wie folgt optimal:

Tabelle worte:
  wort_ID
  wort_STRING

Tabelle postings
  wort_ID
  posting_ID

schreib mal die Art der Relation dazu (1:1? 1:n? m:n?), dann versteht man es besser.

dann könnte man über die wort_ID(INT) joinen

JOIN kostet Zeit. Muß das sein?

Aber ich habe ja schon oben mal nachgefragt wegen eines Binärbaums, habe da auch einiges zu gelesen, wie sich das z.B. in PERL abbilden ließe, aber da weiß ich nicht ob das ganz so schlau ist, denn man müßte jedesmal alle Suchworte in einen Hash laden, und jedesmal den Baum mit den Knoten erstellen. Das wird doch tierisch lange dauern.

Das finde ich nicht schlimm, wenn anschließend ein daemon diese Struktur sehr lange im Hauptspeicher hält. Genau auf diesem Prinzip basiert das neue Forum ...

Kann man eine Baumstruktur nicht fest in irgendeiner Datei speichen, das nur noch der fertige Baum geladen werden und durchsucht werden muß

Sicher. Das ist dann allerdings extrem änderungsunfreundlich.

denn das erstellen des Baums wird vermutlich ähnlich lang dauern wie das erstellen des Fulltext-Index!

Das kommt darauf an, wie Hashes implementiert sind. Ich habe irgendwas vage in Erinnerung, daß man komplexe Datenstrukturen a la Hash in Perl direkt speichern und wieder laden können soll ... aber von konkreten Programmiersprachen habe ich ja bekanntlich keine Ahnung.

Es muß nicht alles im RAM liegen.
Aber _das_ macht den entscheidenen Unterschied!

Das glaube ich nicht. So viele Zehnerpotenzen schneller als eine gute Festplatte ist der RAM nun auch nicht.

Zumindest in meine Tests, wenn der Index im Cache liegt(die SQL-Abfrage kann in MySQL 3.23 noch gar nicht gecached werden!) wird das sehr schnell, sobald der komplette Index auch der Festplatte nach unschärferen Wörtern durchsucht wird wird er langsam.

Sorry, das ist mir nicht konkret genug. Was heißt "unschärfere Wörter"? Dort kann die Ursache des Problems stecken.

Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)
bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer

Du bekommst nicht alle Zugriffe schneller. Du bekommt Zugriffe mit wenigen und gut projezierenden Zugriffen sehr viel schneller, während Zugriffe mit vielen und/oder schlecht projezierenden Suchbegriffen bei Dir variabel viel kosten, im Original aber alles gleich viel.

es ist irgendwie ein Trade-Off, am Anfang war alles auf den Cache optimiert, hinterher wollte ich gerade neue Anfragen beschleunigen, dadurch wurden aber die "alten" erheblich langsamer :-(

Deshalb braucht das Ding ja auch eine Aufgabenstellung.
_Ich_ weiß genau, warum ich Deine Implementierung lieber bedienen wollen würde als meine: Weil ich gut projezierende Suchbegriffe kenne. Deine Implementierung ist sehr viel expertenfreundlicher - wer sie richtig bedient, kann damit Quantensprünge erreichen. Meine Implementierung ist für alle Anwender fast gleich langsam ... wobei auch dort die Verwendung von spaltenbezogenen Suchbegriffen etwas bringt, aber keine großen Faktoren.
Und nun überlege Dir, für welche Zielgruppe _Du_ implementieren willst ...

Oder noch krasser: Glaubst Du, aus der Eingabe der Such-Maske (blacklist, Zahl der Suchbegriffe, etc.) schließen zu können, ob der lineare oder der logarithmische Ansatz schneller sein wird? Du könntest ja auch beides implementieren und dynamisch entscheiden, was Du wirklich tust ... jetzt denk Dir noch ein bißchen KI dazu, also eine lernfähige Maschine ...

Viele Grüße
      Michael