Nous avons un tel système en production intensive avec plus de 30 000 fichiers et plus de 20 Go à ce jour...
Column | Type | Modifiers
-------------+-----------------------------+----------------------------------------------------------
File_ID | integer | not null default nextval('"ACRM"."File_pseq"'::regclass)
CreateDate | timestamp(6) with time zone | not null default now()
FileName | character varying(255) | not null default NULL::character varying
ContentType | character varying(128) | not null default NULL::character varying
Size | integer | not null
Hash | character varying(40) | not null
Indexes:
"File_pkey" PRIMARY KEY, btree ("File_ID")
Les fichiers sont simplement stockés dans un seul répertoire avec l'entier File_ID comme nom de fichier. Nous sommes plus de 30 000 sans aucun problème. J'ai testé plus haut sans problème.
Cela utilise RHEL 5 x86_64 avec ext3 comme système de fichiers.
Est-ce que je recommencerais de cette façon ? Non. Permettez-moi de partager quelques réflexions sur une refonte.
-
La base de données reste la "source maîtresse" des informations sur les fichiers.
-
Chaque fichier est sha1() haché et stocké dans une hiérarchie de système de fichiers basée sur ce hachage :
/FileData/ab/cd/abcd4548293827394723984723432987.jpg -
la base de données est un peu plus intelligente pour stocker les méta-informations sur chaque fichier. Ce serait un système à trois tables :
File:stocke des informations telles que le nom, la date, l'adresse IP, le propriétaire et un pointeur vers un blob (sha1)File_Meta:stocke les paires clé/valeur sur le fichier, selon le type de fichier. Cela peut inclure des informations telles que Image_Width, etc...Blob:stocke une référence au sha1 avec sa taille.
Ce système dédupliquerait le contenu du fichier en stockant les données référencées par un hachage (plusieurs fichiers pourraient référencer les mêmes données de fichier). Il serait très facile de sauvegarder la synchronisation de la base de données de fichiers à l'aide de rsync.
De plus, les limitations d'un répertoire donné contenant beaucoup de fichiers seraient éliminées.
L'extension de fichier serait stockée dans le cadre du hachage de fichier unique. Par exemple, si le hachage d'un fichier vide était abcd8765 ... Un .txt vide fichier et vider .php le fichier ferait référence au même hachage. Ils doivent plutôt faire référence à abcd8765.php et abcd8765.txt . Pourquoi ?
Apache, etc. peut être configuré pour choisir automatiquement le type de contenu et les règles de mise en cache en fonction de l'extension de fichier. Il est important de stocker les fichiers avec un nom valide et l'extension qui reflète le contenu du fichier.
Vous voyez, ce système pourrait vraiment augmenter les performances en déléguant la livraison des fichiers via nginx. Voir http://wiki.nginx.org/XSendfile .
J'espère que cela aide d'une certaine manière. Prenez soin de vous.
