Duplicaté possible:
Stockage des photos et des documents téléchargés - FileSystem VS Base de données BLOBJe commence à développer une application Web, dont le but principal est d'afficher des photos. Les utilisateurs pourront également télécharger des photos.
La première question qui s'est produite était la suivante pour stocker les photos: sur le système de fichiers ou la base de données.
Je vais utiliser une boîte Windows pour héberger le site. La base de données est MySQL et le code du backend est en C # utilisant ASP.NET MVC.
10 Réponses :
Généralement, les gens stockent des données binaires telles que des images sur le système de fichiers, pas la base de données. Ils font référence à la voie du système de fichiers de la base de données. Récupérer des blobs (gros objets binaires) de la base de données est plus lent que de permettre au serveur Web de servir des fichiers statiques à partir du système de fichiers.
Cela rend la vie si facile lorsque vous avez une base de données blob. Vous devriez oublier le cauchemar qui est la gestion du système de fichiers.
id De l'expérience C'est un moyen efficace de gérer des fichiers binaires. Vous avez une base de données qui n'a que des fichiers binaires. Comment cela peut-il être plus difficile à sauvegarder?
Varbinary
Jusqu'à ce que vous ayez besoin de sauvegarder votre base de données et surprise , il a des milliers de concerts de déchets binaires mélangés à la métadonnée.
Oui, cela devrait être l'objectif principal de toute architecture logicielle ... rendre "la vie si facile" pour le développeur. Oubliez les opérations que les personnes qui doivent faire face à une base de données multi-téraoctérabyte ou à l'utilisateur qui doivent attendre que des images se sortent d'un serveur conçu pour stocker des données et non des images.
Vous avez offert des raisons valables de ne pas stocker de données binaires. C'est le même vieux mantra qui a été sensibilisé depuis des années.
... Si vous êtes plus préoccupé par un développement facile ou des considérations académiques qu'avec des problèmes pratiques d'évolutivité et certains des aspects informatiques de la maintenance.
S'il vous plaît dites-moi comment utiliser le système de fichiers est plus efficace ou évolutif?
Parfois, un mantra est, en fait, axiomatique. Parfois, les gens "sonnent à plusieurs reprises" la vérité et parfois, les âmes violicelles courageuses qui font rouiller contre ces truismes sont fausses.
Un système de fichiers est une base de données - une base de données qui devrait être conçue à partir du départ pour stocker des fichiers / documents, par opposition aux petits champs de champs répétés, des magasins relationnels ont été destinés à l'origine. Vous pouvez créer des solutions viables avec une SGBDM, mais vous trouverez une plus grande variété d'outils naturels et intuitifs pour traiter des fichiers lorsqu'il s'agit d'un système de fichiers.
J'utiliserais quelque chose comme Amazon S3.
Mais, si le choix est entre le système de fichiers et la base de données, je choisirais un système de fichiers car il est plus rapide d'images de serveur à partir d'un système de fichiers qu'une base de données.
Système de fichiers, bien sûr, à moins que vous visiez une histoire sur TheDailyWTF. Le moyen le plus simple est d'avoir les photos organisées par une propriété que vous pouvez tirer du fichier lui-même, telles que son hachage SHA-1. Ensuite, il suffit de stocker le hachage dans la base de données, connecté à la clé primaire de la photo et à d'autres attributs (qui l'a téléchargé, la date de téléchargement, etc.).
C'est aussi une bonne idée de diviser les photos sur le système de fichiers, de sorte que vous ne faites pas " T se retrouver avec des millions de fichiers dans un seul répertoire. Donc, vous aurez quelque chose comme ceci: p>
storage/00/e4/f56c0de1c61fdb926e79e8a0a65bd12930c9.jpg storage/25/9a/ec1c55bfb660548a6770238668c4b117d92f.jpg storage/5d/d5/4b01d98f17a9ad9dd1526b49ba39b5aa37a1.jpg storage/63/49/6f740b6c284ce6685dc17d473a7360ace249.jpg storage/b1/75/066d178188dde110149a8422ab651b0ee615.jpg storage/b1/20/a2b7d02b7b0c43530677ab06235382a37e20.jpg storage/da/39/a3ee5e6b4b0d3255bfef95601890afd80709.jpg
L'idée de hachage SHA-1 pour la création de répertoires et de noms de fichiers est brillante. Réponse acceptée.
Mais qu'en est-il de la suppression? Exemple: 2 utilisateurs ont téléchargé le même fichier. Donc, un seul fichier existe car le hachage (chemin) est le même. Lorsque l'un d'entre eux supprimez la photo, le second utilisateur l'aura également perdu. Ai-je raison?
@John Millikin, comment générez-vous et stockez-vous le répertoire de stockage dans la base de données?
@binball vous pouvez garder un compteur simple pour chaque hachage. Si un utilisateur télécharge un fichier correspondant à un hachage existant, augmentez simplement le nombre d'un. Si un utilisateur supprime, vous diminuez le nombre et si le nombre atteint zéro, supprimez-le en toute sécurité. C'est une forme de «comptage de référence»
J'ai une question similaire sur la manière dont les développeurs de l'industrie structurent les dossiers et les fichiers téléchargés et rencontrent ce fil Stackoverflow, cette réponse est géniale, mais elle est ici depuis 11 ans, elle est donc toujours considérée comme une bonne pratique pour structurer les fichiers téléchargés dans cette voie à partir de 2021? Merci
@Han oui, j'ai stocké des fichiers sur le système de fichiers plusieurs fois au cours des 11 dernières années. Fonctionne raisonnablement bien. Cela dit, pour des installations plus petites, j'ai également gardé les photos dans la DB sans dégradation de perf. C'est pratique parce que vous pouvez sauvegarder et restaurer la DB ailleurs et tout est là - vous n'avez pas à faire une étape séparée pour copier les photos. Cependant, il fait un peu à la base de données. Vous devez donc peser les avantages et les inconvénients de votre situation.
La seule raison pour laquelle je voudrais mettre des photos comme des blobs dans une base de données serait si j'avais un groupe de serveurs et j'utilisais la réplication de la base de données pour copier automatiquement les photos sur chaque ordinateur du cluster.
La vie est beaucoup plus simple si vous stockez simplement les photos comme fichiers et stockez les noms de fichiers des photos de la base de données. Si vous devez créer des noms de fichiers uniques pour les photos, vous pouvez utiliser un entier principal de clé de la base de données dans le cadre du nom de fichier. Mais vous pouvez également utiliser un hasch de la photo elle-même, comme suggéré par John Milliken. C'est simple et simple, c'est mieux.
peut également être fait sur le système de fichiers. Pas besoin de mettre des images dans la DB.
"peut aussi être fait"? C'est plutôt terres. Dites-vous que la réplication automatique peut être effectuée? Je présume le cas; Quelqu'un doit avoir écrit un système de réplication de fichier. Mais si vous avez déjà une réplication de base de données configurée, il peut être plus simple de pousser les photos à la place, plutôt que de configurer et de déboguer deux systèmes de réplication distincts. Êtes-vous en désaccord?
Certaines personnes soulignent qu'il est plus facile de gérer si tout est dans la base de données: y compris la fabrication de sauvegardes et la préservation de l'intégrité référentielle.
La seule raison d'envisager même de les stocker dans la DB, imo.
Je dirais que c'est une foutue bonne raison de.
Si vous le stockez dans DB, la DB augmentera rapidement et sera beaucoup plus grande. Il s'agit simplement d'une touche plus compliquée pour obtenir une image de DB pour l'affichage, puis de l'obtenir à partir d'un système de fichiers. D'autre part, vous ferez mieux de vous assurer que les noms de fichier et les chemins ne sont pas synchronisés avec ce qui est stocké dans dB. Dans le passé, j'ai choisi de stocker sur le disque au lieu de dB. Cela m'a permis de déplacer la base de données dans différentes cases. Bien travaillé bien.
Nous avons eu une décision similaire de faire un projet que je suis sur. La chose impérieuse à propos de Jamming Stuff (images et autres choses blobeuses) dans la DB est qu'il est moins probable que quelqu'un puisse supprimer / modifier quelque chose (intentionnellement ou involontairement). Mais ce n'est pas le choix que nous avons fait. Au lieu de cela, nous avons les informations de chemin stockées dans la base de données et utilisons cela pour référencer les données via un chemin UNC. Les chemins de données sont stockés en deux parties - une partie qui fait référence à l'emplacement des données relatives à la machine qu'il réside sur et une partie qui pointe vers quelle machine le groupe de données est activé. Lorsque nous devons déplacer des données autour, nous pouvons mettre à jour les informations de chemin appropriées.
Il est certainement rapide d'obtenir les données sans tirer de la DB. En fin de compte, c'était un facteur déterminant majeur.
Si vous construisez un site Web autour des photos, oubliez la base de données. Si cela deviendra populaire, votre base de données sera heureuse et la majorité de son temps sera consacrée à la livraison de photos. De plus, les bases de données ne sont pas très bien évoluées. Il y a tellement plus d'avantages pour les garder sur le système de fichiers. Et vous pouvez très bien évoluer, avoir des serveurs de contenu statiques, en utilisant des services pour la livraison de contenu.
En outre, Amazon S3 ou d'autres fournisseurs de cloud ont leurs avantages. Par exemple, S3 + Amazon Cloudfront fournira de bonnes performances. Cloudfront met en cache vos fichiers sur des serveurs du monde entier afin qu'ils soient très facilement / rapides accessibles de n'importe où. Mais si nous parlons des photos et que le site devient populaire, vos factures pourraient être assez élevées.
pour s3 Amazon Charges par stockage et par transfert dans / hors du nuage. Pour Cloudfront par virement .
Si vous utilisez SQL Server 2008, il existe un type de données FILESTREM qui gère la plupart des problèmes mentionnés sur la DB deviennent plus grandes. Il gère tous les détails gênants de la synchronisation entre le système de fichiers et la table.
Regardez ici pour un message de blog sur le sujet: Stockez toutes les données dans SQL Server 2008 (Katmai)
Au fait, ce message était simplement informatif ... :)
Laissez la guerre sainte commencer ....
@LocksFree pourrait être des milliers d'images. Pourrait être plus, selon que les gens utilisent réellement le site.