Quelle est la meilleure façon de stocker des fichiers multimédia sur une base de données?

Question

Je veux stocker un grand nombre de fichiers audio dans une base de données, mais je ne sais pas si c'est une bonne pratique. Je voudrais connaître les avantages et les inconvénients de le faire de cette façon.

J'ai également pensé à la possibilité d'avoir des "liens" vers ces fichiers, mais peut-être que cela entraînera plus de problèmes que de solutions. Toute expérience dans ce sens sera la bienvenue :)

Note: La base de données sera MySQL.

Answer 1

Chaque système que je connais qui stocke un grand nombre de gros fichiers stocke en externe à la base de données. Vous stockez toutes les données interrogeables pour le fichier (titre, artiste, longueur, etc) dans la base de données, avec un chemin partiel vers le fichier. Quand il est temps de récupérer le fichier, vous devez extraire le chemin du fichier, lui ajouter une racine de fichier (ou une URL) et le renvoyer.

Alors, vous auriez une colonne "emplacement", avec un chemin partiel en elle, comme "a/b/c/1000", qui vous associez ensuite: "http://myserver/files/a/b/c/1000.mp3"

Assurez-vous que vous avez un moyen facile de pointer la base de données de médias à un autre serveur/répertoire, au cas où vous en auriez besoin pour la récupération de données. En outre, vous pourriez avoir besoin d'une routine qui re-synchronise la base de données avec le contenu de l'archive de fichiers. De plus, si vous avez des milliers de fichiers multimédias, ne les stockez pas tous dans un seul répertoire géant - c'est un goulot d'étranglement au niveau des performances sur certains systèmes de fichiers. Au lieu de cela, les diviser en plusieurs sous-arbres équilibrés.

Answer 2

Une solution simple consisterait simplement à stocker les emplacements relatifs des fichiers sous forme de chaînes et à laisser le système de fichiers le gérer. Je l'ai essayé sur un projet (nous stockions des pièces jointes de bureau à un sondage), et cela a bien fonctionné.

Answer 3

Vous pouvez les stocker en tant que BLOB (ou LONGBLOBs), puis extraire les données lorsque vous souhaitez réellement accéder aux fichiers multimédias.

ou

Vous pouvez simplement stocker les fichiers multimédia sur un lecteur et stocker les métadonnées dans le DB.

Je penche pour la dernière méthode. Je ne sais pas comment cela se fait globalement dans le monde, mais je soupçonne que beaucoup d'autres feraient la même chose.

Vous pouvez stocker des liens (chemins partiels vers les données), puis récupérer ces informations. Facilite le déplacement des disques et leur accès.

Je stocke le chemin relatif de chaque fichier dans le DB avec d'autres métadonnées sur les fichiers. Le chemin de base peut ensuite être modifié à la volée si j'ai besoin de déplacer les données réelles vers un autre lecteur (local ou via un chemin UNC).

Voilà comment je le fais. Je suis sûr que d'autres auront aussi des idées.

Answer 4

Avantages de l'utilisation d'une base de données:

• facile à joindre des fichiers audio avec d'autres bits de données.
• Éviter les opérations d'E/S de fichiers qui contournent la sécurité de la base de données.
• Pas besoin d'opérations de séparation pour supprimer les fichiers son lorsque la base de données enregistrements sont supprimés.

Inconvénients de l'utilisation d'une base de données:

• Database ballonnement
• bases de données peuvent être plus chers que les systèmes de fichiers

Answer 5

Je pense que de les stocker dans la base de données est ok, tant que vous utilisez une bonne implémentation. Vous pouvez lire cet article plus ancien, mais bon, pour trouver des idées sur la façon d'éviter que les plus grandes quantités de données dans la base de données n'affectent les performances.

http://www.dreamwerx.net/phpforum/?id=1

J'ai eu littéralement 100 de concerts chargés dans des bases de données MySQL sans aucun problème. La conception et la mise en œuvre est la clé, faites-le mal et vous allez souffrir.

Plus d'avantages DB (non déjà mentionné): - Fonctionne mieux dans une charge environnement équilibré - Vous pouvez construire une évolutivité de stockage plus back-end

Answer 6

J'ai déjà expérimenté différents projets avec les deux méthodes et nous avons finalement décidé qu'il était également plus facile d'utiliser le système de fichiers. Après tout, le système de fichiers est déjà optimisé pour stocker, récupérer et indexer des fichiers. Le conseil que je voudrais à ce sujet est de stocker seulement un chemin "racine relative" au fichier dans la base de données, puis avoir votre programme ou vos requêtes/procédures stockées/middleware utiliser un paramètre racine spécifique à l'installation récupérer le fichier.

Par exemple, si vous stockez XYZ.Wav dans C: \ MyProgram \ Data \ sounds \ X \ le chemin complet serait

C:\MyProgram\Data\Sounds\X\XYZ.Wav 

Mais vous stockerait le chemin et le nom de fichier ou dans la base de données :

X\XYZ.Wav 

Ailleurs, dans la base de données ou dans votre fichiers de configuration du programme, mémoriser un chemin racine comme SoundFilePath égale à

C: \ MyProgram \ Data \ Sounds \

Bien sûr, vous devez séparer la racine du chemin de la base de données. De cette façon, si vous déplacez l'installation de votre programme, vous n'avez pas besoin de mettre à jour la base de données.

De plus, s'il va y avoir beaucoup de fichiers, trouver un moyen de hachant les chemins de sorte que vous ne liquidez pas avec un répertoire contenant des centaines ou des milliers de fichiers (dans mon petit exemple, il y a des sous-répertoires basé sur le premier caractère du nom de fichier, mais vous pouvez aller plus loin ou utiliser des hachages aléatoires). Cela rend les indexeurs de recherche heureux aussi.

Answer 7

Certains avantages de l'utilisation des blobs pour stocker des fichiers

• frais généraux de gestion Basse - utiliser un seul outil pour la sauvegarde/restauration etc
• Aucune possibilité pour la base de données et système de fichiers pour être désynchronisé
• de capacité transactionnelles (si nécessaire)

Quelques inconvénients

• souffle votre base de données de RAM de serveurs avec les déchets inutiles qu'il pourrait utiliser pour stocker des lignes, des index, etc
• rend vos sauvegardes de DB très grande, donc moins gérable
• pas aussi pratique que d'un système de fichiers pour servir aux clients (par exemple avec un serveur web)

---

Qu'en est-il des performances? Votre kilométrage peut varier. Les systèmes de fichiers sont extrêmement variés, de même que les bases de données dans leurs performances. Dans certains cas, un système de fichiers va gagner (probablement avec moins de gros fichiers). Dans certains cas, une base de données pourrait être meilleure (peut-être avec un très grand nombre de fichiers smallish).

Dans tous les cas, ne vous inquiétez pas, faites ce qui semble le mieux à ce moment-là.

Certaines bases de données offrent un serveur Web intégré pour servir les blobs. Au moment de l'écriture, MySQL ne le fait pas.

Answer 8

Stockez-les en tant que fichiers externes. Puis enregistrez le chemin dans un champ varchar. Mettre de gros blobs binaires dans une base de données relationnelle est généralement très inefficace - ils n'utilisent que de l'espace et ralentissent les choses lorsque les caches sont remplies sont inutilisables. Et il n'y a rien à gagner - les blobs eux-mêmes ne peuvent pas être recherchés. Vous pouvez cependant enregistrer des métadonnées multimédia dans la base de données.