No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso de PostgreSQL

Curso de PostgreSQL

Oswaldo Rodríguez González

Oswaldo Rodríguez González

Otras buenas prácticas

31/32
Recursos

Aportes 32

Preguntas 3

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

Creo que falto una pequeña gráfica para ilustrar mejor el consejo…

Hola siento que esto que explican es de gran utilidad pero debieron explicarlo mejor,

Usar algun diagrama o algo seria genial para ejemplificar.

Un saludo

Con el pdf y todo me costó entender el proceso.

El objetivo es leer los datos de una tabla de datos crudos y una vez leída una fila se le da formato, se guarda en un registro de solo lectura y luego se borra esa misma fila de la tabla.

El problema la tabla de datos crudos se le siguen insertando millones de datos por minuto lo cual hace que borrar una fila pueda demorar minutos en ejecutarse y lograr vaciar la tabla sería imposible.

Entonces para poder realizar este proceso se realiza una transacción que renombre dos tablas que tienen la misma estructura, tabla_1 y tabla_offload , se busca que intercambien el nombre para que de esta forma postgres siempre tenga una tabla a la cual escribir y la tabla de la cual se lee y se borran datos no se le estan realizando inserciones.

De esta forma se logra vaciar la tabla de datos crudos y no hay perdida de datos

Ademas como menciona el pdf es importante considerar que:
La solución final y escalable es usar
particiones, toma más tiempo en implementar, pero es definitiva.

It sounds very interesting, but there is not a visual example 😦

Solo hay una palabra para este profesor: ERUDITO! de verdad el suda experiencia y manejo del tema, que extraordinario tomar un curso asi.

Gracias por el TIP. Lastima que no se grabo el ejemplo en vivo.

Que tip tan cool. Espero aplicarlo pronto 😄

En los escenarios de producción se evita el borrado físico de registros en todas las tablas, y sobre todo transaccionales para evitar consumir recursos de BD y por ende los tiempos de respuestas del Servidor. Recordemos que lo que llevamos al front-end son conjuntos de resultados de una consulta almacenada en forma de vista, consolidar información no es una tarea de un flujo de transaccional de una aplicación. Cuando entregas reportes sobre millones de registros no entregas datos en bruto al contrario ya previamente existe en tu flujo de procesos la conversión de estos datos en bruto a información útil pero sin interrumpir el flujo transaccional

Es decir, el truco está en crear tablas temporales para facilitar la inserción o borrado de información sin que la tabla original se vea saturada de pedidos que puedan relentizarla o tumbarla.

Me parecio a mi o las preguntas estan mal formuladas?

Información resumida de esta clase
#EstudiantesDePlatzi

  • Es importante evitar los bloqueos por inserción y borrados en la misma tabla

  • Para esto puedo cambiar el nombre de la tabla que necesite consolidar y creo una tabla nueva en donde mi aplicación va a estar llenando los datos, así una tabla estará en consolidación y la tabla nueva estará recibiendo datos y no se bloqueara mi app

  • Este cambio de nombre lo debo hacer periódicamente, pero depende de la cantidad de volumen de información que estoy recibiendo

En el archivo se encuentra a mayor detalle

y por ejemplo en el beggin transaction se podria hacer:

BEGGIN TRANSACTION;
ALTER TABLE estadistica RENAME TO estadistica_offload;
CREATE TABLE estadisitica (…);
COMMIT;

??

O sea, tengo un tanque de agua, el cual ya se esta llenando, (el flujo de agua es constante),

lo del renombramiento y redireccionamiento seria, sacarle toda el agua al tanque y echarla en uno nuevo,

y el agua seguirá ingresando al tanque pues lo que hice no afecto el flujo de agua (milisegundos)

??

Excelente tip!!

Este curso seria util para otros motores de SQL como MySQL y SQL Server en versiones developer

Queda claro que se deben implementar este tipo de herramientas de optimización cuando se trabaja con muchos datos, pero cuánto es mucho?

Solo hizo falta una representación visual del consejo.

excelente truco

Buena técnica para optimizar nuestra base de datos.

Excelente documento. Tan explicativo como los videos.

Me costo entenderlo, pero después de verlo varias veces lo entendí. 😃
Enserio muy bueno.

Por lo que entendí el truco sería algo así, buena información.

BEGIN;
ALTER TABLE pasajeros RENAME TO pasajeros_old;
CREATE TABLE pasajeros( nombre character varying, id integer, direccion_residencia character varying, fecha_nacimiento date,
primary key (id));
COMMIT;

BEGIN;
ALTER TABLE pasajeros RENAME TO pasajeros_temp;
ALTER TABLE pasajeros_old RENAME TO pasajeros;
ALTER TABLE pasajeros_temp RENAME TO pasajeros_old;
COMMIT;

Muy interesante, una solución que no se puede idear fácilmente aún con conocimientos previos. Definitivamente, como menciona el PDF, la solución sería utilizar particiones, pero esta es una muy buena opción para no detener el flujo de trabajo en tablas que no fueron particionadas desde su creación. Gracias 😄

a la mayoría de explicaciones les falta una parte visual en la presentación del problema, es común ver que se quedan con muchas palabras y cero apoyo gráfico... Freddy si hace esto, casi todas las explicaciones de él tienen una presentación

El documento en archivos y enlaces es necesario para entender mucho mejor los conceptos del video.

Tal y cómo lo he entendido,se trata de separar una tabla en 2. Una se usará para lo deletes y la otra para los inserts.

Cuando la de los deletes se vacie las tablas intercambiarán sus roles. La que almacenaba los
inserts pasará a usarse para los deletes y la que actualmente está vacía pasará a almacenar los datos añadidos con insert. Parece un buen truco. Gracias 😄

gracias por el consejo

Renombrar tablas

Evitar bloqueos por inserciones y borrados en la misma tabla.

Buen consejo profe!

Debo buscar mas sobre este tipo de tips, porque realmente es una muy buena practica