MySQL maximale zugriffe pro sekunde
So, nun hab ich mal eine Frage an die Datenbankprofis.
Ich habe für ein Hamsterspiel an dem ich arbeite eine Datenbank in MySQL erstellt, die die Daten der einzelnen Hamster mitschreibt. Keine speziellen Daten, sondern wird lediglich beim auftauchen eines neuen Hamsters einmalig eine UUID des Hamsters, des Besitzers, das Datum und der Name des Besitzers in die Tabelle geschrieben. Soweit so gut, da aber von anderen Tieren in diesem Spiel ( die kein MySQL Backend haben ) bekannt ist das es davon tausende gibt und auch täglich hunderte neu dazu kommen, wollte ich nun fragen ob eine MySQL Datenbank eine solche Flut überhaupt schafft. Ich rechne grob das in Spitzenzeiten ca 20 neue Hamster gleichzeitig auftauchen. Schafft eine MySQL das ?
Hier die Hardwaredaten des Systems auf welchem die Datenbank läuft:
- Intel Core 2 Quad @ 2.60
- 12 GB RAM
- 1 GB/s anbindung
- MySQL 5.2
- Ubuntu Server 10.10 64 bit
3 Antworten
Wenn du eine sehr schnelle Datenbank suchst ist Redis glaube ich gar nicht verkehrt. Hier der Wikipedialink zu: http://de.wikipedia.org/wiki/Redis
ich zitiere: "Bis zu ca. 100.000 Schreibvorgänge und ca. 80.000 Lesevorgänge pro Sekunde sind auf herkömmlicher Hardware möglich"
Hört sich doch mal vielversprechend an...;) Die technischen Daten deines Systems sind ja eigentlich ausreichend, daran sollte es nicht scheitern :)
Ich kenn mich mit MySQL nicht sonderlich gut aus, aber 20 neue Datensätze pro Sekunde sollte jedes Datenbanksystem problemlos hinkriegen.
Du kannst doch einfach mal probieren, was der Server so verarbeiten kann. Also eine Insert Into-Abfrage, bei der mehrere Tausend Datensätze auf einmal geschrieben werden, sind kein Problem. Wie es aussieht, wenn mehrere Datensätze in einzelnen Abfragen ankommen, weiß ich nicht.
Du kannst den Server aber mal mit mehreren einzelnen Abfragen füttern und gucken, was passiert. Ich hab bis jetzt nur über Plesk mit einer MySQL-Datenbank gearbeitet. Da kann man im SQL-Fenster mehrere Abfragen untereinander schreiben, die dann nacheinander ausgeführt werden.
Die Frage ist hier immer, wie die SQL-Syntax ausgenutzt wird. Wenn ich grundsätzlich meine Daten immer über ein 'SELECT * FROM blah;' hole und dann die benötigten Daten mit PHP zurecht rücke, bekommt man eher Performance-Probleme, als wenn man sich an Datenbank-Grundlagen hält.
Wenn man immer schön dafür sorgt, dass die Datenbank in der dritten Normalform ist, ist man schon auf dem richtigen weg. Über entsprechend formulierte SELECT-Ausdrücke mit entsprechenden WHERE's usw. bekommt man die Datenflut in der Regel sehr klein. Das hat auch den Vorteil, dass man mit PHP kaum noch etwas "analysieren" oder zurechtfrickeln muss. Dann sind auch mehrere tausend Anfragen pro Sekunde absolut kein Thema. Selbst wenn die Datenbank und der Webserver auf demselben Host laufen.
Nur bei zu großer Flut sollte man dann strikt Datenbank und Webserver trennen. RDBMS an sich haben aber den Vorteil, dass man einzelne Teile auch auf unterschiedlichen Hosts auslagern kann. Über entsprechende JOINs, kann man die Daten aber problemlos wieder zusammensetzen. Ich denke aber nicht, dass Du mit solchen "kleinen" Aufgaben aber irgendwelche komplizierteren Lösungen finden müsstest. Achte einfach darauf, nur genau die Daten abzurufen, die Du auch brauchst. Achte darauf, dass deine Daten in der 3NF sind und achte auf referenzielle Integrität. Dann wirst Du merken, wie leistungsfähig auch MySQL ist.
Beim lesen würde ich da ohne mit der Wimper zu zucken zustimmen, da können es auch tausend pro sekunde sein, jedoch gibt sich MySQL beim schreiben und vor allem beim neu Erstellen recht langsam, daher fragte ich ;)