Yaml ou MySQL

[lemouix]

Mon très cher Melimelo met en place du Yaml pour notre moteur.
Au lieu d'utiliser une bdd pour charger toutes les caractéristiques de défense, attaque, nom, description, etc tout sera stocké dans des fichiers Yaml....

Ma grosse question: le chargement d'infos d'un fichier yaml est il plus rapide que de charger les infos à partir de la base ? et si on se retrouve avec 10 joueurs qui balancent une requête pour afficher les infos sur 10 unités, on se retrouve avec 100 chargements d'infos d'unités tandis qu'avec une base, une requete récupère l'ensemble des informations ....

Le débat est ouvert... à vos cerveaux !

[Seren]

La meilleur réponse ça serait de faire un benchmark.

Par exemple créer 100 000 enregistrements dans une table, vs 100 000 enregistrement dans un fichier YAML et ensuite faire quelques requêtes dessus.

A priori, sans faire de test, je pense que la BDD est plus optimisée pour des requêtes complexes et des accès simultanés à la base. Le fichier YAML accédé par 10 ou 100 utilisateurs en même temps je ne sais pas comment ça va se comporter. Je dirais que ça dépend de l'OS et du filesystem utilisé.

Côté BDD à bas niveau je ne sais pas non plus comment ça se passe, mais au moins ça a été conçu pour .

A mon avis le problème c'est pas trop le temps d'accès, mais plutôt le parallèlisme.

[keke]

Seren a tout dis ^^

Le benchmark pour se rassurer, mais en mon sens la BDD est le plus rapide. Cella peut cependant être utile pour des hébergeurs n'offrant pas de service de BDD.

Bref, A vos Benchmark, prêt, Benchez !

[lemouix]

mdr... Melimelo ! si tu es par là :p

J'en déduis que vous n'avez jamais eu la question ! Disons que niveau BDD il y a beaucoup de choses à gérer, mais un fichier Yaml, c'est un accès disque avec ouverture de fichier...

[Sephi-Chan]

A mon sens, YAML n'apporte aucun intérêt pour du stockage de données.

Pourquoi ?

Parce que c'est YAML. PHP ne propose pas de fonction d'encodage et de décodage pour YAML, donc c'est plus lent qu'un XML ou un JSON puisque tu dois passer par des fonctions qui ne font pas partie du core. Or, comme c'est ton accès aux données qui en dépend, je doute que tu puisses te permettre ces lenteurs.

Ensuite, ça n'est pas fait pour ça. Les fichiers XML/JSON/YAML peuvent par contre te servir pour faire du push (par exemple, actualiser le fichier quand quelqu'un agit sur le site, afin d'avoir une liste des joueurs connectés). Il y a plein de petites utilisations comme ça qui peuvent être très pratiques pour gagner en performances (en particulier pour les jeux qui utilisent des cartes). Et dans ce cas, JSON est ce qu'il y a de plus performant et pratique pour les raisons suivantes :

• PHP possède des fonctions natives pour le traiter (json_encode() et json_decode()) ;
  
• Il est simple à manipuler par PHP puisque ce n'est que de la manipulation de tableau ;
  
• Il est utilisable directement par Javascript (pratique quand on l'utilise avec Ajax) ;
  
• Un flux JSON est très léger puisque c'est une notation très peu verbeuse (contrairement à XML, par exemple) ;
  

Enfin voilà mon avis sur la question.


Sephi-Chan

[lemouix]

Merci Sephi Meli !!! Prends en note !

[Seren]

Le risque c'est pas vraiment le type de fichier, c'est l'accès concurrent. Que ce soit du XML, du JSON ou du YAML c'est toujours pareil.

Qu'est ce qui se passe si deux utilisateurs ont besoin d'accèder en écriture en même temps au fichier ?
1. Cas pessimiste : le fichier est déjà ouvert, donc le deuxième accès est refusé parce que le fopen() ne fonctionne pas.
2. Cas optimiste : les accès se font les uns à la suite des autres, mais par contre ça veut dire que le deuxième utilisateur va attendre que le premier ait fini. Donc ça rame.

Je ne sais pas ce qui se passe en pratique mais ça me paraît dangereux.

Dans le cas d'une BDD ce genre de problème n'existe pas. Au pire il y a une queue de "query" à executer qui s'empile et qui peut ramer, mais c'est étudié pour.

C'est possible d'utiliser des fichiers à la place d'une BDD. Il y a au moins PMwiki qui fait ça pour stocker ses articles. Mais les données sont moins complexes, c'est que du texte, et il y a moins d'accès que pour un jeu. On charge un article et voilà. On a pas besoin de faire 10 requêtes par seconde pour résoudre une action.

A mon avis YAML ou autre c'est très bien pour des donnés quasi statiques, par exemple organisé les règles. Il y a peu de risques d'accès concurrents, ça varie lentement. Ou pour sortir des rapports d'erreurs ou des statistiques.

[lemouix]

Donc, je pensai, on génère des templates pour les unités, les batiments, ressources et on permet d'afficher le lvl, le cout en variable.... que l'on va chercher dans une bdd...

[Melimelo]

Le yaml c'etait pour la generation de l'array qui lui serait mis en cache ...

Ca revenait donc a une include d'un simple FICHIER PHP et la lecture d'un ou deux array ....

Il y eu un mal entendu ^^ je crois.

De plus il me semble qu'une simple lecture d'un array s'avère plus rapide qu'une requête sql, non ?

[Sephi-Chan]

Ah oui, dans ce cas c'est un bon plan. Si le fichier YAML sert à créer un fichier PHP, c'est intéressant. Mais le choix de YAML n'est toujours pas le plus adapté, quoi.


Sephi-Chan