Une meilleure façon de stocker de gros fichiers dans une base de données MySQL?

Question

J'ai un script PHP que vous pouvez télécharger des fichiers très volumineux avec (jusqu'à 500 Mo), et le contenu du fichier est stocké dans une base de données MySQL. Actuellement, je fais quelque chose comme ceci:

mysql_query("INSERT INTO table VALUES('')"); 

$uploadedfile = fopen($_FILES['file']['tmp_name'], 'rb'); 
while (!feof($uploadedfile)) { 
    $line = mysql_escape_string(fgets($uploadedfile, 4096)); 
    mysql_query("UPDATE table SET file = CONCAT(file, '$line') WHERE something = something"); 
} 
fclose($uploadedfile); 

Cela fait bien sûr beaucoup de requêtes sql.

Je l'ai fait plutôt que quelque chose comme

$file = file_get_contents($_FILES['file']['tmp_name']); 
mysql_query("INSERT INTO table VALUES('$file')"); 

parce que épuiserait cependant beaucoup de mémoire le fichier était, et il semblait préférable de faire plus de requêtes SQL que d'utiliser 500 Mo de mémoire.
Cependant, il doit y avoir un meilleur moyen. Dois-je aller de l'avant et le faire de manière file_get_contents ou y at-il un meilleur moyen que CONCAT, ou est-ce que je le fais maintenant le moindre de tous les maux?

Answer 1

Je stocke toujours mes fichiers sur le serveur et stocke leur emplacement dans la base de données.

Answer 2

Je voudrais imaginer que le moyen le plus efficace de faire cela serait de faire toute la validation dans le script jusqu'à l'insertion, puis de sortir et de faire un transfert de fichiers du fichier temporaire $ FILES téléchargé dans une requête d'insertion de ligne de commande MySQL. Vous voulez quelqu'un de mieux que moi pour valider cela, mais il semble que cela enlèverait à peu près le problème de mémoire?

Answer 3

Cela ne fonctionnerait pas réellement (par défaut) avec mySQl, car cela provoquerait une grosse requête de 500 Mo.

$file = file_get_contents($_FILES['file']['tmp_name']); 
mysql_query("INSERT INTO table VALUES('$file')"); 

parce que le max_allowed_packet est réglé sur 16777216. Vous soit demandé de l'augmenter ou le diviser en petits morceaux de 16 Mo (moins requête ~ 500-1000 octets pour la chaîne de requête).

Vous pouvez trouver le max_allowed_packet de votre serveur mysql en faisant l'interrogation

SELECT @@global.max_allowed_packet 

Answer 4

Je dois encore voir une application qui a réellement besoin de stocker des fichiers dans une base de données relationnelle.

Il existe un grand nombre de bases de données puissantes disponibles gratuitement et conçues et optimisées spécifiquement pour stocker/récupérer des fichiers. Ils sont appelés systèmes de fichiers

Stockez vos fichiers dans votre système de fichiers et vos métadonnées dans le SGBDR.

Vous vous inquiétez d'utiliser 500 Mo de mémoire lors de l'insertion, et on ne sait pas pourquoi. Vous allez finalement vouloir récupérer ces fichiers hors de la base de données, et je ne pense pas que vous trouverez un moyen de lire les données de fichier en morceaux.

Answer 5

Vous pouvez utiliser ceci:

http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_load-file Il donne aussi un exemple simple de la requête.

Answer 6

Vous avez raison, dans certains cas, un système de fichiers ne peut pas faire le travail. Parce que les bases de données ont des fonctionnalités telles que le verrouillage, la réplication, l'intégrité, pas de limitation sur le nombre de lignes, etc etc ... Qui n'existent pas dans un système de fichiers.

En outre, la sauvegarde/restauration/migrer le système devient plus complexe et ne peut se faire en toute sécurité sur un serveur exécutant (risque d'incohérence et la perte de données). Ou au moins garantir cela est très difficile dans une configuration DB + FS.

Qu'en est-il d'une migration «/» OS à base de séparation à un « \ » sur la base d'un? Vous devez mettre à jour tous vos chemins.

Votre méthode semble être correcte, mais le découpage en tranches de 4096 octets est trop petite. Mysql n'aura aucun problème à travailler avec des tranches de 256 Ko, par exemple.

De même, je ne voudrais pas concaténer, mais plutôt stocker chaque tranche comme un seul enregistrement. La base de données peut avoir des difficultés à stocker des fichiers volumineux dans un seul enregistrement, ce qui peut entraîner des limitations mentionnées dans d'autres réponses.

Garder les données en tranches permettra de streaming le contenu sans jamais stocker l'ensemble des données en mémoire, par exemple. De cette façon, il n'y a pratiquement aucune limite à la taille du fichier stocké.