Wie funktioniert das hier bei diesem Board

**Troublegum** · 20.03.2002, 21:07

Der Index läuft über die mysql Datenbank.
Es gibt eine sog. Wordlist - eine Tabelle, in der jedes Wort mit Key definiert ist.
In einer zweiten Tabelle werden nun die Wörter den Treffern zugeordnet - also Wort Nr. 2 kommt im Beitrag Nummer 3 vor.

Das Indexieren (heißt das so) dauert nicht so lange (wenn man davon ausgeht, dass immer nur ein Beitrag indexiert wird) - es wird halt jedes Wort des neuen Beitrags gespeichert, falls es nicht schon vorhanden ist, und dann in dem Beitrag zugeordnet.
Wenn du aber 50.000 Beiträge am Stück indexieren musst (neuinstallation oder so), dann musst du mit Rechenzeiten von ein paar Stunden rechnen. mein AMD 400 Mhz hat zum Indexieren von 100 MB Texten (80.000 DS) rund 3 Stunden gebraucht
Eher problematischer ist das löschen eines Beitrags.
Ich hab da die Erfahrung gemacht, dass das u.U. schon relativ lang dauern kann.

Schade ist halt, dass keine Suche nach einem ganzen String möglich ist - man muss die Query halt zerhacken.

Brauchst du noch mehr Informationen ?

**Thommy** · 22.03.2002, 00:07

Hi,

erstmal riesen Dankeschön für die Info!! Na wenn immer nur der eine Beitrag indeciert wird - dann kann es ja eigentlich nicht so lange dauern, das stimmt wohl. Aber wieso dauert's beim Löschen dann länger? Im Prinzip muss er ja dann auch nur für alle Wörter des zu löschenden Beitrags beim Index die Anzahl der Vorkommen im Beitrag abziehen. Oder hab ich wieder mal irgendeinen Denkfehler?

Gruss

Thommy

**Troublegum** · 22.03.2002, 12:17

Im Prinzip muss er ja dann auch nur für alle Wörter des zu löschenden Beitrags beim Index die Anzahl der Vorkommen im Beitrag abziehen.

Ne, so geht das nicht.

Für jeden Beitrag, in dem ein Wort vorkommt, wird ein weiterer Eintrag vorgenommen.

Mal ein Beispiel:
Wortliste
1 => Haus
2 => Möbel
3 => Video
4 => Film
5 => Homecinema

Index
Wort 1 => Beitrag 1
Wort 2 => Beitrag 1
Wort 3 => Beitrag 2
Wort 4 => Beitrag 2
Wort 5 => Beitrag 2
Wort 1 => Beitrag 2

Haus kommt sowohl in Beitrag 1 als auch in Beitrag 2 vor.
Beim löschen von Beitrag 2 wird nur der Index geleert.
Also DELETE FROM INDEX WHERE BEITRAG=2

Also beim löschen eines Beitrags merkst du keine Geschwindigkeitseinbrüche. Hast Recht - aber wenn du ein ganzes Forum mit ein paar Tausend Beiträgen auf einmal löschst, dann schon.

Komischerweise hat mein 400er AMD schon ein paar Probleme damit. Ich hab das Prinzip auch auf eine andere Datenbank als ein Forum angewendet (Text Datenbank) und da dauerts irgendwie viel länger - vielleicht, weil es immer sooo viele Wörter pro Text sind

Aber theoretisch sollte es keine Probleme geben.

**Thommy** · 22.03.2002, 15:36

Achso!

na dann bin ich ja erstmal beruhigt, was meinen Volltext - index angeht. Danke nochmal für Deine Hilfe

Ich hab aber mal och ne Frage zu Indexen allgemein:
Nach meiem jetzigen Verständnis ist es um einiges schneller per UPDATE etwas in der DB zu ändern (zumindest, wenn in der Where-clause ein indiziertes Feld angeben ist) als per INSERT / DELETE einen Datensatz neu anzulegen / zu löschen, weil bei UPDATE eben keine Index - Änderung erforderlich ist. Kann mir einer sagen, ob bei Tabellen (mit zb. 50.000 Datensätzen ) die Indizierung ne zeitraubende Geschichte (mal nur für integer - Felder angenommen) ist oder ist das eher vernachlässigbar gering?

Achja mir fällt gerade nochwas ein, aber vielleicht weiss es ja einer. Wenn ich mit mysql+Fulltext nach Wörtern suche müssen diese ja mind 4 Zeichen lang sein, wodurch Abkürzungen (wie SAP, VW ...) untern Tisch fallen. Gibt es ne Möglichkeit das zu unterbinden - also ohne LIKE - Operator (der braucht einfach zu lange)

