Boardunity & Video Forum

Boardunity & Video Forum (https://boardunity.de/)
-   Programmierung und Datenbanken (https://boardunity.de/programmierung-datenbanken-f23.html)
-   -   MySQL Volltextsuche - Leistungsfähigkeit? (https://boardunity.de/mysql-volltextsuche-leistungsf-higkeit-t776.html)

exe 14.09.2003 14:17

MySQL Volltextsuche - Leistungsfähigkeit?
 
Moin,

ich hatte die Überlegung in diverse Scripte anstatt einer eigenen Implementierung die Volltextsuche zu nutzen die in MySQL integriert ist.
Nun hab ich das mal an einer Datenbank mit 71.000 Liedtexten erprobt und bin zu einem eher negativen Ergebniss gekommen.
Bei Suchwörtern wie "love" die 2000+ Ergebnisse geben dauert eine Abfrage bis zu 7 Sekunden. Da ich bestimmte Suchfunktionen auch auf häufig frequentierten Seiten (beispielsweise die "Ähnliche Themen" Funktion in meinem Board) nutze sind solche Suchzeiten ein bisschen viel.
Meine Frage jetzt: kennt sich jemand mit den Optimierungsmöglichkeiten der Volltextindexe in MySQL aus? Oder hab ich vielleicht einfach was falsch gemacht und die Suche ist weitaus leistungsfähiger (ich kenn mich damit noch nicht wirklich aus)?
Ich sehe halt den Vorteil das man mit dieser Implementierung eine weitaus zuverlässigere und mächtigere Suchfunktion schon fertig bekommt die auch einige durchaus praktische Funktionen besitzt (Bsp. Relevance-Ranking).

exe 14.09.2003 19:08

Code:

SELECT t.lyric_id, t.lyric_title, g.group_id, g.group_name FROM texts t LEFT JOIN groups g ON g.group_id = t.lyric_group_id WHERE MATCH(t.lyric_text) AGAINST('the unforgiven') LIMIT 0,10;
Auf MySQL 3.23.x hab ich mit einfachen Abfragen der Art bei Wörtern die mehr als 10.000 Ergebnisse gebracht haben mehrere Sekunden gebraucht.
Mit MySQL 4.0 komm ich jetzt auf 0,02 Sekunden im Durchschnitt, auch bei Abfragen mit vielen Ergebnissen. Möglicherweise lags daran das die Volltextindexe in MySQL 3 noch nicht so ausgereift waren.
Einziges Manko ist jetzt nur noch das wenn ich aus grossen Ergebnissen (>10.000) via LIMIT aus der Mitte 10 Zeilen raushole die Abfragezeit auf 0,3 Sekunden hochgeht. Aber ich denke das liegt innerhalb der Toleranzgrenze.

exe 14.09.2003 19:19

Wenn ich LIKE verwendet bekomme ich halt das Problem das ich nicht mehr nach mehreren Begriffen suchen kann, ausser ich Verknüpfe die Tabelle für jeden Begriff mit sich selbst und ich hätte keine Trefferquote mehr nach der ich das Ergebniss sortieren kann.
Naja, wenn mein Hoster endlich mal auf MySQL 4 umsattelt werd ich auf die MySQL Volltextsuche umsatteln. Inzwischen funktioniert das eigentlich ganz gut :)

exe 14.09.2003 19:38

Wenn ich den LEFT JOIN weglasse müsste ich die Abfrage halt in 2 aufspalten und das ist langsamer als wenn ich direkt einen LEFT JOIN mache, ich habs grad mal getestet.
Aber der LEFT JOIN ist ja schnell genug. Ich würde sagen eine Suchabfrage zwischen 0,02 und 0,3 Sekunden ist ok von der Geschwindigkeit her ;)

TRS 14.09.2003 21:52

Schon mal an einer Indexierung wie im vB gedacht. Dort werden alle Begriffe mit einer Mindestlänge an Buchstaben in eine Datenbank gespeichert mit der ID des entsprechenden Threads.

Bei der MySQL Abfrage wird dann diese Tabelle genutzt, und kann dann im weiteren Verlauf die Abfrage auf die entsprechenden Threads beschränken.

Könntest bei deinem Projekt dann auch beispielsweise alle Wörter mit mindestens 4 Buchstaben in eine Datenbank mit entsprecher ID des Liedtextes speichern. Dann erstmal diese Datenbank auslesen und entsprechend Fehlermeldung ausspucken oder dann die Suche auf die entsprechenden Lieder beschränken.

Akira 15.09.2003 18:10

ich stehe in wenigen tagen auch vor dem problem das ich eine mysql db habe die rand voll mit texten ist ca. 300 mb :rolleyes:


wie durchsuche ich diese datenbank am geschicktesten? mit einem suchindex wie es das zb. das vb verwendet oder ohne suchindex? was ist besser?

exe 15.09.2003 18:11

Zitat:

Original geschrieben von Reimer
Schon mal an einer Indexierung wie im vB gedacht. Dort werden alle Begriffe mit einer Mindestlänge an Buchstaben in eine Datenbank gespeichert mit der ID des entsprechenden Threads.
Ich benutze im Moment eine Wortliste in Form einer MySQL Tabelle die über eine Verknüpfungstabelle mit den entsprechenden Beiträgen/Texten verbunden wird. Funktionieren tut das prinzipiell schon, nur ist die MySQL Suche etwas mächtiger und in der Handhabung praktisch und ausserdem verbraucht der MySQL Volltext Index weniger Speicherplatz. Das ist bei kleineren Tabellen kein Problem, macht sich aber bei grösseren Geschichten deutlich bemerkbar.

ChristianDuschl 04.05.2004 00:09

mal kurz mit meiner unqualifizierten erfahrung nach was poste...
grundsätzlich ist die performance von mysql sehr stark davon abhängig, welches datenbankmodell unterliegt und auch sehr abhängig davon, welcher tablehandler eingesetzt wird (isam, bdb, etc...). db/2 ist für sowas besser geeignet.
dazu sollte gesagt werden, dass sich mysql prima einsetzen lässt, um qualifiziert auf daten zuzugreifen, sofern man die datensicherheit nicht der datenbank überlässt, aber (wie jede sql- datenbank) sich nich dazu eignet volltextsuchen zu erstellen.

es gibt ein sehr einfaches verfahren, um volltextsuchen sehr... sehr sehr schnell durchzuführen und das ist die vorindizierung. im prinzip heisst das, du gehst umgekehrt vor und erstellst bei eintrag eine wortliste, der du die einträge zuweist. meines wissens gibt es keine schnellere suchmethode, wenn man nur eine geringe anzahl von einträgen hat (<100000000). solche suchmethoden schaffen es locker in 4 ms (rechner i386 2ghtz) in 4 mio einträgen trefferlisten zu ermitteln (ich nutze selber solche methoden).

itst 05.05.2004 13:05

Christian,

sicher hast Du nicht ganz unrecht, aber der Vergleich MySql vs. DB/2 hinkt etwas, gelle ;)

Wie auch immer, die Volltextsuche in MySql 4.x ist es wert, getestet zu werden. Und bisher muss ich sagen, das ich mit den Ergebnissen durchaus leben kann. Es ist wie immer im Leben: Ein Geben und Nehmen.

Die eingebaute Volltextsuche stellt mir Funktionen bereit, die ich ansonsten händisch nachbauen müsste und arbeitet prinzipiell wie eine Vorindizierung. Im Gegenzug mag es sein, das, wenn ich 100%ige Kontrolle über meine Suchfunktion habe, ich ein paar Millisekunden schneller meine Suchergebnisse bekomme. Allerdings liegt das alles noch ein einem vertretbaren von 1 Sekunde bei einfachen und bis zu 3 Sekunden bei komplexeren Suchanfragen (über 3 Tabellen, insgesamt 10Mio. Datensätze).


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:44 Uhr.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25