Re: Consulta para bkp Postgres 8.3, para poder migrar sistema critico.

From: "jvenegasperu (dot)" <jvenegasperu(at)gmail(dot)com>
To: Diego Ayala <netdiego81(at)gmail(dot)com>
Cc: Postgres Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Consulta para bkp Postgres 8.3, para poder migrar sistema critico.
Date: 2017-08-04 19:33:10
Message-ID: CA+KjtGfiu4APqsrk5313k=8hNGfF-J981-0BfNGHyokNR9Nr6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hola Diego

Se me ocurre que hagas lo siguiente:

hazte una tabla digamos con 1000 registros extrayendolos de la tabla de 1.5
Tb

luego miras cuanto pesa esta tabla de 1000 registros

con eso te haces una idea de cuanto pesa cada registro de tu BD.

luego mide y pesa unas cuantas imagens para que tengas una idea de las
medidas y pesos de las fotos

Con esos datos a esa tabla de prueba con 1000 registros resultante aplicale
el script anterior que te pase ajustandole las dimensiones

aplicas el script a la tabla dandole las medidas que te servirian y le
haces vacuum para que actualice las estadisticas

y nuevamente pasas la consulta para el tamaño asi tendras una idea de
cuanto puedes reducir las imagenes. en tu tabla real de 1.5 Tb

PD: Esto te serviria si por ejemplo la alta resolucion de las imagenes no
es necesaria una vez un medico me dijo que necesitaba las fotos con 20
Megapixels para poder notar un minusculo cambio de color que representaba
una infección.

Ahora tu hablas de unas 2000 fotos y 5000Gb por dia eso da 2.5 Mb por foto
y es una barbaridad si te estoy entendiendo bien y se trata de fotos de
cedulas para identificacion o DNI como le llamamos aqui en Peru yo diria
que con 100Kb es ya una exageracion mira ahi te adjunto mi foto que uso
para la cedula y solo pesa 15Kb jeje

Estoy imaginando que se trata de un fotografo que tomas las fotos para la
cedula con una super camara asi pueden retocar la foto y hasta ponerte
terno jajaja como mi foto.

O quizas como es postgres 8.3 ya son como 10 años y antes cargaban las
fotos con scaneres y esas fotos pesaban una barbaridad quiza solo baste
ajustando las imagenes de años pasados para bajar el peso de tu BD a la
quinta parte y hasta menos porque quien sabe y por ahi alguien uso en años
pasados fotos en formato BMP que pesan un monton y por nada porque incluso
solo cambiando el formato sin cambiar tamaño ya ganas muchisimo espacio eso
me lleva a pensar que quiza en tu prueba de 1000 registros puedas incluir
digamos unos 100 registros de cada año. y te averigues cual era el origen
de las fotos.

Bueno ahi te envio mi foto de la cedula para que veas que es mas que
suficiente y eso que solo tiene 15Kb si tu caso se parece a lo que te
comento puedes aplicar estos pequeños aportes saludos

El 4 de agosto de 2017, 13:43, Diego Ayala <netdiego81(at)gmail(dot)com> escribió:

