[MySQL] "Performanceberatung"

[CPU]

Hallo Leute,

ich benötige mal zu folgenden Szenario Eure Meinung; ich habe folgende zwei Tabellen:

fall <- 1 ------ n -> fall_action

• `fall` sind im grunde Kundendaten
• `fall_action` enthält (1) Aufgaben für einen Fall (von den Mitarbeitern gesetzt z.B. "dies und das machen/organisieren"), (2) Freitexte (wenn der Kunde anruft und eine Sonderwunsch hat wird das kurz vermerkt) und (3) Ereignisse des Falls (z.B. Übergabe an einen anderen Mitarbeiter)

Noch ein Paar Zahlen zu den Datenmengen und der Umgebung:

• 1.000 < Anzahl Zeilen in `fall` << 100.000
• 10 < Anzahl Zeilen fall_actionen pro Zeile in `fall` < 30
• 8 Nutzer arbeiten "semigleichzeitig" mit der Datenbank -> nicht so frequentiert
• es werden nur partielle SELECTs auf dieser Tabelle ausgeführt (d.h. SELECT * FROM fall_action WHERE fall_id_FK = 42); keine komplizierten Sachen wie JOINs o.ä.
• MySQL auf einem Linux-Server
• `fall_action` hat 10 Attribute (8xInt, 1xVARCHAR(20), 1xLONGTEXT)

Also, um zum Punkt zu kommen: es kommt ja eine schon mehr oder weniger große Tabelle mit durchschnittlich 100.000 Zeilen (schätze ich mal) auf der dann nur SELECTs ausgeführt werden. Und meine Frage ist nun: ist das so in Ordnung oder wird mir das performancemäßig vor die Füße fallen. D.h. muss ich eine vertikale/horizontale Partitionierung der Tabelle in Betracht ziehen?

Viele Grüße,
CPU

 

[r0b0t]

Index auf fall_id_FK anlegen und alles wird gut. Du kannst dir ja auch FALL00001 bis FALL99999 und je Fall 10-30 ACTION Testdatensätze generieren und es ausprobieren.

 

[DHundt]

Mahlzeit,

wie r0b0t schon schrieb, wenn sich an deiner Query nix ändert

Index auf fall_id_FK anlegen und alles wird gut

Wenn du mehrere parallele Schreib- und Leseanfragen erwartest,
könnte eventuell eine Umstellung der Engine auf "InnoDb" einen Performance-Schub verpassen.
Aber bei 8 Personen seh ich da noch kein Problem.

Sollten die Datenmengen zu groß werden, kannst du auch über Partitionierung nachdenken. An der Anfrage muss man dann nix ändern.

Gruß

 

[Daaron]

InnoDB sollte immer verwendet werden, ist einfach etwas flotter als MyISAM. Wenn man aber wirklich eine Performance-Steigerung haben will, dann sollte man MySQL durch MariaDB ersetzen.
Wenn man außerdem noch WIRKLICH Performance-Sorgen hat, dann sollte man die SQL-Daten replizieren. Schreib-Zugriffe gehen zu 100% auf den Master, alle Lese-Zugriffe gehen an einen oder mehrere Slaves.

 

[Hancock]

Also wenn das nur einfache selects sind, würde ich sagen, dass, solange du genügen RAM hast, du keine Probleme bekommen wirst.
(Hab grad bei mir ne Tabelle mit 4 Mio. Zeilen (3*int und ein varchar), da gehen pro Sekunde 50 000 selects durch (Core2Quad Q6600)).

 

[Daaron]

Man muss den RAM aber auch ausnutzen... das heißt: Nicht die Standard-Einstellungen des Paketes übernehmen, sondern die gesamten Caches etc. ordentlich hochjagen. Debian (6) hat z.B. bei MySQL sehr konservative Einstellungen, die dringend geändert werden müssen. Bei manchen Linux-Distributionen ist im Standard sogar der Cache aus (z.B. OpenSuSE 11)...

 

[Hancock]

Du meinst die Query-Cache? Die machste am besten auch aus...

(Mit der Query-Cache hab ich maximal 10 000 geschafft, weil die Cache für jede Abfrage gelockt und durchsucht werden muss, was arg langsam ist. InnoDB kann da Row-Level-Locking und genauso gut cachen)

Setzt den innodb_buffer_pool_size hoch (z.B. 1.5G bei 32 bit MySQL oder je nach RAM auf 50-75%) und verwend am besten auch InnoDB für deine Tabellen.

 

[Daaron]

Spätestens wenn die Anfragen doch etwas komplexer werden führt um den Query Cache kein Weg drumrum. Ich habe selbst Tests mit einer Magento-Installation mit ~2000 sehr komplexen konfigurierbaren Artikeln gemacht. Bei abgeschaltetem Query Cache waren 2 identische Produktaufrufe sehr langsam. Bei aktivem Cache gehen alle Aufrufe nach dem ersten deutlich schneller.

 

[Hancock]

Ich zitier mal den TE:

keine komplizierten Sachen wie JOINs o.ä.

Und wenn du oft Modifikationen machst, dann ist deine Query-Cache nicht sehr sinnvoll. Ein Shopsystem ist ja hauptsächlich Read-Only.

 

[Daaron]

Natürlich. Und genau deshalb habe ich auch zu einer Master-Slave-Replikation geraten. Die hebelt einige Probleme häufiger Modifikationen aus.

 

[Hancock]

Die Master-Slave-Replikation hilft schon, aber ich denke, ein normaler Computer (8 oder 16 GB RAM) sollte allein locker genügend Leistung haben, um die ganze Anwendung laufen zu lassen.
Ich denke, dem TE geht es vor allem um die Frage, ob er schon "Angst" haben muss, dass er kompliziert optimieren muss, und da denke ich, dass er das nicht muss.