5 Mio Queries/Sekunde?

S

silentiumest

New Member
Hallo,
ich habe ein ziemlich großes Projekt vor. Geplant ist ein MMOG, bei dem 1.000 Spieler gleichzeitig auf einer Welt spielen sollen.

Auf dem Server soll MySql eingesetzt werden. Da die Karte jede Sekunde neu berechnet werden muss, müssen auch entsprechend viele Abfragen gemacht werden. Selects + Updates. Ein Caching wäre also nicht möglich.

Kann man so etwas überhaupt realisieren? Wäre auch möglich mir da 10 Maschinen hinzustellen.
Vielleicht kann man MySql ja auch so einstellen, dass die komplette Datenbank im Arbeitsspeicher liegt.

Oder habt ihr alternative Vorschläge statt MySql?

Bin eher der Programmierer statt der Systemadmin.
 
Last edited by a moderator:
Was für Anforderungen hast du denn an die Datenbank?

Evtl. wäre ja was in Richtung NoSQL für dich (Redis etc.)?
 
Die Datenbank wird nur wenige GB groß werden. Auf sie werden ca. 5 Mio Queries pro Sekunde zukommen. Hälfte Select, Hälfte Update.
Die 5 Mio Queries müssen natürlich in 1 Sekunde fertig sein. Eventuell kann man das Intervall auch auch 2 Sekunden stellen.
 
Bevor du eine relationale Datenbank (und zwangsläufig mehrere Datenbankserver) mit 5.000.000 Abfragen pro Sekunde malträtierst, solltest du vielleicht nochmal deine Software-Architektur und speziell das Datenmodell und dessen Persistierung überdenken.

Auch verteilte Datenspeicher wie Redis oder Memcached sind da mitunter nicht unbedingt die beste Lösung…
 
silentiumest said:
Die Datenbank wird nur wenige GB groß werden.
Click to expand...
Ist es bereits konkreter einzukreisen?
Und wie aufwendig sind die Selects?

Adhoc würde ich antworten: Nutze Oracle auf einer ordentlich performanten Maschine.

Gleichzeitig schließe ich mich z.T. Roger an und würde es ggf. über eine eigene Datenbank-Engine lösen. Aber um das zu beurteilen kenne ich noch zu wenige Details des Projektes.
Evtl. solltest Du wirklich erst in einem Entwickler-Forum anfragen.

huschi.
 
Wenn ich mir das bei Google ansehe, dann wird es im vierstelligen Bereich schon ziemlich dünn. Es gibt einen Blogeintrag, wo von 328000 Queries pro Sekunde gesprochen wird. Da geht es aber anscheinend um eine rein lokal in der DB ablaufende Stored Procedure. Und dann liegt da immer noch ein Faktor 15 zwischen...

Dazu kommen noch Fragen der Netzwerklatenz- und Bandbreite usw. Ich würde da nochmal den Taschenrecher zur Hand nehmen, bevor ich die Hardware bestelle...
 
Ok, vielleicht ein paar mehr Infos zu dem Projekt:

Das ganze ist eine Silverlight-Anwendung, die über WCF mit einem Windows-Server kommuniziert. Der nimmt anfragen von den Clients entgegen uns speichert sie auf einem Datenbank-Server (Linux). Dann gibt es einen weiteren Linux Server, auf dem die Berechnungen für das Spiel gemacht werden. Diese Berechnungen werden wieder in die Datenbank gespeichert und an alle Clients geschickt.
 
Nuja, Facebook is eine der dicksten Seiten im Internet überhaupt und setzt auf MySQL. Da war kürzlich nen Artikel im Golem wie deren Architektur aussieht. Und die haben auf jeden Fall avg:qps von über nen paar Millionen.
 
Facebook hat vielleicht mal MySQL benutzt, jetzt aber bestimmt nicht mehr. Die benutzen NoSQL Datenbanken, welche genau weiß ich jetzt nicht.

An deiner Stelle silentiumest würde ich auch eine NoSQL DB benutzen, sowas wie MongoDB oder CouchDB.
 
Doch Facebook nutzt MySQL:
http://www.mysql.com/customers/industry/?id=85
http://www.mysql.com/customers/view/?id=757

Und wohl auch YouTube.
http://www.mysql.com/customers/view/?id=750
http://highscalability.com/youtube-architecture

Allerdings macht YouTube laut dem Video 100Million Inserts / Day
http://blip.tv/file/537790

Du würdest 432 Milliarden Abfragen machen. Da würde ich doch mal eher irgendwas umcoden denn das ist ja absoluter non-sense ;) Vorallem wenn du nur "Abfragen" machst wäre Memcached absolut das richtige für dich.
 
