noSQL - Est-ce une option valable pour les jeux basés sur le Web? [fermé]

Par opportunité et ennui, un ami et moi avons décidé de créer un jeu basé sur le Web. C'est le premier "jeu" que je créerai, car d'habitude je programme des applications web dans django.

J'ai choisi d'utiliser le même framework pour le jeu, mais je ne suis pas totalement sûr du stockage des données, car je ne peux pas prévoir les exigences futures et les problèmes liés à la base de données. Dernièrement, le mouvement noSQL gagne en force et je voudrais explorer ce domaine.

J'ai donc les questions suivantes:

• Un stockage de données noSQL (basé sur des documents, comme MongoDB) conviendrait-il à un jeu basé sur le Web?
• Quels sont les problèmes qui pourraient survenir en utilisant un SGBDR conventionnel, tel que MySQL?
• Comment assurer la cohérence des données entre les utilisateurs de MongoDB, pendant le jeu ou lors d'événements programmés, tels que les tâches cron?

Aperçu du jeu: jeu d'aventure typique, où le joueur combat des monstres et gagne des objets, etc.

• Certaines données sont statiques sur tous les joueurs: objets, armes, potion, cartes, etc.
• Quelques données liées au joueur: inventaire, métriques (stats), progression, etc.
• Un joueur peut avoir besoin de connaître les statistiques et l'état d'un autre joueur
• Les tâches planifiées seront exécutées à un certain intervalle de temps

Une base de données noSQL conviendrait-elle à un jeu basé sur le Web?

Absolument! De manière générale, les bases de données non relationnelles (telles que MongoDB) sont bien meilleures pour les jeux, car elles sont plus flexibles dans la façon dont elles modélisent les données, tout en étant plus performantes que les bases de données relationnelles (telles que SQL) - ce qui en fait un "gagnant-gagnant" choix.

Quels sont les problèmes qui pourraient survenir en utilisant un SGBDR conventionnel?

L'utilisation de bases de données relationnelles présente deux inconvénients majeurs:

• Manque de flexibilité dans la façon dont vous modélisez les données
• Performance

Le manque de flexibilité dans la façon dont vous modélisez les données est un inconvénient majeur, car l'utilisation d'une base de données relationnelle vous oblige à modéliser les données pour répondre aux besoins de la base de données, plutôt que la base de données répondant aux besoins du modèle. Par exemple, considérez que vous créez le modèle pour la façon dont vous stockerez les éléments dans un jeu à l'aide d'une base de données relationnelle et vous décidez du modèle suivant:

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

Réfléchissez maintenant à la façon dont vous auriez besoin de modifier le modèle pour le faire, procédez comme suit:

• Ajouter un nouveau type d'élément
• Créer une arme avec plusieurs types d'armes
• Créez un objet de potion qui peut également être utilisé comme arme

Certes, toutes ces actions sont réalisables, mais vous ne serez pas la personne la plus heureuse pendant que vous les ferez, et vous vous demanderez probablement: «y a-t-il une meilleure solution pour ce que je veux faire?», «Quand vous le pourriez concevoir un modèle beaucoup plus flexible dans une base de données non relationnelle.

Remarque: Si vous n'êtes pas familier avec la façon dont les bases de données basées sur des documents stockent les informations, veuillez consulter ce lien avant de continuer. Le modèle présenté ci-dessous est conçu pour utiliser une logique similaire à celle présentée dans l'article susmentionné.

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

Il y a beaucoup de bons articles sur les performances des bases de données NoSQL vs SQL, mais en voici un qui fournit des exemples d'application pour que vous puissiez effectuer vos propres tests: MongoDB vs SQL Server 2008 Performance Showdown

Comment assurer la cohérence des données entre les utilisateurs de MongoDB?

MongoDB prend en charge les opérations atomiques en lecture / écriture sur des entités de données uniques (documents), les résultats des requêtes de MongoDB doivent donc toujours être exacts avec ce qui est stocké dans la base de données.

