Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.

Buen día Alvaro…

El punto que mencionas es precisamente lo que nos llevó a utilizar inicialmente el mecanismo de cargar las imágenes y/o documentos a la base de datos; la de poder tener toda la información disponible desde la misma base y al moverse no tener que estar haciendo otras copias, sin embargo ahora nos preocupa el tema de que la base de datos se ha vuelto muy pesada, y pensamos que tal vez había formas más eficientes de manejar este detalle…

Entre las propuestas que estamos analizando en el equipo son:

1. Manejar un directorio de almacenamiento en el servidor en el cual se almacenen los datos con una estructura definida por la aplicación.
2. Crear una base de datos alterna únicamente para el tema de documentos digitalizados y desde la aplicación hacer la conexión a ambas bases para almacenar los documentos y/o la información referente a la aplicación.

Aun estamos definiendo este tema, pero su apoyo y comentarios no han servido de mucho…

Gracias.

Saludos.

> El 11/02/2016, a las 3:20 p.m., Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> escribió:
>
> "Mario Jiménez Carrasco (isccarrasco)" escribió:
>
>> En la empresa donde laboro, tenemos actualmente una aplicación en la
>> que se digitaliza documentos que son cargados directamente a la base
>> de datos como objetos tipo batea, el primer cuestionamiento sería: ¿Es
>> recomendable hacer esto?, o ¿Cuál sería el mecanismo mas recomendable?
>
> Hacerlo de esa forma funciona bien. Sobre todo, considera que si pones
> los archivos fuera de la BD necesitarás considerarlas separadamente en
> caso que quieras hacer respaldos y tener réplicas. Si lo pones todo en
> la BD y manejas replicación streaming (o cualquier otro tipo de
> replicación, en realidad), tus servidores réplica automáticamente
> tendrán toda la información sin tener que preocuparte de un mecanismo
> adicional para copiar los archivos.
>
> La BD será más pesada, obviamente, pero si no tienes el "peso" en la BD
> entonces tendrás que tenerlo en otra parte, y no necesariamente estarás
> en mejor pie. ¿O estás pensando en usar un sistema de archivos en red,
> como LustreFS etc?
>
>> Por otro lado veo que el tamaño de la base de datos ha crecido (obvio
>> por las imágenes), el cuestionamiento en este caso sería, ¿Existe
>> algún plugin de PostgreSQL que comprima las imágenes sin perder la
>> calidad? o ¿este un tema del lado de la aplicación?.
>
> Si el campo es grande, Postgres intenta aplicar compresión usando un
> algoritmo relativamente rápido(*) pero no muy bueno. Si el formato es PDF,
> JPEG o similar, que ya tienen compresión interna, es inútil que la BD
> trate de comprimir de nuevo. En esos casos es mejor usar ALTER TABLE
> SET STORAGE para que la columna se guarde sin intentar la compresión.
> Si estás guardando texto ASCII o grandes documentos XML (que de por sí
> son bastante compresibles), normalmente la compresión es buena idea; si
> no, no.
>
> (*) en realidad, comparado con los nuevos algoritmos, no es tan rápido
> tampoco :-(
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda