nicht angemeldet
Hallo!
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? Wo ist der Vorteil(10er Potenzen) Gegenüber Deiner VErsion die ebenfalls linear halt die ganzen postings, und nicht die Wörter einzelnd durchsucht, was aber am Ende wohl aufs selbe rauskommt, oder? Die Anzahl der zu durchsuchenden Wörter ist dieselbe(zumindest wenn ich das richtig Verstanden habe), nur die Andordnung ist anders.
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?
Für den Normalbetrieb war das prima, aber schon kleinere Änderungen in diesem Baum dauerten Stunden.
OK, hatte mir schon sowas gedacht. Ist ja auch Quatsch, denn dann hänge ich wieder an der Festplatte feste, aber schnell sollte es sein. Nur eigentlich will ich ja eher von der Lösung "alles im RAM" weg, denn das kann zumindest _ich_ mir nicht erlauben, außerdem könnte ich dann auch das gesamte Filsystem wo ich das mache in den RAM legen, was verutlich nochmal gut für den Speed wäre, naja, aber vermutlich erzeugt diese Lösung noch ne ganze Menge an Overhead den ich nicht haben will.
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.
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?
Für den Normalbetrieb denkst Du exakt in den Bahnen wie ich vor knapp zwei Jahren. Die Wartung solcher Strukturen ist aber - gelinde gesagt - eine Katastrophe.
Außerdem ist das Traversieren von Teilbäumen sehr langsam. Wenn Du mit Deinem Modell ein "LIKE 'java%'" emulieren willst (ich wollte das, weil ich Substrings finden können mußte), dann wird es ziemlich teuer, und die Festplatte kommt ordentlich ins Rotieren. Dann noch mehrere Suchanfragen gleichzeitig, die allesamt den Kopf der Festplatte gegeneinander positionieren ... aua. Offenbar war der Dateisystemcache bei Solaris nicht groß genug.
Also fasse ich das zusammen dass das Lesen sehr schnell ist, aber das Schreiben extrem lange dauert.
Was ich aber nicht verstehe, die Datenbank müßte doch erheblich langsamer sein, denn die hat ja nicht nur den Zugriff aufs Dateisystem, genau wie ich(bei 2 Suchwörtern muß ich auch nur 2 Dateien in bekannten Verzeichnissen öffenen, da wird schonma nichts gesucht, dann werden ein paar 100-1000 IDs verglichen, was auch recht schnell ist, und dann einige Posting-Dateien mit den metadaten direkt geöffnet), die DSatenbank hat darüber hinaus ja noch den Aufwand die _gesamten_ Daten in der Tabellen-Datei zu parsen und und zu filtern, das _muss_ doch einfach erheblich langsamer sein, oder? 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 Fourm wäre ein Server wie der vorhandene überfordert beim Ändern und Erzeugen des Baums? Vielleicht kann man dann noch einen eigenen "Cache" bauen indem man die 2-5% am meisten Vorkommenden Suchwörter auf eine RAMdisk schreibt!?
Wenn das bei jedem Zugriff gemacht werden muß, dann ist es aus exakt demselben Grund schlecht wie die Verwendung einer HEAP-Tabelle aus mySQL (Du siehst, die Konzepte sind immer dieselben, nur die Namen ändern sich).
Wenn das aber ein daemon permanent im Speicher hält und Deine CGI-Programme sich per UNIX domain socket mit diesem verbinden, so wie dies im neuen Self-Forum der Fall ist ...
schön, aber da ist es wieder das Problem mit dem beschränkten RAM. Der Hash ist ja gerade die Datenquelle die nur für ein Jahr erheblich über 100MB beträgt.
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 ;-))
Viele Grüße
Andreas