nicht angemeldet
Moin!
Leider steigt jetzt der Datenbankserver in Spitzenzeiten immer wieder aus.
Die dB Abfragen lassen sich nicht weiter optimieren.
Jetzt denke ich über ein Umstieg auf inno dB nach.Ich bin skeptisch, dass ein Wechsel der Engine den entscheidenden Performance-Gewinn bringt, so dass der Server wieder ausreichend Platz hat. Du solltest das aber zunächst im Labor nachstellen und dann mit Tools wie Apaches "ab" messen, ob sich die Anzahl der Requests pro Zeiteinheit steigern lässt.
Ein Wechsel der Storage-Engine kann enorm viel Potential haben, oder auch nicht. MyISAM hat kein vernünftiges Locking implementiert, jeder Schreibzugriff in einer Tabelle sperrt die gesamte Tabelle für parallele Lesezugriffe. Wenn also gleichzeitig geschrieben und gelesen wird, ist das hinderlich, und InnoDB mit seinem Locking auf Datensatzebene ist da deutlich besser geeignet.
Was würde ihr als Alternatives Datenbanksystem empfehlen.
Vielleicht einfach nur auch da clustern. MySQL bringt ein nicht allzuschwer aufzusetzendes Replikatonssystem mit. Damit lassen sich zumindest die Lese-Abfragen recht einfach verteilen.
Replikation löst das Problem nicht, bietet aber eine Methode an, drumherum zu arbeiten. Wenn man die Einschränkungen der Lösung kennt, kann man eventuell damit leben.
Im Kern ist Replikation nur ein Doppelverarbeiten jeglicher schreibender SQL-Queries sowohl auf dem Master, als auch auf dem oder den Slaves. Das bedeutet, dass die Probleme des Lockings hier genauso auftreten werden, denn anders als durch Schreibzugriffe kriegen die Slaves ihre Daten nicht aktualisiert. Weil das Schreiben allerdings nicht zwingend sofort erfolgen muss, können die Slaves hinter dem aktuellen Datenbestand des Masters hinterherhinken - man arbeitet auf den Slaves also nicht zwingend mit aktuellen Daten.
Deshalb bringt es z.B. Probleme, wenn man in seiner DB-Zugriffslogik einfach zwei Verbindungen zum Master und zum Slave aufmacht und alle SELECTs auf dem Slave ausführt. Weil die Schreibzugriffe nicht zwingend schon ausgeführt wurden, wenn das Programm weiterläuft, kann man beim nachfolgenden Lesen der Daten (auf dem Slave) schon mal von einem veralteten Datenstand überrascht werden. Session-Daten in so einer Datenbank zu speichern ist definitiv keine gute Idee.
Ansonsten sollten sich doch zumindest ein paar sicher eher allgemein gehaltene Performance-Benchmarks im Netz finden lassen. Wenn dir dabei ein System ins Auge fällt, das angeblich besser abschneidet, dann versuch es in deinem Labor einzubinden und miss die Unterschiede unter deinen konkreten Bedingungen nach. Vielleicht ergibt sich dann ein ähnliches Bild wie im Benchmark oder auch ein ganz anderes.
Ohne zu analysieren, wo das Problem genau liegt, kann man keine pauschalen Hilfen anbieten. Allerdings klingt es relativ vernünftig, zunächst von MyISAM auf InnoDB umuzusteigen, sofern das keine Features beeinträchtigt, die derzeit von MyISAM benutzt werden. Im Zweifel wäre ja auch ein teilweiser Umzug möglich.
- Sven Rautenberg