Suche online(funktionsfähig) / Perfromance-Verbesserungen?

[Andreas Korthaus]

Hallöchen!

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?

Muß ich überlsen oder vergessen haben, jedenfalls bin ich dann auch selbst auf den trichter gekommen, nachdem bei Datensatz 4000 das ganze mehr als 1 Sekunde pro Datensatz dauerte - mit sinkender Tendenz ;-)
Aber auch das nachträgliche erstellen dauer bei 12.000 Datensätzen und ca. 50 MB mehr als eine Halbe Stunde, das Nadelöhr ist ganz klar mein RAM, 256 ist deutlich zu wenig. Interesant was man unter Linux so alles "momitoren" kann ;-)

Klar bringt vor allem viel RAM viel, weil die ganzen Indices sich nun mal viel besser im RAM machen, als auf Festplatte.

Und die 2. Sache ist das ich für Linux meien uralte 4GB Festplatte verwende, vermutlich mit tierischen Ansprechzeiten, Drehzahl und mit 66er FSB..., ausßerdem Rattert die so, muß glaube ich mal tauschen :) Wobei Linux rtrotzdemnoch erheblich schneller ist als Windows2K!

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.

Stimmt, das hatt eich nur irgendwie im Kopf, war abr glaube ich mal angedacht gewesen, wenn man das ihne Fulltext, sondern manuell löst.

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).

Sehr gute Idee. Sollte man denn nicht lieber die Indices zusammenlegem, ich meine jetzt im allgemeinen, oder lieber enzelnde?
Aber warum braucht der themenbereich keien Volltxt-index? Die "navigation" durch alte Beiträge ist IMHO sehr verbesserungswürdeig, die Archivdateien sind_viel_ zu unübersichtlich, und die Suche nur chronologisch. Ich denke hier könnte man doch was draus machen, natütlich nicht mit den Standards von mySQL 3.23, aber so allgemein! Vielleicht kombiniert mit einem BEwertungssystem, aber dsas hatte wir ja schonmal ;-)
Auf alle Fälle muß das Archiv mal etwas strukturiert werden, udn am besten noch die Namen genannt werden, damit man die Beiträge aucgh 3 Wochen später noch halbwegs zuordnen kann! Wenn die Suche nicht geht ist man total aufgeschmissen, oft weiß ich in welchem Thread die Lösung meines Problems steht, komme aber nicht dran(jetzt schon ;-))!
ich probier emal ein bisschen rum, vielleicht bekome ich ja mal ne gute  _und_ praktikable Idee ;-)

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).

Ja, das ist wirklich gut. Nur was mich stört, die kleinen Beiträge, mit wenig drin stehen ganz oben, das ist IMHO falsch! Man bräuchte noch ein Feld mit der Länge des Threads. Vielleicht noch verknüpüft mit der Vielosterstatistik, um mit einem Allgorythmus ein kleines Ranking hinzubekommen, warum eigentlich nicht? WI egesagt, wenn denn MySQl 4 mal bei mir funktioniert, probier ich da mal einiges...
Von mir aus kann ich die Adresse auch so lassen, dann teste ich auf einer anderen Seite, udn wenn die Suche mal ausfällt hätte man trotzdem noch eine - wenn auch schwache - Aussicht auf Erfolg ;-) Ich baue da gleich noch ein paar Kleinigketen ein, und will das gesamte Archiv 2002 eintragen. Dann brauche ich noch nen Cronjob der Aktuelle Beitäge abfragt und fertig ist das ertmal.

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.

Aber mydql hat doch auch eine statische Liste, udn die iszt englische. Ich meine nur hierfür als Pendant!

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!

Nicht so schnell ;-) Bedenke das ich als "verhältnismäßiger DAU" dies zu stande gebracht habe, Mit Eurem Wissen und den Indice oder ganzen Tabellen im RAM, und noch dies oder das... wird das ganze erheblich schneller. Dann noch die 4er VErsion... was ich merke, wenn ich neue Wörter suche, dauert das meist um 1 Sekunde. Wenn das Wort schonmal gesucht wurde wird es _erheblich_ schneller. So geht das immer weiter(nicht unendlich), aber das ist genau das Gegenteil zu aktuellen Suche. Die funktioniert umso besser, je wenger Leute sie benutzen. Bei der logarithmischen Suche und den Indices ist das was anders, die DB merkt sich jede Suche! Ich bin fest davon überzugt das sich das bei höherer Belastung sehr positiv auswirkt!

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.

hm, ich habe beides ;-) Aber ich habe RH. Leider weiß ich nicht genau welches Script jetzt genau die Internet-Verbindung anstößt, außerdem sind das alle komplexe bash-Scripte, soll ich auch so ein Script schreiben??? Und hat das nicht was mit ip-up zu tun? Aber da weiß ich auch nicht wohin :-(

grüße
andreas
http://selfarchiv.d2g.com/