Le bon SGBD pour un jeu vidéo en ligne sur navigateur à fort trafic [Résolu]

[Fabien Henon]

Bonjour,

Je suis en train de développer un jeu vidéo sur navigateur. Le projet avance bien et je me pose des questions techniques par rapport à la résistance à la charge des serveurs.

Par rapport au serveur hébergeant le jeu les problèmes de surcharge peuvent être évités en ayant plusieurs serveurs et en redirigeant les joueur vers des serveurs moins chargés.

Par contre pour la BDD je me demande comment faire. En effet les données sont les mêmes pour tous les joueurs et donc je risque d'avoir environ 300 000 requêtes à la seconde (je suppose que MySQL ne tient plus le coup à ce rythme ?).

Je me pose alors plusieurs questions :
- Quel SGBD est-ce qu'il faudrait que j'utilise pour résister à autant de requêtes et aussi pour stocker plusieurs milliards de données (il faudrait donc aussi que les index supportent des très grandes valeurs)
- Est-ce qu'il faudrait que je partage le jeu en plusieurs BDD sur plusieurs serveurs ? Et que les joueurs choisissent un serveur et ne le quittent plus ?

J'avoue ne pas encore très bien savoir comment gérer tout ça et j'aimerais avoir vos conseils. De plus je ne connais pas les limites des SGBD.

Bien sûr quand je parle de 300 000 requêtes à la seconde j'anticipe mais ça reste quelque chose de réaliste et qui correspond à notre prévisionnel sur ce projet, il me semble donc important que je prévois tout ça dès la conception plutôt qu'une fois le problème de surcharge rencontré. Lorsque je parlais avec des développeurs de jeux vidéo ayant bien marchés ils me disaient que le goulot d'étranglement est la BDD.

Je vous remercie par avance de votre aide et de vos conseils !

[Jester]

300k requêtes à la seconde? Donc disons 300k joueurs faisant une action en même temps sur la même instance du jeu?

C'est irréaliste.

Le reste des réponses est sur :
http://fr.slideshare.net/wooga/10000...he-splash-2011

La BD est le goulot d'étranglement ça dépend, notemment de la compétence des gens. En tout cas, il y a toujours des solutions.

[Fabien Henon]

La présentation est très intéressante !

Cependant je ne suis pas sûr d'avoir tout compris.

Déjà au début si j'ai bien compris il y avait 2 BDD. Est-ce que ça veut dire que le jeu était divisé en instances et que les joueurs devaient en choisir une ? Ou bien est-ce que ça veut dire qu'il y avait un système avec MySQL qui permet de gérer une BDD sur plusieurs serveurs ?

Apparemment MySQL tient donc pas mal le coup lorsqu'on a beaucoup de trafic ? PostGreSQL n'est pas meilleur à ce niveau là ?

Est-ce qu'on a le temps en pratique de voir venir les problèmes et de les régler ou bien est-ce qu'il faut vraiment tout prévoir à l'avance ?

D'après ce que j'ai compris, MySQL peut tenir le choc jusque 1000 opérations de mise à jour par seconde ?
Si on dépasse ce nombre que se passe t'il concrètement ? Latence ? Crash du serveur ?

Merci de vos réponses

[Jester]

Ca dépend de pas mal de paramètre ce qui arrive, dans un cas c'est ça. Tout se gère toujours avec un peu de temps et de l'argent quand les gens sont compétents.

Faites votre produit et benchmakez pour trouver la limite de votre infrastructure.

Mais d'abord faut faire le produit. Et c'est pas la choix de la DB qui va influer de beaucoup sur la qualité du produit. Prennez là où vous êtes à l'aise.

[Fabien Henon]

D'accord merci !

Et par contre au niveau de l'architecture de la BDD du site, est-ce que ça vaut le coup de faire plusieurs instances du jeu et de la BDD ? Pour ainsi répartir la charge ? Ou bien est-ce que la BDD est censée tenir le coup avec une seule instance ?

[Jester]

Ca peut mais souvent c'est une décision de design et pas une limitation technique (ou à la rigueur une limitation de la compétence des devs)

[al1_24]

Si l'accès au SGBD est effectué au travers de requêtes optimisées et respectant toutes les règles du langage SQL, il ne sera pas difficile de changer de SGBD en cours de développement, voire d'exploitation.
Cela demande bien sur d'être rigoureux et de ne pas céder à la facilité des à-peu-près que propose mySql.

[SQLpro]

Envoyé par Fabien Henon

...
Par contre pour la BDD je me demande comment faire. En effet les données sont les mêmes pour tous les joueurs et donc je risque d'avoir environ 300 000 requêtes à la seconde (je suppose que MySQL ne tient plus le coup à ce rythme ?).

