2011-07-29 3 views
7

Voici la meilleure méthode que j'ai trouvé jusqu'à présent et je voudrais savoir s'il existe une meilleure méthode (j'en suis sûr!) Pour stocker et récupérer des millions d'images utilisateur:Quel est le moyen le plus rapide et le plus efficace de stocker et de récupérer des images lorsque vous avez des millions d'utilisateurs sur un serveur LAMP?

In afin de maintenir le répertoire tailles de bas et éviter d'avoir à faire des appels supplémentaires à la DB, je suis en utilisant les répertoires imbriqués qui sont calculées en fonction de l'ID unique de l'utilisateur comme suit:

$firstDir = './images'; 
$secondDir = floor($userID/100000); 
$thirdDir = floor(substr($id, -5, 5)/100); 
$fourthDir = $userID; 
$imgLocation = "$firstDir/$secondDir/$thirdDir/$fourthDir/1.jpg"; 

de ID utilisateur ($userID) vont de 1 aux millions.

Donc, si je ID utilisateur 7654321, par exemple, la première image de cet utilisateur sera stocké dans:

./images/76/543/7654321/1.jpg 

pour l'ID utilisateur 654321:

./images/6/543/654321/1.jpg 

pour l'ID utilisateur 54321 il serait :

./images/0/543/54321/1.jpg 

Pour l'ID utilisateur 4321 ce serait:

./images/0/43/4321/1.jpg 

pour l'ID utilisateur 321 ce serait:

./images/0/3/321/1.jpg 

pour l'ID utilisateur 21 ce serait:

./images/0/0/21/1.jpg 

pour l'ID utilisateur 1 il serait:

./images/0/0/1/1.jpg 

Cela garantit qu'avec un maximum de 100 000 000 d'utilisateurs, je n'aurai jamais un répertoire avec plus de 1 000 sous-répertoires, il semble donc garder les choses propres et efficaces.

J'ai comparé cette méthode à l'utilisation de la méthode de "hachage" suivante qui utilise la méthode de hachage la plus rapide disponible en PHP (crc32). Cette méthode de « hachage » calcule le deuxième répertoire que les 3 premiers caractères dans le hachage de l'ID utilisateur et le troisième répertoire comme le prochain 3 caractère afin de distribuer les fichiers au hasard, mais uniformément comme suit:

$hash = crc32($userID); 
$firstDir = './images'; 
$secondDir = substr($hash,0,3); 
$thirdDir = substr($hash,3,3); 
$fourthDir = $userID; 
$imgLocation = "$firstDir/$secondDir/$thirdDir/$fourthDir/1.jpg"; 

Cependant , cette méthode de «hachage» est plus lente que la méthode que j'ai décrite plus haut, donc ce n'est pas bon.

Je suis ensuite allé un peu plus loin et a trouvé une méthode encore plus rapide du calcul du troisième répertoire dans mon exemple original (floor(substr($userID, -5, 5)/100);) comme suit:

$thirdDir = floor(substr($userID, -5, 3)); 

Maintenant, cela change comment/où les 10.000 premiers ID utilisateur de sont stockés, ce qui fait que certains répertoires ont soit 1 sous-répertoire utilisateur ou 111 au lieu de 100, mais il a l'avantage d'être plus rapide puisque nous n'avons pas à diviser par 100, donc je pense que ça vaut le coup à long terme .Une fois la structure du répertoire est définie, voici comment je prévois de stocker les images individuelles réelles: si un utilisateur télécharge une deuxième photo, par exemple, il irait dans le même répertoire que leur première photo, mais il serait nommé 2.jpg. L'image par défaut de l'utilisateur sera toujours 1.jpg, donc s'ils décident de faire de leur deuxième image l'image par défaut, 2.jpg sera renommé 1.jpg et 1.jpg sera renommé 2.jpg.

Last but not least, si je devais stocker plusieurs tailles de la même image, je les stocker comme suit pour l'ID d'utilisateur 1 (par exemple):

1024px:

./images/0/0/1/1024/1.jpg 
./images/0/0/1/1024/2.jpg 

640px :

./images/0/0/1/640/1.jpg 
./images/0/0/1/640/2.jpg 

C'est à peu près tout.

Alors, y a-t-il des failles avec cette méthode? Si oui, pourriez-vous les signaler?

Existe-t-il une meilleure méthode? Si oui, pourriez-vous le décrire? Avant de commencer à l'implémenter, je veux m'assurer de disposer de la méthode la meilleure, la plus rapide et la plus efficace pour stocker et récupérer des images afin de ne pas avoir à le changer à nouveau.

Merci!

+1

J'espère que rien de ce que vous stockez/accédez de cette façon est privé ou confidentiel, car il devient extrêmement facile de naviguer vers les dossiers d'image des autres utilisateurs –

+0

La confidentialité n'est pas une préoccupation dans mon cas, donc cela ne devrait pas être un problème. Mes utilisateurs veulent voir leurs photos. Par souci de rigueur, si la vie privée était une préoccupation, quelle solution recommanderiez-vous? – ProgrammerGirl

+1

Le moyen le plus rapide de charger des millions d'images est de ne pas les charger. C'est-à-dire, utilisez 'memcached', et reposez sur l'hypothèse que 95% des utilisateurs veulent voir le même 5% des images tout le temps. – Damon

Répondre

3

Est-ce pas soins sur les petites différences de vitesse de calculting le chemin, il ne matière. Ce qui importe, c'est la façon dont les images sont distribuées dans les répertoires, combien est court le chemin, combien il est difficile de déduire la convention de nommage (remplaçons 1.jpg par 2.jpg .. wow, ça marche ..) .

Par exemple, dans votre solution de hachage, le chemin est entièrement basé sur userid, ce qui placera toutes les images appartenant à un utilisateur dans le même répertoire.

Utilisez l'alphabet entier (majuscule et minuscule, si votre FS le prend en charge), et pas seulement les chiffres. Vérifiez ce que d'autres logiciels font, un bon endroit pour vérifier les noms directs hashed est google chrome, mozilla, ... Il est préférable d'avoir des noms de répertoires courts. Plus rapide à chercher, occupe moins d'espace dans vos documents html.

+0

Mais les petites différences de vitesse/CPU requises ne seront-elles pas amplifiées de manière significative lorsque des millions d'utilisateurs interagiront simultanément avec le serveur? – ProgrammerGirl

+0

@Programmer si une si petite différence d'efficacité rend votre site inutilisable, alors vous devriez utiliser une ferme de serveurs pour étendre votre site. Il y a des préoccupations plus importantes et plus importantes que l'efficacité, comme la sécurité. Effectuer des contrôles de sécurité n'est pas "efficace", mais la vitesse de chargement de votre page n'a pas d'importance si vous perdez tous vos utilisateurs. Si vous avez vraiment des millions d'utilisateurs et que vous ne pouvez pas vous permettre une batterie de serveurs, vous devez probablement repenser votre modèle d'entreprise. –

+0

* tout * va être agrandi. –

Questions connexes