nicht angemeldet
MySql: Professionelle Volltextsuche
Hallo Leute,
Ich habe eine Datenbank mit ca. 1 Mio. Einträgen. Ein Eintrag besteht aus ca 5 - 10 Worten. Jetzt möchte ich in diesen Einträgen suchen. Um das zu realisieren benutze ich die MySql-Volltextsuche mit MATCH ... AGAINST. (Fulltext-index). Das klappte bisher auch recht gut. Als es zu langsam wurde hab ich am Query-Cache etwas rumgeschraubt. Dann gings wieder einigermaßen. Da sich die Zugriffe und die Datenbankeinträge weiter häufen, muss jetzt eine schnellere Suche her.
Ein grund für die recht langsame Suche ist vermutlich, dass zu einem Suchwort gut 30.000 Einträge gefunden werden. Die Sortierung von so vielen Einträgen dauert natürlich.
Ich habe überlegt ob ich selbst eine Volltextsuch realisiere wie z.B. hier vorgestellt: http://www.phpbar.de/w/Volltextsuche
Jetzt versteh ich aber nicht genau wieso diese selbst programmierte Volltextsuche schneller als die MySql-interne (Match...Against). Woduch entsteht der Performancegewinn.
Was ich brauch ist eine sehr schnelle Volltextsuche, schneller als die MySql-interne. Aber ob der Weg mit den drei zusätzlichen Tabellen (siehe Link) wirklich der richtige ist, weiß ich nicht??
Was mir bei dieser Variante auch Sorgen macht, ist die Performanceeinbuse bei mehreren Suchbegriffen. Siehe: (etwas runterscrollen) http://www.phpbar.de/w/Diskussion:Volltextsuche
Ich weiß das ist viel Zeug grad und bestimmt auch nicht das einfachste Thema, aber über ein paar Tipps bzw. Hilfestellungen würde ich mich sehr freuen. Danke schonmal!!
-
Hallo,
Ich habe eine Datenbank mit ca. 1 Mio. Einträgen. Ein Eintrag besteht aus ca 5 - 10 Worten. Jetzt möchte ich in diesen Einträgen suchen. Um das zu realisieren benutze ich die MySql-Volltextsuche mit MATCH ... AGAINST. (Fulltext-index).
Ein grund für die recht langsame Suche ist vermutlich, dass zu einem Suchwort gut 30.000 Einträge gefunden werden. Die Sortierung von so vielen Einträgen dauert natürlich.wie suchst Du? Nach was suchst Du? Wo ist der Flaschenhals genau?
Ich habe überlegt ob ich selbst eine Volltextsuch realisiere wie z.B. hier vorgestellt: http://www.phpbar.de/w/Volltextsuche
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.
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz
wie suchst Du? Nach was suchst Du? Wo ist der Flaschenhals genau?
zur Datenbank
- ca 1 Mio Datensätze
- 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
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
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.
Was vielleicht noch wichtig ist, ist dass sich die Anzahl an verschiedenen Suchbegriffen die Sinn machen auf, ein paar Tausend begrenzt. Nun könnte ich alle Query im Query-Cache speichern. Allerdings wird die Datenbank alle 60 min erweitert. Dadurch wird der Query-Cache wieder gelöscht.
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. Auch wenn dadurch die Güte der Ergebnisse verschlechtert wird.
Sieht man von der schlechten Komprimierung ab, sollte die Volltextsuche doch recht schnell laufen. Oder ist sie dann weiterhin unbrauchbar? (Wieso?)
Ist die Suche schneller als die MySQL-intern volltextsuche?
Ist die Variante mit den 3 zusätzlichen Tabellen üblich bei der Realisierung einer Volltextsuche? Oder geht das noch Professioneller/Schneller?Grüße
immi
-
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
-
Ach ja, und vielen Dank für die Antwort! :)
-
-
-
Hallo,
schaumal hier, vielleicht ist das interessant für dich.
Sipatshi
siehst auf den ersten Blick sehr interessant aus!
Danke!
-