nicht angemeldet
Hi Andreas,
Wenn ich in die bestehende Tabelle jetzt einen Monat mit ca. 3000 Datensätzen einfüge, dauert das merh als 30 Minuten, ohne Index geht das unter 1 Minute!
klar. Der reine Importer muß ja praktisch nicht denken
- der Indexer dagegen hat einen Haufen zu tun.
Meine Erfahrungen stammen allerdings von einem SUN-Server mit 4 GB RAM und mehreren CPUs ... Ja, das ist kein Wunder! Ich habe eien AthlonXP 2000 und 256 MB DRR RAM, da sollte ich bei gelegenheit
Deine CPU ist immerhin viermal schneller getaktet als meine ...
bdb_cache_size 8388600
Den BDB-Treiber benutzt Du nicht - das kannst Du vermutlich auf 0 setzen.
myisam_sort_buffer_size 8388608
Wenn ich mich recht erinnere, dann ist das hier der Kandidat für die CREATE INDEX-Statements. Wenn Du zuerst importieren und dann indexen willst, dann gib hier alles, was Du kannst.
War das alles oder gibts da noch interessante Dinge?
Hm, das ist lange her, daß ich diese Liste mal durch- gearbeitet habe - und alles habe ich damals auch nicht verstanden.
Und wie ich es auch sehe kann man mit anders kompilieren... unter Linux eh nicht mehr so viel rausholen, wichtiger wäre es eine optimale Datenstruktur und optimale Abfragen zu bekommen
Ja. Bei den Tabellen sieht es schon sehr gut aus, finde ich. Die mySQL-Tuning-Parameter kenne ich nicht gut genug, das macht ein Kollege von mir im Büro ...
Wie groß ist die Indexdatei, die für Deine Tabelle erzeugt werden muß? Wenn diese nicht in den RAM paßt, wird die Sache sehr viel langsamer. Welche Index-Datei jetzt? Es werden ja merhere Dateien zu einer Tabelle angelegt,
Haben wir verschiedene mySQL-Implementierungen? Zu jeder Tabelle gibt es drei Dateien:
- *.frm: Das CREATE TABLE-Statement.
- *.MYD: Die Tabellen-Daten.
- *.MYI: Alle (!) Indexe.
und die Tabelle hat jetzt schon über 100 MB, dazu kommt ein 60MB Index, nur Fulltext und Primary.
Aha. Schaffst Du es, den Sortier-Puffer auf mehr als diese 60 MB aufzublasen? Dann ist zuerst INSERT und danach CREATE INDEX ziemlich schnell. Andernfalls ertrinkst Du bei dieser Methode in Disk-I/O.
Hast Du /ver/tmp auf einer RAM-Disk liegen? Du meinst /var/tmp?
Ups - das war aus dem Gedächtnis zitiert und sollte wohl eher /var/log heißen - kann bei Dir aber anders konfiguriert sein. In meinem Falle war es so, daß ich temporäre Objekte angelegt habe und mySQL die in dieses Verzeichnis geschrieben hat - in der sicheren Erwartung, dort eine RAM-Disk vorzufinden ... was bei uns aber nicht der Fall war ...
Ich überlege aber, da mit 4 GB für Windows auch zu wenig ist, ob ich nicht noch eine bessere Platte kaufe, so eine ATA 133 mit 7200 UPM und Zugriff- zeiten unter 8 ms,das wäre hier glaube ich ange- bracht
Ich weiß nicht, was Du investieren kannst.
Aber RAM ist für eine so spezielle hochperformante Anwendung praktisch durch nichts zu ersetzen - auch nicht durch eine teure Festplatte. 512 MB RAM kosten für einen modernen Bus so um die 150 Euro ...
Wer oder was ist "iostat"? Kenne ich nicht und es ist nichts mit dem Namen installiert.
Gnlpfts. Wieso ist UNIX eigentlich nicht gleich UNIX? (Bei mir gibt es dieses Kommando sowohl unter AIX als auch unter Solaris.)
Außerdem sind die lesenden Zugriffe sehr schnell, da kann ich kaum gleichzeitig schreiben und das noch messen... wie geht das?
iostat ist ein Systemkommando, welches die Zugriffe auf alle Devices periodisch auflistet. Ich habe bei Performancetests eine Shell offen, wo ich damit zu- sehe, was ich an Last auf das System werfe.
"top" ist ein vergleichbares, aber anderes Tool, das eher die CPU-Last beschreibt, aber beispielsweise auch die IOWAIT-Quote anzeigt.
Das ist halt komisch, ich kann da überhaupt gar keinen roten Faden finden. Mal dauert das 0,03 und mal 13.
Das kommt darauf an, ob Du auf den RAM oder auf eine Festplatte zugreifst. ;-)
Was ich nur nicht weiß, ich habe das Gefühl, normal der Fulltext Index und dessen Abfrag ist sehr schnell, wie ist es denn wenn ich "normale WHERE- BEdingungen damit kombiniere, so wie ich das zur Zeit mache, ist das perfromance-mäßig egal?
FULLTEXT generiert eine Menge von Zeilen-IDs in irgend einem Puffer - im Index steht ja nur eine Referenz auf die eigentliche Tabellenzeile drin. Jeder dieser Treffer muß nun dazu genutzt werden, die entsprechenden Felder aus der eigentlichen Tabelle zu fischen - je mehr Spalten, um so mehr Daten sind zu holen. Benötigt werden dabei alle Felder, die in der SELECT-Liste oder in einer WHERE-Klausel auftauchen. Anschließend werden die restlichen WHERE-Klauseln gegen diese Felder ausgewertet - deren Größe ist also durch- aus wichtig (ein LIKE %term% gegen die komplette Po- sting ist hier teuer, deshalb muß die Treffermenge hinreichend klein sein).
Oder sollte ich lieber mehrere Fulltext-Indices und die dann abfragen? Ich habe in der Tat ein Problem damit vergleichbare Daten zu bekommen. Die gleiche Abfrage kann 100 mal so lange dauern, k.A. warum. Halt wenn der Index diffus ist und das System durch andere Prozesse etwas ausgelastet ist, vielleicht ist auch die kleine Platte fast voll... ich weiß es nicht.
Miß mit "top" oder irgendwas in der Art die IOWAIT- Quote während Deiner Abfragen. Besitzt Du mehrere Festplatten? Wenn ja: Kannst Du die Daten- und die Index-Datei Deiner Tabelle auf verschiedene Festplatten legen (per symbolic link)? In diesem Falle würdest Du verhindern, daß bei einem umfangreichen Zugriff auf sowohl Daten als auch Index- blöcke der Lesekopf der Festplatte ständig hin- und her positionieren muß ... das würdest Du dann an einer hohen IOWAIT-Rate erkennen können. Deine CPU ist sehr schnell - die sollte nicht von Deiner Platte ausgebremst werden.
btw, kennst Du einen Befehl der einem anzeigt wieviel Platz noch auf einer Platte/Partition zur Verfügung steht, möglichst in Byte?
"df -k" ?
Und man verwendest immer nur einen Index? Man könnte denselben Index mit mehreren Wörtern ja auch mehrmals abfragen
Ich vermute, das macht mySQL auch, wenn Du ein AND über mehrere MATCHes desselben FULLTEXT-Index machst. (Das müßte Dir EXPLAIN dann eigentlich auch so zeigen.)
$query = SELECT... WHERE"; foreach(explode("+",$suchstring) as $suchwort){ $query .= " match... against($suchwort)"; } mysql_query($query); So in etwa, was sagst Du dazu?
Entscheidend ist, was EXPLAIN dazu sagt. ;-)
- die Vielposterstatistik, ich weiß, hört sich dumm an, aber wenn viele Leute aus den oberen Regionen in einem Thread schreiben ist der meist sehr interessant, warum also nicht diese Informa- tion für ein Ranking nutzen???
Verfeinere auf separate Vielposterstatistiken pro Kategorie. Meine "Expertise" für SERVER gegenüber JAVASCRIPT unterscheidet sich um Zehnerpotenzen. ;-)
- höhere Gewichtung des Titels
Ja, gefällt mir. Hat aber den Nachteil, daß es vom Suchbegriff abhängt, also zur Laufzeit berechnet werden muß. Die Vielposter-Kennzahl kann zur Import- zeit berechnet werden, und Du kannst die Ergebnisse direkt per ORDER BY danach sortieren!
- Noch höhere gewichtung der Kategorie
Unwahrscheinlich, daß das jemals etwas bewirkt.
- Vorkommen im Autoren-Feld
Da würde mir die in der bisherigen Suche vorhandene Möglichkeit, einzelne Terme gezielt nur in einzelnen Feldern zu suchen, besser gefallen. Ich will früher projezieren, um später weniger sortieren zu müssen.
- Die Zeit, neuere Threads ein wenig besser bewerten
Ack.
Und vielleicht eine Checkbox"ich habe in dem Thread gepostet", wenn man das später mit einem Forum-Login verbindet wäre das zumindest für mich ganz interessant!
Das ist implizit eine weitere WHERE-Klausel über den Author - erfordert aber, daß das Formular weiß, wer mit "ich" gemeint ist. (Login?)
Das Problem bei Fullteyt besteht unter anderem auch darin, dass wenn ich sortieren will und die Abfrage ein Limit enthält kommen da je nach Sortiereung, ganz anderer Daten bei raus!
Wenn Dein Limit zuschlägt, dann ist ohnehin schon etwas schief gegangen: Dann hast Du vielleicht schon die be- sten Treffer ignoriert.
und was da noch so stand. Konnte man hier nicht auch irgendwo den Minimum-Wert für Suchwörter von 4 verändern?
"Diese Eigenschaft des FULLTEXT-Index der myISAM-Tabel- len von mySQL wird durch die Konstante MIN_WORD_LEN in der Datei myisam/ftdefs.h der mySQL-Quelltext-Distri- bution festgelegt."
Aber wenn ich ein Limit in der Abfrage einfüge, und einfach wahllos Datensätze zurück bekomme, halt wenn mehr als das Limit gefunden werden, dann ist das doch wirklich "ungünstig"!
Deshalb mußt Du den Anwender zwingen, so lange weitere Begriffe anzugeben, bis Du alle Treffer hinreichend schnell berechnen kannst.
Das mache ich immer gleichzeitig, sollte ich nicht machen, aber da meien EDV-Kenntnisse noch immer recht beschränkt sind, kann ich nicht sagen "alles ist möglich"!
Doch, kannst Du. ;-)
Wenn Du ein gutes Konzept für die Aufgabenstellung hast, mit Prioritäten für die einzelnen Anforderungen, dann kannst Du damit zu einem Spezialisten gehen, der an jede Deiner Anforderungen einen Haken machen, sie durchstreichen oder Dir die Kosten der Implementierung erklären kann. Denn die Art der Implementierung ist eben nicht die Aufgabe der Spezifikation. Umgekehrt kann Dir dieser Spezialist aber nicht Deine Aufgabenstellung schreiben, weil es Deine Aufgaben- stellung ist - eine sehr subjektive Angelegenheit also.
Definiere eine "gute" Ranking-Funktion. Wie man diese dann umsetzt, soll Dich vorerst nicht interessieren. Wenn ich das alleine mache schon ;-)
Beim Schreiben Deiner Aufgabenstellung kann ich nicht mithelfen - beim Umsetzen schon, wie Du siehst.
Das weiß ich auch nicht. Wäre es eigentlich nicht viel schlauer, diese Worte anstat mit einem Stop- Word-Liste zu filtern, diese zu entfernen?
Dann findest Du sie auch in Phrasen nicht mehr ...
Das sollte kein Problem sein und könnte die Suche entlasten. Problematischer wird es dann wieder bei der Phrasensuche, ob sich das kombinieren läßt?
Nein, fürchte ich. Was weg ist, ist weg.
Du siehst, das ist ein trade-off. Aufgabe Deiner Spezifikation ist es, Dich zu entschei- den, was von beidem Dir wie wichtig ist - ob und wie es vereinbar ist, das entscheidet die Implementierung.
Aber das schlimmste ist die Beschränkung auf Worte über 3 Buchstaben!
Siehe oben: Eine Zeile ändern und mySQL neu übersetzen.
Die Relevanz wid doch immer ausgerechnet, wie soll ich das abschalten?
Ich dachte, die Relevanz wird nur dann ausgerechnet, wenn Du die Bewertungsfunktion in der SELECT-Liste hast. In diesem Fall wird dann auch implizit nach diesem Feld sortiert, selbst wenn Du kein ORDER BY angegeben hast.
Was meinst Du mit "stub file"? Eine Datei in die Du den Status schreibst, welche DB gerade verwendet wird?
Eine Datei, deren Name diesen Status ausdrückt.
Ich will sie gar nicht öffnen müssen (und das Betriebs- system erst mal die Berechtigung dafür prüfen lassen)
- nur ihre Existenz abfragen. Das geht am schnellsten.
Wie kann ich denn den Cache so groß wie möglich bekommen?
Über die mySQL-Konfigurationsdirektiven.
Und wie kann ich das objektiv testen ...
Durch wechselnde Suchbegriffe - und zwischendurch ei- nen Neustart des mySQL-Daemons, wenn Dir die Beispiele ausgehen.
Viele Grüße Michael