Danke und Gruss alle

Thommy

**Troublegum** · 22.03.2002, 20:38

Ich hab aber mal och ne Frage zu Indexen allgemein:
Nach meiem jetzigen Verständnis ist es um einiges schneller per UPDATE etwas in der DB zu ändern (zumindest, wenn in der Where-clause ein indiziertes Feld angeben ist) als per INSERT / DELETE einen Datensatz neu anzulegen / zu löschen, weil bei UPDATE eben keine Index - Änderung erforderlich ist.

Sorry, ich hab ein paar Verständnisprobleme.
Beim Indexieren (wir gehen von einem komplett leeren Index aus), brauchst du keine DELETE oder UPDATE Queries.
Du musst jedes Wort des Textes durchgehen, es evtl. in die Wortliste einfügen und in den Index schreiben.

Wenn das Wort schon in der Wortliste ist, wunderbar.
Einfach alle schon existierenden Wörter mit INSERT IGNORE oder REPLACE INTO in den Index einfügen.
Wenn das Wort nicht existiert, mit INSERT IGNORE (ist ja Unique) die neuen Wörter einfügen.
Mit INSERT () SELECT * FROM WORTLISTE WHERE wort IN (gerade eingefügte Wörter) ( also ein Subselect).

UPDATE oder DELETE Queries kommen höchstens zum Einsatz, wenn du einen bereits indexierten Text änderst.
In dem Fall würde ich einfach den Text aus dem Index löschen und den geänderten Text neu indexieren.
Ich wüßte auch ehrlich gesagt gar nicht, wie du das mit UPDATE machen willst. Mit DELETE müsstest du dann ja eh alle Wörter löschen, die im Text nun nicht mehr vorkommen (geändert).
Ich finde es einfacher, wenn du erst den Text aus dem Index löschst und dann neu Indexierst. So musst du nicht überprüfen, ob ein Wort weggefallen ist.

Kann mir einer sagen, ob bei Tabellen (mit zb. 50.000 Datensätzen ) die Indizierung ne zeitraubende Geschichte (mal nur für integer - Felder angenommen) ist oder ist das eher vernachlässigbar gering?

Hm. Für Integer Felder ? Das ist doch wieder was ganz anderes.
In ein Integer Feld passt ja nur eine Zahl. Da dürfte das natürlich schneller gehen, als für viele einzelene Wörter.
Aber wo hast du Integerfelder, die unbedingt so indexiert werden müssen ? Reicht da nicht der mySQL Index ?
Also ich schätze mal (kein Verlass), dass du für 50.000 Zahlen höchstens ein paar Sekunden oder Minuten brauchst. (Timeout ist ja egal - wird ja nicht alles in einem Stück gemacht).

Achja mir fällt gerade nochwas ein, aber vielleicht weiss es ja einer. Wenn ich mit mysql+Fulltext nach Wörtern suche müssen diese ja mind 4 Zeichen lang sein, wodurch Abkürzungen (wie SAP, VW ...) untern Tisch fallen. Gibt es ne Möglichkeit das zu unterbinden - also ohne LIKE - Operator (der braucht einfach zu lange)

Wieso müssen die mindestens 4 Zeichen lang sein ? Versteh ich nicht ganz. Sorry.
Wenn du mit WHERE wort IN (Suchwörter) suchst, brauchst du keinen LIKE Operator. Dann kannst du aber keine Platzhalter benutzen, glaub ich. Kommt drauf an, für was du deine Suche brauchst. Aber warum braucht der Like Operator einfach zu lang ?
Erst die Wörter identifizieren/auslesen und dann über die IDs die Beiträge finden. Dürfte doch recht flott gehen ? Oder liege ich falsch ?

MfG Troublegum

**Thommy** · 22.03.2002, 21:41

Hi Troublegum,

ich glaube wir haben gerade ein bisschen aneineander vorbei geredt. Sorry ich hab mich wohl wieder mal zu unverständlich ausgedrückt. - Ich probiere es halt nochmal.

Ich hab aber mal och ne Frage zu Indexen allgemein:
Nach meiem jetzigen Verständnis ist es um einiges schneller per UPDATE etwas in der DB zu ändern (zumindest, wenn in der Where-clause ein indiziertes Feld angeben ist) als per INSERT / DELETE einen Datensatz neu anzulegen / zu löschen, weil bei UPDATE eben keine Index - Änderung erforderlich ist.

