2011-01-17 15 views
8

Ejecuto un sitio web para compartir imágenes que tiene más de 1 millón de imágenes (~ 150GB). Actualmente estoy almacenando estos en un disco duro en mi servidor dedicado, pero me estoy quedando rápidamente sin espacio, así que me gustaría moverlos a Amazon S3.Mover 1 millón de archivos de imagen a Amazon S3

He intentado hacer un RSYNC y RSYNC tardó más de un día en escanear y crear la lista de archivos de imagen. Después de otro día de transferencia, solo había completado un 7% y había ralentizado mi servidor hasta el último momento, así que tuve que cancelarlo.

¿Hay una mejor manera de hacerlo, como GZIP a otro disco duro local y luego transferir/descomprimir ese único archivo?

También me pregunto si tiene sentido almacenar estos archivos en múltiples subdirectorios o ¿está bien tener todos los millones de archivos en el mismo directorio?

+3

Esto no está relacionado con la programación. – Alan

+0

Puede ejecutarlo por la noche cuando su servidor no está tan ocupado. También existe la herramienta "agradable" que podría reducir su problema de lentitud. Como rsync se puede configurar para omitir duplicados, la velocidad mejorará eventualmente. Definitivamente dividiría las imágenes en subdirectorios ya que muchos comandos de Linux comienzan a fallar una vez que obtienes más de 100.000 archivos. Otro problema es que puede quedarse sin inodos si tiene demasiados archivos. –

Respuesta

5
  1. Dado que no existen los archivos (aún) en S3, enviarlos como un archivo de almacenamiento debe ser más rápido que el uso de un protocolo de sincronización.

  2. Sin embargo, comprimir el archivo no ayudará mucho (si es que lo hace) para los archivos de imagen, suponiendo que los archivos de imagen ya estén almacenados en un formato comprimido como JPEG.

  3. Transmitiendo ~ 150 Gbytes de datos va a consumir una gran cantidad de ancho de banda de red durante mucho tiempo. Esto será lo mismo si intenta usar HTTP o FTP en lugar de RSYNC para hacer la transferencia. Una transferencia fuera de línea sería mejor si es posible; p.ej. enviar un disco duro, o un conjunto de cintas o DVD.

  4. Poner un millón de archivos en un directorio plano es una mala idea desde el punto de vista del rendimiento. mientras que algunos sistemas de archivos manejarían esto bastante bien con O(logN) veces de búsqueda de nombre de archivo, otros no con O(N) búsqueda de nombre de archivo. Multiplica eso por N para acceder a todos los archivos en un directorio. Un problema adicional es que las utilidades que necesitan acceder a los archivos en orden de nombres de archivos pueden disminuir significativamente si necesitan clasificar un millón de nombres de archivo. (Esto puede explicar en parte por qué rsync tomó 1 día para hacer la indexación.)

  5. Poner todos sus archivos de imagen en un directorio es una mala idea desde una perspectiva de administración; p.ej. para hacer copias de seguridad, archivar cosas, mover cosas de un lado, la expansión en varios discos o sistemas de archivos, etc.

+0

¿Sería razonable dividir archivos de 1 m en 1,000 subdirectorios? No hay razón para tener más de 1 nivel de archivos ¿verdad? – makeee

+0

Sí, lo haría. Hay varias maneras de hacerlo, dependiendo de cómo se nombran y organizan, cómo se quiere administrar, etc. –

+1

Si voy a dividir los archivos, gzip no parece tener sentido ... puede simplemente recorrer cada elemento en la base de datos, tomar el nombre del archivo, copiar el archivo a S3, cambiar su nombre de archivo a su ID de autoincrement mysql. Luego puedo dividir los archivos según su ID (además ya no tendré que tener una columna de nombre de archivo en el archivo db). Incluso si toma un mes, al menos puedo hacer una porción cada día y comenzar a leer desde S3 los archivos que están en S3, y eliminar los archivos viejos en el servidor para ahorrar espacio. Eso parece razonable? – makeee

4

Una opción que puede usar en lugar de transferir los archivos a través de la red es ponerlos en un disco duro y enviarlos al servicio import/export de Amazon. Usted no tiene que preocuparse por saturar la conexión de su servidor de red, etc.

+0

Lamentablemente, esta no es una opción, ya que no tengo fácil acceso al centro de datos para hacer algo como esto. – makeee

25

Una opción podría ser la de realizar la migración de un modo vago.

  • Todas las imágenes nuevas van a Amazon S3.
  • Cualquier solicitud de imágenes que aún no estén en Amazon desencadenará una migración de esa imagen a Amazon S3. (ponerlo en cola)

Esto debería llevar rápidamente todas las imágenes recientes o comúnmente trasladadas a Amazon y reducirá la carga en su servidor. A continuación, puede agregar otra tarea que migre a los demás lentamente cada vez que el servidor esté menos ocupado.

+1

¡buena sugerencia! – sdolgy

+2

Tomé exactamente este enfoque recientemente, cuando necesitaba migrar 40 millones de imágenes a S3. He puesto el código que utilicé en Github, ojalá alguien más lo encuentre útil: https://github.com/mikery/s3cacher –

+0

También estoy a favor de esta idea. Elegante. –

Cuestiones relacionadas