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


20

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


1
Un problème avec certaines bases de données noSQL est qu'elles ne peuvent pas faire de requêtes imprévues au moment de la "conception" de manière rapide sur d'énormes ensembles de données comme les journaux d'événements: gamedev.stackexchange.com/q/4465/450 Veuillez garder à l'esprit que les bases de données noSQL nécessitent la même chose techniques contre l'injection de requêtes normales que les bases de données normales.
Hendrik Brummermann

1
@nhnb: Une bonne façon de reformuler votre point est "d'utiliser une base de données relationnelle pour les données de relation et d'utiliser une base de données objet / document pour les données objet / document". Malheureusement, je ne pense pas que la plupart des gens aient de l'expérience ou passent beaucoup de temps à penser à la modélisation, ce qui conduit à de mauvaises conceptions, quel que soit leur choix.

2
En réponse à votre question "NoSQL est-il une option valable pour les jeux basés sur le Web?" Je crois que la réponse est oui. Les bases de données NoSQL ont déjà été utilisées pour des jeux sur le Web (comme FarmVille) et offrent beaucoup de flexibilité. Le principal point de discorde pour cette question semble être "quel est le meilleur (NoSQL ou SQL)?". Chaque système a ses avantages et ses inconvénients, mais les deux sont des options parfaitement légitimes. Si vous cherchez une liste détaillée des avantages d'un système par rapport à l'autre, vous voudrez peut-être payer une visite aux programmeurs StackExchange. :)
Ari Patrick

Réponses:


21

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


Dans l'exemple que vous avez écrit en utilisant sql, comment le modéliseriez-vous à un niveau élevé en utilisant nosql?
Pran

4
-1, votre réponse n'affiche que des données statiques. Tout le débat sur SQL vs NoSQL pour les bases de données de jeux implique des données très dynamiques. La meilleure chose à faire serait de montrer une transaction NoSQL qui échange quelque chose entre deux joueurs - un événement très courant, et la plupart des jeux se trompent quel que soit le type qu'ils choisissent.

3
@Ari: Il y a beaucoup plus de données statiques, mais personne ne se soucie du débit pour les écritures, car personne n'y écrit - pas d'écritures, pas de transactions, pas d'ACID, pas de vraie question de base de données, même si vous les stockez dans une. Il est alors facile de répondre à cette question - il suffit de la garder en mémoire. Certainement "Comment pouvons-nous charger des données statiques plus rapidement?" est une question intéressante, mais je ne pense pas qu'elle soit du tout liée aux questions de SQL contre NoSQL. - En ce qui concerne les opérations multi-documents, cela signifie-t-il que votre base de données aurait un document avec par exemple tous les acteurs?

2
@Ari: Veuillez ne pas confondre NoSQL, qui est une idée, et MongoDB, qui est une base de données particulière. Lors de mon dernier travail, nous avons livré deux jeux sur une base de données NoSQL et obtenu une excellente concurrence avec une faible latence. Mais notre base de données NoSQL a également pris en charge les transactions multi-documents avec verrouillage au niveau du champ. NoSQL n'est pas une «chose» unique comme SQL, il fait simplement référence à toute base de données n'utilisant pas SQL (et n'utilisant généralement pas de schémas relationnels).

5
Juste mon $ .02, mais "pas performant" n'est pas un inconvénient du SGBDR. C'est un inconvénient de stocker des données non relationnelles dans un SGBDR, de ne pas régler votre SGBDR, de ne pas comprendre ce que fait votre SQL, de ne pas indexer, etc. etc. etc. Si vous avez des données relationnelles, vous constaterez que les SGBDR sont incroyablement optimisés.
Robbie

19

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.


1
Ce sont toutes d'excellentes raisons d'éviter NoSQL jusqu'à ce que vous en ayez réellement besoin. Surtout # 3. À moins que vous n'ayez déjà des millions d'utilisateurs (et que vous refusiez de partager quoi que ce soit), vous serez probablement beaucoup plus productif avec MySQL.
ojrac

5
1. Vous utiliseriez: "pour x dans db.user.find ({" level ": {" $ gt ": 30}})" 2. Techniquement, ce que vous avez écrit est aussi un script, donc je suis Je ne sais pas trop quel est votre point. 3. Il est TRÈS possible de créer un MMO en utilisant SQL, et en fait, de nombreux MMO ont été développés en utilisant la technologie. La technologie NoSQL est relativement nouvelle et a déjà été adoptée par des services comme Amazon, Google et Facebook pour ses performances et sa flexibilité. 4. Dans NoSQL, vous devez écrire vos propres contraintes, mais c'est simplement le coût d'une flexibilité supplémentaire.
Ari Patrick

2
Je suis d'accord avec votre déclaration de réflexion à deux reprises. C'est en partie ce que je fais ici avec cette question :)
Pran

10
SQL n'est pas une balle de ruban. NoSQL n'est pas une solution miracle. Réfléchissez bien avant d'utiliser une technologie.
stonemetal

5
Concernant 3, le problème n'est pas tant que SQL est lent , mais que SQL est en retard . De manière générale, les bases de données SQL obtiennent un excellent débit au détriment de la latence. Pour un jeu basé sur le Web, c'est probablement ce que vous voulez! Pour un jeu en réseau en temps réel, ce n'est probablement pas le cas, et la plupart des MMO "de type WoW" qui utilisent SQL utilisent une couche de mise en cache devant lui qui supprime la plupart des avantages de SQL, c'est pourquoi NoSQL est un grand pas en avant pour leur.

18

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.


1
+1 Merci pour la comparaison des deux options. De plus, vous faites un bon point en disant que les données statiques ne doivent pas être dans la base de données.
Pran

1
+1 Cependant, je pense que vous négligez de mentionner l'un des principaux avantages (bien, pour ou contre selon la perspective) de No SQL, c'est-à-dire qu'il est sans schéma, ce qui permet de stocker des données hautement dynamiques. Je vais en fait utiliser un mélange des deux pour mon projet actuel avec PostgreSQL pour des trucs qui s'intègrent bien dans le modèle relationnel, et Mongo pour des trucs semi-statiques qui ne le sont pas. (par exemple, un journal qui peut être utilisé pour générer une relecture, où, relationnellement, je devrais avoir soit une colonne qui stocke un PK à partir d'une des nombreuses autres tables, soit une table avec des noms de colonnes génériques, par exemple param1 param2)
Davy8

1
@ Davy88: noSQL n'est pas nécessairement sans schéma, et avoir une base de données "hautement dynamique" n'est pas vraiment un plus. Si tout ce que vous avez est une soupe de données, vous ne pouvez pas faire d'indexation, vous ne pouvez pas faire de verrouillage au niveau du champ, et même les requêtes simples se posent des questions sur ce qui se passe si une clé n'existe pas.

@ user744, que font les choses que vous mentionnez?
expiredninja

5
  • 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 .


Oui, j'ai aussi entendu parler de couchdb, en fait, même sur le site Web de mongodb, ils le comparent généralement. Je pense que je dois faire des recherches sur couchdb vs mongodb.
Pran

2

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


Quelles fonctionnalités pensez-vous vous entraîneraient davantage dans NoSQL ou la couche de persistance comme j'aime à y penser?
expiredninja

1
peut-être un système de coordonnées si votre jeu est basé sur le gps, quelque chose qui pourrait nécessiter une recherche avancée. Fondamentalement, si vous êtes bon avec MySQL, restez-y, est-il possible de l'utiliser également comme un nosql
Ronan Dejhero
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.