Edit: fourni un exemple NoSQL de base de données d'articles

Quelques mots défendent les bases de données SQL.

1 - Si vous avez une base de données SQL, vous pouvez travailler avec vos données non seulement par clé primaire. La plupart des requêtes dans MMO passent par PK, mais lorsque vous devez trouver tous les utilisateurs de niveau> 30, que ferez-vous dans le monde NoSQL?

2 - Si vous avez un langage SQL, vous pouvez créer des "correctifs" pour réparer les données cassées. Par exemple: "mettre à jour player_items set flag = 0 où item_type_id = 100". Comment pouvez-vous résoudre ce problème dans NoSQL? Je pense que vous devrez faire un script qui analysera toutes vos données ...

3 - Les bases de données SQL ne sont pas aussi lentes que vous pouvez le penser. Mes collègues créent le jeu MMO basé sur le Web, qui effectue 5000 transactions par seconde dans MySQL. Cela ne vous suffit-il pas? Sinon, vous pouvez utiliser le partitionnement pour mettre à l'échelle votre base de données.

4 - SQL a des contraintes de clé étrangère et de bonnes choses qui vous aideront à trouver des bogues dans votre code.

NoSQL n'est pas une solution miracle. Il ne résout que quelques problèmes et apporte de nombreux nouveaux problèmes. Donc, mon conseil - réfléchissez bien avant de choisir NoSQL.

La réponse est oui, c'est une option valable mais non, ce n'est probablement pas une excellente idée .

Il y a deux problèmes majeurs avec SQL que NoSQL essaie de résoudre en ce qui concerne les jeux.

Le premier est la latence, ou décalage. Dans un sens, les bases de données SQL sont incroyablement rapides, traitant des milliers de transactions ou plus en dixièmes de seconde. Dans un autre sens, ils sont incroyablement lents, car le traitement de quelques transactions peut prendre le même temps. Pour la plupart des utilisations de bases de données, cela n'a pas d'importance, mais les jeux ont un composant en temps réel, il ne s'agit donc pas seulement du nombre de transactions que vous pouvez effectuer par seconde, mais du temps moyen nécessaire pour répondre à une transaction de base de données.

Cette latence est un problème majeur pour les jeux en temps réel. De nombreux développeurs qui ont besoin de grandes bases de données (généralement pour les MMO) construisent une couche de mise en cache qui se situe entre la base de données et les serveurs de jeu afin d'éviter ces blocages, puis vident le cache périodiquement. Le problème? Vous venez d'évoquer les principales raisons d'utiliser une base de données - atomicité, cohérence, isolement et durabilité .

Mais ce problème ne s'applique pas aux jeux Web. Vous avez déjà une connexion à latence élevée entre le joueur et le jeu, vous pourriez donc aussi bien obtenir le débit fourni par SQL, ainsi que les avantages d'un logiciel mature et bien connu.

Le deuxième problème, cependant, s'applique à vous, et c'est le inadéquation de l'impédance relationnelle-objet . Les jeux traitent des objets, les bases de données traitent des lignes. Si vous avez de la chance, un objet peut être transformé en ligne simplement en listant ses champs, mais la plupart du temps les objets sont hiérarchiques, et vous devez les aplatir d'une manière ou d'une autre pour les mettre en lignes.

Les bases de données basées sur des documents, comme CouchDB et MongoDB, résolvent ce problème en promouvant le document en objet de niveau supérieur, plutôt qu'en ligne ("document" dans ce cas est synonyme d '"objet"). Mais ce faisant, ils perdent de nombreux avantages des bases de données SQL. Le débit est beaucoup plus faible et les algorithmes de verrouillage deviennent beaucoup plus compliqués.

