Ressourcen optimal nutzen...

[ShOrtYk]

Hallo,

ich entwickel momentan ein kleines Browsergame und stehe vor der Frage, wie man den Ressourcenaufwand für die DB-Anfragen möglichst gering halten kann.

Wie immer - wenn jemand eine nette Seite im Netz kennt, die sich umfangreich mit dem Thema beschäftigt, wäre ich auch mit einem Link zufrieden, aber ich konnte leider nichts finden.

Ich habe nun also das Problem, dass ich nicht weiß, welche Aufteilung innerhalb der MySql Tabellen sinnvoll ist.

Um das mal am Beispiel Userdaten zu verdeutlichen.
Wäre es z.B. besser, wenn man die Zugangsdaten (nickname, email, pw...) und die Spieldaten (rohstoffe etc.) in zwei unterschiedliche Tabellen speichert, oder macht das auch keinen Unterschied, wenn man beides in eine packt?

Heißt - zählt letztenendes nur die Anzahl der Anfragen auf unterschied. Tabellen oder ist nur die Gesamtanzahl der Anfragen an die DB ausschlaggebend?

Ich hoffe, mein Problem ist deutlich geworden.

Danke für jede Hilfe
Markus

 

[hpvw]

Mir ist immer wieder aufgefallen, dass in Verbindung mit PHP vor allem die Anzahl der Abfragen, also die Anzahl der Aufrufe von [phpf]mysql_query[/phpf] relevant ist.

Wenn Du einen Join oder Subquery anbringen kannst, ist es meistens performanter, als in einer mysql_fetch_*-Schleife jeweils ein neues Query zu starten.

Wenn Du hierarchische Strukturen hast, auf die Du überwiegend lesend zugreifst, ist das MPTT-Model bzw. Nested Sets wesentlich performanter, als die übliche Adjazenz-Liste (parentId).

Wenn Du ordentlich Objekte kapseln willst, z.B. User, von denen ggf. in einem Skript sehr viele als Gegner abgefragt werden, solltest Du Dir überlegen, wie Du möglichst alle relevanten auf einmal ausliest. Der inperformante Weg wäre nur eine Klasse User zu implementieren, die im Konstruktor eine ID übergeben bekommt und sich die restlichen Daten dann einzeln selbst aus der DB zieht. Besser wäre dann z.B. eine User-Verwaltungsklasse, die gleich alle (relevanten) aus der DB zieht und die Daten den jeweiligen Objekten zuweist bzw. von der sich die Objekte Ihre Daten holen können.

Soweit erstmal zum Query-Sparen.

Ein weiterer Punkt ist die Vermeidung von zu umfangreichen Berechnungen im Query. Ich hatte hier zum Beispiel mal ein Query zur Berechnung der Distanz zwischen zwei Geokoordinaten mit viel Sinus, Cosinus und Tangens gepostet. Das hat natürlich rein wissenschaftlichen Charakter. Möglicherweise sind Stored Procedures noch die bessere Wahl gegenüber der Berechnung in PHP. Das habe ich jedoch noch nicht getestet.

Wenn sich z.B. für eine Bedingung, die die Datenflut erheblich einschränkt eine umfangreiche Berechnung nicht vermeiden lässt, sollte diese als letzte stehen, so dass MySQL diese Bedingung möglichst selten prüfen muss. Um bei der Distanz zu bleiben ("suche alle User, die keine 200km auseinander wohnen") könnte man zum Beispiel das Gebiet zunächst quadratisch eingrenzen, was verhältnismäßig wenig Ressourcen kostet und dann mit einer UND-Bedingung verknüpft die Berechnung der exakten Distanz hinterher schieben. Trifft die erste Bedingung nicht zu, wird der Optimizer bei UND auf die Prüfung der zweiten verzichten.

Beim Datenbank-Design ist es sicher etwas performanter, wenn die DB nicht vollständig normalisiert ist und ggf. ein paar Hilfswerte speichert/cacht. Allerdings bin ich damit bisher immer auf die Schnauze gefallen, weil dann doch noch mal etwas geändert werden musste, was unnormalisiert Unmengen mehr Arbeit macht oder zu Inkonsistenzen führte, die praktisch nicht mehr aus dem System zu entfernen waren.

Last but not least sollte der Query-Cache aktiviert sein.

Jetzt fällt mir erst mal nichts mehr ein, aber vollständig ist das sicher noch nicht.

Gruß hpvw