nicht angemeldet
Hallo Michael!
es geht nicht darum, _wo_ die Daten gespeicher werden,
sondern _wie_.
Naja, aber auch das _wo_ ist nicht ganz so unwichtig, denn Plattenzugriffen dauren doch erheblich länger als direkte RAM-Zugriffe! Aber das sind wieder 2 Dinge, Du redest glaibe ich vom schreiben der Tabelle, was vermiutlich langsamer ist als bei MyISAM, und ich rede vom auslesen, was kaum merklich schneller ist. Was jetzt am Ende das schnellste ist muß ich genau messen, aber jetzt verstehe ich. Ich hatte immer nur das Auslesen zum Vergleichen herangezogen.
Siehe oben: Auch sehr viele sehr kleine Daten brauchen
zum Sortieren sehr viele sinnlose Vergleiche.
Bei MyISAM etwas nicht? Vermutlich ist das bei myISAM auch langsamer, so spricht nur das schnellere Schreiben für MyISAM.
Und so, wie ich den HEAP verstanden zu haben glaube,
ist der Sinn der Sache, daß dabei implizit ein Index
aufgebaut wird - genau das, was wir vermeiden wollen,
weil dafür eine Sortierung notwendig ist.
Du wirst es wissen. Ich habe das so verstanden, dass das ein Hash ist(für mein Verständnis eine Art Array), der als Index benutzt werden kann/sollte. Man kan ja auch hier extra einen Index erzeugen, halt nicht besonderes wie Fulltext, und man kann auch nicht nach dem erzeugten Index sortieren. Aber warum sollte man- wenn HEAP selbst ein Index ist - einen Index über einen Index erstellen können?
MYISAM im
RAM muß für Deinen Zwecke besser sein als HEAP.
Wie bekommt man myISAM in den RAM? Du sagts immer was von RAM-Disc, aber was ist das? Sowas habe ich nicht! Geht das auch anders?
Du sollst auch nicht alle Parameter verdoppeln - das
kostet RAM und macht die Sache langsamer.
Ich habe ja auch nicht alles verdoppelt, nur das was mir vernünftig erschien, aber der RAM-Verbrauch steigt ja erst mit zunehmender Anzahl an SELECTS, sonst nicht! (da hatte ich noich kein HEAP)
Das einzige an Tuning was ich hier für sinnvoll halte, ist den Anfragen-Cache(welche Variable auch immer das sein mag) so groß wie möglich zu halten, so dass die Anfragen nicht immer neu auf die Platte zugreifen müseen. Den Fulltext-Index selbst weiß ich auich nicht wei ich den in den RAm bekomme, der hat ja immerhin 60 MB, aber zu besten Testzeiten hat MySQL etwas über 30 MB Ram belegt.
Du sollst
den richtigen Parameter finden und ihn verzehnfachen.
Aber wo steht welche Parameter was genau tut? Da steht eine Liste mit Beispielwerten, aber dei bringt mit nichts. Dann sind noch ein üar Beispiele für spezzielle Anforderungen aufgeführt, die ich aber nicht nachvollziehen kann, da am Ende für sehr viele Anfragen der Cache auf ein paar KB reduziert wird!
Aber ich dachte, HEAP wird im RAM abgelegt, und
MyISAM auf der Festplatte!
Deshalb hatte ich in Dir in einem meiner vorherigen
Postings den Link auf die mySQL-Doku gezeigt, wo
steht, _wo_ diese Daten auf der Festplatte gespeichert
werden. Wenn Du diesen Pfad auf eine RAM-Disk legst,
hast Du Deine MYISAM-Tabellen im RAM ... und brauchst
kein HEAP mehr.
Und wie geht das? Kann ich einen Teil des RAMs "mounten" oder wie soll ich mir das Vorstellen, oder ist eine RAM-Disk ein Hardware-Teil?
"top" hast Du aber?
ja.
Normalerweise solltest Du eine
IOWAIT-Anzeige im einstelligen Prozentbereich haben.
Wenn die während einer Abfrage deutlich zweistellig
wird, dann bremst Deine Platte das Systen.
Ich habe mal in der RH-Mailing-Liste angefragt, wie ich an den Wert komme.
Gnlpfts. Mein "top" zeigt mir mehr an.
(http://www.sunmanagers.org/pipermail/sunmanagers/2001-November/008101.html)
schön ;-)
Ich fürchte, Du wirst das gesamte Kapitel 5 einmal
linear durchlesen müssen - nicht, um es komplett zu
verstehen, sondern um zu lernen, welche Themen dort
behandelt werden. Das ist ein Ideengeber ohne Ende.
Ja, ich habe es jetzt 2 oder 3 mal komplett gelesen, wie gesagt vieles nicht verstanden, aber seh rinteresant. 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?
Konkreter Versuch - setz mal diesen Wert hier so hoch,
wie nur irgend möglich bei Dir:
"key_buffer_size"
Habe ich auf 64 MB gesetzt, kein Unterschied. Aber kannst Du mir mal sagen wo Du die Erklärung her hast? Sowas suche ich schon die ganze Zeit und finde es nicht!
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", das ist sehr schlecht! Ich müßte auch teuilstrings finden könnewn, aber das kann zumindet 3.23 noch nicht, udn ohen Fuulltext 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!
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 Grundauswahl. Das Limit ist nur eien Sicherheit gegen ganz grobe Such-Begriffe.
Klar, aber das Scipt kann nunmal nicht so schlau
sein wie Du ;-)
Doch. Das muß es sogar. Das ist der Trick an der Sache.
Yep. Mach eine Statistik über alle Worte Deiner
Datenbank - und setze "Andreas" auf die Schwarze
Liste. ;-)
Das dumnme an der schwarzen liste, ich gebe
"Andreas" ja nicht nru zum Spaß ein! Das soll ja
auch Auswirkungen auf das Ergebnis haben!
Hat es auch - Du sollst ja "Andreas" nicht ignorieren,
sondern diesen Begriff nur nicht mit MATCH abfragen,
sondern ganz normal mit LIKE.
Und am besten auch nicht im Posting-Body, sondern nur
im Author - es liegt an Deinem Eingabeformular, dem
Anwender zu erleichtern, Dir diese eingeschränkte
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? Also Parallel zu den Match()Against(), oder am Ende in der Temporären Tabelle? 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.
mache ich später, meinst Du das wäre besser als
meine instr() Varianteß Wie gesagt kostet die so
gut wie nicht!
Diese Aussage glaube ich nicht, solange sie unabhängig
von der Treffermenge ist.
Bedenke das es sich nur um die Autoren-Spalte handelt, die ist ja recht kurz! Und es kostet durchaus was, halt ca. 1/10 Sekunde, je nachdem(über die Autor-Spalte der kompletten Ursprungstabelle). Vermutlich ist das nachträglich schneller.
Bei vielen Treffern kostet _jede_ Operation etwas.
Entscheidend ist, ob die Kostenfunktion linear oder
überlinear mit der Anzahl der Treffer wächst - und in
dieser Hinsicht ist Sortieren fast immer der worst case.
Daher mache ich das so spät wie möglich!
Grüße und vielen Dank nochmal,
Andreas