Performance-Problem

[Marc Albrecht]

Moin,

> > Meine Frage bezieht sich - das versuche ich gerne noch einmal darzulegen
> > - darauf, wie wir bei einer 360MB-großen MYD-Datei auch die Datensätze,
> > die in der Tabelle (primary key!) weiter "hinten" liegen, in adäquater
> > Geschwindigkeit erhalten können.
>
> MYSQL sortiert nicht nach dem Primary Key. Ich hab leider deine Frage
nicht
> hier, aber ich denk mal die Frage, die ich hab wird da nicht drin stehen.
Wird
> in dieser Tabelle oft gelöscht und neu eingefügt, kann es also sein, das
viele
> Lücken in den MyISAM Blöcken stehen und diese wieder durch neuere
Datensätze,
> die eigentlich "hinten" stehen müssen gefüllt werden?

Nein, in der betreffenden Tabelle wird _meist_ geINSERTed (aber immer mit
neuen Primary IDs, wobei, wenn mySQL das ignoriert, das wohl weniger wichtig
ist), ab und zu jedoch "am Block" auch deleted. geUPDATEd wird recht selten
(bis nie).

> Hast du schon mal einen optimize Table gemacht und dann die Performance
> getestet?

Wir haben sogar die Tabelle per Script ausgelesen und in eine Kopie
eingefügt (also sozusagen eine brute force garbage collection durchgeführt).
Das Ergebnis ist nahezu 100%ig identisch.

> Ich hab mal kurze Tests gemacht, in einer Tabelle mit ca. 200k Einträgen.
Je
> nachdem, wo ich die Datensätze rausnehme, schwankt die Zeit um ca. Faktor
50.
> Also im allgemeinen kann ich dein Problem bestätigen (und nein, AFAIK
wurde
> _diese_ Tabelle nur einmal gefüllt, und verrichtet seitdem ihren Dienst.

Woops. Das haut ja in die gleiche Kerbe - und dürfte, wenn es sich als ein
_generelles_ Problem herausstellt, für unsere weiteren Projekte das absolute
KO-Kriterium für mySQL sein... das möchte ich nicht hoffen, denn ich fühle
mich mittlerweile sehr wohl mit dieser Lösung.

> > Für HILFE wäre ich sehr dankbar. Ich geben gerne jede Art von
> > Information heraus, die hierbei helfen kann. Ideologische Diskussionen
> > bringen mich aber (leider) nicht weiter.
>
> Dann verbreit keinen ideologischen Schwachsinn, dann muss den keiner
> korregieren.

Ich verbreite gar nichts sondern gebe schlichtweg Infos zu dem von mir
bemerkten Problem bekannt. Es ärgert mich aber, die gleichen Informationen
doppelt geben zu müssen, dafür bitte ich um Vergebung.

Du bestätigst ja (leider!) mit Deinem Test meine Befürchtungen, es hier mit
einem Design-Fehler von mySQL zu tun zu haben. Ich warte noch etwas auf
alternative (Test?) Vorschläge, an welcher Stelle wir schrauben können. Ich
hänge z.B. gerne statt 2 RAID0-Platten 10 rein - gar kein Problem. Wenn ich
weiss, daß ich dann vernünftige Performance erhalte... auch andere
Filesysteme könnte man probieren oder optimierte Blocksizes (es sollte ja
kein Problem sein, die durchschnittliche Zeilengröße aus der Tabelle zu
bekommen und daraus einen sinnvollen Wert für die Blocksize des Filesystems
abzuleiten - das System, um das es geht, bedient NUR diesen
Aufgabenkomplex).

Ideen in dieser Richtung würde ich gerne ausprobieren. Ich habe auch schon
erwogen, die Tabelle horizontal zu verkleinern (statt 35 Spalten 3 x 12 zum
Beispiel) - auch wenn das mir nicht sehr sympatisch erscheint.

> Im übrigen gibts keinen Grund, in der Gegend rumzuschreien.

Oh, manchmal ist es notwendig, wichtige Komponenten deutlich
herauszustellen - und da hilft Schreien durchaus :-)

Marc Albrecht

---
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql