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 47

Preguntas 4

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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 馃槮

yo en el minuto 2:52 馃槀

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

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

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.

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

El objetivo de renombrar una tabla es para poder extraer datos de una tabla que esta siendo alimentada constantemente con miles de datos (ej. c谩maras de seguridad, sensores, aplicaciones m贸viles). Esto debido a que las filas se est谩n reindexando constantemente y no permitir铆a tomar los datos reales adem谩s de presentar problemas en la integridad de la informaci贸n.

Para esto, se debe cambiar el nombre de la tabla de la cual se desea extraer la informaci贸n, esto con una ligera variaci贸n que permita diferenciarla de una nueva tabla que llevar谩 el nombre de la tabla original, tal cual, con la misma estructura y especificaciones de las columnas. Esta orden se ejecutar谩 en una transacci贸n que permita un cambio r谩pido y verificado paso a paso, de esta forma se evita que la app caiga al no encontrar la tabla objeto del cambio de nombre, sino que al contrario, tendr谩 una tabla vac铆a para continuar alimentando y el data analyst tendr谩 a disposici贸n los datos para sus consultas y reportes.

--AQU脥 COPIA Y PEGA EL SQL DE LA TABLA PARA CREARLA CON LAS MISMAS CARACTER脥STICAS--
CREATE TABLE viajes_offload
(
    viaje_id integer NOT NULL DEFAULT nextval('viajes_viaje_id_seq'::regclass),
    t_inicio time without time zone,
    t_fin time without time zone,
    fecha timestamp without time zone,
    pasajero_id integer,
    ruta_id integer,
    CONSTRAINT viajes_pkey PRIMARY KEY (viaje_id),
    CONSTRAINT viaje_pasajero_fkey FOREIGN KEY (pasajero_id)
        REFERENCES public.pasajero (pasajero_id) MATCH SIMPLE
        ON UPDATE CASCADE
        ON DELETE CASCADE
        NOT VALID,
    CONSTRAINT viaje_ruta_fkey FOREIGN KEY (ruta_id)
        REFERENCES public.rutas (ruta_id) MATCH SIMPLE
        ON UPDATE CASCADE
        ON DELETE CASCADE
        NOT VALID
)
TABLESPACE pg_default;

ALTER TABLE IF EXISTS public.viajes
    OWNER to postgres;
REVOKE ALL ON TABLE public.viajes FROM usuario_consulta;
GRANT ALL ON TABLE public.viajes TO postgres;
GRANT UPDATE, INSERT, SELECT ON TABLE public.viajes TO usuario_consulta;

--RENOMBRAR TABLAS--
BEGIN;
ALTER TABLE IF EXISTS viajes RENAME TO viajes_julio2022;
ALTER TABLE viajes_offload RENAME TO viajes
COMMIT;

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

Que tip tan cool. Espero aplicarlo pronto 馃槃

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;

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

Me parecio a mi o las preguntas estan mal formuladas?

es un buen tip pero hubiera sido mejor un ejemplo practico

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 馃槃

Me costo entenderlo, pero despu茅s de verlo varias veces lo entend铆. 馃槂
Enserio muy bueno.

Excelente tip!!

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)

??

Holy shit, este es un consejo super pro

Aun con la lectura del pdf,me parece bastante complejo , voy a buscar ejemplos y usos practicos para ver si puedo entender mas.

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;

??

L谩stima no expliquen bien :(

Amerita un ejemplo paso a paso.

Me cost贸 mucho trabajo entender esta idea, pero en realidad es un concepto bastante simple. Perm铆teme explicarlo utilizando una analog铆a con un vaso y una llave abierta.

Imag铆nate que tienes un vaso, al que llamaremos 鈥渧aso 1鈥, y una llave que est谩 constantemente abierta, representando el flujo continuo de datos. Si quieres beber agua de ese vaso, tendr谩s que llevarlo a tu boca, pero mientras lo haces, el agua de la llave se desperdiciar谩. Para evitar este desperdicio, traemos otro vaso vac铆o, al que llamaremos 鈥渧aso 2鈥. Una vez que decidimos que el agua fluya hacia el vaso 2, ahora lo llamamos 鈥渧aso 1鈥.

En el contexto de la consolidaci贸n de datos, esto significa que creamos una nueva tabla que reemplaza a la tabla original. La nueva tabla debe tener los mismos campos que la tabla original para que las nuevas inserciones de datos funcionen correctamente, como si siempre hubieran estado destinadas a la tabla original.

Seg煤n yo entend铆, a modo de resumen, en lugar de 鈥渃ortar, pegar y borrar鈥 de una tabla a otra datos que se registran extremadamente r谩pido, lo que se hace en su lugar es disponer de dos tablas con los mismos atributos:

  • Tabla_1: Entran nuevos datos de forma constante.
  • Tabla_2: No entran nuevos datos.

Entonces, cada vez que terminemos de hacer lo que necesitemos con la Tabla_2, que es 鈥渆st谩tica鈥, borramos los datos y renombramos las tablas, haciendo 鈥渆st谩tica鈥 a la otra (Tabla_1 pasa a llamarse Tabla_2 y viceversa, la Tabla_2 pasa a llamarse Tabla_1).
As铆 conseguimos que la que acabamos de vaciar empiece a recibir datos mientras que todo el sistema sigue funcionando.

en pocas palabras lo que queria desir pero no dijo fue esto., supon que de antemano as creado una tabla igual a viajes y la llamaste viajes_offload

BEGIN;
ALTER TABLE IF EXISTS viajes RENAME TO viajes_julio2022;
ALTER TABLE viajes_offload RENAME TO viajes
COMMIT;

Esta explicacion se parece mucho a las replicas. Pero llevado a un nivel mas avanzado.

interesante consejo, si tiene su l贸gica

Si entendiste lo que dijo el profe, tomaste notas. luego vas al pdf y aterrizas en c贸digo las acciones que menciona el profe. te queda mas claro su l贸gica, utilidad y funcionamiento.

Este es un gran tip, al comienzo no entend铆 pero luego hice un diagrama en f铆sico repitiendo cada segmento del proceso, imagin谩dome como ser铆a diagrama del flujo del tip y todo encaj贸 y fue muy simple pero complejo a la vez waos, este profesor es mucha calidad!!!

excelente truco

Buena t茅cnica para optimizar nuestra base de datos.

Excelente documento. Tan explicativo como los videos.

Seria conveniente, dar otros tips de buenas practicas

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.

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