Was ich damit eigentlich fragen wollte bezog sich nicht auf einen Voltext-Index, sondern vielmehr auf Indexe von integer-spalten (also zum Beispiel autmatisch hochzählende oder sonstige Schlüsselspalten zwischen Tabbellen). Und meine Frage war nun, ob nun eine insert/delete - Anweisung generell länger benötigen als eine update - Anweisung. Weil ja bei insert / delete die indizierten Spalten (zumindest die eines automatisch hochzählenden Primärschlüssels) der tabelle geändert werden müssen, während bei einer update - Anweisung ja nur ein bereits bstehender Datensatz geändert wird und somit der indizierte Primarschlüssel nicht neu indiziert werden muss. Gleiches gilt für Schlüsselfelder (zwischen mehreren Tabellen) - zumindest sofern diese nicht durch den update betroffen sind)

Und meine Frage diesbezüglich war halt, ob nei großen Mengen an Datensätzen die Indizierung des Primäschlüssel/Schlüsselfelder sehr zeitraubend sind, wenn man einen Datensatz hinzufügt oder löscht?

Wieso müssen die mindestens 4 Zeichen lang sein ? Versteh ich nicht ganz. Sorry.

Also das Buch, welches ich gerade in der Hand habe sagt mir, dass bei myql Die Suche per Volltextsuche mind.4 Zeichen lang sein muss.

Zitat
"Wörter müssen mind. 4 Zeichen lang sein, damit sie berücksichtigt werden. Das macht die Such enach Abkürzungenn wie SQL unmöglich "

???

WHERE wort IN (Suchwörter)

Bei der Anweisung wird doch meines Wissens ein kompletter Zeichenkettenvergleich der gesamten Spalte "wort" gemacht, oder??
Bei einer Grossen Tabelle dauert das doch ewig, oder etwa nicht??

Ok, ich hoffe mal - ich war ketzt ein bisschen verstänlicher :-)

Nochmals Danke !!!!

Thommy

**Troublegum** · 22.03.2002, 22:22

Hallo Thommy,

interessantes Thema, ehrlich

Also ich greife erstmal den zweiten Punkt auf, du erlaubst ?

Also das Buch, welches ich gerade in der Hand habe sagt mir, dass bei myql Die Suche per Volltextsuche mind.4 Zeichen lang sein muss.
Zitat
"Wörter müssen mind. 4 Zeichen lang sein, damit sie berücksichtigt werden. Das macht die Such enach Abkürzungenn wie SQL unmöglich "

Wahrscheinlich war das nur ein Beispielscript, das diese Begrenzung eingebaut hatte.
Denn technisch ist das nicht haltbar. Du kannst genausogut nach einen 1 zeichenlangen String suchen wie nach einem 10 Zeichen langen.
Mal ne Frage: Meinst du mit Volltextsuche jetzt ne einfache Query mit feld LIKE '%Suchwort%' oder eine Suche über einen Index (worüber wir gerade reden) ? Aber eigentlich ist es egal. Man kann genausogut nach Strings suchen, die weniger als 4 zeichen haben.

--------------------------------------------------------------------------------
WHERE wort IN (Suchwörter)
--------------------------------------------------------------------------------
Bei der Anweisung wird doch meines Wissens ein kompletter Zeichenkettenvergleich der gesamten Spalte "wort" gemacht, oder??
Bei einer Grossen Tabelle dauert das doch ewig, oder etwa nicht??

Du erlaubst ein Zitat aus dem mySQL Manual (Link zum Dokument)

expr IN (value,...)
Returns 1 if expr is any of the values in the IN list, else returns 0. If all values are constants, then all values are evaluated according to the type of expr and sorted. The search for the item is then done using a binary search. This means IN is very quick if the IN value list consists entirely of constants. If expr is a case-sensitive string expression, the string comparison is performed in case-sensitive fashion:
mysql> select 2 IN (0,3,5,'wefwf');
-> 0
mysql> select 'wefwf' IN (0,3,5,'wefwf');
-> 1

Ich schätze mal, das IN() viel schneller läuft als LIKE
Aber du kannst eben keine Platzhalter wie bei LIKE verwenden.

Was ich damit eigentlich fragen wollte bezog sich nicht auf einen Voltext-Index, sondern vielmehr auf Indexe von integer-spalten (also zum Beispiel autmatisch hochzählende oder sonstige Schlüsselspalten zwischen Tabbellen). Und meine Frage war nun, ob nun eine insert/delete - Anweisung generell länger benötigen als eine update - Anweisung. Weil ja bei insert / delete die indizierten Spalten (zumindest die eines automatisch hochzählenden Primärschlüssels) der tabelle geändert werden müssen, während bei einer update - Anweisung ja nur ein bereits bstehender Datensatz geändert wird und somit der indizierte Primarschlüssel nicht neu indiziert werden muss. Gleiches gilt für Schlüsselfelder (zwischen mehreren Tabellen) - zumindest sofern diese nicht durch den update betroffen sind)

