Déplacement d'un million de fichiers image vers Amazon S3

Je lance un site Web de partage d'images qui contient plus d'un million d'images (~ 150 Go). Je les stocke actuellement sur un disque dur de mon serveur dédié, mais je manque rapidement d'espace, je voudrais donc les déplacer vers Amazon S3.Déplacement d'un million de fichiers image vers Amazon S3

J'ai essayé de faire un RSYNC et il a fallu un jour à RSYNC pour balayer et créer la liste des fichiers image. Après un autre jour de transfert, il n'était que 7% terminé et avait ralenti mon serveur jusqu'à un crawl, j'ai donc dû annuler.

Existe-t-il un meilleur moyen de le faire, par exemple GZIP vers un autre disque dur local, puis de transférer/décompresser ce fichier unique?

Je me demande également s'il est judicieux de stocker ces fichiers dans plusieurs sous-répertoires ou est-ce bien d'avoir tous les fichiers million + dans le même répertoire?

Source

2011-01-17 makeee

Ceci n'est pas lié à la programmation. – Alan

Vous pouvez simplement l'exécuter la nuit lorsque votre serveur n'est pas aussi occupé. Il y a aussi le "gentil" outil qui pourrait réduire votre problème de lenteur. Puisque rsync peut être configuré pour ignorer les doublons, la vitesse s'améliorera finalement. Je diviserais certainement les images en sous-répertoires car de nombreuses commandes Linux commencent à échouer une fois que vous avez> 100.000 fichiers. Un autre problème, vous pouvez manquer d'inodes si vous avez trop de fichiers. –

Étant donné que les fichiers n'existent pas (encore) sur S3, les envoyer comme un fichier d'archive devrait être plus rapide que d'utiliser un protocole de synchronisation. Toutefois, la compression de l'archive n'aidera pas (voire pas du tout) les fichiers d'image, à condition que les fichiers d'image soient déjà stockés dans un format compressé tel que JPEG.
Transmettre ~ 150 Go de données vont consommer beaucoup de bande passante réseau pendant une longue période. Ce sera la même chose si vous essayez d'utiliser HTTP ou FTP au lieu de RSYNC pour effectuer le transfert. Un transfert hors ligne serait préférable si possible; par exemple. envoyer un disque dur, ou un ensemble de cassettes ou de DVD.
Placer un million de fichiers dans un seul répertoire est une mauvaise idée du point de vue des performances. alors que certains systèmes de fichiers s'en sortiraient assez bien avec O(logN) temps de recherche de nom de fichier, d'autres pas avec O(N) recherche de nom de fichier. Multipliez cela par N pour accéder à tous les fichiers d'un répertoire. Un problème supplémentaire est que les utilitaires qui ont besoin d'accéder aux fichiers dans l'ordre des noms de fichiers peuvent ralentir considérablement s'ils ont besoin de trier un million de noms de fichiers. (Cela peut expliquer en partie pourquoi rsync a pris 1 jour pour faire l'indexation.)
Mettre tous vos fichiers image dans un répertoire est une mauvaise idée du point de vue de la gestion; par exemple. pour effectuer des sauvegardes, archiver des éléments, déplacer des éléments, étendre à plusieurs disques ou systèmes de fichiers, etc.

Source

2011-01-17 02:52:58

Serait-il raisonnable de diviser des fichiers de 1m en 1000 sous-répertoires? Il n'y a aucune raison d'avoir plus d'un niveau de fichiers? – makeee

Oui, il le ferait. Il y a plusieurs façons de le faire, selon la façon dont ils sont nommés et organisés, comment vous voulez les gérer, etc. –

Si je dois diviser les fichiers, gzip ne semble pas avoir de sens. peut simplement faire une boucle dans chaque élément de la base de données, récupérer le nom de fichier, copier le fichier sur S3, changer son nom de fichier en identifiant mysql autoincrement. Ensuite, je peux juste diviser les fichiers en fonction de leur ID (plus je n'aurai plus besoin d'avoir une colonne de nom de fichier dans la base de données). Même si cela prend un mois, je peux au moins faire une partie chaque jour et commencer à lire à partir de S3 pour les fichiers qui sont sur S3, et supprimer les anciens fichiers sur le serveur pour économiser de l'espace. Cela semble raisonnable? – makeee

Une option que vous pourriez utiliser au lieu de transférer les fichiers sur le réseau est de les mettre sur un disque dur et de l'expédier au service import/export d'amazon. Vous n'avez pas à vous soucier saturant votre connexion réseau du serveur, etc.

Source

2011-01-17 02:30:43 GWW

Malheureusement, ce n'est pas une option, car je n'ai pas un accès facile au centre de données pour faire quelque chose comme ça. – makeee

Une option peut être d'effectuer la migration de manière paresseuse.

Toutes les nouvelles images vont à Amazon S3.
Toutes les demandes d'images qui ne sont pas encore sur Amazon déclenchent une migration de cette image vers Amazon S3. (file d'attente en haut)

Cela devrait assez rapidement faire passer toutes les images récentes ou communément récupérées sur Amazon et ainsi réduire la charge sur votre serveur. Vous pouvez ensuite ajouter une autre tâche qui migre lentement les autres lorsque le serveur est le moins occupé.

Source

2011-01-17 03:18:27

belle suggestion! – sdolgy

J'ai pris cette approche récemment, quand j'avais besoin de migrer 40 millions d'images vers S3. J'ai mis le code que j'ai utilisé sur Github, j'espère que quelqu'un d'autre trouve cela utile: https://github.com/mikery/s3cacher –

Je suis également favorable à cette idée. Élégant. –

Déplacement d'un million de fichiers image vers Amazon S3

Répondre

Questions connexes