Discussion :

[bastien31000]

Bonjour,

Je viens de finir une discussion sur le forum Décision SGBD de developpez.net, que vous pouvez voir ici :

http://www.developpez.net/forums/d93...s/#post6959182

Qq m'a répondu que dans mon cas, c'est à dire avec une base de données pouvant contenir 1000 ou 10 000 documents de 1 ou 2Mo en moyenne, il pourrait être plus intéressant de les gérer directement en base que de gérer seulement les adresses des fichiers en base et les fichiers sur disque, ce que je fais actuellement.

Le stockage en base me simplifierait la tache au niveau gestion, sécurité, backup. Et je peux stocker les blobs dans une table différente de la table qui contient les données associées aux fichiers (nom, taille, ...).

N'étant pas un expert bases de données, je n'ai pas vraiment de notions en terme de performance et de l'impact que ça peut avoir.

Si j'ai disons 1000 documents pour commencer et même 10000, avec une moyenne de 1Mo ou 2 Mo par doc, on arrive à une base de 10Go à 20Go. Les données représenteraient 1% de la base et le binaire 99%.

Une base de 10, 20 ou 50 Go, dont 99% en binaire, cela est facile à gérer avec mysql en terme de perf ? (sur un serveur dédié)

J'ajoute que je ne suis pas à gagner qq millisecondes, ni meme centiemes !

Mon architecture logicielle est déjà prévue pour une telle gestion car je récupère les documents et images à partir d'une fonction et non pas d'une url.

Merci pour le retour
Bastien

[Gouyon]

Personnellement je limite les blobs au maximum. Je préfère avoir une architecture ou ma base contient une grande majorité de données et une minorité de blobs.
Maintenant il faudrait faire un essai en créant une base avec des blobs et une autre avec les données des blobs dans des fichiers et faire des requêtes pour voir les performances.

[bastien31000]

ah... Ce sujet d'héberger ou pas les données binaires en base est vraiment compliqué car à chaque nouveau post, j'ai un avis soit d'un coté, soit d'un autre.

Je sais bien que rien n'est blanc ou noir et qu'il n'y a pas de solution ultime. Dasn certains cas, il vaudra mieux héberger seulement les chemins en base et les fichiers sur le filesystem et dans d'autres cas, tout héberger en base.

On m'a répondu sur l'autre forum que pour ma problématique, tout héberger en base serait plus simple et devrait être ok coté perf, mais en demandant l'avis d'expert mysql.

Je vais faire un essai en intégrant 1000 ou 2000 docs de 1Mo pour voir ce que ça donne par rapport aux perfs actuelles.

Mais personne n'aurait un retour d'expérience sur la gestion d'une base de qq dizaines de Go sur mysql avec beaucoup de blob (mais les blobs étant dans des tables séparées pour ne pas gêner une recherche simple sur les metadonnées des fichiers) ??

Merci pour la réponse quand même !

Bastien

[CinePhil]

Ça dépend de ce que tu dois faire de ces blobs.

S'il s'agit seulement de les extraire un par un à la demande de l'utilisateur, ça ne devrait pas poser de problème car le flux est le suivant :
1) Poste utilisateur demande le document d'id = N.
2) Le programme PHP envoie la requête au SGBD pour récupérer le blob d'id = N.
3) Le SGBD utilise l'index de la table et extrait du disque dur le blob.
4) Le programme PHP traite le blob pour le transformer en fichier lisible par l'utilisateur puis l'envoie sur le poste client.

=> Pour le SGBD : 1 lecture d'index et une lecture de disque (je schématise quand même un peu mais c'est l'idée). Ça reste léger et n'est pas forcément la principale activité du SGBD.

S'il s'agit par contre d'afficher des paquets de documents stockés en blob ou de les télécharger par paquet, tu comprendras facilement que le SGBD va avoir une importante activité de récupération de données sur disque et c'est ça qui plombe les performances car un SGBD travaille au maximum en mémoire vive.

=> Il vaut mieux alors, à mon avis, ne stocker en BDD que les liens vers les fichiers qui eux sont stockés dans leur format naturel sur disque, dans un répertoire dédié et protégé.

Autre détail à prendre en compte : la sauvegarde ! En principe, elle ne se fait pas avec une simple copie du répertoire de la BDD mais par mysqldump qui crée un fichier SQL permettant de reconstruire intégralement la BDD avec ses données.
Avec les fichiers en blob, tu va sauvegarder un fichier SQL de plusieurs Go de données !
La sauvegarde d'une BDD ne contenant que les métadonnées sera beaucoup plus légère, rapide à faire et rapide à restaurer en cas de crash et les fichiers pourront eux être sauvegardés facilement par copie du répertoire de stockage. En plus, avec les fichiers en répertoire, tu peux même faire une sauvegarde intelligente (incrémentale) en ne sauvegardant chaque jour que les fichiers ajoutés et/ou modifiés et la totalité du répertoire une fois par semaine ou par mois.

Je vois beaucoup plus d'inconvénients au stockage de fichiers en blob que d'avantages :
- traitement des blob pour les transformer en fichiers lisibles ;
- sauvegarde lourde de la BDD et restauration longue ;
- potentiellement de grosses lectures sur disque par le SGBD s'il y a des extractions en masse de blobs.

[bastien31000]

Bonjour,

Merci pour le retour argumenté.

Le fonctionnement sera en effet comme tu le décris avec la plupart du temps un usage ponctuel pour récupérer un fichier et l'afficher au client.

Les cas d'usage où j'aurais besoin de récupérer d'un seul coup plusieurs blob seront :

• l'export de plusieurs documents clients (export annuel par exemple)
• la sauvegarde

Concernant l'export, je suis en qq sorte obligé de générer le zip de tous les documents sur le moment. Ca peut donc en effet être un problème si ça monopolise la RAM pendant la génération.

Concernant la sauvegarde, je peux la faire la nuit par exemple, ce qui décale le problème. J'ai cru aussi comprendre qu'il était possible de faire une sauvegarde incrémentale avec la base de données et qu'il n'était pas nécessaire de sauvegarder la totalité de la base à chaque fois.

http://dev.mysql.com/doc/refman/5.0/...up-policy.html

De plus, j'ai 2 types de documents différents:
- des documents qui ne seront pas récupérés mais utilisés dans le service en ligne
- des documents générés par le service en ligne.

Une dernière solution serait de ne pas stocker ces derniers types de documents mais de la générer à la demande (ce que je fais actuellement).

L'idée de les stocker en base était justement de ne pas avoir à les générer d'un coup lors d'une demande d'export client par exemple (générer 100 docs pdf est très gourmand coté serveur). Mais du coup, si générer le pdf à partir des données est aussi gourmand que générer le document à partir du blob, il n'y a pas d'intérêt à conserver ce type de document en base.

Je vais peut être réfléchir à distinguer les 2 types de documents, stocker les documents qui ne nécessiteront pas un export et une extraction multiple mais pas les autres qui pourraient nécessiter une extraction en masse.

Concernant l'utilisation de fichiers distribués, on m'a aussi parlé de ça : http://www.gluster.org/

Merci pour les retours
Bastien