Discussion :

[Michel Rotta]

J'ai un projet de développement d'un jeu et je suis en train de calibrer la taille de la base de données ce qui me donne quelques boutons.

En résumé, je vais utiliser la métaphore de l'arbre.

J'ai des joueurs qui vont pouvoir posséder des arbres dans une foret. Le nombre de joueur dans une partie devrait tourner autour de 10000. Les données sont relativement peu importante par joueur (le gros des données sera stockées sur un autre serveur permettant l'accès à toutes les forets), on va dire dans les 1k par joueur, probablement moins.

Chaque joueurs peut posséder plusieurs arbres, de 1 à ++, disons 200, au delà, le temps de gestion de sa foret particulière sera tellement lourd qu'il ne pourra pas assumer, en moyen et en fin de partie, un joueur devrait posséder dans les 120 arbres. Chaque arbre doit avoir un certains nombres d'informations dans les 250o

Chaque arbres va comporter de 1 à ++ branches, là aussi le maximum sera la possibilité du joueur de gérer les branches. en moyenne j'estime à 150 branches par arbre et dans les 250o par branche.

Chaque branche va comporter de 1 a 1000 feuilles (la c'est plus précis pour la bornes supérieur), en moyenne dans les 200 feuilles par branches. Maintenant cela ce complique, il peut y avoir des feuilles différentes sur chaque branches, chaque feuille est spécialisée et il va exister dans les 1000 types de feuilles différentes. Les données stockées par chaque feuilles sont différentes en taille et en volume, elle seront gérée par des objets différents au niveau PHP. J'estime en moyenne le volume de donnée d'une feuille à 30o.

Et pour finir, il y a des insectes de nombreux types qui peuvent être stocké sur certaines feuilles (certaine ne peuvent rien stocker, d'autre peuvent stocker certain type d'insectes, jamais tous les types). Il faut bien sur savoir pour chaque feuille le nombre d'insecte et leur type et ne pas autoriser un insecte a changer de feuille si la feuille de destination ne peut le recevoir. Pour un insecte on doit savoir son type, là feuille où il se trouve et son nombre ), donc dans les 15o.


Il y a plusieurs choses que je ne vois pas comment gérer :

• les données différentes pour chaque feuilles qui obligerait à avoir une structure de table différente pour chaque type mais le nombre de requêtes pour obtenir l'arbre pourrait être faramineuses. Avec les chiffres donnée ci dessus et si j'arrive à mettre les données dans chaque feuille dans une table, je me retrouve avec une table de 36.000.000.000 enregistrements de 15o soit d'un poids de 502Gio.
• Les insectes qui peuvent, pour certains, être géré au niveau de la branche, la feuille où ils se trouvent n'a pas d'importance, c'est le nombre total sur les feuilles de la branche qui compte, mais, pour d'autre, la feuille doit être identifiée.

J'ai envisagé plusieurs solutions :

• Les feuilles sont liées définitivement à leur branche (alors que les branches peuvent elles changer d'arbre)(ce sont des espèces particulières !). Je pourrais donc envisager un champ de type LONGTEST pour chaque branche et y stocker les données sérialisées des feuilles. C'est la table des branches qui prendrait un coup important, mais simplifierait le stockage des feuilles dans 1000 tables (!) ou une table avec tous les champs possible et plein de vide, catastrophique en terme de place. Je peux aussi envisager une sérialisation non standard plus compact, voir utiliser des données compactées (zip) pour diminuer la taille du champs LONGTEST.
• Couper la table branche ou/et feuille sur plusieurs disques pour en permettre l'utilisation.
• Utiliser un base noSql pour les feuilles

Un dernier problème ce pose à moi. Les arbres sont posées sur une carte en 2D et ont tous une position. Ces positions peuvent changer et évoluer. j'ai besoins de facilement retrouver tous les arbres à moins de 150m d'un arbre précis. Il y a dans MySql une fonction de gestion de coordonnées, quel serait, ici, la performance pour trouver tous les arbres dans un rayon donné autour d'un autre ?

Pour ceux qui sont arrivé jusqu'ici, merci de m'avoir lu.

Amicalement,
Michel

[CinePhil]

C'est très abstrait comme problème !

Le seul conseil que je peux te donner est : Commence par normaliser au maximum les données. Tu auras probablement des tables avec de très nombreuses lignes mais qui ne seront constituées que de clés étrangères. Avec un type entier pour les identifiants (clés primaires) et pour les clés étrangères, associé à un bon indexage, les performances peuvent rester très correctes, même avec plusieurs dizaines de millions de lignes. Après ça dépend aussi de la performance du serveur ! Ne pas lésiner sur la quantité de mémoire vive !

je vais utiliser la métaphore de l'arbre.

Il s'agit vraiment d'un jeu où les joueurs vont gérer des forêts ou c'est une métaphore pour quelque chose de plus complexes et plus fantastique encore que des branches qui changent d'arbres ?

Et avant que tu atteignes 10 000 joueurs, tu as un peu de temps non ? Il y a tellement de jeux en ligne déjà !

[Michel Rotta]

C'est vraiment une métaphore et il n'y aura pas de bois ni d'arbre ni de foret.

Je sais qu'il y a beaucoup de jeu en ligne, mais viser la dernière place n'a pas d'intérêt.

Ce qui me fait le plus de "peur" c'est les feuilles qui sont de très nombreux types et ont besoins de stocker des données très différentes de l'une à l'autre. Au départ il y avait deux type de branche, mais en fait elle sont tellement semblable qu'elles peuvent être confondues avec peu de concessions.

Reste les feuilles.

[CinePhil]

Ta métaphore de branches et de feuilles reste très abstraite.

Tu pourrais nous dire plus concrêtement de quoi il s'agit ?