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.