Messagerie: BDD ou fichier?
|
28-07-2013, 03:28 PM
Salut à tous,
une question de basse technique: stockez-vous les messages de vos jeux (forums inclus) dans une base de données (type MySQL, Postgre...) ou les stockez-vous dans des fichiers "FTP", sur le disque dur du serveur?
28-07-2013, 04:12 PM
(Modification du message : 28-07-2013, 04:13 PM par Sephi-Chan.)
Qu'entends-tu par des fichiers "FTP" ? Les fichiers du systèmes de fichier ?
En tout cas, je suis pour stocker les données de ce type dans la base de données : c'est fait pour ça, et ça le fait bien mieux que le système de fichier. Le système de fichier n'est pas optimal pour de gros volumes : si ton système tombe à court d'inodes, il va se comporter comme si le disque était plein. Juste pour exemple, la partition principale de ma machine (celle sur laquelle l'OS est installé) fait 210 GB (dont 80 GB restants, formaté en HFS+) et dispose de 50 millions d'inodes (dont 31 millions utilisés). Le serveur JeuWeb dispose de 10 millions d'inodes (230 000 utilisés). Ensuite, la base de données est optimisée pour conserver une partie (ou la totalité) des données d'une base en RAM pour un accès plus rapides : ce que ne fait pas le système de fichier. Pourquoi voudrais-tu faire ça ?
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)
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: 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.
28-07-2013, 05:14 PM
Si le fichier est généré "à la volée", j'ai du mal à comprendre comment le serveur peut dire au proxy, au cache ou au CDN "ce fichier n'a pas été modifié depuis la dernière fois". Le mécanisme pour dire cela impliquerait soit de stocker cette date de nous même, soit de re-générer le fichier et comparer (ce qui donc me semble tout aussi lourd que de re-générer le fichier et le renvoyer tout le temps).
Pour la volumétrie, c'est vrai. Mais cela dépend alors de la quantité de données mises dans chaque fichier, donc, une mauvaise volumétrie me semblerait plutôt être due à une mauvaise estimation des quantités de données lors de la phase de conception. En revanche, là, je perds effectivement l'outil de recherche dans le texte. Qu'entends-tu par "vues" des données? L'affichage des messages dans la navigateur? Et ok, c'est à voir pour MongoDB, merci de la piste.
28-07-2013, 05:24 PM
(Modification du message : 28-07-2013, 05:34 PM par Sephi-Chan.)
Tu peux utiliser le caching HTTP de plusieurs façon : dire que ton document est valide pendant une durée donnée, mais tu peux également utiliser des ETags : utiliser une donnée dynamique qui sera peu coûteuse à récupérer et qui te permettra de dire si le cache est à jour ou non : une requête est effectuée mais dans certains cas aucun contenu ne sera pas téléchargé (quand l'ETag du document que possède déjà le client correspond à l'ETag généré par le serveur).
Quand je parle de vues de l'information, c'est dans une optique de stocker des données prêtes à l'emploi pour un usage spécifique : ça ne colle pas forcément à un autre usage. Dans la terminologie des data warehouse, c'est ce qu'on appelle les data marts (créer des dimensions, plus simples et efficaces à utiliser que les données normalisées). Je ne sais pas si ça s'applique dans ton cas particulier, mais c'est à considérer.
28-07-2013, 05:37 PM
L'ETag doit donc être stocké coté serveur... Ok, je retiens aussi l'idée.
Oui, d'accord, mais donc dans ce cas, ce sont plutôt des données "ordinateur" que des données "humaines". Par données humaines, j'entends des données qui sont seulement destinés à l'affichage humain, alors que les données ordinateur seraient plutôt des informations que la machine va traiter, assembler, et modifier (donc, elle doit les "comprendre"). Or, les messages me semblent être des données humaines, qui n'ont donc pas de "vues" pour la machine et qui seraient alors parfaitement compatibles avec un stockage au fichier. A l'inverse, les meta données des messages (date de création, d'édition, identifiant de l'auteur...) sont plus des données machines, qui auraient besoin de plusieurs vues, et qui donc iraient dans la BDD (mais sauver une dizaine d'entiers correspondant à ces meta données est souvent bien moins pesant que stocker le message entier). Merci de ces réponses constructives, j'essayerai donc de voir MongoDB et ETags, et d'utiliser cette idée avec parcimonie. |
|
|
