Desde una perspectiva técnica, hay dos lados del problema: un proyecto web similar a una red social (con usuarios, organizaciones que interactúan con fotos) y luego la plataforma de carga, procesamiento y almacenamiento de imágenes. El primero es complejo en lógica pero fácil en tecnología, el segundo es solo el otro lado.
Depende del conjunto de habilidades de su equipo, cualquier marco web adecuado podría construir el portal web. Con las pilas de Python en mente, Django proporciona un marco básico para usuarios, objetos y sistemas de permisos integrados, podría ser un buen punto de partida. El frasco con algunos complementos (Flask-User, Flask-sqlalchemy, etc.) también funcionaría bien. Un diagrama ER adecuado realmente ayudaría al proceso de diseño antes de acceder a las páginas vistas.
Entonces esa es la plataforma de imagen.
- Cómo implementar una aplicación web Java con Jetty incrustado en un VPS
- ¿Qué sucede si los datos de mi aplicación web crecen muy rápido?
- Para un producto estable existente que tiene nuevas características agregadas de forma incremental, ¿hay alguna diferencia entre AGILE y la cascada "rápida" (donde las características se reducen para que puedan desarrollarse rápidamente)?
- Quiero construir algunas herramientas internas para nuestro departamento de TI. Si tengo la capacidad de alojar una aplicación web, ¿es mejor ir con una aplicación nativa o HTML5?
- ¿Cómo se puede mejorar Remember The Milk?
- La carga de imágenes de 500M generalmente excedería la capacidad habitual del navegador y requiere alguna forma de carga de complementos o integración con el servicio FTP.
- Las imágenes deben ser procesadas: redimensionadas para diferentes propósitos (miniatura, vista previa rápida, etc.) que requiere mucha CPU. Generalmente requiere una cola de trabajos (Celery, por ejemplo), un clúster / granja de procesamiento con un almacenamiento compartido (S3 es una solución popular para los usuarios de AWS)
- Almacenamiento escalonado. Las miniaturas se solicitan con la frecuencia más alta, por lo que requiere almacenamiento en caché y distribución rápida: CDN sería la frontera, entonces escuché a personas que usan MongoDB GFS para esta tarea. No se debe acceder / descargar los originales con mucha frecuencia, por lo tanto, se pueden colocar en algunos lugares secundarios y más lentos para ahorrar costos.
Y puede haber otro “sistema de back-end” (quizás conectado) para proporcionar a los usuarios el progreso de la carga / procesamiento y permitir a los administradores monitorear el contenido en busca de usos inapropiados.
Poner todo junto, con mi fondo de Python en mente:
Infraestructura:
- Linux, por supuesto.
- Algunas máquinas requieren CPU alta (procesadores de imagen) y otras requieren E / S (nodos de almacenamiento primario)
- Alguna plataforma escalable IaaS (EC2, por ejemplo) para procesar servicios de granja, primario (almacenamiento de instancia EC2) / almacenamiento secundario (S3) y una CDN
- Soluciones de monitoreo interno que aseguran que todas las partes (servidor web, aplicaciones Python, Redis, DB, Mongo, cola de trabajos, procesadores de imágenes …) funcionen correctamente. Usé supervisor para Python y db y algunas personas prefieren Nagios / Monit para monitorear y alarmar con otra forma de controles de servicio.
Para la web:
- Cualquier marco apropiado (Django / Flask / etc). Según la complejidad de las lógicas comerciales, la oferta inicial del marco puede ayudar más en las etapas iniciales, pero después de algún punto, todas son similares.
- Base de datos SQL para web
- Almacenamiento para acceso rápido a imágenes: soluciones autohospedadas basadas en MongoDB u otras soluciones, o simplemente use S3
- CDN
- Caché interno (Redis) / servidores web (Nginx)
Para el backend de la imagen:
- ¿Subir aplicación / complemento / integración FTP?
- Cola de trabajo: Apio / Gearman / etc.
- Instalaciones de procesamiento de imágenes: ImageMagick u otras herramientas con alto rendimiento. Scripts que impulsan estas herramientas y se integran con el resto del sistema.
Este sería un proyecto bastante grande. Con algunos servicios externos (S3, por ejemplo), algunas tareas podrían ser más fáciles que antes, pero aún es de naturaleza compleja.
No estoy muy familiarizado con GAE y no estaría seguro si GAE es más rentable y / o flexible que mi solución interna.
