[pyar] DB Blob or not Blob, thats the question

[MAbeeTT]

2015-12-04 16:47 GMT-03:00 Juan Carlos <juancarlospaco en gmail.com>:
> On Fri, Dec 4, 2015 at 4:23 PM MAbeeTT <mabeett en gmail.com> wrote:
>>
>> Son timadas de un sistema
>
>
> No a Timar sistemas.
>
>
>> A pesar de usar el parámetro uploadseparate, para que separe las
>> imágenes en un pool de directorios se hace inmanejable los backups de
>> los containers en los que se aloja el sistema, son horas y horas,
>> estimo que solo listando archivos, o cargando índices en los tar lo
>> que fuera de cada uno de los muchos archivos.
>
>
> Podria zipearlo antes de copiarlo(?), cosa de copiar 1 archivo en lugar de
> 950943859435439 jpgs, que No lo comprima, que solo los encapsule.

El tema es que para zippearlo tiene que saber cuáles son, y allí es
donde el backup ocupa mucho tiempo y no solamente allí. De hecho los
~120K que les indinco, son el máximo peso, los archivos pesan todos
120K o *menos*. Me refiero a más de 20G en un millón de archivitos. Es
como la definición misma de fragmentación interna; pero a la vez
expuse la restricción de resolver en espacio de usuario.

>
>> codifica en base64 el contenido
>
>
> Base64 te da 33% mas de peso.
>
>
>> Mi preguntas son, ¿Si corro todo a blob, no estaré corriendo también
>> el problema a la base de datos? ¿es un tamaño demasiado grande el
>> máximo de 110K por archivo para hacer db blob?
>> ¿Alguna consideración particular sobre el uso de la base de datos?
>
>
> Si nos comentas que el problema es la performance del backup probablemente
> el problema es la performance del backup  :)

Mmmm, el problema que detecto es de performance en el backup, pero no
sería necesariamente el único: tendría que hacer ensayos en el sistema
mismo.




-- 
             .::MAbeeTT::.

 mabeett [at] gmail [ dot] com