Question

Actuellement, j'ai des images (6 Mo maximum) stockées sous forme de BLOB dans une table InnoDB. Alors que la taille des données augmente, la sauvegarde nocturne augmente de plus en plus, ce qui nuit aux performances normales.

Les données binaires doivent donc aller dans le système de fichiers. (les pointeurs sur les fichiers seront conservés dans la base de données.)

Les données ont un arbre comme relation:

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

Je souhaite maintenant que les données soient réparties de manière uniforme dans la structure de répertoires. Comment dois-je accomplir cela?

Je suppose que je pourrais essayer MD5 ('userId, albumId, imageId'); et découper la chaîne résultante pour obtenir le chemin de mon répertoire:

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

Cela me permettrait de mapper le premier caractère sur un serveur et de répartir uniformément la structure de répertoires sur plusieurs serveurs.

Toutefois, ne conservera pas les images par utilisateur, ce qui risquerait de les diffuser pour un album sur plusieurs serveurs.

Ma question est la suivante:
Quel est le meilleur moyen de stocker les données d'image dans le système de fichiers de manière équilibrée, tout en conservant les données utilisateur / album ensemble?

Est-ce que je pense dans la bonne direction? ou est-ce la mauvaise façon de faire les choses?

Mise à jour:
Je vais choisir la chaîne md5 (user_id) pour le fractionnement au plus haut niveau. Et mettez ensuite toutes les données utilisateur dans le même compartiment. Cela garantira une distribution uniforme des données tout en gardant les données utilisateur stockées proches les unes des autres.

  /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 séparé par derrière (j'aime cette idée!) pour réduire le nombre d'albums par répertoire (bien que cela ne soit pas nécessaire pour la plupart des utilisateurs).

Merci!

Était-ce utile?

La solution

Séparez simplement votre ID utilisateur par derrière. par exemple

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

En ce qui concerne la sauvegarde, vous pouvez utiliser la réplication MySQL et sauvegarder l’esclave. base de données pour éviter les problèmes (verrous, par exemple) lors de la sauvegarde.

Autres conseils

Une chose à propos de la répartition des noms de fichiers dans différents répertoires. Si vous envisagez de scinder vos noms de fichiers md5 en différents sous-répertoires (ce qui est généralement une bonne idée), je vous suggérerais de conserver le hachage complet en tant que nom de fichier et de dupliquer les quelques premiers caractères sous forme de noms de répertoires. . Cela facilitera l'identification des fichiers, par exemple. lorsque vous devez déplacer des répertoires.

par exemple

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

Si vos noms de fichiers ne sont pas distribués de manière uniforme (pas un hachage), essayez de choisir une méthode de division qui obtient une distribution égale, par exemple. les derniers caractères s'il s'agit d'un identifiant d'utilisateur incrémentant

J'utilise cette stratégie avec un identifiant d'image unique

  • inverser la chaîne
  • remplissez-le avec un zéro non significatif s'il y a un nombre impair de chiffres
  • divise la chaîne en sous-chaînes à deux chiffres
  • construisez le chemin comme 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 images et 100 sous-dossiers et que la charge est répartie uniformément entre les dossiers les plus à gauche.

De plus, vous avez juste besoin de l’ID de l’image pour atteindre le fichier, pas besoin de lire le tableau d’images contenant d’autres métadonnées. Les données utilisateur ne sont pas stockées de manière rapprochée et la relation ID-Path est prévisible, elle dépend de vos besoins.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top