> 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 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. > > 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. > 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. > > > El mar, 26 sept 2023 a las 16:11, Enrique Herrera Noya > (<enrique.herreran...@gmail.com <mailto: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 clapri = 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 clapri 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. > > > > 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. >> >> 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. 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. >> >> 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. En resumen, execution plan. revisa bien el modelo y asegurate que no estes callendo en un trigger que te este haciendo todo lento. > > 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
