nicht angemeldet
Hi andreas,
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 ;-)
Dann ist Deine Maschine offenbar doch ziemlich langsam.
Meine Erfahrungen stammen allerdings von einem SUN-
Server mit 4 GB RAM und mehreren CPUs ... der schlägt
sich bei dieser Aufgabenstellung großartig.
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.
Wieviel RAM hast Du mySQL zugeordnet? 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.
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!
Hast Du /ver/tmp auf einer RAM-Disk liegen?
Hast Du mal mit iostat gemessen, ob Du während eines
lesenden Zugriffs auf den FULLTEXT-Index Schreibzu-
griffe (!) auf eine Festplatte hast?
Sehr gute Idee. Sollte man denn nicht lieber die
Indices zusammenlegem, ich meine jetzt im
allgemeinen, oder lieber enzelnde?
Dazu müßtest Du eine entsprechende Messung machen.
Du kannst natürlich in die Posting-Spalte einen belie-
bigen String Eintragen - da dürfen auch die anderen zu
indexenden Felder drin stehen, da Du ja später nicht
den eigentlichen Inhalt des Thread aus dieser Spalte
füttern, sondern statt dessen auf das Original linken
wirst.
Aber warum braucht der themenbereich keien Volltxt-
index?
Das kommt darauf an, wie Du auf ihn zugreifst.
Eine normale relationale Datenbank kann pro Query nur
einen einzigen Index nutzen - und das wird bei Dir
immer der FULLTEXT-Index sein, sofern ein Suchbegriff
angegeben war (und Suchvorgänge ohne Suchbegriff sind
in Deinem Konzept derzeit ja wohl nicht vorgesehen).
Deshalb bringen weitere Indexe bezüglich der Lese-
performance erst mal nichts - wenn mySQL durch den
FULLTEXT eine Tabellenzeile ausgewählt hat, kann es
relativ schnell deren Inhalt abgreifen und darin das
Feld mit dem Themenbereich prüfen.
Ich denke hier könnte man doch was draus machen,
natütlich nicht mit den Standards von mySQL 3.23,
aber so allgemein!
mySQL 4.0 kündigt mir nichts an, was die Funktionalität
oder Architektur Deiner Suche signifikant ändern würde.
Bedenke auch, dass du bei einer Abfrage über den
Volltextindex eine Relevanzangabe erhälst, die du
nutzen kannst ...
Ja, das ist wirklich gut. Nur was mich stört, die
kleinen Beiträge, mit wenig drin stehen ganz oben,
das ist IMHO falsch!
Lies mal im mySQL-Handbuch nach, wie diese Relevanz
berechnet wird.
Wie würdest Du es tun, wenn Du gar keine Ahnung hast,
was die Postings bedeuten? Über die relative Häufigkeit
des Wortes innerhalb des Textes. Und die ist bei kurzen
Postings natürlich höher als bei langen. Ergo: Verwirf
diese Idee, sie bringt Dich hier nicht weiter.
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?
Schreib Dir ein Konzept dafür. Ignoriere völlig, wie Du
es implementieren müßtest.
Definiere eine "gute" Ranking-Funktion. Wie man diese
dann umsetzt, soll Dich vorerst nicht interessieren.
Aber mydql hat doch auch eine statische Liste, udn
die iszt englische. Ich meine nur hierfür als
Pendant!
Und welche Worte würdest Du auf diese Stopwortliste
setzen? Ich habe mir dafür ein Konzept ausgedacht -
das ist aber auf meine Art von Daten bezogen.
Wobei ich gestehen muß, Ihr hattet Recht,
so viel schneller ist die DB auch nicht,
Gib nicht so schnell auf. Deine Lösung wird andere (!)
Stärken oder Schwächen haben.
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...
Poste doch mal die exakten SQL-Statements. Und schalte
die Verwendung der impliziten Rating-Funktion ab - die
kostet nämlich viel Zeit! Und gib die Treffer erst mal
unsortiert aus - sortieren kostet entsetzlich viel Zeit
bei vielen Treffern.
Aha! :) Wie du siehst, ist auch eine Datenbank-
lösung nicht endlos überlegen - mehr Performance
kriegt man also nur über schnellere oder
parallele Maschinen.
Sven, dem stimme ich nicht zu. Der Haupteffekt der
Datenbank ist die Verwendung einer logarithmischen
statt einer linearen Suche - das bringt bei den vor-
liegenden Daten wahrscheinlich mindestens eine Zehner-
potenz.
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!
Inkrementelles Indexing ist nicht das Problem.
Da gibt es durchaus noch ein paar Tricks.
Beispielsweise: Halte eine _zweite_ Datenbank im Hin-
tergrund, welche dieselben Postings enthält, und baue
für _diese_ den Index täglich neu, in einer via 'nice'
niedrig gescheduleten shell. Während dieses Aufbaus -
der via cron in den frühen Morgenstunden läuft - kann
die andere Datenbank online verfügbar sein.
Danach lasse Dein CGI-Frontend dynamisch bestimmen,
welche der beiden Datenbanken gerade die aktuelle ist -
es reicht, wenn Dein Indexer ein stub file entsprechend
setzt.
Ich selbst verwende dies an einer anderen Stelle, wo
ich tatsächlich die Indexe täglich neu baue (mit noch
viel mehr Einträgen, fast 20 Millionen Stück).
Bei dem, was Deiner Posting-Suche ähnlicher ist, indexe
ich aber inkrementell - und verbrauche täglich bei 5000
neuen 'Postings' nicht mal eine CPU-Minute.
mySQL 3.23 ist toll, wenn man gute Hardware verwendet.
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.
Richtig - weil auf Teile des FULLTEXT-Baumes zugegrif-
fen wird, die beim zweiten Mal noch in irgend einem
Cache liegen.
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.
Das ist bei Deiner Suche genauso. Der Cache ist ja
irgendwann auch mal voll.
Bei der logarithmischen Suche und den Indices ist
das was anders, die DB merkt sich jede Suche!
"Jede" nicht.
Ich bin fest davon überzugt das sich das bei höherer
Belastung sehr positiv auswirkt!
Deine Suche muß schon beim ersten Zugriff schnell sein.
Du kannst nicht erwarten, daß die Anwender ähnliche
Suchbegriffe eingeben - und Dein RAM ist auch sehr
begrenzt.
Viele Grüße
Michael