nicht angemeldet
Hi Andreas,
also erst mal vorweg:
1. Das, was Du machst, _ist_ vernünftig.
2. Wirklich gut wird die Suche aber nur, wenn Du mehr
als einen Suchbegriff erlaubst.
Daß die Ranking-Funktion von mySQL nicht zur
Aufgabenstellung paßt, hast Du ja selbst gesehen.
Ja, da hatten wir schonmal drüber diskutiert, aber
soweit ich weiß ist es im Selfforum nicht möglich
eigene <> in den HTML-Quellcode zu bekommen, oder?
Also sollte es gehen, oder? Irgendwie muß ich den
Code ja rausbekommen! Daher filtere ich erst die
Basisdaten aus dem Thread(Thema, User, zeit), dann
entferne ich die html-tags, und dannach wandele ich
html-entitäten um.
Wenn Du einen eigenen Indexer schreiben willst, dann
brauchst Du so etwas, ja.
Alternative: Laß Dir von Christian die existierenden
Indexdateien geben, damit Du erst mal die Datenbank
schnell kriegst.
Den Parser kannst Du hinterher immer noch schreiben.
Ich habe jetzt 3 Stunden lang versucht MySQL 4 zu
installiern, was an sich nicht schwer war,
Dein Modell funktioniert mit mySQL 3.23 gut genug.
Mach es erst mal damit.
denn gerade für Volltext-Suche ist die 4er erheblich
besser.
Hast Du die 4.0 schon mal damit im Einsatz gesehen?
(Ich noch nicht, ich kenne nur die Handbücher dazu.)
Was ich gemerkt habe, der Index muß immer aktuell
sein, wenn ich ein paar 1000 Datensätze in die
Tabelle schreibe, wird die Suche erheblich
langsamer.
Dann stimmt etwas nicht. Der Trick der Indexe ist doch
gerade, daß es _nicht_ langsamer wird.
Wenn Du 10000 Worte in einem binären Baum darstellst,
dann hat der eine Höhe von 13 Knoten. Eine Million
Worte bewirken eine Höhe von 20 Knoten - die Suche darf
also maximal um 50% mehr Zeit benötigen, tatsächlich
aber deutlich weniger, weil der gesamte Overhead (z.B.
das Parsen des SQL-Statements) unverändert anfällt.
Ich habe jetzt ca. 12.000 Datensätze in der DB(1 pro
Thread), und da dauert es mehr als 15 Minuten den
Index neu zu erstellen! Auch wenn ich eine kom-
pletten Dump im batch-modus einlese!
Das ist wahr.
Aber dieser Aufwand darf nur ein einziges Mal anfallen.
Und die ganze Zeit ist die CPU und der Arbeits-
speicher bis zum Anschlag ausgelastet!
Natürlich. Index bauen bedeutet Sortieren, und das
kostet sowohl sehr viel CPU-Last als auch sehr viel
RAM, um möglichst wenige I/O zu benötigen, die ja viel
langsamer wäre als Zugriffe im Hauptspeicher.
Ich denke daher das mehr CPU-Power und vor allem RAM
sehr wohl was bringt! Kann man nie genug haben,
zumindest solange das System drauf ausgereichtet
ist.
Ja - das Aufbauen eines großen Index kann Ressourcen
jeder Art brauchen. Also sollte man vermeiden, dies
zu oft zu tun.
Wie pflegt Ihr denn solche Indices?
Inkrementell. Auch wenn es langsam ist (siehe unten),
es ist in Deinem Fall die einzige Möglichkeit, wenn
die Postings online in Deine Datenbank fließen (das
wird ja am Ende der Entwicklung der Fall sein).
Ich habe eine solche Datenbank mit einer Million (!)
'Postings' drin (mittlere Größe: 2KB), und das inkre-
mentelle Indexen kostet so gut wie keine CPU-Zeit.
Die Datenbank lasse ich jetzt auch mal online, würde
mich mal interssieren was Ihr davon haltet.
Die Idee ist richtig, und Du wirst dabei wertvolle
Erfahrungen sammeln, die Du mit Daniela austauschen kannst.
id smallint(6) NOT NULL default '0',
Ich würde lieber 24 Bit nehmen als 6 Ziffern.
topic varchar(20) NOT NULL default '',
title varchar(100) NOT NULL default '',
Bei beiden kann Dir die Forum-Software die exakten
Maximalwerte sagen.
body text NOT NULL,
Wie lang ist "text"?
Gäbe es etwas Kleineres, das 12 kB aufnehmen kann?
time int(10) NOT NULL default '0',
Gute Idee - ich mag das, auch wenn mySQL dafür wahr-
scheinlich proprietäre Datentypen hat.
PRIMARY KEY (id),
UNIQUE KEY id (id),
Die untere Zeile ist redundant.
FULLTEXT KEY body (body,topic,title)
Wie ist es mit den anderen Spalten (author)?
) TYPE=MyISAM;
Yep. (Das ist der Defaultwert bei mySQL.)
Wobei ich glaube ich auf unique und Primärschlüsel
verzichten kann, denn das bringt hier eh nichts.
Kommt darauf an. Den Primärschlüssel für die ID würde
ich auch haben wollen - und sei es nur, um die Konsi-
stenz der Daten zu gewährleisten.
Meine 'Suche' kann beispielsweise nicht nur suchen,
sondern auch filtern - etwa die letzten 100 Postings
eines Autors etc. Dafür würdest Du dann den FULLTEXT-
Index nicht nehmen, sondern einen Index über die
Author-Spalte concat den timestamp.
Verschiedene Anfragearten können zu unterschiedlichen
Indexstrukturen führen, die parallel sinnvoll sind.
Die Gewichtung ist aber nicht das gelbe vom Ei.
Das ist noch viel zu unflexibel.
Vergiß die Ranking-Funktion. Bestimme erst mal einen
schnellen Zugriff auf alle legalen Treffer für
a) mehr als einen Suchbegriff und
b) Phrasen
Danach kannt Du immer noch eine eigene Ranking-Funk-
tion auf die gefundenen Treffer anwenden, wenn es denn
sein muß. Eine Ausgabe, die umgekehrt nach Datum sor-
tiert herausgespult wird wie bisher, ist auch nicht so
schlecht als erste Version. Wenn Deine Anwender mehrere
Suchbegriffe eingeben dürfen, die Du mit AND verknüpfen
kannst, wird die Treffermenge so klein, daß Du eine
gute Ranking-Funktion darauf anwenden kannst.
Der Phrasenfilter wird etwas schwieriger ...
entweder ich füge eine weiter Spalte ein, und hier
dann duch Leerzeichen getrennt 5 mal das Thema und
10 mal den Titel, und das dann mit in den Index
aufnehmen, oder 15 weiter Spalten mit entsprechend
5 mal Titel und 10 mal Themenbereich.
Mach's nicht.
Ruiniere Dir nicht Deinen Architekturansatz, bevor Du
diesen bezüglich Performance richtig beherrschst.
Ich habe auch schon ein eine eigene stop-word Liste
gedacht, indem ich beim Anlegen der Datensäzte dort
ausgewiesene Wörter entferne.
Schau im Archiv nach - ich habe schon mal gepostet,
wo im mySQL-Quelltext dessen eigene Stopwortliste
steht und wie Du diese anpassen kannst.
Wobei ich gestehen muß, Ihr hattet Recht, so viel
schneller ist die DB auch nicht,
Momentan vergleichst Du Äpfel mir Birnen. Gib nicht so
schnell auf.
aber auf der anderen Seite habe ich keine Ahnung
wie man das ganze wirklich performant macht,
Schau Dir erst mal mit EXPLAIN an, wie die Datenbank
Deine Statements überhaupt umgesetzt hat.
Wird der FULLTEXT-Index wirklich verwendet?
Viele Grüße
Michael