La bonne nouvelle est qu'il existe déjà de nombreux outils de cartographie relationnelle-objet (ORM) pour le langage que vous utilisez. Ils vous permettent de traduire entre les objets en mémoire et les lignes de la base de données de manière assez transparente. Ces outils ne conviennent généralement pas aux jeux en temps réel à grande échelle, car ils peuvent présenter les pires aspects des performances des bases de données SQL et NoSQL. Mais c'est bien pour un jeu Web - au pire, lorsque vous rencontrez des problèmes de performances, vous pouvez recommencer à faire des transactions à l'ancienne. Le problème de latence ne vous fait pas de mal et l'augmentation du débit vous aide.

Enfin, pour développer un point que j'ai fait ailleurs : il ne s'agit pas de données de jeu statiques. Je ne parle pas de la description de vos objets ou des dégâts de votre arme ou des sprites ou quoi que ce soit ici. Je veux dire les vraies données de jeu modifiables, comme ce qui est dans l'inventaire d'un joueur ou quelles sont ses statistiques. Tout ce dont vous avez besoin pour les données statiques est un magasin de données. Il se peut que la chose la plus simple à faire soit d'utiliser la même base de données que le magasin de données pour cela car vous avez un excellent ORM; vous aurez peut-être juste besoin du système de fichiers. Il s'agit de deux problèmes distincts, et une réponse n'a pas besoin (et ne correspondra probablement pas) aux deux cas.

• Un stockage de données noSQL (basé sur des documents, comme MongoDB) conviendrait-il à un jeu basé sur le Web?

Je conseillerais de jeter un oeil à couchdb

Son interface est basée sur javascript, donc elle se fondra assez bien avec les jeux basés sur HTML5 / javascript.

Il est également capable de fonctionner «hors ligne» (faire une copie locale de la base de données), puis de se synchroniser avec le serveur plus tard (vous pouvez l'utiliser pour des donjons instanciés, par exemple)

• Quels sont les problèmes qui pourraient survenir en utilisant un SGBDR conventionnel, tel que MySQL?

Le problème principal serait que les bases de données sans SQL se comportent de manière assez différente des bases de données relationnelles. Faire le changement mental peut être difficile.

Par exemple, regardez comment les " requêtes " sont effectuées dans couchdb. Tout se fait en javascript.

• Comment assurer la cohérence des données entre les utilisateurs de MongoDB, pendant le jeu ou lors d'événements programmés, tels que les tâches cron?

Le processus de «synchronisation» des bases de données est appelé réplication dans le jargon de couchdb. Vous verrez également le terme cohérence . Il existe plusieurs services intégrés qui traitent de la réplication et de la cohérence. Voir par exemple le processus de réplication incrémentielle .

En fonction de ce que vous avez dans votre jeu, vous pouvez éventuellement utiliser les deux et les connecter via les modèles de votre jeu. Par exemple, le joueur pourrait et devrait être en RDB (informations de connexion) mais l'inventaire du joueur / stockage variable pourrait aller à noSQL, donc votre module de joueur pourrait login()utiliser RDB etfetchInventory() utiliser noSQL par la clé primaire.

Les cartes, par exemple, mieux vaut être enregistrées dans NoSQL (coordonnées => tableau d'objets différents par exemple) je n'imagine pas enregistrer ce qu'une zone contient dans RDB (sauf une chaîne sérialisée dont vous avez besoin de désérialiser complètement pour lire une partie de? More CPU et de la RAM gaspillée!) vous pouvez encore enregistrer des zones dans RDB, par exemple la zone "ville X" contient les coordonnées / blocs suivants ([3,4], [8,7] ...)

vous pourriez et devriez probablement utiliser les deux, et jeter un œil au stockage volatile comme memcache dont vous pourriez avoir besoin ou à certaines données temporaires (serait plus rapide que d'utiliser le disque dur à coup sûr! et vous économise beaucoup de CPU mais pas de RAM)

donc à la fin>

cela dépend de ce que vous voulez avoir dans votre jeu! cheerz