nicht angemeldet
Hallo nochmal!
War gerade über den 12 KB, habe das ein wenig verküzen müssen ;-)
Der indes ixt jetzt erstellt, hat über 60 Minuten gedauert. Wen ich jetzt suche, dauert es 1-2 Sekunden, bei bekannten Wörtern meist unter 0,1. Was meinst DU, wenn ich nicht eine Datensatz pro Thread verwende, sondern wie in der aktruelen Suche, einen Datensatz pro Posting - wird das schneller oder langsamer? Wenn ich bedenke das manche Suchworte nur ien einigen wenigen Postings eines Threads vorlkommen müßte das doch eigentlich besser gehen oder?
Also eines habe ich gelernt:
Volltext ust genau das Falsche für so ein Forum ;-)
Keineswegs.
Implementiere ein AND für mehrere Terme, und Du wirst
sehr viel bessere Ergebnisse bekommen, auch ohne
ranking-Funktion.
Aber da bräuchte ich dann mehrmals match against, oder mysql 4
Bedenke, daß eine Suche nach nur einem Term so viele
Ergebnisse liefern muß, daß selbst die beste Ranking-
Funktion dadurch überfordert wird. Wie soll die Funk-
tion denn wissen, was eigentlich gesucht war?
Klar, aber die Leute wissen oft leider nicht die speziellen Wörter wonach sie sollten
Implementiere AND und NOT kompatibel zur bisherigen
Suche, und mach dann Deine Zeitmessungen nochmal.
Ok, ich versuche es mal. Ich lass die Suche jetzt wieder so wie sie ist und verwende eine testseite.
Das hängt von den Inhalten der WHERE-Klauseln ab.
Je selektiver Deine Suchbegriffe sind, desto schneller
ist die Treffermenge aus dem indexbaum extrahiert.
Eine Suche nach "HTML" dauert viel länger als eine
nach .htaccess!
Ja, das ist so wenn man nur den Fulltest verwendet, aber wenn man echte Where spalte = $wert dazuschreibt, wie ist das dann? So wie ich das jetzt messe ist das recht egal, auch ohen extra Index, der ja eh nichts bringen würde!
Ich habe eine hart codierte Stopwortliste, die einige
zu häufige Suchbegriffe gar nicht mehr im FULLTEXT-
Index sucht, weil die Treffermengen zu groß werden.
Meine Suche müßte man von einigen Leuten probiert werden, und ich müßte mal ne ganze Zeit lang die Suchstrings loggen udn danach analysieren, dann könnt eman so eine Liste machen. Die kann dann mitr einkompiliert werden, doer noch besser - direkt aus allen Postings gelöscht werden. Eine Dolppelte Datenhaltung sollte hier besser sein, der Performancxe zuliebe!
Kannst Du auch nicht, weil er nicht verwendet wird
(EXPLAIN!). Der macht nur das INSERT langsamer.
Substring-Funktionen arbeitet nicht mit Indexen.
ist trotzdem nicht viel langsamer als eine direkter Vergleich! Nachträglich geht sowas ja nicht - wie? Dann müßte ich alle Auswählen und dann nochmal manuel filtern, das ist doch bestimmt nicht gut!
Mach weiter - als nächstes sind die guten Erfahrungen
dran. ;-)
ich hoffe ;-)
Du hast zu große Treffermengen.
AND und LIMIT werden beide sehr viel bringen.
Limit 100 hatt ich immer drin, da ich mir dessen bewußt war, AND werde ich mal probieren!
die volle Geschwindigkeit gibt es nur in Standard-
einstellung, sobald man die Suche weiter einschränkt
kostet das Geschwindigkeit - manchmal zumindest, ich
versteh es halt nicht.
Poste den exakten SQL-Code der generierten Anweisungen.
Für die Testphase: Implementiere einen zusätzlichen
CGI-Parameter "debug=1", welcher das generierte SQL-
Statement in die Ausgabe schreibt, sowie das Ergebnis
eines darauf angewendeten EXPLAIN, und am besten auch
die Anzahl der dabei erzielten Treffer nach jedem
Schritt.
Was heißt nach jedem Schritt? Ich habe ein SQL-Statement und das hat x Trefer, was soll ich da schrittweise machen? Später vielleicht bei einem eigenen Ranking!
So lernst Du, wie sich die Ausführungspläne
der schnellen und der langsamen Statements voneinander
unterscheiden, und wann welche Deiner Indizes verwendet
werden und wann nicht.
Zur Zeit habe ich nur einen, sollte ich mehr verwenden? Vielleicht für verschiedene Suchvariationen? Weiß imme rnoch nicht, ob ich jetzt einen Index pro Spalte anlegen soll oder einen über alle Spalten. as doofe ist, ich kann das nicht "mal eben" testen, das Anlegen würde mehrere Stunden dauern, die ich die Tabelle dann nicht verwenen kann.
Alles außer FULLTEXT ist momentan sinnlos. Im Augen-
blick sind Deine SQL-Stamements wichtiger, und das,
was die Datenbank daraus macht (EXPLAIN anwenden).
Aber was bringt mir EPPLAIN denn jetz wirklich? Es sagt ob es Fulltext verwendet, und sonst? Ist doch recht mager, oder? Ich zeige under http://selfarchiv.d2g.com/ oben das Statement an, und unter den Ergebnissen explain dazu.
KEY name_2 (name) *ups* ;-))) das war glaub ich der performancefressende Übeltäter!
Beim INSERT kostet das etwas, beim SELECT darf es
keinen Unterschied machen, weil es einfach ignoriert
wird.
Aber nicht wenn zur Zeit wo ich und andere da getestet haben dieser index nich erstellt wird, das macht die DB ziemlich langsam! Wie gesagt, 80 Sekunden...
"SELECT id,topic,title,name,time
FROM selfarchiv
WHERE MATCH (body,topic,title)
AGAINST ('".mysql_escape_string($_GET['suchausdruck'])."')";
AND name = '".mysql_escape_string($_GET['Verfasser'])."'";
AND INSTR(name,'".mysql_escape_string($_GET['Verfasser'])."')>0";
Wie wird INSTR implementiert? Das kann eine Katastrophe
sein, weil es die Verwendung von Indexen abschalten
dürfte.
Nein, 1. ist das gut schnell wie ich finde, 2. zeigt EXPLAIN fulltext an
Laß die Finger von Substring-Operationen -
vorerst jedenfalls. Wenn Du _das_ filtern willst, tue
es in PHP - da geht es schneller.
Eben nicht!!! Ich will z,B. bei der Eijgabe von Andreas auch spalten mit "Andreas Korthaus" finden. ich will nicht alle Datensätze finden in denen Andreas Irgendwo vorkommt, sindern mit Andreas als Autor. Also braich ich eien zusätzliche Bedingung. Und da eh nur ein Index verwendet wird, kann ich auch keinen 2. Volltext-Index über diese Spalte machen, denn den eigentlichen Fulltext brauchte ich IMMER.
Wenn ich das in PHP filtern wollte, müßte ich _ALLE_ Datensätze auswählen, in denen der Suchbegriff vorkommt, und dann in PHP filtern. Damit hat doch MySQL erheblich mehr Arbeit! Aber genau solche Sachen, da bin ich halt nicht so sicher! Aber probiere es mal aus, das ist gar nicht so langsam, ich hhätte da auch gedacht, aber folgende Abfrage dauert nur 0.02 Sekunden:
http://selfarchiv.d2g.com/index.php?suchausdruck=fsockopen&Kategorie=&Verfasser=Andreas&Listing=ranking&submit=Suche+starten
mit order by time dauerrt das ganze doppelt so lange.
So langsam funktioniert es auch, ich bekomme immer dieselben Ergebnis-Zeiten, also kann ich jetzt mal ein wenig testen, und werde die Tabelle vorerst nicht verändern.
Mal ein paar Messungen:
Standard Fulltext-Abfrage: 0.004
mit ORDER BY time: 0.007
mit 2. Bedingung (=) 0.004
mit 2. Bed. und ODER BY 0.005
mit INSTR 0.004
mit INSTR und ODER BY 0.006
mit 2. Bed und INSTR 0.005
Was auffällt, so allgemein auch, das schlimmste ist order by, die Where-Bedingungen machen fast nichts aus, machmal wird es sogar noch schneller, und instr() macht nichts aus! Kannst Du aber gerne widerlegen ;-)
Gib eine Meldung aus: "Diese Suche erzeugte zu viele
Treffer - bitte geben Sie exaktere Suchbegriffe an",
wenn Dein Limit erreicht wurde.
Auch später in der Praxis? Newbies verstehen sowas sehr schlecht! Aber wäre vielleicht mal ein Weg die dazu zu bringen ;-)
Vielen Dank nochmal für die große Hilfe, ist jedesmal spannend Deine Postings zu lesen!
Viele Grüße
Andreas