Creando un sitio de carga de archivos que escala

Question

Estoy intentando construir un sitio de carga de archivos como un proyecto paralelo, y nunca he creado algo que necesite manejar una gran cantidad de archivos como este. Por lo que puedo decir, hay tres opciones principales para almacenar y recuperar los archivos (tenga en cuenta que puede haber múltiples archivos por carga, así que, por ejemplo, el sitio web.com/a23Fc puede permitirle descargar uno o varios archivos, dependiendo de la cantidad que el usuario originalmente subido - similar a imgur.com):

• palillo de todos los archivos en un directorio de archivos de gran tamaño, y utilizar un (relacional) DB de averiguar qué archivos pertenecen a qué direcciones URL, y luego volver una lista de nombres de archivos dependiendo de eso. Ejemplo: cargas de usuario website.com/abcde~~V~~plural~~3rd, por lo que consulta la base de datos de todos los archivos relacionados con las subidas abcde, devuelve sus nombres de archivo, y el sitio de salida a aquellos.
• Use CouchDB porque le permite adjuntar archivos a registros individuales en la base de datos, por lo que cada URL/carga podría ser un registro de base de datos con archivos adjuntos. Ejemplo, cargas de usuario website.com/abcde, CouchDB agarra el documento con la ID de abcde, agarra los archivos adjuntos a ese documento, y les da al usuario.
• Sáltese por completo el uso de una base de datos, y para cada carga, cree un nuevo directorio y pegue los archivos en eso. Ejemplo: el usuario carga website.com/abcde, el sitio busca un directorio/files/abcde /, toma todos los archivos de allí y se los da al usuario, por lo que una base de datos no está involucrada en absoluto.

¿Cuál de estos parece ser el más escalable? Como dije, tengo muy poca experiencia en esta área por lo que si estoy completamente apagado o si hay una cuarta opción obvia, estoy más que abierto a ella. Tener miles o millones de archivos en un único directorio (es decir, la opción 1) no parece muy inteligente, pero tener miles o millones de directorios en un directorio (es decir, la opción 3) no parece mucho mejor.

Answer 1

Recomiendo cualquier solución que pueda completar personalmente en el menor tiempo posible. Si ya tienes prototipos de CouchDB en funcionamiento, ¡adelante! Lo mismo para una solución orientada a las relaciones o al sistema de archivos.

tiempo de salida al mercado es más importante que la arquitectura por dos razones:

1. Este es un proyecto paralelo, usted debe tratar de llegar lo más lejos a lo largo como sea posible.
2. Si el sitio se vuelve popular, ya que el propósito principal es de carga de archivos, es probable que reconstruir el servicio básico al menos una vez, tal vez más, durante la vida del sitio.

Answer 2

Una empresa que solía trabajar se enfrentó a este problema exacto con aproximadamente un petabyte de archivos de imagen. Su solución fue utilizar Andrew File System (ver http://en.wikipedia.org/wiki/Andrew_File_System para más información) para almacenar los archivos en una estructura de directorio que coincidía con la estructura de la URL. Esto se escalo muy bien en la practica.

También registraron la existencia de los archivos en una base de datos por otros motivos que eran internos de su aplicación.

Answer 3

Si va a ASP.NET usuario aquí es el artículo que describe cómo utilizar el sistema de archivos distribuido para la granja de servidores web http://weblogs.asp.net/owscott/archive/2006/06/07/DFS-for-Webfarm-Usage---Content-Replication-and-Failover.aspx