MySQL Performanceoptimierung

Re: MySQL Performanceoptimierung

kombipaket — Sun, 06 Apr 2008 15:18:45 GMT

Welche Zugriffe erwartest denn ?

Wenn wir mal in Volltextsuchen und "mehr oder minder statische" Zugriffe teilen - wieviele werden in der Hauptverkehrszeit pro Sekunde passieren ?

Im Prinzip ists einfach: solange weniger als 10 Queries pro Sekunde kommen, wird alles wurscht sein - der Engpaß wird dein Netzwerk sein.

Darüber wirds spannend... Wobei ich mich hier zuwenig in MySQL auskenne. Ausgehend davon, daß Parsen von Statements mal teuer ist - verwendet ihr bind-Variablen um das zu umgehen ? Histogramme ? Wenn nicht allzuviele parallele Indexzugriffe (die kosten Rechenzeit) auftreten, wird die CPU auch egal sein.

Datenbanken sind tendenziell IO-Bound und nicht CPU-Bound... Jeder Euro, den du ihn Ram investierst ist meist besser angelegt als dieselben Euro in bessere CPUs zu packen.

Bei massiv-parallelen Zugriffen (sagen wir mal ab daumen mal pi 100 Queries per Sec) wird CPU auch spannend - wobei ich dann wohl auf eine andere Datenbank setzen würde.

Re(3): MySQL Performanceoptimierung

Undying — Thu, 20 Mar 2008 14:02:35 GMT

Dann würd ich mal meine Architektur/Anforderungen überlegen ...

Re: MySQL Performanceoptimierung

Ardjan — Tue, 18 Mar 2008 21:24:16 GMT

Viel Hauptspeicher. Logfiles und DB-Files auf getrennte Platten. Indexe optimieren. Queries vereinfachen und optimieren.
Das sind mal die erste Optionen.

Dann habe ich gesehen das du Binärdateien im DB speichern willst: nicht tun. Bilder über der Pfad/Dateiname referenzieren.

PDF oder Word mittels eigene Modulen indizieren, wie schon vorgeschlagen.

Re(6): MySQL Performanceoptimierung

ruprecht69 — Tue, 18 Mar 2008 21:15:31 GMT

MySQL hat Volltextsuche eingebaut.
Aber korrekt, ich würde auch nie auf die Idee kommen riesige Mengen von Binärdaten in die DB zu schreiben - eher nur Metadaten und den Rest auf die Platte.

Re(5): MySQL Performanceoptimierung

adhoc — Wed, 12 Mar 2008 15:45:48 GMT

wollen
tun da viele

wie dr. watson schon schrieb,
hilft dir da das pdf in der DB sowieso nix..

ausserdem macht man volltextsuche eher nicht mit der sql-datenbanken, sondern mit Lucene oder sowas ähnlichem ...

(ausser es gibt inzwischen spezielle "module" für volltextsuche in sql, aber das weiß nicht, da hab ich mich schon lange nicht mehr damit beschäftigt...)

Re(5): MySQL Performanceoptimierung

Dr. Watson — Wed, 12 Mar 2008 15:01:18 GMT

PDF mit eigenen Algorithmen parsen, Plaintext in der DB speichern.
Den ganzen overhead durch das Fileformat brauchst du nicht in der DB, wenns dir nur um den Inhalt geht.
Selbiges bei MS-Word-Dokumenten.

Glaub mir, MySQL mit solchen Datenmengen wird auf Dauer einfach unlustig, dafür ist es nicht ausgelegt.

Re(4): MySQL Performanceoptimierung

Zappa F. — Wed, 12 Mar 2008 14:58:20 GMT

naja - aber wir wollen eben die PDFs durchsuchbar machen...

Re(3): MySQL Performanceoptimierung

adhoc — Wed, 12 Mar 2008 14:08:48 GMT

würd die pdf/bilder auch nicht in der db speichern
(auch wenn das ein paar wenige vorteile hätte)

dafür ist dann das (inkrementelle) backup wesentlich kleiner...

Re(3): MySQL Performanceoptimierung

Dr. Watson — Wed, 12 Mar 2008 13:59:12 GMT

Bilder, PDFs und Movies in einer MySQL DB?

Also ich würde mir das ganze noch mal gründlichst überlegen...das sind dann meistens die Projekte, die lokal beim Entwickeln ganz gut funktionieren, und "in the wild" dann, mit steigender Datenmenge, plötzlich nicht mehr zu gebrauchen sind.

Re(2): MySQL Performanceoptimierung

Zappa F. — Wed, 12 Mar 2008 13:46:22 GMT

naja - die Größe der Datenbank rührt primär von darin enthaltenen Bildern, PDFs und Movies. Insbesondere wollen wir mit unserer Seite in Zukunft auch eine Volltext-Suche in PDFs und ev. Worddokumenten ermöglichen...

grüße
F.Z.

Re: MySQL Performanceoptimierung

Dr. Watson — Wed, 12 Mar 2008 11:23:01 GMT

Ein paar GBytes? Bist du sicher dass du dir das mit MySQL antun willst?
Da wird ein tägliches Backup auf jeden Fall zur Pflicht.

Aber zur eigentlichen Frage - eine DB lebt vom Hauptspeicher, also ist jede Menge RAM eine gut Idee. In deinem Fall aber würde ich die Abfragen PHP seitig in einen Cache schreiben. Nehme mal an, dass sich die Daten nicht im Sekundentakt ändern, wenns auf die Minute aktuell ist wirds wohl auch noch reichen.

Re(4): MySQL Performanceoptimierung

Zappa F. — Tue, 11 Mar 2008 12:36:58 GMT

wir "vermischen" die Ausgabe einer Typo3 Webseite eben mit handgeschriebenen PHP-Sql abfragen. Dies geschieht teilweise aus Sicherheitsgründen...

Re(3): MySQL Performanceoptimierung

FunkFish — Tue, 11 Mar 2008 12:32:14 GMT

was ist den das für ein projekt? eine größere Website!
Wenn sich Daten nicht die ganze Zeit ändern, wäre es dann nämlich idealer zu definierten zeiten (alle 15 min oder 30 min) statische Seiten generieren zu lassen. in wie weit das mit typo3 realisierbar ist weiß ich nicht. ich kenn das nur von Wordpress und Joomla! Habs selber aber noch nie benötigt.

Re(2): MySQL Performanceoptimierung

Zappa F. — Tue, 11 Mar 2008 12:22:50 GMT

also wäre eine Option auch noch ein großer Hauptspeicher?

Re: MySQL Performanceoptimierung

FunkFish — Tue, 11 Mar 2008 12:02:43 GMT

das einfachste wäre cachen, aber in dem ausmaßen die du beschreibst werden wahrscheinlich andauernd datenbank einträger erstellt und geändert.

MySQL Performanceoptimierung

Zappa F. — Tue, 11 Mar 2008 11:59:43 GMT

Hi;

Webserver mit den üblichen Verdächtigen - Apache, PHP5, Typo3, Mysql.
Auf diesem Läuft eine Typo3 Seite, welche zusätzlich durch handgeschriebenen PHP-Code automatisch aus einer Mysql Datenbank befüllt wird (Bei jedem Aufruf der Seite).

Die DB wir im Endausbau etwa eine Größe von mehreren hundert MBytes bis zu ein paar GBytes haben. Wie läßt sich da nun mehr Performance mit einem Handelsüblichen Server heraus holen - mit möglichst hoher CPU-Taktrate oder durch den Einsatz von wasweissich Quadcore-Prozessoren? Inwieweit beschleunigt so eine Multithreading die Ausgabe aus 1 Datenbank?

F.Z.