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
