nicht angemeldet
Hallo,
wie suchst Du? Nach was suchst Du? Wo ist der Flaschenhals genau?
BOOLEAN MODE, NATURAL LANGUAGE, ...?
- ca 1 Mio Datensätze
das ist nicht überragend viel. Datenbanken können mit sowas umgehen, auch MySQL.
- zu Durchsuchender Eintrag besteht aus 5 - 10 Worten (keine langen Aufsätze)
zur Suche
- Über ein Suchfeld können User einen oder mehrere Suchbegriffe (soll auf maximal 4 - 5 begrenzt werden) eingeben
- Ein Treffer soll nur geliefert werden, wenn das Suchwort mindestens einmal exakt (abgesehen von Groß/Kleinschreibung) im zu durchsuchenden String vorkommt. (-> %LIKE% ist also nicht notwendig)
- Es werden pro Seite 20 Ergebnisse angezeigt: MATCH ... AGAINST ... LIMIT 20
- Für die benötigte Seitenanzahl werden alle Treffer gezählt: kein LIMIT
Du scheinst SQL_CALC_FOUND_ROWS nicht zu kennen.
Der Flaschenhald
- Die Suche geht sehr schnell, solange unter 1000 Ergebnisse gefunden (0.005s s) werden.
- Wenn viele Ergebnisse (30.000) vorliegen wirds langsam (0.5 s)
- Es gibt viele Suchbegriffe bei denen so viele Ergebnisse vorliegen
- Bei mehreren Datenbankzugriffen pro Sekunde geht dann nicht mehr viel
was sagt das slow-query-log? Hast Du Feintuning Deiner Volltextsuche betrieben? Was sagen die MySQL-Werkzeuge zur Abfrageanalyse?
Wenn die Suche nur bei vielen Ergebnissen langsam wird, dann kann das ja an der Sortierung der Suchergebnisse nach Relevanz liegen. Je mehr, desto aufwendiger. Ich würde auch gerne die Suche begrenzen auf 1000 Treffer. Niemand will sich 30.000 Treffer anschauen. Aber bei MATCH ..AGAINST muss er ja erstmal alle finden, um die Relevanz zu berrechnen und dann zu Sortieren.
dafür ist der Volltextindex da. Du solltest natürlich von Zeit zu Zeit die Statistiken aktualisieren.
der dortige Artikel ist schlimm, die dort vorgestellte Suche unbrauchbar, siehe </archiv/2010/3/t196217/#m1314709> und </archiv/2010/3/t196217/#m1315919>. Professionell ist anders.
Du kritisierst den Artikel vorallen wegen der Komprimierung. Diese Komprimierung scheint mir jedoch einen Performancevorteil zu bringen.
Nein, natürlich nicht. Sie macht Daten kaputt. Das kann man nicht wollen.
Auch wenn dadurch die Güte der Ergebnisse verschlechtert wird.
Das ist viel schlimmer. Die Jungs haben keine Ahnung von Zeichenkodierung. Das ist erschreckend. Die Suche liefert Unsinn.
Sieht man von der schlechten Komprimierung ab, sollte die Volltextsuche doch recht schnell laufen. Oder ist sie dann weiterhin unbrauchbar? (Wieso?)
Ja selbstverständlich ist sie unbrauchbar. Schreib' ich doch dort. Es werden Selfjoins über riesige Tabellen verwendet, wenn man mehr als einen Suchbegriff verwendet. Das skaliert überhaupt nicht und ist eine Performancebremse erster Güte.
Ist die Suche schneller als die MySQL-intern volltextsuche?
Bei mehr als einem Suchbegriff und Deinem Datenbestand: ganz bestimmt nicht. Um Größenordnungen lahmer. Je mehr Suchbegriffe, um so schlimmer wird es. Nochmal: diese Suche amateurhaft zu nennen, beleidigte Amateure ...
Ist die Variante mit den 3 zusätzlichen Tabellen üblich bei der Realisierung einer Volltextsuche? Oder geht das noch Professioneller/Schneller?
a) Florian hatte im von mir verlinkten Thread ebenfalls Lucene ins Spiel gebracht.
b) Mir scheint im ersten Schritt Deine Verwendung der MySQL-eigenen Volltextsuche optimierbar.
Freundliche Grüße
Vinzenz