Comment stocker des images dans votre système de fichiers

Question

Actuellement, j'ai des images (max. 6MB) stockées dans des BLOB dans une table InnoDB. Comme la taille des données est en croissance, la nuit de sauvegarde est en croissance de plus en plus lent entravant le fonctionnement normal.

Ainsi, les données binaires besoin d'aller dans le système de fichiers. (pointeurs vers les fichiers seront conservés dans la base de données.)

Les données a un arbre comme la relation:

- main site
  - user_0
    - album_0
    - album_1
    - album_n
  - user_1
  - user_n
etc...

Maintenant, je veux que les données soient répartis uniformément à travers la structure de répertoire. Comment dois-je accomplir?

Je suppose que je pourrais essayer, MD5('userId, albumId, imageId'); et tranchez la chaîne résultante à obtenir mon chemin d'accès au répertoire:

/var/imageStorage/f/347e/013b/c042/51cf/985f7ad0daa987d.jpeg

Cela me permettrait de cartographier le premier caractère d'un serveur et de distribuer uniformément la structure de répertoire sur de multiples serveurs.

Ce ne serait cependant pas à garder des images organisé par l'utilisateur, susceptibles de propager les images pour 1 album sur de multiples serveurs.

Ma question est:
Quelle est la meilleure façon de stocker les données d'image dans le système de fichiers d'une manière équilibrée, tout en gardant l'utilisateur/l'album de données ?

Suis-je la pensée dans la bonne direction? ou est-ce de la mauvaise façon de faire les choses tout à fait?

Mise à jour:
Je vais aller pour l' md5(user_id) chaîne de découpage pour l'séparés au plus haut niveau. Et puis mettre toutes les données de l'utilisateur dans le même seau. Cela permettra d'assurer une répartition homogène des données, tout en conservant les données de l'utilisateur stockées à proximité.

/var
 - imageStorage
 - f/347e/013b
 - f347e013bc04251cf985f7ad0daa987d
 - 0
 - album1_10
 - picture_1.jpeg
 - 1
 - album1_1
 - picture_2.jpeg
 - picture_3.jpeg
 - album1_11
 - picture_n.jpeg
 - n
 - album1_n

Je pense que je vais utiliser albumId coupée en deux par derrière (j'aime cette idée!) pour garder le nombre d'albums par répertoire petits (même si il ne sera pas nécessaire pour la plupart des utilisateurs).

Merci!

Answer 1

Divisez simplement votre ID utilisateur par derrière. par exemple

 UserID = 6435624 
Path = /images/24/56/6435624
 

Quant à la sauvegarde, vous pouvez utiliser la réplication MySQL et sauvegarder la base de données esclave pour éviter les problèmes (par exemple les verrous) lors de la sauvegarde.

Answer 2

une chose à propos de la distribution des noms de fichiers dans des répertoires différents, si vous pensez à diviser votre md5 noms de fichiers dans différents sous-répertoires (qui est généralement une bonne idée), je suggère de maintenir la complète de hachage comme nom de fichier et copie la première quelques caractères comme les noms de répertoire. De cette façon, vous sera plus facile d'identifier les fichiers par exemple, lorsque vous devez déplacer les répertoires.

par exemple

abcdefgh.jpg -> a/ab/abc/abcdefgh.jpg

si vos noms de fichiers ne sont pas uniformément répartis (pas une table de hachage), essayez de choisir un mode de découpage qui obtient une même distribution, par exemple, les derniers caractères si c'est une incrémentation d'identifiant de l'utilisateur

Answer 3

Je suis en utilisant cette stratégie, donné une unique photo d'identité

• inverser la chaîne
• zerofill ne avec zéro si il y a un nombre impair de chiffres
• morceau de la chaîne en deux chiffres des sous-chaînes

• construire le chemin d'accès ci-dessous

  17 >> 71 >> /71.jpg
  163 >> 0361 >> /03/61.jpg
  6978 >> 8796 >> /87/96.jpg    
  1687941 >> 01497861 >> /01/49/78/61.jpg
  

Cette méthode garantit que chaque dossier contient jusqu'à 100 photos et de 100 sous-dossiers et la charge est répartie uniformément entre les gauche de la plupart des dossiers.

En outre, vous avez juste besoin de l'ID de l'image pour atteindre le fichier, pas besoin de lire l'image de la table contenant d'autres métadonnées. Les données de l'utilisateur ne sont pas stockées rapprochés, en effet, et l'ID de Chemin le rapport est prévisible, cela dépend de vos besoins.