Re: Performance MySQL
- From: "Michael Wurz" <spammic@xxxxxxxxx>
- Date: 21 Jul 2005 02:04:35 -0700
Hallo zusammen,
erstmal möchte ich mich für euren zahlreichen Antworten bedanken.
> Warum schreibst du einmal Englisch und einmal Deutsch?
Dass ich zwischendurch mal auf Englisch rübergesprungen bin, tut mir
leid. Ich telefoniere im Moment sehr viel mit den Staaten, was das
Missgeschick in keinster Weise entschuldigen soll. Ich bemühe mich nun
noch stärker im Deutschen zu bleiben, :-)
Meine Antworten, Fragen und Stellungnahmen zu euren Hilfen:
(Habe hierzu alle Anmerkungen aus den verschiedenen Beiträgen
zusammengefasst!)
> Eine grafische Darstellung wird sicher keine 1.000.000 Zeilen haben.
Doch. Die grafische Darstellung wird aus ca. 1 Mio Daten generiert. Ich
schicke erst den Query an die Datenbank ab, der mir die Zeilen
selektiert [WHERE], anschließend mache ich Subqueries
(Auswahlkriterium ist das Datum) zur Aggregierung ich über spezielle
Intervalle
> Weisst du an der Stelle wirklich was du tust?
Ich denke schon. Falls der Kunde eine Grafik über diese Menge an Daten
wünscht, habe ich keine andere Wahl, oder? Sicherlich werden die
Zeilen zu Mittelwerten zusammengefasst, weil ich ja nicht 1 MIO Pixel
in einem Diagramm setzen kann, aber die zu Grunde liegende Gesamtmenge
liegt in dieser Größenordnung. Hintergrund zum Projekt: Wir erfassen
Temeperaturwerte [1 Wert pro Messstelle pro Minute]. Über die Jahre
sind dort Unmengen von Einzeleinträgen zusammen gekommen. Nun habt ihr
auch eine bessere Vorstellung zu dem Projekt! Sorry, dass ich nicht
gleich damit rausgerückt habe, :-)
> Mir scheint es, dass deine WHERE-Bedingung nicht ausreichend ist.
Naja, ich kann ja nur nach dem Datum [timestamp] und der Temperatur-ID
[Messstellennummer - tid] filtern. Auf beiden habe ich einen Index
liegen.
Eine klassische Abfrage sieht im Moment bei mir so aus:
SELECT DATE_FORMAT(timestamp, '%d.%m.%Y %H:%i:%s') AS date, temperature
FROM temperature WHERE tid = X1 AND timestamp > X2 AND timestamp <= X3
LIMIT X4
oder auch als Aggregatfunktion
SELECT AVG(temperature) AS avg FROM temperature WHERE tid = X1 AND
timestamp > X2 AND timestamp <= X3
> Pack da mehr RAM rein.
Ok, wieviel Riegel soll ich nachlegen? Insgesamt 2048 MB? Was benötigt
man denn mindestens um bei MyISAM mit großen Tabellen arbeiten zu
können? Ich habe leider wenig Erfahrung mit Hardware, wie ihr auch
schon an den Platten gemerkt habt. :-(
> Betriebssystem [das da wäre?]
Linux infong 2.4
> Bei InnoDB ist die Abschätzung schwieriger.
In den Temperaturtabellen setzen wir dank der schnellen Reads und der
Möglichkeit von Concurrent Inserts nur MyISAM Storages ein. InnoDB
Tables benötigen wir nur für die Messstellen und
Parameter/Einstellungen, da uns dort die Locking Granularität von
MyISAM das Leben schwer macht.
> Für Bulk-Verarbeitung brauchst du ein vernünftiges Platten-System
Ja, da muss es hingehen. Danke für die Hinweise.
> Der Author von <http://www.oreilly.com/catalog /hpmysql/index.html>
> arbeitet bei Yahoo!, da kann man kaum von "allgemeinen Analysen"
> sprechen...
Ich wollte da Niemanden zu nahe treten. Genau das Buch habe ich
gelesen. Das Kapitel 5 über Query Performance ist wirklich sehr gut
geschrieben und hat uns auch schon viel weitergeholfen, allerdings
hätte ich dort nicht eure Einschätzungen aus der direkten Praxis
["I/O Probleme", "Platten sind driss" etc.] bekommen, :-)
> Wie kann man Queries noch weiter optimieren? Weiter als was?
"weiter" als ich es bisher getan habe. Ich habe die Queries schon mit
EXPLAIN stark optimieren können. Die Geschwindigkeitsvorteile mit den
Indizes sind enorm, aber ich bin davon überzeugt, dass man dort noch
mehr rauskitzeln kann. Die Hardware und falsch konfigurierte
Buffergrößen sind hier ein guter Ansatz.
> Wenn du dann allerdings noch Daten von der Platte kratzen mußt
Wann tritt dieser Zustand ein? Sobald die Indizes nicht genutzt werden
können oder nicht mehr in den key_buffer passen, korrekt?
> Die typische Lösung im OLAP-Bereich heißt Partitionierung und da hat
> MySQL bis jetzt noch nichts zu bieten.
Da sprichst du einen prikären Schwachpunkt von MySQL an, :-) Ansonsten
bin ich von dem DBMS schwer begeistert!
> Details? Was sagt EXPLAIN zu deiner Query? Wird die Query schneller,
> wenn du nur die indizierten Spalten SELECTierst? Welcher Tabellentyp?
Ja, erheblich! s.o.! Tabellentyp = MyISAM
> Ich habe die Erfahrung gemacht, dass mySQL bei einer Query immer nur einen Index verwenden kann.
Thx, Marian! @dirk/Axel: Könnt ihr das bestätigen? Ich habe zwei
Indexes und bei der Analyse mit EXPLAIN fallen dort jeweils
Unterschiede in der Performance auf. Also muss MySQL auch in der Lage
sein beide auszuwerten.
Hoffe, dass ihr euch durch diesen langen Beitrag kämpft und dann
nochmal unterstützt. Ich bin wirklich begeistert von dieser
Datenbankgruppe. In den java und j2me Gruppen steckt nicht so viel
Kompetenz drin wie hier, :-(
Freue mich auf euer Feedback,
ciao Michael
.
- Follow-Ups:
- Re: Performance MySQL
- From: Fabian Schladitz
- Re: Performance MySQL
- From: Axel Schwenke
- Re: Performance MySQL
- From: Marian Heddesheimer
- Re: Performance MySQL
- References:
- Performance MySQL
- From: Michael Wurz
- Re: Performance MySQL
- From: Marian Heddesheimer
- Performance MySQL
- Prev by Date: mySQL und Multiprozessor
- Next by Date: Re: mySQL und Multiprozessor
- Previous by thread: Re: Performance MySQL
- Next by thread: Re: Performance MySQL
- Index(es):
Relevant Pages
|
