2011-12-02 15 views
7

Estoy buscando un lugar ideal (rendimiento efectivo y mantenible) para almacenar datos binarios. En mi caso, estas son imágenes. Tengo que hacer un procesamiento de imágenes, escalar las imágenes y almacenarlas en un lugar adecuado al que se pueda acceder mediante un servicio RESTful.Lugar ideal para almacenar datos binarios que se pueden representar llamando a una url

De mi investigación hasta ahora tengo algunas opciones, como:

  1. solución NoSQL como MongoDB, GridFS
  2. Almacenamiento como archivos en un sistema de archivos en una jerarquía de directorios y luego usando un servidor web para acceder a las imágenes por url
  3. repositorio
  4. Apache Jackrabbit Documento
  5. tienda en una memoria caché algo así como Memcache, calamar Proxy

¿Alguna idea de cuál escogerías y por qué sería útil o hay una mejor manera de hacerlo?

Respuesta

1

Almacenar las imágenes como blobs en un RDBMS en otra opción, e inmediatamente obtener garantías sobre integridad, seguridad, etc. (si está configurado correctamente en la base de datos), almacenar metadatos adicionales, administrar la colección con SQL, etc.

+1

Cabe señalar que en aplicaciones donde el volumen de archivos que se ingresan al sistema es muy alto, esto no siempre es una opción. Los blobs se almacenan como archivos completos y no fragmentados, por lo que los valores de las filas pueden ser realmente grandes y hacer copias de seguridad de bases de datos exponencialmente más grandes. Uno siempre debe considerar las consideraciones de replicación y el volumen de entrada antes de ir con esta opción. – DeaconDesperado

7

Acabo de empezar a usar GridFS para hacer exactamente lo que describió.

Desde mi experiencia hasta ahora, la principal ventaja de GridFS es que evita la necesidad de un sistema de almacenamiento de archivos por separado. Toda nuestra capa de persistencia ya está en Mongo, por lo que el próximo paso lógico sería almacenar nuestro sistema de archivos allí también. El espacio de nombres plano simplemente oscila y le permite un lenguaje de consulta enriquecido para recuperar sus archivos en función de los metadatos que quiera adjuntar a ellos. En nuestra aplicación utilizamos un objeto 'appdata' que incluía toda la información de propiedad, asegure

Otra cosa a considerar con el almacenamiento de archivos NoSQL, y especialmente GridFS, es que se fragmentará y expandirá junto con sus otros datos. Si tiene todo su almacén de valores-clave de BD dentro del servidor mongo, eventualmente, si alguna vez tiene que expandir su clúster de servidores con más máquinas, su sistema de archivos crecerá junto con él.

Puede sentir una pequeña "caja negra" ya que los datos binarios en sí se dividen en fragmentos, un prospecto que asusta a los que se usan para un sistema de archivos basado en un directorio clásico. Esto se alivia con la ayuda de programas de administración como RockMongo.

En general, para almacenar imágenes en GridFS es tan fácil como insertar los documentos, la mayoría de los controladores para todos los idiomas principales manejan todo para usted. En nuestro entorno, tomamos cargas de imágenes en un punto final y usamos PIL para realizar cambios de tamaño. Luego, las imágenes se obtuvieron de mongo en otro punto final que solo daba salida a los datos y lo mimetizaba como un jpeg.

¡La mejor de las suertes!

EDITAR:

Para darles un ejemplo de un archivo trivial cargar con GridFS, aquí está el enfoque más simple en PyMongo, la biblioteca de Python.

from pymongo import Connection 
import gridfs 

binary_data = 'Hello, world!' 

db = Connection().test_db 
fs = gridfs.GridFS(db) 
#the filename kwarg sets the filename in the mongo doc, but you can pass anything in 
#and make custom key-values too. 
file_id = fs.put(binary_data, filename='helloworld.txt',anykey="foo") 
output = fs.get(file_id).read() 
print output 
>>>Hello, world! 

También se puede consultar en contra de sus valores personalizados si se quiere, que puede ser muy útil si desea que sus consultas a estar basados ​​fuera de la información personalizada relativa a su aplicación.

try: 
    file = fs.get_last_version({'anykey':'foo'}) 
    return file.read() 
catch gridfs.errors.NoFile: 
    return None 

Estos son sólo algunos ejemplos sencillos, y los controladores para muchos de los otros idiomas (PHP, Ruby, etc.) todos tienen cognados.

+0

Gracias por compartir, realmente lo aprecio. ¿Crees que leer desde la E/S del disco es más caro o simplemente tener todos los datos en un solo lugar fue la razón para tenerlo en mogo y cómo está funcionando hasta ahora? – dineshr

+0

El tiempo de IO de archivo realmente no tomó en cuenta nuestra decisión, aunque para referencia el tiempo de recuperación es comparable a una consulta indexada estándar en sql. Dado que el volumen de archivos es extremadamente alto, la principal razón fue la atracción de tener un gran espacio de nombres que se pudiera dividir horizontalmente. El uso de GridFS hace que la estructura del directorio ya no sea un problema, y ​​sus archivos se pueden buscar e insertar usando los controladores de la API. Funcionó muy bien en una aplicación RESTful donde las solicitudes de URL determinaron la respuesta. – DeaconDesperado

3

Yo iría por liebre en combinación con su honda marco RESTO http://sling.apache.org

honda le permite cargar/descargar archivos a través de REST llama o WebDAV mientras que el repositorio de liebre que subyace le da un almacenamiento performante con la posibilidad de almacenar su archivos en una estructura de árbol (o planos si lo desea).

Ambos jackrabbit y sling admiten un mecanismo de evento donde puede procesar de forma asincrónica la imagen después de cargarla, es decir, crear miniaturas.

El manual en http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html describe cómo manipular datos utilizando la interfaz REST proporcionada por el cabestrillo.

Cuestiones relacionadas