28-07-2013, 04:45 PM
(28-07-2013, 04:25 PM)Xenos a écrit : Oui, par FTP, j'entends système de fichiers. Les intérêts du système de fichier:
- Possibilité de mise en cache ou d'utilisation des CDN (le fichier, type XML ou JSON, est publique et stockable sur proxy ou en cache du navigateur)
- Limite drastiquement toutes les injections (puisque BDD et messageries sont physiquement séparées)
- Evite que la BDD ne "gonfle" (si chacun des 10.000 joueurs peut avoir 1.000 messages de 10.000 caractères chacun, cela veut dire que la BDD peut pointer à 100Go alors que les données du jeu dépassent rarement les 0.1 à 1Go)
- Sépare les données de jeu (BDD, chiffres) des données "humaines" (messages échangés)
* La BDD peut aller en RAM: oui, mais les fichiers peuvent aller dans le cache du client / proxy, et (à tester) la durée de livraison d'un simple fichier statique par le serveur peut être plus rapide que {interprétation du PHP, + connexion au SQL + requête SQL}
* Limite d'inode: Rien n'oblige à avoir 1 fichier par message; j'aurai plutôt vu 1 fichier par joueur (messagerie privée), ou 1 fichier par discussion ou par catégorie (forum)
Enfin, les messages sont assez peu soumis aux changement (c'est plutôt de l'insertion et de la lecture). En d'autres mots, une fois un message inséré, je n'ai pas de raison de revenir dessus (oui, on peut l'éditer, mais le cas est assez rare et peut donc être un poil plus lourd en terme de temps de traitement). C'est un genre de données "quasi statiques", et je trouvais cela un peu lourd d'utiliser une BDD, hyper dynamique, pour cela.
Et j'oubliais: la base de donnée, vidée de la colonne "contenuDuMessage", peut alors utiliser des lignes de taille fixe, ce qui il me semble accélère les requêtes (mais je n'ai pas de statistiques là dessus)
Attention à ne pas attribuer au système de fichiers les qualités de HTTP (telle que l'utilisation d'un CDN et de règle de caches). Les URL qu'on requête en HTTP ne correspondent pas forcément des fichiers de système de fichiers : ça peut être des documents générés à la volée (à partir d'une base de données, ou d'autres fichiers, ou de services tiers, etc.).
Si ta base de données ne gonfle pas en nombre de document et en poids, c'est quelque chose d'autre qui va gonfler : et les fichiers ne profiteront pas d'une grosse volumétrie idéale pour de la compression de masse, par exemple.
De plus, tu devras passer par un système tiers pour de l'indexation (type Lucene et ses enfants (Solr, Elastic Search, etc.) afin de permettre la recherche dans ce contenu. La plupart des SGBDR fournissent des outils pour ça.
Je ne trouve pas du tout l'idée idiote, mais j'émets de nombreuses réserves car ce que tu peux gagner d'un coté (sur plusieurs aspects, telles que la simplicité (1 fichier = 1 discussion), la performance (pas de jointure à faire, les données sont déjà prêtes à l'emploi), alors que les base de données relationnelles sont parfaites pour croiser des données afin d'en obtenir de nouvelles et pour les maintenir (cas de la suppression d'un compte, d'un message, etc.). Si tu veux cette souplesse, tu devras probablement créer différentes "vues" de tes données, ce qui sera plus difficile à maintenir et qui te posera des problèmes déjà largement résolus par les base de données qui ont fait leur preuves).
Après, tu peux aussi regarder du côté des bases de données orientée documents comme MongoDB, ça se rapproche de ce que tu décris tout en fournissant beaucoup d'outils.