Da steig ich immer noch nicht ganz durch.
Beim indexieren wird doch nur der Inhalt (Integer) einem Key zugewiesen.
Der Indexierungsvorgang ist also abhängig vom Inhalt. Wenn der nur aus einer Zahl besteht, sollte es schon schneller gehen als wenn es 500 Wörter sind.

Du meinst jetzt, wenn sich der Inhalt ändert ?
Das wäre ja wieder ein anderer Fall.
Dann müsstest du den Eintrag neu indexieren oder den Index ändern. Da kannst du in der Tat UPDATE verwenden, da der Inhalt ja nur aus einer Zahl besteht und du nicht die einzelnen Wörter berücksichtigen musst (bei Wörtern musst du mit DELETE den EIntrag aus dem Index löschen und ihn dann neu indexieren).
Ich schätze mal, du meinst das. Dass wenn man einen Wert ändert. Aber dann ändert sich ja wohl nur einer, sodass die Geschwindigkeit eher keine Rolle spielt, oder ?

Darf ich fragen, wofür du den Volltextindex verwenden willst ?
Was das für ne Anwendung ist ?
Also meine Meinung ist, dass das so etwas nur für eine Integer Spalte absolut sinnlos ist.
Wenn es eine fette Textdatenbank ist, wäre es möglicherweise auch einen Versuch wert, die Volltextsuch Funktionen von mySQL zu nutzen (http://www.mysql.com/doc/F/u/Fulltext_Search.html)

PS: So ein ähnliches Thema hatte ich hier gestartet. Mittlerweile hab ich mir das vB angeschaut und bin etwas schlauer.

**Thommy** · 23.03.2002, 00:02

Hallöle - ich bins nochmal

Wenn es eine fette Textdatenbank ist, wäre es möglicherweise auch einen Versuch wert, die Volltextsuch Funktionen von mySQL zu nutzen (http://www.mysql.com/doc/F/u/Fulltext_Search.html)

Eigentlich meinte ich das die ganze Zeit. Aber hier gilt doch die Restriktion mit den mind. 4 Zeichen oder steh ich jetz total auf dem Schlauch. Oder Kennst Du ne andere Möglichkeit effizient ne Voltextsuche zu gestalten, wenn du bespielsweise ein Lexikon oder Forum mit 50.000 Einträgen hast. Naja ok man könnte natürlich die Spalte mit den Stichwörtern / Forumbeiträgen normal indezieren, aber ..ähh was spricht eigentlich dagegen. Achja per mysql Voltextsuche wird noch eine Gewichtung aller Suchergebnisse durchgeführt - die haste ja sonst nicht.

Gruss

Thommy

**Troublegum** · 23.03.2002, 00:23

Hm. Nach dem, was ich da lese, ist das ja echt praktisch.
Doch die Einschränkungen sind mir irgenwie zu derb

The minimum length of words to be indexed is defined by the MySQL variable ft_min_word_length. See section 4.5.6.4 SHOW VARIABLES. Change it to the value you prefer, and rebuild your FULLTEXT indexes.

Ich glaube kaum,dass man das ändern kann, wenn man nicht seinen eigenen Server hat.
Ich weiß aber auch nicht, auf wie viel ft_min_word_length eingesetllt ist.

The 50% threshold is determined by the particular weighting scheme chosen. To disable it, change the following line in `myisam/ftdefs.h':

Das mag ja manchmal ganz nützlich sein, aber bei mir wohl kaum.
Und ich kann normalerweise auch nicht auf myisam/ftdefs.h zugreifen.

Für mich kommt das deshalb weniger in Frage

**Thommy** · 23.03.2002, 09:14

Hi,

Note that full-text search was carefully tuned for the best searching effectiveness. Modifying the default behavior will, in most cases, only make the search results worse. Do not alter the MySQL sources unless you know what you are doing!

The minimum length of words to be indexed is defined by the MySQL variable ft_min_word_length. See section 4.5.6.4 SHOW VARIABLES. Change it to the value you prefer, and rebuild your FULLTEXT indexes.

mmh,
Hat vielleicht jemend hier einen Erfahrungswert, ob die Suche noch aktzeptabel funktioniert, wenn man die Minimallänge auf 2 oder zumindest 3 Buchstaben reduziert?

Gruss

Thommy

**Troublegum** · 23.03.2002, 21:29

Hm.. Also da ist so ein Index wohl doch nicht so schlecht.
Schnell ist er jedenfalls. (hab ich getestet).

Nur stört mich die Tatsache, dass man keine Suche nach einem kompletten String durchführen kann -> Benutzung von LIKE -> wart wart.

Wie funktioniert das hier bei diesem Board