[Mysql] Volltextsuche

[Benny]

Huhu Junx,

hab mich eben mal bissi mit der Volltextsuche von MySQL informiert. Dabei ist es ja leider nur möglich nach ganzen Wörtern zu suchen und nicht nach Wortteilen. So, nun könnt ich vorher den Such-Query auswerten und das ganze mit like-Operatoren lösen. Was denkt ihr davon ? Wäre dann eine Suche mit 1-2 Stichwörtern über 3 Spalten (1x varchar, 2 text) von ca. 300 Datensätzen. Die Geschwindigkeit ist denk ich mal noch verträglich.

Leider hab ich leider auch eine Datenbank in der ich in 360.000 Datensätzen suchen muss.

Habt ihr vielleicht irgendwelche Lösungsansätze für eine Volltextsuche mit Teilbegriffen ?

Wäre euch zutiefst dankbar

greets,
Benny

[RFZ]

Huhu Junx,

Moin,

Leider hab ich leider auch eine Datenbank in der ich in 360.000 Datensätzen suchen muss.

Ich hab auch eine Volltextsuche mit 90.000 Datensätzen und kenne das Problem. Früher hab ich auch mit LIKE gearbeitet, da es besser an meine Bedürfnisse anzupassen war, aber irgendwann wurde es einfach zu langsam. Ich hab heute auch mit der Volltextsuche schon ab und zu Suchzeiten über ein paar Sekunden...
Leider kenne ich keine Lösung... wär aber auch an einer interessiert :)

Benny

cu RFZ

[Philipp Hasenfratz]

Halihallo Benny

hab mich eben mal bissi mit der Volltextsuche von MySQL informiert. Dabei ist es ja leider nur möglich nach ganzen Wörtern zu suchen und nicht nach Wortteilen. So, nun könnt ich vorher den Such-Query auswerten und das ganze mit like-Operatoren lösen. Was denkt ihr davon ?

Ich halte es für eine sehr schlechte Lösung, da sie keineswegs skalierbar ist. Falls
deine Datenbank mal mehr als 360.000 Datensätze hat, wirst du mit erheblichen
Performanceeinbussen zu rechnen haben. Der LIKE-Operator (mit beginnendem %) erzwingt
_immer_ einen Fulltable-Scan, das heisst: die ganze Datenbank muss Byte für Byte
durchsucht werden. Geht man von einer durchschnittlichen String-Länge von 200 aus,
braucht mysql ca. 360.000*(200-<query-word-length>) Stringvergleiche (von guten Text-
Matching-Algorithmen abgesehen). Es ist unschwer vorzustellen, was dies bei einer
Milliarde Datensätzen für die Performance bedeutet. Für eine derartige Fulltext-Suche
_braucht_ es umbedingt einen Index, wenn die Lösung skalierbar sein soll.

Das Problem ist, dass du bei einer Suche nach einem Wortteil weder einen Fulltext- noch
einen anderen Index verwenden kannst. Die einzige Lösung wäre einen eigenen Index dafür
zu programmieren.

Geht man ganz allgemein von einem Dokument aus, dessen Wörter indiziert werden sollen und
zwar so, dass auch nach Wortteilen gesucht werden kann, müsste man einen Index über alle
Wortteile erstellen. Nehmen wir z.B. das Wort "Computergehäuse", müssten die Strings:
"Computergehäuse", "omputergehäuse", "mputergehäuse", "putergehäuse", ... indexiert
werden. Falls dann jemand nach "pute" sucht, wird u.a. auch "putergehäuse" respektive
"Computergehäuse" gefunden und zwar unter Verwendung des Index. Da ein derartiger Index
sehr, sehr viele Wörter und Wortteile enhalten würde, würde es die Kapazität einer
Festplatte wohl sehr schnell sprengen. Die Datenmenge des Index liesse sich zwar über
einige "Regeln" einfach verkleinern, jedoch wäre auch diese Lösung nicht skalierbar.
Es scheint so, als ob wir die Skalierbarkeit bzgl. Performance damit lösen könnten, nicht
jedoch im Hinblick auf die Speicherkapazität. Aber auch hierfür gibt es einige Lösungen:
Wir müssen zwar jedes Wort und jedes Teilwort indexieren, aber warum denn das ganze?
Für die Performance wäre ein Indexieren der ersten fünf Bytes wohl völlig ausreichend,
denn dann hätten wir die Fulltextsuche bereits auf alle (Sub-)Strings beschränkt, die
in den ersten fünf Bytes übereinstimmen, diese stark verkleinerte Ergebnismenge können
wir dann immer noch mit dem langsamen LIKE-Operator durchsuchen. Die gesamte Datenmenge
mit LIKE zu verarbeiten ist jedoch eine Katastrophe.
Nun gut, auch ein Index über die ersten 5 Bytes eines jeden Substrings artet in
höllischem Speicherverbrauch aus. Aber wenn wir davon ausgehen, dass ein Index absolut
notwendig ist, ist es ggf. ein guter Kompromiss. Durch einiges Feintuning liesse sich
die Datenmenge bestimmt verkleinern.

Ob sich jedoch ein eigener Fullindex wirklich lohnt halte ich für fraglich. Die
wesentlich bessere Lösung wäre eine Art Wörterbuch, durch dessen Hilfe man die Teilwörter
aus einem Wort extrahiert und diese dann einzeln indexiert. Das wäre eine geniale
Lösung, aber leider bräuchte man dieses "Wörterbuch" und das ist kontrollierter
Wortschatz und somit an Handarbeit gebunden (+Sprachabhängig). Natürlich könnte man da
nicht nach "put" suchen und bekommt "Computer" als Teil des Ergebnisses, aber wäre das
denn wirklich Sinn der Suche? - Meiner Meinung nach nein.

Was meinen andere zum Thema?

Wäre dann eine Suche mit 1-2 Stichwörtern über 3 Spalten (1x varchar, 2 text) von ca. 300 Datensätzen. Die Geschwindigkeit ist denk ich mal noch verträglich.

Was soll das bringen?

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

Ich halte es für eine sehr schlechte Lösung, da sie keineswegs skalierbar ist.

Wieso? Es skaliert doch wunderbar, sogar fast vollkommen linear, oder? ;-)
Davon träumt doch so mancher "Skalierer" ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Ich halte es für eine sehr schlechte Lösung, da sie keineswegs skalierbar ist.
Wieso? Es skaliert doch wunderbar, sogar fast vollkommen linear, oder? ;-)
Davon träumt doch so mancher "Skalierer" ;-)

:-)   Manche Sachen lassen sich jedoch logarithmisch viel, viel besser abbilden :-)

Viele Grüsse

Philipp