Almacenamiento de imágenes en PostgreSQL

Question

Muy bien, así que estoy trabajando en una aplicación que utilizará un back-end de Linux ejecutando PostgreSQL para mostrar imágenes en un cuadro de Windows con el anverso escrito en C# .NET, aunque el front-end apenas debería importar Mi pregunta es:

• ¿Cuál es la mejor manera de lidiar con el almacenamiento de imágenes en Postgres?

Las imágenes son alrededor de 4-6 megapíxeles cada una, y que está almacenando más de 3000. También podría ser bueno tener en cuenta: no se trata de una aplicación web, habrá como máximo alrededor de dos frontal termina accediendo a la base de datos de una vez.

Answer 1

En la base de datos, hay dos opciones:

• bytea. Almacena los datos en una columna, exportados como parte de una copia de seguridad. Utiliza funciones de base de datos estándar para guardar y recuperar. Recomendado para tus necesidades.
• blobs. Almacena los datos externamente, normalmente no se exportan como parte de una copia de seguridad. Requiere funciones de base de datos especiales para guardar y recuperar.

He usado bytea columns con gran éxito en el pasado almacenando 10 + gb de imágenes con miles de filas. La funcionalidad TOPS de PG prácticamente niega cualquier ventaja que tengan los blobs. Necesitará incluir columnas de metadatos en cualquier caso para nombre de archivo, tipo de contenido, dimensiones, etc.

Answer 2

Pruebe this. Utilicé el formato binario de objetos grandes (LOB) para almacenar documentos PDF generados, algunos de los cuales tenían más de 10 MB de tamaño, en una base de datos y funcionó maravillosamente.

Answer 3

No almacenar en imágenes en la base de datos a menos que sea absolutamente necesario. Entiendo que esta no es una aplicación web, pero si no hay una ubicación de archivo compartido, puede señalar guardar la ubicación del archivo en la base de datos.

//linuxserver/images/imagexxx.jpg 

entonces tal vez usted puede configurar rápidamente un servidor web y almacenar las direcciones URL en la base de datos (así como la ruta local). Mientras que las bases de datos pueden manejar LOB y 3000 imágenes (4-6 megapíxeles, asumiendo 500K de una imagen) 1.5 Gigs no es una gran cantidad de sistemas de archivos espaciales están mucho mejor diseñados para almacenar archivos de gran tamaño que una base de datos.

Answer 4

respuesta de Re jcoby:

bytea ser una columna de "normal" también significa el valor de ser leído por completo en memoria cuando la tomase. Blobs, por el contrario, puede transmitir en stdout. Eso ayuda a reducir la huella de memoria del servidor. Especialmente, cuando almacena 4-6 imágenes MPix.

No hay problema con la creación de blobs. pg_dump proporciona la opción "-b" para incluir los objetos grandes en la copia de seguridad.

Entonces, prefiero usar pg_lo_ *, puede adivinar. respuesta

Re Kris de Erickson:

yo diría que el :) contrario. Cuando las imágenes no son los únicos datos que almacena, no los almacene en el sistema de archivos a menos que sea absolutamente necesario. Es un beneficio estar siempre seguro de la coherencia de sus datos y tener los datos "en una sola pieza" (DB). Por cierto, PostgreSQL es excelente para preservar la coherencia.

Sin embargo, la realidad es a menudo demasiado exigente con el rendimiento ;-), y te obliga a servir los archivos binarios del sistema de archivos. Pero incluso entonces tiendo a utilizar el DB como el almacenamiento "maestro" para los binarios, con todas las otras relaciones vinculadas consistentemente, mientras proporciono un mecanismo de caché basado en el sistema de archivos para la optimización del rendimiento.

Answer 5

Actualización a 2012, cuando vemos que el tamaño de imagen y el número de imágenes, están creciendo y creciendo, en todas las aplicaciones ...

Necesitamos alguna distinción entre "imagen original" y "imagen procesada", como una miniatura

como la respuesta de Jcoby decir, hay dos opciones, a continuación, le recomiendo:

• uso blob (objeto binario grande): para la tienda de imagen original, en su mesa. Véase la respuesta de Iván, PostgreSQL additional supplied modules, etc. How-tos

• usar una base de datos independiente con DBlink (no hay problema con la copia de seguridad de las gotas!): Para la tienda de imagen original, en otra base de datos (unificado/especializado). En este caso, prefiero bytea, pero blob es casi lo mismo. Separar la base de datos es la mejor forma de crear un "servicio web de imagen unificada".

• use bytea (matriz BYTE): para almacenar en caché las imágenes en miniatura. Guarde en caché las pequeñas imágenes para enviarlas rápidamente al navegador web (evitando problemas de renderización) y reduzca el procesamiento del servidor. Caché también metadatos esenciales, como ancho y alto. El almacenamiento en caché de la base de datos es la forma más fácil, pero verifique sus necesidades y las configuraciones del servidor (por ejemplo, los módulos de Apache): store thumbnails at file system puede ser mejor, compare las actuaciones. Recuerde que es un servicio web (unificado), luego se puede almacenar en una base de datos separada (sin copias de seguridad), sirviendo a muchas tablas. Ver también PostgreSQL binary data types manual, tests with bytea column, etc.

NOTA 1: (!) Hoy está obsoleto el uso de "dual solutions" (database+filesystem). Hay muchas ventajas en usar "solo base de datos" en lugar de dual. PostgreSQL tiene un rendimiento comparable y buenas herramientas para exportación/importación/entrada/salida.

NOTA 2: PostgreSQL recordar que sólo tienen bytea, no tienen un defecto de Oracle BLOB :. El estándar define SQL (...) BLOB" El formato de entrada es diferente de bytea, pero las funciones y operadores proporcionados son más o menos lo mismo ", Manual.

---

EDITAR : No cambió el texto original por encima de hoy (mi respuesta fue Abr 22 de '12, ahora con 14 votos), I   estoy abriendo la respuesta para los cambios (ver "Wiki modo ", puede editar!), para proofreading y para actualizaciones.
La pregunta es estable (@ Ivans '08 respuesta con 19 votos), por favor, ayuda a mejorar este texto.

Answer 6

Rápida actualización a mediados de 2015:

Puede utilizar la interfaz de datos PostgreSQL Exteriores, para almacenar los archivos de la base de datos más adecuado. Por ejemplo, coloque los archivos en un GridFS que es parte de MongoDB. Luego use https://github.com/EnterpriseDB/mongo_fdw para acceder a ella en Postgres.

Tiene las ventajas de que puede acceder, leer, escribir o hacer una copia de seguridad en Postrgres y MongoDB, dependiendo de lo que le dé más flexibilidad.

También son envoltorios de datos externa para sistemas de archivos: https://wiki.postgresql.org/wiki/Foreign_data_wrappers#File_Wrappers

A modo de ejemplo que puede utilizar éste: https://multicorn.readthedocs.org/en/latest/foreign-data-wrappers/fsfdw.html (ver aquí por breve ejemplo de uso)

que le da la ventaja de la coherencia (todos los archivos vinculados están definitivamente allí) y todos los demás ACID, mientras todavía hay en el sistema de archivos real, lo que significa que puede utilizar cualquier sistema de archivos que desee y el servidor web puede servirlos directamente (también se aplica el almacenamiento en caché del sistema operativo).)