nicht angemeldet
Hi Andreas,
... weiter im Text:
Und wie geht das? Kann ich einen Teil des RAMs
"mounten" oder wie soll ich mir das Vorstellen,
Ja, so ungefähr. Wie genau eine RAM-Disk installiert
wird, das wirst Du in ihrer Beschreibung lesen. Es
wird aber immer so ähnlich funktionieren wie "mount",
auch wenn es nicht dieses Kommando selbst verwendet.
Auch "mount" blendet ja ein über einen Treiber be-
triebenes Gerät in den Verzeichnisbaum ein - wobei
Du als Anwendungsprogramm nicht zwischen einem Fest-
platten- und einem NFS-mount unterscheiden kannst.
Ja, ich habe es jetzt 2 oder 3 mal komplett gelesen,
wie gesagt vieles nicht verstanden, aber sehr
interesant. Aber das Kapitel mit den Server-
Parametern finde ich etwas kurz, oder gibt es dazu
irgendwie ein eigenes Kapitel, was die einzelnen
Paramter genau machen?
Ich fand die Beschreibung mit den Parametern auch kurz.
Aber kannst Du mir mal sagen wo Du die Erklärung
her hast? Sowas suche ich schon die ganze Zeit
und finde es nicht!
http://www.mysql.com/doc/en/SHOW_VARIABLES.html
Da kann man sogar selbst Kommentare abgeben - habe ich
teilweise auch gemacht.
Was mich aber am meisten stört, fsockopen
würde ich nicht suchen können, da teilstring.
Das habe ich nicht verstanden.
Wenn im Posting spwa ssteht..
<?
fsockopen("bla.bla.de");...
dann fidne ich dieses Posting weder Durch die
Eingabe von "fsockopen()"
noch durch "fsockopen"
In _beiden_ Fällen solltest Du es finden.
Der Punkt ist: mySQL-FULLTEXT hat eine eigene Vorstel-
lung davon, was ein "Wort" ist. Im mySQL-Quelltext gibt
es eine Beschreibung, welche Zeichen legale "wordchars"
sind - und "(" ist keiner!
Deshalb wird in Deinem Beispiel durchaus "fsockopen"
als Wort im FULLTEXT-Index gespeichert werden - und
sogar bei Deiner Eingabe von "fsockopen()" sollte es
gefunden werden, weil der FULLTEXT-Treiber auch bei
der Ausführung von MATCH erst mal Deinen Suchbegriff
analysiert (deshalb funktioniert ja eine Eingabe von
mehreren Begriffen mit Leerzeichen getrennt).
Diese wordchars kannst Du selbst auch ändern - genau
wie die Mindestlänge eines FULLTEXT-Eintrags. Das ist
ein C-Makro in einer der Dateien des MYISAM-Tabellen-
treibers - das findest Du im mySQL-Quelltextverzeich-
nis "src/myisam".
Der voreingestellte Wert ist allerdings m. E. sinnvoll
- ich selbst habe dort nichts ändern müssen.
das ist sehr schlecht! Ich müßte auch teuilstrings
finden könnewn, aber das kann zumindet 3.23 noch
nicht
Versuche, das "wordchars"-Konzept zu verstehen. Es
ist im ersten Moment verwirrend - aber es lohnt sich.
und ohne Fulltext hat das wohl kaum sinn, es sei
denn ich durchsuche per %LIKE% nochmal die temporäre
Tabelle, wobei ich in diesem Fall aber die
Kompletten Postings reinschreiben müßte, was
womöglich schnell an Grenzen stößt!
So macht es in der Tat keinen Sinn.
Da müßtest Du schon eher die FULLTEXT-Funktionalität
selbst nochmal implementieren, also einen Wort-Zerleger
schreiben und eine Tabelle bauen, die nur aus zwei
Spalten besteht, dem Wort und der Posting-ID, und über
dem Wort einen non-unique Index definieren ...
(Ich habe das für eine andere Anwendung mal so reali-
siert, mit einer Tabelle mit 20 Millionen Einträgen -
damit habe ich eine Suche, die eigentlich LIKE %...%
ist, über Indexverwendung irre schnell bekommen: Jeder
Postfix ist bei mir ein Tabelleneintrag ... denn LIKE
...% arbeitet _mit_ Index ...)
Zurück zu FULLTEXT: Definiere, was Du als Bestandteil
eines Wortes, also eines Suchbegriffs zu akzeptieren
bereit bist, und passe ggf. die wordchar-Definition an.
Um dann allerdings "fsockopen()" zu finden und an
Stellen, wo "fsockopen" ohne "()" steht, _keinen_
Treffer zu erzielen, müßtest Du
1. in Deinem PHP-Skript begreifen, daß "fsockopen()"
kein "word" ist und
2. deshalb _nach_ dem erfolgreichen FULLTEXT-Zugriff
in einem weiteren Filterschritt ein
"LIKE %fsockopen()%"
dahinter schalten.
Letzteres ist der schon mehrfach angesprochene Phra-
senfilter: Suche zunächst nach allen Worten über den
FULLTEXT-Index und prüfe anschließend die (hoffentlich
schon sehr wenigen) Treffer daraufhin, ob es wirklich
"echte" Treffer waren. Das LIKE ist teuer - deshalb
muß vorher die Trefferzahl schon sehr klein sein ...
ein Phrasenfilter nach "HTML " kann nicht schnell
werden.
LIMIT 0, 1000
Das wirkt zu spät.
lustig! Wie soll ich das vorher begrenzen?
Indem Du die einzelnen Schritte voneinander
trennst.
Aber wie? Erstmal brauche ich doch eine Grund-
auswahl. Das Limit ist nur eien Sicherheit gegen
ganz grobe Such-Begriffe.
Aber "Andreas" ist in diesem Fall _zu_ grob.
Wenn Du zuerst nur nach "fsockopen" suchst, bekommst
Du eine bereits kleine Treffermenge; an dieser Stelle
kannst Du allerdings ein "pathologisches" Trefferlimit
von vielleicht 3000 setzen, damit Du nicht in Treffern
ertrinkst. (Dessen Erreichen reduziert wieder die
Qualität der Treffer, aber das merkst Du und kannst
es in der HTML-Ausgabe anzeigen.)
Danach kommt dann erst der Vergleich mit "Andreas",
der _nicht_ über den FULLTEXT-Index geht - erneut mit
einem LIMIT versehen, diesmal mit demjenigen, das für
die spätere Ausgabe gelten soll.
In diesem Falle hast Du die Query in zwei SELECTs
zerlegt und das Ergebnis in einer temporären Tabelle
gepuffert, um zwischen den beiden Bedingungen ein
LIMIT feuern zu lassen.
Im vorliegenden Fall war das wahrscheinlich nicht
mehr notwendig - da hätte es gereicht, nut "fsockopen"
über den FULLTEXT zu suchen, weil der Vergleich mit
"Andreas" aufgrund des verwendeten Zugriffspfades
nachgeschaltet ist, also nur auf die Treffer des
FULLTEXT-MATCH angewendet wird.
Auch die unterschiedliche Auswertung der beiden WHERE-
Terme ist aber schon eine solche Serialisierung - wenn
Du beide Terme über MATCH suchst, dann sind sie
gleichrangig, und mySQL muß für die geballte Ladung
Treffer den FULLTEXT-Index bemühen - und JOINen, also
sortieren.
Bedeutung zu sagen. Je mehr Informationen der Anwender
in diesem Formular eingibt, desto bessere SELECT-
Statements kannst Du daraus generieren.
Ja, das mit den Namen hatte ich ja so gemacht.
Sollt eich das denn dann erst hinterher machen,
oder die Kategorie und den Namen direkt zum Filtern
im ersten SELECT verwenden?
Das Problem ist, daß ich die Funktionalität der ge-
samten Suche nicht überblicke. Wird es jemals eine
Möglichkeit geben, alle Postings eines Autoren ohne
Angabe eines Inhaltsmusters anzufordern? Dies würde
eine andere Indexarchitektur erfordern.
Ich ignoriere diese Möglichkeit mal und beschränke
mich auf das, was bisher geht:
Also Parallel zu den Match()Against(),
Ja.
Nach meinen MEssungen kostet eien zusätzliche WHERE
Bedingung durchaus Zeit, aber dafür sortiere ich in
der Temporären tabelle weniger, wobei das Abfragen
der kleinen temp. Tabelle wirklich mit weniger als
1/1000 nicht ins Geewicht fällt, daher sollte ich
wohl am Anfang nur mit Match erstmal den Fulltext-
Indes allgemein abfragen, und in einem 2. Schritt
den Rest.
Das WHERE muß irgendwann einmal gemacht werden, und
Du wirst nie einen Indexzugriff dabei durchführen
können - egal, ob Du es schon direkt nach dem MATCH
oder in einer späteren Filterstufe erledigst.
Daraus folgt: Mach es so früh wie möglich.
In der temporären Tabelle sortiert Du Zeilen, nicht
Spalten. Wie breit diese Zeilen sind, das ist für
die Sortierung irrelevant (weil mySQL sicherlich nur
Pointer auf diese Zeilen neu verketten wird).
Die Breite der Sortierspalte selbst ist allerdings
wichtig (weil der Vergleich langer Werte teurer ist
als der Vergleich kurzer Werte - deshalb gefällt mir
die Datums-Codierung als UNIX time stamp so gut).
Bedenke das es sich nur um die Autoren-Spalte
handelt, die ist ja recht kurz!
Ja - aber wenn Du mehrere hunderttausend INSTR-Opera-
tionen durchführen mußt, weil der vorherige FULLTEXT-
Zugriff nichts oder nur ganz wenig gefiltert hat
("HTML" ;-), dann ist das trotzdem teuer. (Wahrschein-
lich wird es identisch zu LIKE %...% realisiert ...)
Viele Grüße
Michael