Almacenamiento de imágenes escalable

Question

Actualmente estoy diseñando una arquitectura para una aplicación basada en la web que también debería proporcionar algún tipo de almacenamiento de imágenes. Los usuarios podrán cargar fotos como una de las características clave del servicio. También ver estas imágenes uno de los usos principales (a través de la web).

Sin embargo, no estoy seguro de cómo realizar un componente de almacenamiento de imágenes tan escalable en mi aplicación. Ya pensé en diferentes soluciones, pero debido a las experiencias faltantes, espero escuchar sus sugerencias. Aparte de las imágenes, también los meta datos deben ser atavados. Aquí están mis pensamientos iniciales:

1. Use un sistema de archivos (distribuido) como HDFS y prepare servidores web dedicados como "clientes del sistema de archivos" para guardar imágenes y solicitudes de servicio cargadas. Los meta datos de la imagen se guardan en una base de datos adicional que incluye la información de FilePath para cada imagen.

2. Use un sistema orientado a BigTable como HBase sobre HDFS y guarde las imágenes y los meta datos juntos. Una vez más, los servidores web de puentes de puente se cargan y solicitudes.

3. Use una base de datos SCHEMALESS TOMPLAMENTE como CouchDB para almacenar imágenes y metadatos. Además, use la base de datos en sí para cargar y revelar utilizando la API RESTFUL basada en HTTP. (Pregunta adicional: CouchDB guarda blobs a través de Base64. Sin embargo, ¿puede devolver los datos en forma de imagen/jpeg, etc.)?

Answer 1

Hemos estado usando CouchDB para eso, guardando imágenes como un "archivo adjunto". Pero después de un año, los archivos de base de datos GB CouchDB multidosizados resultaron ser un dolor de cabeza. Por ejemplo, la replicación de CouchDB todavía tiene problemas si lo usa con tamaños de documentos muy grandes.

Por lo tanto, simplemente reescribimos nuestro software para usar CouchDB para información de imagen y Amazon S3 para el almacenamiento de imágenes real. El código está disponible en http://github.com/hudora/huimages

Es posible que desee configurar un servicio de almacenamiento compatible de Amazon S3 en el sitio para su proyecto. Esto lo mantiene flexible y deja la opción de Amazon sin requerir servicios externos por ahora. Valla Parece convertirse en el clon S3 más popular y escalable.

También le insto a que busque el diseño de LiveJournal con su excelente código abierto. Mogilefs y Perlbal ofrendas. Esta combinación es probablemente la configuración de servicio de imagen más famosa.

También el arquitectura de flickr Puede ser una inspiración, aunque no ofrecen software de código abierto al público, como lo hace LiveJournal.

Answer 2

"Pregunta adicional: CouchDB guarda blobs a través de Base64".

CouchDB lo hace no Guarda blobs como base64, se almacenan como binario recto. Al recuperar un documento JSON con ?attachments=true Convertimos el binario en disco a base64 para agregarlo de manera segura a JSON, pero eso es solo una cosa de nivel de presentación.

Ver Adjuntos independientes.

CouchDB sirve archivos adjuntos con el tipo de contenido con el que se almacenan, es posible, de hecho común, para los archivos adjuntos HTML, CSS y GIF/PNG/JPEG directamente a los navegadores.

Los accesorios se pueden transmitir y, en CouchDB 1.1, incluso admiten el encabezado de rango (para la transmisión de medios y/o la reanudación de una descarga interrumpida).

Answer 3

Usar Algas (solía llamarse Weed-FS), una implementación del documento Haystack de Facebook.

Seaweed-FS es muy flexible y se reduce a lo básico. Fue creado para almacenar miles de millones de imágenes y servirlas rápido.

Answer 4

¿Ha considerado los servicios web de Amazon? S3 es el almacenamiento de archivos basado en la web, y SimpledB es una tienda de atributos clave. Ambos son performadores y altamente escalables. Es más costoso que mantener sus propios servidores y configuraciones (suponiendo que lo hagas tú mismo y no contratar a las personas), pero te subes mucho más rápido.

EDITAR: Lo retiro: es más caro a largo plazo a grandes volúmenes, pero para un volumen bajo supera el costo inicial de comprar hardware.

S3: http://aws.amazon.com/s3/ (podría almacenar sus archivos de imagen aquí, y para el rendimiento tal vez tenga un caché de imagen en su servidor, o tal vez no)

SimpledB: http://aws.amazon.com/simpledb/ (Los metadatos podrían ir aquí: mapeo de ID de imagen a los datos que desee almacenar)

