aquí me surge que mas que el SQL en si, es un tema de la gestión de datos,
tenemos por costumbre, " dale echale datos no mas la bbdd aguanta"
(donde trabajo, estamos en las mismas pero por inserción)
estuvimos dándole vueltas como solucionar el tema, y miramos fuera de la
caja:
del archivo histórico solo necesitamos unos años hacia atrás, por ende
solo una vez debimos esperar bastante tiempo en proceso , las
siguientes iteraciones siempre es menor el movimiento de datos
historicobig contiene el historial de 5 años hacia atrás, historico5
contiene los últimos 5 años, de esa forma , en el big se usa un sql no
necesariamente optimizado
y en le historico5 , es mucho menor los teras, así que se demora menos
el proceso , para la auditoria estarán todos los datos, y para el
borrado sera mas fácil.
cuando los datos en historico5 son mas viejos de 5 años, se mueven a
historicobig
espero te ayuden estas ideas
El 26-09-23 a las 18:16, Horacio Miranda 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
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>) 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.
**
*
*
*
*
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
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