> Buen dia, Gracias por tu ayuda, te explico, la tabla principal, de imagen
> crece a razon de 4 a 5 GB por dia, debido a que se procesan entre 1500 a
> 2000 renovaciones o nuevas emisiones de cedulas de identidad personal, por
> eso ese crecimiento. Es un software propietario que se instalo con el 8.3
> en windows, ya varios años atras, por lo tanto el mantemiento y demas se ha
> complicado.
>
> El 4 de agosto de 2017, 14:08, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
> escribió:
>
>> Diego que tal buen dia
>> Queria preguntarte porque esta creciendo tanto tu BD ¿no sera que por
>> ejemplo tienes fotos gigantes y no las necesitas tan grandes?
>>
>> Por ejemplo a mi me pasaba que mis usuarios tomaban fotos con camaras y
>> celulares con resoluciones de 8 10 o hasta 16Mb y luego las subian a la BD
>> a traves del sistema y bueno el resultado es que cada imagen la mas pequeña
>> pesaba 3 MB y cuando las mostraban en pantalla en el monitor pues ni
>> siquiera caben en el monitor tenian estar jugando con la lupa para que
>> puedan verse.
>>
>> y claro se ajustaba el tamaño en el sistema web pero igual a veces se
>> notaba lento cuando tenia que cargar una iamgen muy grande
>>
>> Asi que lo que hice fue pues cambiarle el tamaño a todas las fotos
>> considerando solo un alto maximo de 999 pixeles y conservando el ratio de
>> aspecto asi ocupa casi todo el alto de la mayoria de monitores y se ven
>> bien.
>> bueno lo hice por partes con un where para ir avanzando y reduje el
>> tamaño de mi BD como 40 Gb en mi caso no tengo tanta información.
>>
>> Quizas sea tu caso aqui te dejo el script en php que use para cambiar el
>> tamaño a las imagenes quizas sea tu caso.
>>
>> set_time_limit(0);
>>
>> ini_set('gd.jpeg_ignore_warning', 1);
>>
>> $conn = pg_connect("user=usuario password=clave dbname=nombre_bd
>> host=ip_del_deserver port=5433");
>>
>> $result = pg_query($conn, "SELECT fotos_notif_id FROM cp_fotos_notif
>> where fotos_notif_id >= 17105 ");
>>
>> session_start();
>> ob_end_flush();
>> ob_start();
>>
>> while ($raw = pg_fetch_array($result)) {
>>
>> $query = pg_query($conn, "SELECT foto FROM cp_fotos_notif where
>> fotos_notif_id = " . $raw['fotos_notif_id'] . " ");
>> $row = pg_fetch_row($query);
>>
>> $image = pg_unescape_bytea($row[0]);
>>
>> $fichero = file_put_contents('image_original.jpg', $image);
>>
>> $fotito = 'image_original.jpg';
>>
>> //Ruta de la imagen original
>> $rutaImagenOriginal = $fotito;
>>
>> //Creamos una variable imagen a partir de la imagen original
>> $img_original = imagecreatefromjpeg($rutaImagenOriginal);
>>
>> //Se define el maximo ancho o alto que tendra la imagen final
>> $max_ancho = 999;
>> $max_alto = 999;
>>
>> //Ancho y alto de la imagen original
>> list($ancho, $alto) = getimagesize($rutaImagenOriginal);
>>
>> if ($alto > 999) {
>>
>> //Se calcula ancho y alto de la imagen final
>> $x_ratio = $max_ancho / $ancho;
>> $y_ratio = $max_alto / $alto;
>>
>> //Si el ancho y el alto de la imagen no superan los maximos,
>> //ancho final y alto final son los que tiene actualmente
>> if (($ancho <= $max_ancho) && ($alto <= $max_alto)) {//Si ancho
>> $ancho_final = $ancho;
>> $alto_final = $alto;
>> }
>> /*
>> * si proporcion horizontal*alto mayor que el alto maximo,
>> * alto final es alto por la proporcion horizontal
>> * es decir, le quitamos al alto, la misma proporcion que
>> * le quitamos al alto
>> *
>> */ elseif (($x_ratio * $alto) < $max_alto) {
>> $alto_final = ceil($x_ratio * $alto);
>> $ancho_final = $max_ancho;
>> }
>> /*
>> * Igual que antes pero a la inversa
>> */ else {
>> $ancho_final = ceil($y_ratio * $ancho);
>> $alto_final = $max_alto;
>> }
>>
>> //Creamos una imagen en blanco de tamanio $ancho_final por
>> $alto_final .
>> $tmp = imagecreatetruecolor($ancho_final, $alto_final);
>>
>> //Copiamos $img_original sobre la imagen que acabamos de crear
>> en blanco ($tmp)
>> imagecopyresampled($tmp, $img_original, 0, 0, 0, 0,
>> $ancho_final, $alto_final, $ancho, $alto);
>>
>> //Se destruye variable $img_original para liberar memoria
>> imagedestroy($img_original);
>>
>> //Definimos la calidad de la imagen final
>> $calidad = 95;
>>
>> //Se crea la imagen final en el directorio indicado
>> imagejpeg($tmp, "ejemplo.jpg", $calidad);
>>
>> $data = file_get_contents('ejemplo.jpg');
>> $pg_tmp = pg_escape_bytea($data);
>>
>> //pg_query($conn, "insert into fotitos (foto) values('{$pg_tmp}')");
>> pg_query($conn, "UPDATE cp_fotos_notif SET foto = '{$pg_tmp}'
>> WHERE fotos_notif_id = " . $raw['fotos_notif_id'] . " ");
>>
>> echo 'se actualizo'.$raw['fotos_notif_id'].'<br>';
>>
>> } else {
>>
>> echo $raw['fotos_notif_id'].' ya tiene el tamaño menor a 999
>> <br>';
>> }
>>
>> ob_flush();
>> flush();
>> }
>> pg_close($conn);
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> El 4 de agosto de 2017, 11:11, Diego Ayala <netdiego81(at)gmail(dot)com>
>> escribió:
>>
>>> Buenos días, tengo un compañero de una institución que esta teniendo
>>> problemas, el problema es el siguiente, tiene una DB PostgresSQL 8.3 sobre
>>> windows, aclaro que es un sistema critico, y que al adquirir el software
>>> hace varios años, se lo entregaron asi, el tema es que se esta quedando sin
>>> espacio en disco, y ya no puede agregar discos(tiene 2TB de capacidad, pero
>>> ya esta utilizado 1,8 TB), el cluster tiene varias DB's, pero es una DB la
>>> que tiene 1 sola tabla que es la que esta con crecimiento , la tabla tiene
>>> 1.5TB (imágenes), que esta sobre un tablespace (otro disco) que también
>>> esta quedando sin espacio, la pregunta que tengo, como se puede optimizar
>>> el Backup, pg_dump, ya que dura aproximadamente 16hs en terminar y otras 15
>>> horas en restore, es un sistema critico que no se puede parar por mucho
>>> tiempo, la idea es migrar a un servidor nuevo, con mas disco, pero implica
>>> parar para realizar el bkp, pero es mucho tiempo, alguien podria darme una
>>> mano de como realizarlo, lastimosamente, el 8.3 no tiene todavia la
>>> replicacion nativa, por lo tanto no puedo utilizar el SR.
>>>
>>> Gracias.
>>>
>>>
>>
>>
>> --
>> José Mercedes Venegas Acevedo
>> cel Mov RPC 964185205
>>
>> Member of the PHP Documentation Group (Spanish)
>>
>
>

--
José Mercedes Venegas Acevedo
cel Mov RPC 964185205

Member of the PHP Documentation Group (Spanish)

Attachment Content-Type Size
image/jpeg 15.0 KB

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Daymel Bonne 2017-08-04 19:50:24 Re: Que se debe tener en cuenta para migrar de versión postgres 9.4.5 a 9.6.3
Previous Message mauricio pullabuestan 2017-08-04 19:01:40 Que se debe tener en cuenta para migrar de versión postgres 9.4.5 a 9.6.3