Tout dépend de la volumétrie... Sachant que les SGBDR mettent toutes les données en mémoire, si vous avez affaire à de petites requêtes durant moins de 1 ms, alors cela ne fait que 300 s de CPU... Si le SGBR cjoisit sait les faire en parallèle, par exemple répartit sur 64 cœurs, cela ne fait plus que 4,68 s de CPU et si enfin il est capabale de faire du "rescan" c'est à dire réutiliser un scan de table en cours pour une autre requête, vous pouvez diviser encore ce chiffre par 8 ou 10.. On arrive alors à 0,58 s de CPU et vous êtes OK avec un seul serveur...
Il faut aussi que votre SGBDR supporte le pooling de connexion.

Bref, au panier MySQL et PostGreSQL ! visez au moins SQL Server...

Et si cela ne suffit pas, il faudra paralléliser les serveurs, mais ça c'est une autre paire de manche !
A +

[Fabien Henon]

Bonjour et merci pour vos réponses !

Pour compléter un que ce que je dis, nous utilisons le langage Java pour le site et nous utilisons JPA et Hibernate (j'avoue ne pas bien savoir distinguer leur utilité) pour la gestion de la BDD.

Pourquoi MySQL et PostGreSQL seraient à mettre au panier ? Ils ne supportent pas la parallélisation des requêtes ?

SQL Server serait donc un meilleur choix ?

Je suppose qu'il nous serait assez facile de commencer avec PostGreSQL et de migrer sur SQL Server dès que la charge devient trop importante, qu'en pensez-vous ?

[SQLpro]

Envoyé par Fabien Henon

Bonjour et merci pour vos réponses !

Pour compléter un que ce que je dis, nous utilisons le langage Java pour le site et nous utilisons JPA et Hibernate (j'avoue ne pas bien savoir distinguer leur utilité) pour la gestion de la BDD.

Pourquoi MySQL et PostGreSQL seraient à mettre au panier ? Ils ne supportent pas la parallélisation des requêtes ?

SQL Server serait donc un meilleur choix ?

Je suppose qu'il nous serait assez facile de commencer avec PostGreSQL et de migrer sur SQL Server dès que la charge devient trop importante, qu'en pensez-vous ?

La vous partez dans les choux tout de suite. Java est un langage des plus lents. Si vous envisagez sérieusement 300 000 requêtes SQL à envoyer par seconde à un SGBDR en java, je vous conseille de prévoir un budget conséquent pour acheter 10 000 serveurs frontaux !!!
Et en plus avec la pire merde qui soit Hibernate... c'est bien plus encore qu'il faudra.

MySQL se vautre à partir d'une dizaine de user, là ou PostGreSQL arrive à sa limite de 100 en toute sérénité... Il faut rajouter pgPoll, mais ça gère pas beaucoup plus (quelques centaines de connexion en //)

mais pour SQL Server, la limite est nativement de 32 000 !!!

En sus ni MySQL ni PostGreSQL ne savent paralléliser les requêtes...

Avant de vous lancer dans une telle aventure je vous conseille de lire au moins ces deux papiers :
http://img1.lemondeinformatique.fr/f...s-epaisses.pdf
http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[Fabien Henon]

Java peut être lent, mais qu'en est-il de l'ASP via le C# ou le VB, PHP, RubyOnRails qui sont tous aussi des langages interprétés ? Les différences de performances ne devraient pas être si grandes ?

Hibernate est-il si mauvais que ça ? N'est-il pas utilisé par certains sites à fort trafic ?

Par rapport au budget de départ que nous avons je pense qu'il faudrait que nous commencions avec un SGBDR gratuit comme PostGreSQL et que nous migrions ensuite sur SQL Server par exemple dès que la charge se fait sentir.

A côté de ça je pense que l'on va designer notre jeu de façon à avoir plusieurs instances qui soient sur plusieurs serveurs, ainsi la charge sera réduite sur chacun des serveurs.

Je lis les papiers de ce pas !

[Jester]

En même temps je vous ai montré une présentation qui montre que Wooga sait gérer 100k db ops par seconde dont 50k update. Zynga donne aussi ses méthodes de stockage qui ont aussi débuté avec MySQL.

Ni Java ni MySQL ne seront le problème dans les prochains temps. Le problème sera d'abord de faire un jeu qui attirera assez de joueur pour que la question se pose et ensuite la compétence des devs.

Tant que vous n'êtes pas au stade de beta privée, vous pouvez même utiliser H2 si ça vous permet d'aller plus vite.

Au travail

[SQLpro]

Envoyé par Fabien Henon

Java peut être lent, mais qu'en est-il de l'ASP via le C# ou le VB,

C'est nettement plus performant... car optimisé pour Winows... Exemple site fnac.com, cdiscount, ooshop...

PHP

pas mal non plus

, RubyOnRails qui sont tous aussi des langages interprétés ? Les différences de performances ne devraient pas être si grandes ?

Plus de couche = plus lent. En sus on ne peut optimiser un même langage que sur une seule plateforme.... Seuls les grands éditeurs arrivent à optimiser plus finement...

Hibernate est-il si mauvais que ça ? N'est-il pas utilisé par certains sites à fort trafic ?

Absolument aucun. Certaines entreprise ont même fait faillite à cause de la lenteur d'Hibernate lors de la montée en charge...

Par rapport au budget de départ que nous avons je pense qu'il faudrait que nous commencions avec un SGBDR gratuit comme PostGreSQL et que nous migrions ensuite sur SQL Server par exemple dès que la charge se fait sentir.

Une fois ferré avec un SGBDR, vous aurez du mal à en sortir car le SQL est rarement compatible d'un SGBDR l'autre.

A côté de ça je pense que l'on va designer notre jeu de façon à avoir plusieurs instances qui soient sur plusieurs serveurs, ainsi la charge sera réduite sur chacun des serveurs.

C'est possible pour les serveur WEB et quasiment impossible pour les SGBDR. En effet il faudrait que TOUS possèdent la même information au même moment ce qui suppose de distribuer les transactions sur les n serveurs. Donc, mis à part Oracle en architecture RAC (et il faut concevoir l'appli et le modele de donées qui va avec) ou SQL Server avec une mode de réplication transactionnel, votre systèmes est infaisable.

Je lis les papiers de ce pas !

Pourquoi ne pas commencer par la version gratuite de MS SQL Server (Express). Certe les bases sont limtées à 10 Go, mais vous pouvez en concevoir 32 000 sur la même instance et allez jusqu'à 10 instances par serveur.
Ensuite passez à l verison Web dont le prix de licence est modique et sensuite en fonction de la mntée en charge, allers vers la standard ou l'enterprise...

A +

[Fabien Henon]

Merci de vos réponses, je tiens compte de vos remarques à tous.

Juste par rapport à faire plusieurs instances de BDD en fait je ne cherche pas à paralléliser les BDD, mais plutôt à designer le jeu pour diviser les joueurs sur des BDD différentes mais avec des données différentes (les français d'un côté, les anglais de l'autre par exemple, ...)

[Fabien Henon]

Par contre je me demandais si quand on utilise Hibernate en précisant directement les requêtes compliquées pour optimiser le tout, les performances étaient toujours aussi mauvaises ?

Par exemple il m'arrive lorsque la requête utilise des jointures de la préciser manuellement pour avoir une requête bien faite qui n'engendre qu'une seule requête sur la BDD plutôt que plusieurs en temps normal.

[SQLpro]

Voici les métrqiues de Hibernate (entre autres) vous y constaterez qu'un simple UPDATE met 24 fois plus de temps qu'un UPDATE fait directement sur le SGBDR sans passer par la couche objet.
http://ormeter.net/

De plus si vous voulez des performances il faut développer UNIQUEMENT en procédures stockées et ne jamais faire de requêtes initialisées depuis le client.

A +

[Fabien Henon]

Merci pour vos réponses, ça m'est très utile !

[CinePhil]

Envoyé par SQLpro

Voici les métrqiues de Hibernate (entre autres) vous y constaterez qu'un simple UPDATE met 24 fois plus de temps qu'un UPDATE fait directement sur le SGBDR sans passer par la couche objet.
http://ormeter.net/

De plus si vous voulez des performances il faut développer UNIQUEMENT en procédures stockées et ne jamais faire de requêtes initialisées depuis le client.

A +

Une preuve de plus qu'un ORM est un Objet Réellement Merdique !

[alassanediakite]

Salut

Envoyé par SQLpro

Voici les métrqiues de Hibernate (entre autres) vous y constaterez qu'un simple UPDATE met 24 fois plus de temps qu'un UPDATE fait directement sur le SGBDR sans passer par la couche objet.
http://ormeter.net/

De plus si vous voulez des performances il faut développer UNIQUEMENT en procédures stockées et ne jamais faire de requêtes initialisées depuis le client.

A +

La discussion est certe résolu, mais juste une remarque. Je pense que lien parle de NHibernate et non de Hibernate. Mes excuses si je suis dans le choux
@+

[Jester]

Dans un thread qui explique que php est plus rapide que Java, qui préconise d'utiliser SQL Server alors qu'aucun jeu de ce type n'utilise SQL Server dans la concurrence, je crois qu'on est plus à cette approximation près.