Daten in Baumstruktur speichern

[Michael Schröpl]

Hi Andreas,

Ein Index ist ein Index.
Nur arbeitet der FULLTEXT auf einer Spalte einer Tabelle, die Du nicht explizit siehst.
Ja, aber wo ist das jetzt logarithmisch? Es werden doch _linear_ alle Wörter abgearbeitet, oder?

Keineswegs. Du arbeitest ja mit dem Index über diese Tabelle. Und der rekursive Abstieg innerhalb des Indexbaums ist im günstigsten Fall (UNIQUE INDEX) ein logarithmischer Zugriff.
Sind die Treffer nicht unique, dann müssen die gefundenen Teilbäume traversiert werden ... das ist dann etwas lästiger, aber hoffentlich immer noch besser als linear. (Der Super-GAU ist ein Indexbaum mit lauter identischen Suchbegriffen ... deshalb muß ein intelligenter Query Optimizer die mittlere Projektivität eines jeden Index kennen.)

Ist das </archiv/2002/11/30580/#m165087> in etwa das was Du damit gemeint hast?
Ja. Ich habe diesen Thread nachträglich gelesen, hatte Christians guten Ausführungen aber nichts hinzuzufügen.
Ich wollte auch nur sicher gehen ;-) Solang ich den Fulltext Index verwende brauch ich die ja nicht, aber bei einer eigenen Tabelle sollte ich mit Hilfe dieser Funktion die Datensätze generieren oder?

Ja. Dieser "Wort-Zerschlager" inklusive seiner wordchar-Funktion ist etwas, das Du dann selbst implementieren müßtest, um das INSERT/UPDATE/DELETE in die zusätzliche Tabelle hinzukriegen. (Und was ich selbst implementiert habe, um anschließend meine Stopwortliste zu bauen.)

Dann wird es nicht schnell. Es sei denn, Dein Betriebssystem hasht diese komplette Struktur, hält sie also als sortierten Baum im RAM. Das wiederum hängt vom Treiber Deines Dateisystems ab ... bei Solaris war dieser Caching-Effekt sehr stark beobachtbar.
Bei Linux wird glaube ich alles im RAM gerhalten, was man zuletzt verwendet hat, da gibt es irgendeinen Automatismus. Aber wie gesagt, ich hab nicht genug RAM, und Ihr auch nicht, wenn Du alle Archive... da reinpacken wolltest, dann würde es schon Eng für andere Anwendungen.

Eben. Du wirst nicht besser als bei FULLTEXT, was von mySQL sicherlich ebenfalls intelligent geswappt wird.

Das Aufbauen dauert zu lange. Und mir lief ein 10-GB-Dateisystem über, weil mir die inodes ausgingen.
Wieviele Dateien/Verzeichisse hattest Du denn da grob geschätzt? Gibt doch bestimmt Dateisysteme die hier besonders spendabel sind, oder nicht?

Bei Solaris kann ich die inodes nicht beliebig genau angeben. Dort nimmt das Dateisystem eine Mindestgröße pro Datei an, d. h. es beschränkt die Menge der inodes pro MB Dateisystem.
Meine 10-GB-Platte war bezüglich inodes voll, bezüglich Dateien nahezu leer ...

Also fasse ich das zusammen dass das Lesen sehr schnell ist, aber das Schreiben extrem lange dauert.

Ja. "mkdir" unter Solaris ist viel langsamer als "md" unter Windows NT4, beispielsweise - ich habe dasselbe Programm auf beiden Maschinen laufen lassen, und ein Pentium 800 schlug den fetten Solaris-Hobel um Faktor 10. Es kann natürlich sein, daß dies bei bestimmten Dateisystemtreibern unter *NIX weniger krass ausfällt ...

die Datenbank hat darüber hinaus ja noch den Aufwand die _gesamten_ Daten in der Tabellen-Datei zu parsen und und zu filtern

Wieso? Um das zu verhindern, legst Du doch die Indexe an.

Und wenn man für das ganze ein schönes Fronntend und schöne Wartungsscripte schreibt, meinst Du bei dem Daten-Aufkommen wie hier im Forum wäre ein Server wie der vorhandene überfordert beim Ändern und Erzeugen des Baums?

In Deinem Fall müßte immerhin nur eingefügt werden und nicht gelöscht. In meinem Fall war das schlimmer - da konnten von Tag zu Tag mal 10% des Datenbestands an Änderungen anfallen.

Ich verwende das von uns diskutierte Verfahren mit mySQL-FULLTEXT für eine Datenbank mit einer Million "Postings", die allerdings im Schnitt kleiner sind (ca. 1500 Bytes). Ich habe pro Tag etwa 30000 Zugriffe auf diese Tabelle ... und mySQL frißt im Schnitt keine 10% Maschinenlast dabei, obwohl simultan auch noch neue Postings eingefügt und geindext werden (ca. 5000 Stück pro Tag). Was die Sache bei mir so schnell macht (die meisten Suchanfragen dauern deutlich weniger als 5 Sekunden), das ist die Qualität der Suchbegriffe, die in meinem Fall aufgrund der Natur der Daten meistens ziemlich gut ist. Ich habe auch einige wenige Anfragen pro Tag, die länger als 30 Sekunden dauern ... der Mittelwert ist allerdings hinreichend gut.

Vielleicht kann man dann noch einen eigenen "Cache" bauen indem man die 2-5% am meisten Vorkommenden Suchwörter auf eine RAMdisk schreibt!?

Das habe ich nicht verstanden. Meinst Du die Suchworte oder die zugehörigen Postings? Das erste macht m. E. wenig Sinn, das zweite kann 90+% aller Postings ausmachen.

So mal ganz blöd gefragt, ist das von der Performance was ganz anders als z.B. in PHP so einen Hash(array) zu erzeugen, die print_r() Ausgabe zu puffern und in eine Variable und dann in eine Datei schreiben, die dann auf einer RAMdisk speichern und dann in andere PHP-Scripte einbinden?  (wenn Du das nachvollziehen konntest ;-))

Über PHP kann ich keinerlei Aussagen machen.

Viele Grüße
      Michael