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

C'est assez amusant quand-même.

Il faut bien évidemment faire les bon choix techniques avant de commencer à développer, mais il faut arrêter de voir tout de suite dans le "gros", faut arrêter de rêver.

C'est très peu probable que ce jeu en ligne fasse 300k requêtes par seconde.
MySQL ou PostgreSQL peuvent très bien convenir. Vu qu'à ce que j'ai compris le jeu utilisera un ORM il sera alors plus ou moins aisé de faire la migration sur un autre SGBDDR si un jour le besoin est.

Je vois qu'SQLpro est plutôt pro-Microsoft (tant mieux vu qu'il est MVP).
Mais il faut arrêter de dénigrer les autres technologies, comme Java.
Java reste moins performant que les langages compilés tel que le C, mais il reste quand-même plutôt bon.
La plateforme .Net et le C# sont certainement au même niveau que le Java.
SQL Server est certes certainement très bon mais pour un simple jeu par navigateur, pourquoi ne pas utiliser des technologies libres ?

Citation:

---

Envoyé par iMeee

SQL Server est certes certainement très bon mais pour un simple jeu par navigateur, pourquoi ne pas utiliser des technologies libres ?

---

La demande initiale est bien quel SGBD pour gérer 300k requêtes par secondes.

Je pense aussi comme Jester et vous que c'est probablement vu trop gros pour commencer, mais on ne peut pas reprocher à SQLPro de répondre à la question.

Bonjour

Citation:

---

Envoyé par Fabien Henon

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.

---

SQL Server existe en version gratuite (SQL Server Express). Vu ce que vous décrivez, vous serez vite contraint de bypasser votre ORM pour certaines requêtes complexes ou spécifiques (faire des procédures stockées, ...) et alors changer de SGBDR ne se fera pas sans mal (malgré votre ORM ou toute surcouche d'abstraction que vous utiliserez)...

Citation:

---

Envoyé par Waldar

La demande initiale est bien quel SGBD pour gérer 300k requêtes par secondes.

Je pense aussi comme Jester et vous que c'est probablement vu trop gros pour commencer, mais on ne peut pas reprocher à SQLPro de répondre à la question.

---

Par contre, il est urgent qu'il arrête d'écrire des contre-vérités en dehors de son domaine d'expertise.

D'une part l'excellente petite présentation du début du topic montre qu'un jeu peut servir 2 millions d'utilisateurs avec quelques dizaines de serveurs alors qu'il est écrit en Ruby.

Fact: Ruby est grosso merdo entre 10 et 50x plus lent que Java (l'implémentation du calcul de pidigits n'est manifestement pas optimisée). Si Java était si peu performant, Oracle n'aurait pas pris la peine d'intégrer une JVM dans son moteur de bases de données et d'en faire l'un de ses principaux chevaux de bataille.

Donc si ça marche en Ruby, il n'y a pas de raison que ça ne marche pas en Java, pour peu qu'on fasse un peu attention à ce qu'on fait. Et d'ailleurs, pas mal de jeux en ligne ont leurs serveurs écrits en Java.
Ensuite, PostgreSQL est capable de répondre à 350 000 queries/sec et 14000 écritures/sec (seulement) sur une machine 64 cores. Il faudrait vraisemblablement mettre plusieurs instances en parallèle. Mais même si on n'atteint pas un tel débit, comme le montre la présentation, le vrai secret est de limiter les accès à la base en tapant au maximum dans les caches redis ou memcache. Si le backend est optimisé, on peut diviser par 5 ou 10 les accès à la Bdd.
Donc en principe, si on a une grosse machine multicore pour la base doublée d'un cache redis sur d'autres serveurs, et d'un moteur de jeu écrit en Java sur quelques serveurs supplémentaires, il est parfaitement possible d'atteindre des centaines de milliers de joueurs pour un jeu Flash en ligne.

Après, il y a d'autres problèmes, qui sont décrits dans le slide suivant (qui fait suite au slide d'avant: http://fr.slideshare.net/wooga/20121...e-game-servers). En gardant l'état de la partie complètement en RAM et en écrivant sur le disque uniquement quand le joueur quitte l'application (ce qui a impliqué de réécrire leur backend de Ruby à Erlang), ils ont divisé par 100 le nombre d'écriture en base, et sont donc passés de 150+ serveurs à 3 serveurs seulement, tout en augmentant la disponibilité.
Leur 4e backend gère les parties multijoueurs, et leurs exigences ressemblent un peu à ce qu'offrent des bases NoSQL comme HBase et Cassandra.
http://fr.slideshare.net/wooga/you-a...tiplayer-games
Ils ont choisi Riak.