Quels SGBD sont assez rapides pour un jeu en ligne (quelques milliers de joueurs)? [fermé]

Je fais actuellement un jeu MMORPG, qui pourrait avoir plusieurs milliers de joueurs en ligne en même temps (probablement pas; juste un vœu pieux). Nous voulions d'abord utiliser MySQL, mais j'ai entendu dire qu'il n'était pas assez rapide pour cette échelle.

Quel SGBD est assez rapide? À quoi ressemble SQL Server (comme j'ai appris SQL Server à l'école)?

C'est une question vraiment difficile à répondre. Vous pouvez prendre la plate-forme de base de données la plus rapide au monde, concevoir un schéma horrible, écrire une application merdique autour d'elle, puis être tenté de blâmer la plate-forme de base de données. Dans le même temps, vous pouvez utiliser gratuitement SQL Server Express et, avec la bonne conception, la logique d'application et une approche d'évolutivité raisonnable (par exemple, la mise à l'échelle des lectures par la mise en cache des données, etc.), vous pouvez écrire une application qui gère des milliers de utilisateurs aucun problème.

Dois-je croire que SQL Server peut gérer des milliers d'utilisateurs? Absolument. Dois-je croire qu'Oracle et DB2 peuvent également le faire? Certainement. MySQL? Pas sûr, pas assez d'expérience là-bas. Accès? Probablement pas un choix judicieux du tout. Si vous êtes familier avec SQL Server, je suggère que c'est la voie que vous envisagez, gardez à l'esprit que votre choix de SGBDR ne dictera pas en soi le succès ou l'échec.

Permettez-moi de le dire ainsi, vous vous souvenez de GameSpy Arcade du début / milieu des années 2000? Il exécutait des milliers de jeux et fonctionnait tous sur SQL Server et supportait des dizaines de milliers d'utilisateurs à la fois (oui, nous avions plusieurs serveurs SQL là-bas faisant diverses choses). Tout dépend de la conception de la base de données et de la façon dont vous utilisez le système. Faites-le correctement et votre projet réussira, faites-le incorrectement et votre projet échouera, mal.

La bonne réponse dépend beaucoup de la plate-forme pour laquelle vous programmez.

Il se trouve que quelqu'un a posé cette question pour une plate-forme spécifique dans StackOverflow il y a environ 1,5 an.

Que ce soit MySQL, SQL Server, Oracle, PostgreSQL ou un autre SGBDR, vous devez être très créatif avec l'infrastructure de base de données. Si vous avez un chéquier ouvert pour le matériel et un SGBD de qualité industrielle, Oracle est pour vous (si en fait, Oracle RAC serait plus souhaitable). Si vous développez à l'aide d'IIS et d'un environnement Microsoft, il s'agit de SQL Server jusqu'au bout. Si vous avez des soucis budgétaires et que vous voulez une apparence Oracle, PostgreSQL à la rescousse. Si vous avez des problèmes budgétaires, une imagination débordante et que vous souhaitez microgérer le moteur de stockage à votre guise pour prendre en charge la conformité ACID, les lectures à grande vitesse et une variété d'architectures de réplication, je dirais de manière préjudiciable MySQL.

Le SGBD devrait être le moindre de vos soucis avec MMORPG. Les problèmes de programmation présentent toujours de plus gros poissons à faire frire. Alors, prenez votre décision avec prudence et sagesse, car quel que soit le SGBD que vous choisissez, vous devez vivre avec (de la même manière que FaceBook doit vivre avec MySQL ).

Ce n'est pas la bonne question. Les performances de votre jeu dépendront de l'architecture complète et de la pile technologique que vous choisirez et de la façon dont il sera mis en œuvre. Le SGBD n'est qu'un composant de la pile. Je risquerais de deviner qu'il est peu probable que le SGBD soit un facteur limitant les performances, à moins que vous architecturiez les choses très mal. Votre couche de domaine, le cache et la façon dont vous distribuez et développez le site semblent être des préoccupations beaucoup plus importantes.

Tout SGBDR tombera avec l'échelle en fonction de la façon dont il est configuré, mis à l'échelle et comment l'application l'utilise.

Je pense que vous avez deux questions en une. Le premier, "quels SGBD sont capables de conserver les données de jeu de manière efficace." (subjective, à mon humble avis) La seconde, "comment puis-je faire évoluer ce SGBD pour qu'il fonctionne avec des milliers d'utilisateurs?"

De nombreux services en ligne ont trouvé la combinaison de MySQL et Memcached pour fournir d'excellentes performances et évolutivité. Cependant, il arrive un moment où cette solution échoue également. Cependant, cela pourrait être exactement ce dont vous avez besoin.

De plus en plus de services en ligne prennent en sandwich une solution NoSQL dans leur architecture. J'ai une certaine expérience avec CouchBase et je le trouve utile.

Le code, la conception et vos disques (pour les écritures) déterminent généralement les performances. Pas la plateforme.

Vous pouvez jeter un œil à CUBRID . C'est un SGBDR open source qui est très "chaud" en Corée du Sud en ce moment. Il est supposé fonctionner le mieux / très rapidement pour les applications Web avec un grand nombre d'utilisateurs (ils disent 50k ou quelque chose comme ça).

Je pense que n'importe laquelle des principales bases de données peut gérer la charge si elle est bien conçue. Malheureusement, j'estimerais que moins de 1% de toutes les bases de données sont bien conçues. (J'ai personnellement traité des données provenant de milliers de bases de données différentes exécutant une grande variété de fonctions, donc je pense que j'ai une bonne idée du manque de qualité qui existe dans le monde réel.)

Je vous suggère fortement d'obtenir des livres sur le réglage des performances de la base de données que vous choisissez et de les lire attentivement avant de commencer à concevoir. Il y a beaucoup de choses qui aideront votre base de données à mieux fonctionner et qui devraient être conçues dès le départ. Le simple fait de savoir comment écrire des requêtes performantes et des index de conception est essentiel pour obtenir une bonne conception. Ce type d'étude et de performance intégrée n'est pas une optimisation prématurée. Il n'y a aucune raison d'utiliser des techniques connues de destruction des performances dans la conception. Les bases de données doivent être conçues pour les performances dès le départ.

Nous avons des jeux mobiles avec des milliers de joueurs et nous avons vu une énorme baisse de charge en allant aux pools de connexions persistantes IIS / .NET mysql. mysql 5.1

Pensez à conserver les données «en écriture seule» ailleurs pour réduire la charge sur la base de données que vous choisissez Cassandra ou syslog même. Pensez à conserver des données à évolution rapide, hautement transitoires mais reconstructibles dans une base de données nosql comme memcache, riak, etc.