Last edited by a moderator:
Also wenn hier jemand 5 Millionen Queries pro Sekunde machen will und gerade mal 1000 Spieler online sein sollen, dann ist da mit Sicherheit ein ganz großer Kontruktionsfehler hinsichtlich des Designs in der Software.

Eine Diskussion um die genaue Datenbanksoftware halte ich hier für völlig fehl am Platz. Mit entsprechenden Caching-Lösungen sollte es überhaupt kein Problem sein auch MySQL einzusetzen, welche man im Übrigen für jede andere Datenbank-Lösung auch bräuchte. Zur Not kommt ne Batterie Cache-Server vor die Datenbank und dann passt das schon. ;)

Ohne eine genauere Kenntnis, was diese Software tut kann man hier meiner Meinung nach nur eine schlechte Aussage darüber machen, wie die Serverlandschaft für das Ganze aussehen müsste. Ich kann nur sagen, dass bei 5 Millionen Queries pro Sekunde irgendwo der Wurm drin ist, aber das haben ja schon Andere erwähnt. :)
 
Armadillo said:
Also wenn hier jemand 5 Millionen Queries pro Sekunde machen will und gerade mal 1000 Spieler online sein sollen, dann ist da mit Sicherheit ein ganz großer Kontruktionsfehler hinsichtlich des Designs in der Software.
Click to expand...

Das wären (überschlagen) 5000 Queries pro Spieler pro Sekunde ...
Klingt in der Tat etwas viel *grübel*
 
Da die Karte jede Sekunde neu berechnet werden muss, müssen auch entsprechend viele Abfragen gemacht werden.
Click to expand...
Datenbanken sind zum speichern, nicht zum verteilen! Du willst doch nicht deinen Grossenkel die Map auf der <NAME-eines-Promi-hier> gespielt hat in Echtzeit zeigen? Alles was du willst ist die Map - oder zumindest inkrementelle Updates oder Initialisierungsvektoren- der aktuellen Version verteilt.

Die aktuelle Map-Version kann im RAM-Space eines Daemon gehalten werden und entweder ueber shmop oder Unix-Sockets den Schnittstellen zur Verfuegung gestellt werden. Das gesamte kombiniert mit der Comet long-polling Methode fuer Browserspiele oder eine direkte TCP-Schnittstelle (oder UDP sofern die Voraussetzungen getroffen werden) - voila.
Sofern es notwendig ist kann ein fork sich mit der Archivierung der jeweils aktuellen Version in eine Datenbank beschaeftigen - welche dann exakt 1 Query/Sekunde (INSERT) abkriegt :)

Youtube setzt uebrigens afaik -und genauso wie alle anderen Google-Dienste - massiv auf BigTable.
Ob nur die Verteilung innerhalb der Cloud ueber Bigtable faehrt und im Cluster MySQL schnurrt weiss ich allerdings nicht ;)
 
Last edited by a moderator:
Ich habe mir gedacht, dass ich mit MySql nicht so weit kommen werde.

Wie würdet ihr das jetzt konkret realisieren? Ich weiß jetzt nicht, in wie weit es möglich ist mit der WCF Dienstanwendung direkt Sachen im Ram zu speichern. Dazu werde ich mich im entfernten Bekanntenkreis mal mit einem MS-Profi kurzschließen.
Oder würdet ihr so weit gehen, die Anwendung auf Linux laufen zu lassen und Windows dann mit Linux kommunizieren zu lassen? Auch da müsste ich mich erkundigen, wie man das technisch realisieren kann.
 
*Bauschmerzen* .NET-Anwendung als Server? [*]
In dem Fall musst du wohl ueber Sockets fahren - allerdings nicht die erwaehnten UNIX-style (da diese logischerweise unter Windows nicht zur Verfuegung stehen). Windows-Software kann ich nicht mit Tipps dienen, wuerde es aber spontan ueber UDP-Pakete realisieren. Ob es bessere Methoden gibt oder ob das Rumpfuschen im RAM-Bereich anderer Anwendungen sinnvoll/machbar ist weiss ich aber nicht :)

Sorry.... couldn't .... resist
http://lmgtfy.com/?q=windows+.net+shared+memory

Solltest du nur ein Prozess laufen haben welcher alle Clients versorgt brauchst du uebrigens weder noch - in dem Fall ists ja in seinem eigenen RAM-space bereits gespeichert.


[*] Okok, ich bin ruhig... ich entwickle PHP-Anwendungen als TCP-/UDP-Server. (Welches uebrigens eine erstaunlich gute Performance zutage legt sofern man richtig programmiert :) )
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top