Hi Christian!

Korrekt. Tatsaechlich ist es sinnvoll, das mit 3 Tabellen zu
loesen, da eine n:m-Beziehung vorliegt:

Postings        Woerter
   |     Nodes     |
   |       |       |
   +-------+-------+
     1:n       n:1

Jedem Posting sind n Nodes zugeordnet, jeder Node ist 1 Wort
zugeordet.

Ich glaube so habe ich es mir auch vorgestellt.

und nicht
jedes einmal, sondern so oft es insgesamt vorkommt, mit
einer 2. Spalte Posting_ID.

Warum sollte man Woerter doppelt speichern? Du kannst
stattdessen die Wertigkeit mitspeichern, in einer weiteren
Spalte.

Das hatte ich jetzt Michaels Aussage entnommen, dass man nur eine Tabelle verwendet, mit je Wort => Posting_ID, und dann könnte man über Wort einen Index legen ung hätte dann auch sowas wie eine logarithmische Suche, da im Index ja auch nur jedes Wort 1 mal vorkommt, und mit Hilfe dieses Index kann die DMS dann auf den Teil der Tabellen_Datei zugreifen, der für das Ergebnis relevant ist.

Der Fulltext-Index ist eine Blackbox. Wie genau er
funktioniert, ist doch eigentlich unwichtig.

Naja, ich verstehe halt nicht wieso er so langsam ist/bleibt! Erst durch Caching wird das ganez schnell, nur leider sind die meisten Suchanfragen sehr verschieden und liegen meist nicht mehr im Cache, also wird das ganze extrem langsam. Ich überlege halt eienn Fulltext-Index manuell in einer, bzw. 3 Tabellen nachzubilden. Das würde ich dann wenigstens verstehen und könnte das entsprechend versuchen anzupassen.

Woher weiß ich vorher was der User als nächstes in der DB
sucht?

Gar nicht. Warum solltest du das wissen muessen? Behalte die
durchschnittlich am meisten gebrauchten Teile permanent im
Speicher und gut.

Das ist das was sowohl mein Filesystem als auch der MySQL-Cache tut, nur wenn man sich mal so Suchanfragen ansieht, dann sind die doch sehr verschieden. Das Problem ist das ca. 90% der Suchanfragen sehr selten sind. Die kann an nicht alle im Cache halten, die 10% die öfter sind, gut, aber die nicht gecachten seltenen Anfragen müssen jedesmal im kompleten Index gesucht werden, der Volltext Index für den gesamten Self-Raum hätte bestimmt 250 MB, der müßte dann also komplett einmal geparst werden, durchsucht werden und dann müßten die Daten der Ergebnisse noch aus der Tabellen-Datei von der Platte geholt werden, aber das ist dann das geringste Problem. ODer habe ich das jetzt total faslch verstanden? ODer muß der Index nicht geparst werden?

Theoretisch, praktisch aber nur die von mir genannten gut
50 MB/sek.

Und wie kommst du auf solche Aussagen? Kannst du die belegen?

Ich habe es in verschiedenen Quellen gelesen, z.B. hier: http://www.de.tomshardware.com/storage/02q1/020301/wd120-01.html, aber auch in der CT..., die Werte sind immer ähnlich.

OK, aber woher weiß ich jetzt welche 10 Byte ich genau
raushole?
Das ergibt sich aus deiner Datei-Struktur.

was? Welche Dateistruktur? Ich rede hier von einer Datenbank?!

Nehmen wir mal einen Baumartigen Index. Das Dateiformat kann
man so anlegen, dass man den Baum direkt anlegen kann. Wenn
ich jetzt dem Pfad folge, hole ich immer nur genau die Teile
von der HD, die ich als naechstes brauchen werde. Das kann
ich z. B. erreichen, indem ich bei jedem Knoten mitspeichere,
wo die naechste Node zu finden ist. Das kann im einfachsten
Fall ein Pointer sein und im schlimmsten Fall ein Dateiname
mit einem Byte-Index.

Also wird beim MySQL Volltext irgendwie ein binärer Baum auf der Festplatte gespeichert, und der wird dann halt durchsucht(das meine ich mit logarithmisch im Gegensatz zum succesiven Durchsuchen einer Tabelle). Aber das müßte doch tierisch schnell sein, ist es aber nicht. Da muß man wohl noch ein einigen Stellen ausbessern.

Viele Grüße
Andreas