Qu'est-ce Qu'il Faut éviter De Stocker En Bdd, Pour limiter le poids de la BDD

Bonjour,

Nous somme en train de concevoir un peu tous les aspects de notre jeu mais je m'inquiète un peu au sujet du poids de la BDD.

Il y avait par exemple certaines idées de proposées pour créer des niveaux de relation entre les personnages (de façon à ce qu'on reconnaisse tout de suite un gars qu'on connait mais pas un autre s'il nous dit pas son nom). Seulement avec un nombre de joueur important, cette idée me semble irréalisable.

Il y avait aussi (dans une moindre mesure) le fait de créer des objets "uniques" (càd par exemple que deux morceaux de pain seraient enregistrés dans la BDD sur deux lignes au lieu d'une seule). Je me demande si c'est possible de le faire où s'il vaut mieux abandonner tout de suite l'idée.

etc...

J'aimerai donc bien si possible avoir vos retours d'expérience à ce sujet. Est-ce qu'il y a des pièges à éviter à tout prix ?

(puis aussi savoir si vous auriez une idée du poids en BDD "normal" pour chaque joueur dans un jeu de gestion en moyenne)

Salut,

juste en ce qui concerne les bouts de pain. Il semble logique de créer un seul pain qui définit comment est un morceau de pain.

Après cela, tu créeras une ligne pour chaque bout de pain du jeu, c'est normal. Cependant, cette ligne contiendra le strict minimum du genre l'ID pain, sa position (ou est-il sur la map), s'il est mangé, rogné, etc...

Cela te permet de stocker un lien vers une image "pain.gif" et autres descriptions longues mais une seule fois par objet.

En ce qiu concerne tes questions, fait déjà un jeu qui regroupe cent personnes. Je suis sûr que la BDD tiendra le coup et que cela te permettra de voir venir d'autres hébergements plus gros. La taille est, aujourd'hui, un problème de moindre importance. Seuls comptent la vitesse d'affichage des pages, et surtout l'intérêt du jeu

C'est surtout que si on prévoit de faire des aspects en rapports avec des choses qu'il nous serra impossible de maintenir par la suite, ça va nous posez pas mal de problèmes à tout changer. Je sais bien que la taille n'est pas un problème en sois mais pour les BDD, 1 Go, ca demande quand même déjà pas mal de ressources serveur par exemple.

D'ailleurs ma question n'est pas vraiment là mais plus pour éviter les pièges qui peuvent faire augmenter la BDD de façon exponentielle (donc il s'agit plus de 100Mo ou de 1Go mais d'une BDD qui va doubler de volume sans arrêt au bout de quelques inscriptions).

Est-ce que vous vous êtes déjà penché sur la question pour vos jeux ?

Je dirais même que les questions que tu te poses sont essentielles dans tous projets informatiques.


Déjà, jette un oeil sur les méthodes de conception de BDD relationnelles (formes normales et tout l'toutim : MERISE). Celui-là peut-être :
http://cyril-gruau.developpez.com/uml/tutoriel/ConceptionBD/

Ensuite, des outils comme PowerAMC t'aident à modéliser ta base de données, générer les scripts du MPD (modèle physique de données) à partir du MCD (conceptuel) et te donne le moyen de calculer le volume des tables sur certaines hypothèses.

Tout ce travail est rarement fait dans notre "microcosme" amateur; mais c'est un tord. Dans mon boulot, je ne laisse jamais mes développeurs démarrer le moindre développement sans une phase de conception (qui vient APRES les Spec dans la méthodo "classique" Top-Down -- le fameux cycle en V qu'on apprend à l'école)

Ta démarche est excellente et si je peux t'aider (sans que ca me prenne trop de temps ;-) ), ce sera un plaisir.

Kalan

De ma petite expérience sur la question, je dirais que tant que tu taille tes champs comme il faut, en utilisant les divers types qui sont à ta disposition et les tailles, ainsi qu'en utilisant des cléfs et des index, c'est le plus important.

Ensuite, je plussoie d'une part sur la méthode, tu fais bien de te poser ces questions maintenant, et sur le conseil de débuter quelques parties pour essayer de valider si ce que tu avais calculé dans tes prévisions se vérifie. Notamment sur la partie "fixe" et la partie dépendante du nombre de joueurs.

Concernant les objets uniques et autres, il est certain que si tu veux limiter la taille, mais surtout le nombre d'enregistrements, pour optimiser tes temps de requetage de la base de données, il faut essayer de limiter tout ce qui pourrait être unique.

Après, il faut le mettre en balance avec ce que cela apporte au jeu.


Pour tenter de te donner des billes concrêtes, je vais parler un petit peu de Daifen : C'est un wargame, à priori donc ce que tu entend par "jeu de gestion"... Mais j'ai un doute vu que tu parle de "bout de pain".

La base de données pèse aujourd'hui 50 Mo, pour entre 800 et 900 joueurs ayant une partie en cours. Le plus haut que je sois monté était dans les 65 Mo avec à peu près le triple en nombre de joueurs.

Mais il faut relativiser un peu : Il y a à peu près 30 Mo qui est pris par le forum, 5 Mo pris par la messagerie interne entre les joueurs... Et Daifen a 7 ans. Il y a de la purge, mais pas sur tout, donc l'aspect durée est également à prendre en compte pour relativiser la taille de la base.

Enfin, j'ai très peu d'objets uniques : Une dizaine d'artefacts, les parties, et bien sûr, les joueurs.


Après tu peux également gagner un peu sur la BDD en mettant dans des fichiers les constantes ou autres valeurs qui ne changent que très rarement, ça peut être une piste aussi.

Personnellement je l'utilise parfois pour stocker les libellés associés aux codes qui eux sont stockés en BDD. Mais pas toujours, c'est à examiner au cas par cas.

Re,

Je suis d'accord avec tout ce qui se dit !
J'ai le même genre de boulot que Kalan apparemment, et n'hésite donc pas à poser des questions précises : s'il ne répond pas je tâcherai de palier à son absence.

En tout cas : si ta base double de taille "sans arrêt" au bout de quelques inscriptions c'est qu'il y a un vrai problème

Et moi je ne suis pas du tout daccord moi !

Les index etc, très important c'est sur, mais on peux toujours changer après coup (je veux dire par là que c'est pas impossible).
Par contre, avoir des liens ("des niveaux de relation") entre tout les joueurs va evidamment exploser
a un moment la base de donnés donc c'est beaucoup plus important de se soucier de ce genre de problèmes !

Si tu veux avoir une liste de qui se connais qui dans ton jeux, fais plutôt une nombre maximale
que ton joueur puisse se souvenir d'avoir rencontré (ex. 50, il faut donc qu'il oublie les plus
vieux/moins interessants), ce qui fais que la BDD augmente d'un facon lineaire
avec le nombre de joueurs et pas exponentiel.

Pour le pain (je ne sais pas pourquoi mais je trouce que c'est marrant comme exemple)
tu peux faire un "objet reference : Tranche de pain, ID=7" puis les deux tranches de pain, c'est
un "objet : Tranche de pain (ID=7) Nombre : 2".
Comme ça en prime tu peux changer les characs de tout les tranches de pain en un
click (ok, c'est un desavantage aussi) mais plus important, les 4 tranches de pain
prendront qu'un entré dans la DB.


Enfin je dis ça ...

/Ludvig

En ce qui concerne les relations entre joueurs, je trouve dommage de limiter. Tu peux toujours avoir tes joueurs :
toto (1)
titi (2)

qui se connaissent bien :
1 2 bien

Ici le lien est double : 1 connait bien 2, donc 2 connait bien 1 => 1 seul enregistrement.

Si un troisième arrive, tata (3). Au départ, il ne connait personne, tu n'as donc aucun enregistrement. S'il se met à connaitre 1, tu auras :
1 2 bien
1 3 à peine
par exemple...

Ca évite de faire exploser la base, car la plupart des joueurs ne se connaitront pas. En stockant un chiffre à la place du "niveau" :
1 2 7
1 3 1
Tu allègeras la taille de ta base.
Ici, on peut considérer que chaque ligne prend 3 octets, alors qu'une ancienne ligne genre "1 3 à peine" contenait 9 octets...

Le tout, c'est de se demander ce que ca peut apporter au joueur. Est-il vraiment intéressant de stocker autant d'information ?

Erreur !

Erreur aussi je presume, sauf si on a moins que 256 joueurs ^^ mais
le problème n'est pas là car la question est pas combien de bytes un champ prends vue
que ça va augmenter d'un facon exponentiel...
c.a.d avec 10 joueurs qui se conaissent, ça fais 2*10*10=600 entrés, 500 joueurs feront un million d'entrés et 5.000 ->50 millions ...

Bref, c'est pas rien même si on peux penser que ça peux passer.

Enfin, ça tiendra surement un bon bout de temps

/Ludvig

Non, si on considère que la relation «connaît» est strictement réciproque (ce qui me paraît très discutable), N joueurs qui se connaissent tous les uns les autres ce n'est pas N*N lignes, mais Somme(1,N) lignes dans la table.
En imaginant la table (id_A, id_B, relation) avec id_A et id_B sur 16 bits (65000 joueurs) et relation sur 4 bits (16 niveaux de relation), soit 20 bits/ligne :
Pour 500 joueurs :
- Règle non réciproque => 250'000 lignes => 610 Ko
- Règle réciproque => 125'250 lignes => 306 Ko
Enfin ça reste de l'ordre de N²...

Avec la règle réciproque tu divises par 2 la taille de ta table, mais tu perds en précision d'information, par exemple impossible de simuler l'espionnage : on ne peut pas dire que A connaît des détails sur B si B ne connaît pas les mêmes détails sur A.
Pour récupérer cette précision, tu peux faire une table à 4 colonnes : (id_A, id_B, relation_A_B, relation_B_A).
Tu as ainsi la même précision que pour la règle non réciproque, mais le même nombre de ligne qu'avec la règle réciproque + 4 bits par ligne, pour reprendre l'exemple des 500 joueurs qui se connaissent tous les uns les autres, avec toutes les combinaisons possibles non réciproques, on aurait 125'250 lignes à 24 bits/ligne soit 367 Ko.

Franchement, avant d'avoir 500 joueurs qui se connaissent tous les uns les autres, tu as de la marge. Déjà avant d'avoir 500 joueurs
Mettons que tu aies tous les joueurs de JPC du web qui aille sur ton site et qu'ils prennent tous le temps de discuter entre eux, tu aurais une table de 357 Mo. C'est effectivement trop, mais un tel niveau de précision de l'information vaut bien ça.

Note que tes calculs étaient faux de toute façon, 10 joueurs qui se connaissent c'est 10*10 et pas 2*10*10, et en plus... 2*10*10 = 600 c'est pas trop ça

Des sites comme myspace ou linkedin proposent (et encouragent) les membres à créer des liens entre eux. Je n'ai pas l'impression que leur base n'explose

Le moindre message texte écrit par un joueur prendra plus de place que tous ses liens vers d'autres joueurs.

Bah de tte facon y a pas de miracles
:

clé étranger + jointures, on ne fait rien de mieux

Cette solution reste assez limitée dans le cadre d'une base de donnée MySQL, tu est obligé d'avoir une version recente qui accepte les tables InnoDB.

Mais sinons, je suis d'accord ^^ !

D'autres te l'ont proposés au dessus, il y a des normes de conception pour les structures types base de donnée (Merise citée et UML par exemple)

Essai de te renseigner la dessus. Mieux vaut passer quelques jours sur un papier que plusieurs semaines a regler des problemes de performance !

Oue donc pas a prendre à la légère quand même ^^

Ca donne 200 (vue que je peux savoir qui tu es sans que tu me conaisse ^^) donc oui, c'etait une erreur


Enfin, maintenant qu'on a dit tout ça, et que ça tiens surement si on fais gaffe : bon prog !

/Ludvig
ps. linkedin & co. je vois pas où on connais des milliers de personnes là dedans (chaqu'un) ?? et le debat etait (je crois) attention au mechant N², pas sur l'optimisation de base enfin on s'est un chouilla egaré du sujet initiale quoique...

Mais quelle bonne idée !
Je me demande bien d'ou elle viend cette idée

hehe. Et oui, c'est gérable de facon réaliste, puisque les joueurs ne connaissent pas tout le monde, il suffit d'uniquement stocker les connaissances (et non pas les inconnus)


Ma table de connaissance as 11,083 enregistrement et fait 642.9 KB ... plus qu'acceptable considérant que ma table des messages stocké fait 599.3 Mo
Et pour répondre au possible questionnement de "mais comment ca c'est plus du double de la taille théorique prévue?) Bah ca je le dis pas, c'est mon secret, mais un indice: le nom d'une personne, c'est pas marqué dans son front. S'il te dit qu'il se nomme Roger, tu l'apellera Roger.

Avoir une Base de donnée de taille n'est pas problématique si elle est bien structuré. J'ai déjà créer une base de 28 millions d'items qui fesait 4 Go environ sans problème majeur (rendu la, c'est insertions étaient lente c'est vrai)

Ce qu'il ne faut pas stocker dans une base de donnée à mon avis c'est des trucs unique:
Si ca n'est pas du pour s'afficher dans une liste, c'est à stocker dans un fichier d'option puisque c'est unique (Exemple: le path de base vers le root)

Ensuite tout ce qui est binaire, je ne vois pas l'utilité de stocké ca dans la DB.
Les images peuvent être placé dans un dossier protégé par un .htaccess et PHP peut généré dynamiquement l'image avec GD en la chargeant du dossier. Protection assuré donc.


Donc voilà, mes conseils sont:
- De bonnes structures de tables
- Moins de 10 000 000 d'éléments par table c'est correct coté rapidité
- Un shéma de DB bien réalisé
- Utilise des ID partout plutot que des var_char, ca parrait pas mal.
- Évite de stoker des fichier dans la DB
- Pense à Optimiser de temps en temps.

Ha ouais, des objets 100% personnalisable selon les besoins des joueurs, mais d'ou peuvent bien venir ces idées la ?

Tu m'a choppé un programmeur ?



Edit:
404 messages... le chiffre de l'innexistance. Rendu à autant de messages, tu cesse d'exister; officiellement un no-life.

En même temps Sybler, ces idées, elles sont pas révolutionnaires on y a tous pensé un moment ou un autre
Simplement certains le mettent en place et d'autres non. Mais l'idée en elle-même...

Bah c'est la première fois que je lis ou entend parlé de la fonctionnalité de considérer les perso comme inconnu et de pouvoir les nommers en jeu. (Mis à part dans des conversations qui m'impliquait et ou c'était moi qui en parlait...)

Je me trompe peut-être, mais je trouve drôle de voir coup sur coup 2 trucs qui sont des choses qu'on retrouve sur mon moteur de jeu et généralement pas sur d'autres.

Mais que ce soit bien clair, je ne suis pas fâché... J'ai même donné des conseils sur comment faire et je n'essaie pas de jouer au plus fort. Je trouve juste ca étonnant comme considences. (Surtout pour les connaissances, les items c'est plus général)

Et euh, pourquoi mettre les images dans un dossier protégé ?

Perso, au niveau des objets unique, je ne sais pas comment tu gère tes objets, mais moi j'ai crée un système "intelligent" qui crée les caractéristiques de l'objet seulement si l'objet est droper. Sa évite d'avoir 5000 objets en base pour seulement 100 utilisés...

Phenix

Galerie privé, controle d'accès sur le visionnement, etc.


Exemple: une mappe d'un lieu est affiché sur le mur d'un lieu préci.

Ca permet d'éviter qu'en donnant l'URL à un ami par MSN qui se trouverais dans un autre lieu que celui-ci puisse voir la dite mappe.

Edit: C'est drôle comment je dois toujours justifier chaque chose que je dis sur ce forum... Toujours quelqu'un pour dire: "Mais pourquoi tu veux faire ca ?"... (C'est d'ailleurs pour ca qu'au moment de coder mon Javascript de Drag n drop, j'étais allé sur un autre forum de Dev... Pas que le niveau y étais pas ici, simplement que si je devais me mettre à expliquer en détails le pourquoi de toutes mes questions, expliquer un framework ca aurait été péniblement long (pour les 2 cotés))

Enfin, je dis ca comme ca; puissent ces propos êtres constructifs...

En même temps c'est pas un forum de développeurs ...

Moi aussi je m'étais demandé à quoi servait de protéger les images, d'ailleurs ça ne résoud pas vraiment le problème que tu décris, puisque le joueur peut toujours faire une capture d'écran.

Pub interdite sur les forums de TdJ

Ce message a été modifié par LoK le Mercredi 18 Juillet 2007 à 10h31

sybler : Comme le dit gtm, l'intérêt de "protéger" une image est assez bizarre. Car la personne a téléchargé l'image pour la voir sur son ordinateur. Il ne pourra peut-être pas donner l'url, mais donner l'image directement. C'était le pourquoi de ma question, j'aurais du préciser...
En ce qui concerne le "trop de questions" que l'on te pose, faut pas le prendre mal. Et d'une sur un forum les messages ne sont pas toujours clairs et/ou facile sà comprendre, et de deux, si tu expliques pourquoi, ca peut donner des idées à d'autres, tout simplement !

phenix : oui, pourquoi pas, mais dès que ton jeu aura un peu de monde et un peu de passé, je pense que la plupart des objets seront utilisés, non ? Et pour la place que ca prend, même 5000 objets, c'est vraiment pas grand chose.