El mar, 26 sept 2023 a las 17:16, Horacio Miranda (<hmira...@gmail.com>) escribió:
> > > On 26/09/2023, at 5:34 PM, Jairo Graterón <jgrate...@gmail.com> wrote: > > Hola Enrique > la tabla tiene la siguiente definición > > > Tirate el \d comprobante > Si creo que me equivoque la table tiene id como clave primaria y (num_ruc, num_comprobante), no puedo compartir mucho por el tema de confidencialidad. > No veo el indice que mencionas en la definición. > > create table comprobante > ( > id bigserial not null, > num_ruc varchar(11) not null, > num_comprobante bigint not null, > fecha date not null, > monto numeric(10,2), > estatus char(1) not null, -- 0 anulado, 1 activo > primary key(id), > unique (num_ruc, num_comprobante) > ); > para buscar rápidamente un cliente tenemos el siguiente índice > create index idx_num_ruc on comprobante(num_ruc); > > > El unique num_ruc,num_comprobante en el fondo es un trigger, Tirate los > explain (buffers,analyze delete …. > > De la operación, esto te puede decir por que se demora tiempo. > > Cuando se establece la relación comercial el estado(GOB) nos envía el > histórico de los comprobantes del cliente para cuando se realicen > ciertas operaciones se pueda validar el estatus, la fecha y el monto. > > > Esto suena a que debes revisar por el tiempo que debes tener los > registros, puede que tengas que mantener 6 años de registros. > > Lo que exigen es un mínimo de tres meses. > > Ciertamente para eliminar un cliente se puede usar *delete from > comprobante where num_ruc='999999' *pero mensualmente se asocian o se van > entre 100 a 200 clientes y > el delete se vuelve lento para borrar millones de registros, es un > procedimiento que requiere autorización y registro de auditoría. > > > Si te preocupa el tamaño, revisa que estes usando compresión. > > Usamos postgresql 11 y 12, veo que la versión 14 se puede comprimir por columnas, lo revisaré. Se decidió no borrar ya que creaba mucho I/O en el disco que afecta el > desempeño del sistema, ahora esa tabla va por los 2mil millones y sigue > creciendo. > > > > Puedes desactivar los sorts, cuando borres, esto optimiza las busquedas > secuenciales en postgresql para borrar cosas masivas. Todo depende del plan > de ejecución de tu operación. > > Ok, voy a solicitar una prueba. > > > El mar, 26 sept 2023 a las 16:11, Enrique Herrera Noya (< > enrique.herreran...@gmail.com>) escribió: > >> >> veamos si te entiendo >> tienes por un lado *num_ruc *y por otro >> *num_comqrobante * >> >> y la clave primaria la creas concatenando *cla**pri = >> num_ruc.**num_comprobante >> * >> >> como el numero de comprobante siempre es mayor el mas reciente puedes >> determinar desde que año quieres borrar basándote en el correlativo >> >> ahora bien si quiere borrar todo lo relacionado a un cliente, bastaría >> usar una condición donde *cla**pri** sea menor a >> **num_ruc.**num_ultimocomprobante >> *y que ademas *num_ruc **= num_rucaborrar *, de esta forma usas la clave >> primaria lo que sera mas rápido que usar en la sentencia solo *num_ruc *que >> no es clave primaria >> >> > Borrado por clave primaria ( que tiene un indice Implicito ), es siempre > más rápido. Dado que en este caso el indice es de una columna simple. > > Se debe borrar por ruc que es el identificador del cliente. > >> >> >> El 26-09-23 a las 12:11, Jairo Graterón escribió: >> >> Saludos lista >> >> Tengo un requerimiento sobre liberar el espacio ocupado por registros de >> ventas de >> los clientes que ya no tienen relación comercial con nosotros. >> >> Actualmente la tabla *comprobantes *tiene 2mil millones de registros, >> debido a que >> tiene registros de históricos de ventas proporcionados por el estado para >> controlar >> la emisión única de comprobantes. >> >> > Esto no es mucho, estas seguro que el espacio se te va en esto ? yo tengo > una base de datos que me genera 2M de registros diarios. > > También hay otras tablas pero esa es la más grande. > >> Cada cliente tiene su identificador único *num_ruc* junto con el número >> de comprobante es la clave primaria. >> >> > No es mejor, cuando hagan un refactor que hagan una columna que refleje el > dato? num_cliente. que significa ruc? > > >> Hacer un *delete from comprobantes where num_ruc='xxx'* no es óptimo ya >> que es lento y el espacio no se recupera en el disco, usamos servicios en >> la nube y cobran por espacio ocupado. >> >> > Después de borrar, debes hacer un vacuum, sin embargo el espacio (marca de > agua por lo que te cobran ya esta usado ) aun que hagas drop, vacuum, etc. > la marca de agua del disco ya esta corrida, no vas a ahorrar plata en este > nivel. > No es mi plata jejeje, sólo un requerimiento para reducir costos, ya que hay aprox 10 BD con otros modelos de negocio de la organización y ocurren casos similares al mío. > > Pero si es es mucho ( que 1T deben ser como 40USD en amazon por ejemplo ) > despues de librar espacio tendras, que bajar la base, hacer un rsync al > disco nuevo y eliminar el disco viejo. ( ignoro que ahorro puedas hacer > ahi). > > > >> Así que me gustaría sus experiencias si han implementado particionamiento >> de tablas ya que veo que no es necesario hacer delete sino drop table. >> >> > Es problema del cloud es el espacio usado en el disco, no la base de > datos. aun que tengas espacio libre no puedes achicar los discos, hacer > mantención te puede ayudar a dejar de crecer en el futuro. cuando el disco > se usa. ya estas pagando por el, Yo trabajaba en Amazon New Zealand, esta > pregunta me la hicieron un par de veces algunos clientes, y uno de ellos > recuerdo que terminaron haciendo un rsync para mover los datos de un disco > a otro para pagar menos. > > Vale, lo probaré. > >> Haciendo cálculos tendríamos la tabla maestra y 8mil tablas relacionadas >> por cada cliente asociado. >> >> > Yo no tendría tantas tablas hijas. Creo que lo que necesitas es un proceso > de off-boarding donde metes los clientes con todos los datos relacionados > en una base con discos más lentos historica ( que debe ser más barato ). > > Ahora ojo que en sistemas más grandes es más barato tener un server que > cloud, si las competencias están en tu empresa, mejor pongan un server, con > discos IOAccelerators para cosas bien calientes y discos SSD que salen como > 400 a 700 USD los discos de 1.6T SSD de 12Gb/s SAS, para HP o DELL. en un > datacenter decente, puede que con varios discos y un par de servidores > estes OK. > > El cloud también falla, no es aprueba de balas. y si tienes un desastre > sin replicación y sin respaldos. bueno es ruleta rusa. > > La empresa tiene su modelo de negocio en la nube, difícilmente quiera comprar hardware. > > En resumen, execution plan. revisa bien el modelo y asegurate que no estes > callendo en un trigger que te este haciendo todo lento. > Lo evaluaré con mis compañeros. Gracias. > > >> Enrique Herrera Noya >> -- >> +56 992303151 >> Red Hat Certified Engineer RHCE Nº100223072 (RH6.0) >> Red Hat Certified System Administrato RHCSA Nº100223072 (RH6.0) >> Red Hat Certified Technician (RHCT) Nº605010753835478 (RH5.0) >> Novell Certified Linux Professional CLP 10 >> Red Hat Delivery Specialist -Container Platform Application Deployment I >> Red Hat Delivery Specialist - Container Platform Administration I >> RED HAT SPECIALIST >> How to Sell Red Hat OpenShift for Infrastructure >> How to Sell Red Hat OpenShift for Developers >> Red Hat Sales Engineer Specialist - Container Platform >> Red Hat Sales Engineer Specialist – Automation >> >> >
