nicht angemeldet
Moin!
Was ich gemerkt habe, der Index muß immer aktuell sein, wenn ich ein paar 1000 Datensätze in die Tabelle schreibe, wird die Suche erheblich langsamer. Ich habe jetzt ca. 12.000 Datensätze in der DB(1 pro Thread), und da dauert es mehr als 15 Minuten den Index neu zu erstellen! Auch wenn ich eine kompletten Dump im batch-modus einlese!
Du hast sicher in der Doku gelesen, dass es schneller geht, die Tabelle zunächst ohne Volltext-Index anzulegen und zu befüllen, und den Index erst nachträglich hinzuzufügen, oder?
Und die ganze Zeit ist die CPU und der Arbeitsspeicher bis zum Anschlag ausgelastet! Ich denke daher das mehr CPU-Power und vor allem RAM sehr wohl was bringt! Kann man nie genug haben, zumindest solange das System drauf ausgereichtet ist. Wie pflegt Ihr denn solche Indices?
Klar bringt vor allem viel RAM viel, weil die ganzen Indices sich nun mal viel besser im RAM machen, als auf Festplatte.
Wobei ich glaube ich auf unique und Primärschlüsel verzichten kann, denn das bringt hier eh nichts. Die Gewichtung ist aber nicht das gelbe vom Ei. Das ist noch viel zu unflexibel. Außerdem ist das Verhätnis nicht ganz richtig. Ich hatte mir folgendes überlegt, um dem Titel und dem Themenbereich mehr Gewicht zu verleihen:
entweder ich füge eine weiter Spalte ein, und hier dann duch Leerzeichen getrennt 5 mal das Thema und 10 mal den Titel, und das dann mit in den Index aufnehmen, oder 15 weiter Spalten mit entsprechend 5 mal Titel und 10 mal Themenbereich.
Das bringt beim MySQL-Volltextindex aber leider genau das Gegenteil. Je häufiger ein Wort vorkommt, desto weniger relevant ist es, und desto geringer die Ergebnisgewichtung. Dein Vorhaben könnte zur Folge haben, dass man nichts mehr findet.
Wenn du Titel, Thema und Postingtext unterschiedlich gewichten willst, dann mach drei statt einen Volltextindex (wobei der Themenbereich eher _keinen_ Volltextindex benötigt, denn da ist die Auswahlmöglichkeit ziemlich gering).
Bedenke auch, dass du bei einer Abfrage über den Volltextindex eine Relevanzangabe erhälst, die du nutzen kannst. Beispielsweise könntest du die Relevanz der Titelfunde entsprechend multiplizieren und dann die Relevanz der Postingfunde addieren, um eine Gesamtrelevanz zu erhalten (und danach zu sortieren - macht ja alles mySQL für dich, wenn du willst).
Ich habe auch schon ein eine eigene stop-word Liste gedacht, indem ich beim Anlegen der Datensäzte dort ausgewiesene Wörter entferne.
Bringt auch nichts in Verbindung mit dem Volltextindex. Da werden häufig vorkommende Wörter automatisch zu Stop-Wörtern, die man über den Index nicht mehr findet.
Wobei ich gestehen muß, Ihr hattet Recht, so viel schneller ist die DB auch nicht, aber auf der anderen Seite habe ich keine Ahnung wie man das ganze wirklich performant macht, da gibt es ja glaube ich noch einige Möglichkeiten...
Aha! :) Wie du siehst, ist auch eine Datenbanklösung nicht endlos überlegen - mehr Performance kriegt man also nur über schnellere oder parallele Maschinen. Wobei es IMO etwas Overkill ist, nur für die Archivsuche eine eigene Maschine hinzustellen, die dann auch noch regelmäßig die neuen Archiveinträge mitgeteilt bekommen muß. Google zieht sich da relativ leicht aus der Affäre, weil dort in regelmäßigen Abständen Updates der Suchdatenbank auf die Cluster verteilt werden. Die Zeitabstände sind aber wohl monatlich - für die Archivsuche unzumutbar!
Mal ne ganz andere Frage: Wo kann ich unter Linux einstellen, welche Programe beim Starten geladen werden? Also mein dyndns client z.B.? den starte ich jetzt immer manuell aus der shell, das kann es ja nicht sein!
Unter /etc/rc.d/ sind diverse Skripte, die Startaufgaben erledigen (kann sein, dass der Pfad Suse-geschädigt ist und normalerweise auf /sbin/init.d/ lautet). Weiterhin befinden sich in diesem Verzeichnis einige Unterverzeichnisse rcX.d (für das X eine Ziffer), in denen sich symbolische Links auf die Skripte befinden. Die Namensgebung ist einheitlich: K - Kill-Skript, stoppt einen Dienst, wenn der Runlevel (die Ziffer im Verzeichnisnamen) verlassen wird. S - Start-Skript, startet den Dienst. Die nachfolgende Zahl gibt an, in welcher Reihenfolge die Skripte abgearbeitet werden. Dein DynDNS-Skript sollte sinnvollerweise erst dann gestartet werden, wenn dein Netzwerk gestartet ist, und gestoppt werden, bevor dein Netzwerk stoppt.
Mein Skript für DynDNS heißt "ddclient" und ist im Runlevel 2 (nur Kommandozeile - was brauch ich X auf einem Server) mit S25ddclient und K09ddclient verknüpft. Wird als ziemlich zum Schluß gestartet (nach S25 kommt bei mir nicht mehr viel), und ziemlich zum Anfang gestoppt (K09 ist das erste Skript).
- Sven Rautenberg