Editar 2: Ni siquiera sabía sobre esto, pero hay un nuevo servicio web llamado Amazon CloudFront (http://aws.amazon.com/cloudfront/). Es para la entrega rápida de contenido web, y se integra bien con S3. Algo así como Akamai para tus imágenes. Podrías usar esto en lugar del caché de la imagen.

Answer 5

Usamos Mogilefs. Somos usuarios de pequeña escala con menos de 8TB y unos 50 millones de archivos. Cambiamos de almacenar en Amazon S3 hace algunos años para obtener un mejor control de los nombres de los archivos y el rendimiento.

No es el software más bonito, pero es muy "probado de campo" y básicamente todos los usuarios lo están utilizando de la misma manera que lo será.

Answer 6

Tal vez eche un vistazo a la descripción de Facebook Haystack

Aguja en un pajar: almacenamiento eficiente de miles de millones de fotos

Answer 7

Como parte de Cloudant, no quiero presionar el producto ... pero BigCouch resuelve este problema en mi pila de aplicaciones científicas (Física, ¡nada que ver con Cloudant, y ciertamente nada que ver con las ganancias!). Se casa con la simplicidad del diseño de COCUHDB con el auto-retraso y la escalabilidad que falta en CouchDB de servidor único. Generalmente lo uso para almacenar un número menor de archivos grandes (multi-GB) y una gran cantidad de archivos pequeños (100 MB o menos). Estaba usando S3, pero los costos GET realmente comienzan a acumularse para archivos pequeños a los que se accede repetidamente.

Answer 8

Ok, si todas esas cosas de AWS no van a funcionar, aquí hay un par de pensamientos.

En cuanto a (3), si coloca datos binarios en una base de datos, saldrán los mismos datos. Lo que lo convierte en un JPEG es el formato de los datos, no lo que la base de datos cree que es. Lo que hace que el cliente (navegador web) piense que es un JPEG es cuando establece el Content-type encabezado image/jpeg. También podría establecerlo en algo más (no recomendado) como el texto y así es como el navegador intentaría interpretarlo.

Para el almacenamiento en disco, me gusta CouchDB por su simplicidad, pero los HDF ciertamente funcionarían. Aquí hay un enlace a una publicación sobre cómo servir contenido de imagen de CouchDB: http://japhr.blogspot.com/2009/04/render-couchdb-images-via-sinatra.html

Editar: aquí hay un enlace a una discusión útil sobre las imágenes en caché en Memcached vs servirlas desde el disco en Linux/Apache.

Answer 9

He estado experimentando con parte de la funcionalidad _update disponible para los servidores de View CouchDB en mi servidor Python View.

Una cosa realmente genial que hice fue una función de actualización para las cargas de imágenes para poder usar PIL para crear miniaturas y otras imágenes relacionadas y adjuntarlas al documento cuando se empujen a CouchDB.

Esto podría ser útil si necesita manipulación de imágenes y desea reducir la cantidad de código e infraestructura que necesita para mantenerse al día.

Answer 10

He escrito una tienda de imágenes sobre Cassandra. Tenemos muchas y escrituras y lecturas aleatorias de lectura/escritura es baja. Para una alta relación de lectura/escritura le sugiero MongoDB (Gridfs).

Answer 11

Aquí hay un ejemplo para almacenar la imagen BLOB en CouchDB usando PHP Laravel. En este ejemplo, estoy almacenando tres imágenes basadas en los requisitos del usuario.

Establecer la conexión en CouchDB.

$connection = DB::connection('your database name');

/*region Fetching the Uers Uploaded Images*/

$FirstImage = base64_encode(file_get_contents(Input::file('FirstImageInput')));
$SecondImage =base64_encode(file_get_contents(Input::file('SecondImageInput')));
$ThirdImage = base64_encode(file_get_contents(Input::file('ThirdImageInput')));

list($id, $rev) = $connection->putDocument(array(
    'name' => $name,
    'location' => $location,
    'phone' => $phone,
    'website' => $website,
    "_attachments" =>[
        'FirstImage.png' => [
            'content_type' => "image/png",
            'data' => $FirstImage
        ],
        'SecondImage.png' => [
            'content_type' => "image/png",
            'data' => $SecondImage
        ],
        'ThirdImage.png' => [
            'content_type' => "image/png",
            'data' => $ThirdImage
        ]
    ],
), $id, $rev);

...

Igual que puede almacenar una imagen única.