Salut,
Il y a en a forcément parmi vous qui ont eu à faire le choix pour le stockage d'images à savoir mettre ça directement dans des champs binaires ou mettre juste un lien vers le nom du fichier stocké à part sur le file system.
C'est pour faire un site contenant en gros un bon millier d'images de 500Ko chacune ainsi qu'une centaine de vidéos d'environ 10 à 20 Mo (avec Apache et soit du Php soit du Ruby comme language).
Avantages/Inconvénients pour le fs:
A: liens directs dans la page == perf optimales
A: images "visibles" directement en browsant le fs et donc modifiables aussi
I: C'est pas dans la base :-)
Avantages/Inconvénients pour la bdd (ce sera PostGreSql):
A: tout est lié dans la base == un seul backup, contraintes d'intégrité, etc
A: traitement à la volée lors de l'extraction
I: perfs mauvaises surtout avec plusieurs clients en même temps
I: pas de gestion directe des champs binaires (avec PhpPgAdmin par exemple)
Quelqu'un aurait-il déjà fait quelques tests à ce sujet ?
Forum Programmation.SQL Images dans une bdd ou sur le file system ?
29
sept.
2006
# Troisieme solution:
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 4.
BDD + FS
Tu stocke tes images/video dans un dossier non exporté dans ton serveur web, et tu crée un script qui streame les fichiers.
Ainsi tu peut faire du traitement lié a ta DB pour les droits d'accès etc..
et garder une certaine simplicitée de gestion de la base d'images.
Sinon pour repondre a ta question les perfs de postgresql sont ce quelles sont. De mon experience il a tendance a être uniformement lent quand les accès se multiplient. Et je ne pense pas que lui rajouter des données binaires l'accelère (taille de row variable & co).
Quand au perfs d'un apache en serveur de fichier brut elles sont a proprement parler tres tres bonnes, et mieux vaut garder le maximum de ressource possible pour traiter les choses vraiment dynamiques.
donc moi je choisirait l'option 1
[^] # Re: Troisieme solution: (bis)
Posté par duaner . Évalué à 7.
- Si le fichier n'existe pas sur le disque, re-ecrire l'url en par ex: images.php?pic=tonimage.jpg qui enverrait l'image et le cacherait sur le disque
- sinon le servir statiquement, ou meme encore continuer a le servir par script, qui irait le chercher sur le disque si certaines conditions sont remplies (pour par exemple eviter le hotlinking...)
Une idée comme ca...
[^] # Re: Troisieme solution: (bis)
Posté par zx81 . Évalué à 1.
Mais bon, je vais quand même faire quelques tests avec la base en direct, juste histoire de voir où en sont les sgbd libres au niveau des blobs :-)
[^] # Re: Troisieme solution: (bis)
Posté par BAud (site web personnel) . Évalué à 2.
Après, j'avais surtout regardé les LOB d'Oracle (soit stockage en base, soit champ pointant vers répertoire du FS qui combinait les avantages du FS et de la BDD concernant les droits mais avec potentiellement une attention particulière à porter aux sauvegardes de la base et du FS pour que les deux restent synchros).
Il faut aussi voir qu'en architecture 3-tiers, tu as souvent apache en frontal (sur un ou plusieurs serveurs), un (ou plusieurs) serveurs d'applis et un serveur base de données (éventuellement redondé...). L'utilisation du FS devient problématique dans ce cas : doit-il être sur le(s) serveur(s) apache ou sur le serveur de base de données (le partage NFS est foireux... la synchro sur plusieurs serveurs apache peut être problématique...).
L'idée du cache web est très bonne, je la retiens ;-) (avec un risque pour la gestion des droits tout de même :/ )
# FS
Posté par clearstream . Évalué à 1.
Si t'as bien organisé ton site, tu dois pouvoir passer facilement du stockage FS à BDD.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.