La base de las huellas digitales y fotos de Chile ( para 20M de personas )
pesaba en el 2008 9 Teras.
Y estoy hablando de 13 huellas para los dedos, foto de tu firma y foto de la
cara de la persona. ( sí hay personas con 12 dedos ). ( como se esto ?, era el
DBA del Registro Civil de Chile entre el 2005 y el 2008 ).
Si quieres saber el tamaño de tu base de datos.
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC limit 1;
SELECT pg_size_pretty(pg_database_size('geekdb'));
Hay varias funciones para saber el peso de algunos objetos.
https://www.postgresql.org/docs/9.1/static/functions-admin.html
<https://www.postgresql.org/docs/9.1/static/functions-admin.html>
Espero esto te sirva.
> On 5/08/2017, at 7:33 AM, jvenegasperu . <[email protected]> wrote:
>
> 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 <[email protected]
> <mailto:[email protected]>> 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 . <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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)
> <foto_jvenegas.jpg>
