Otras buenas prácticas

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.

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.

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

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

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

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.

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

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;

Hice una infografía que creo que puede ayudar a comprender el tema con mayor facilidad:

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;

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

es un buen tip pero hubiera sido mejor un ejemplo practico

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?

En resumen toca hacer particiones!!!

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

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;

??

Evitar bloqueos por inserciones y borrados en la misma tabla en PostgreSQL puede ser abordado mediante diversas estrategias.
Transacciones más Pequeñas:

• Realiza transacciones más pequeñas. Si tienes una transacción grande que involucra muchas inserciones y borrados, divide la tarea en transacciones más pequeñas. Esto reduce la probabilidad de bloqueos prolongados.

Orden de las Transacciones:

• Asegúrate de que las transacciones realicen las operaciones en el mismo orden. Por ejemplo, si estás insertando y luego borrando, asegúrate de que todas las transacciones sigan este patrón. Esto puede reducir la posibilidad de conflictos.

Bloqueo de Filas Específicas:

• Utiliza cláusulas WHERE más específicas en tus comandos DELETE y UPDATE para afectar solo las filas necesarias, reduciendo así el riesgo de bloqueos.

Índices Efectivos:

• Asegúrate de tener índices eficientes en las columnas utilizadas en las cláusulas WHERE de tus comandos DELETE y UPDATE. Esto puede ayudar a reducir el tiempo de bloqueo.

Uso de VACUUM:

• Ejecuta el comando VACUUM periódicamente. Este comando libera espacio y mejora la eficiencia, especialmente después de grandes operaciones de borrado.

Configuración de Aislamiento:

• Revisa la configuración de aislamiento de tu base de datos. Ajusta la configuración transaction_isolation si es necesario. Un nivel de aislamiento más bajo puede reducir el tiempo de bloqueo, pero ten en cuenta las implicaciones de consistencia.

Particionamiento de Tablas:

• Considera el uso de particionamiento de tablas para dividir grandes conjuntos de datos en particiones más pequeñas. Esto puede reducir el riesgo de bloqueos.

Uso de SERIALIZABLE:

• Si es necesario, puedes cambiar el nivel de aislamiento a SERIALIZABLE para prevenir conflictos. Sin embargo, esto puede afectar el rendimiento.

Uso de Herramientas de Monitoreo:

• Utiliza herramientas de monitoreo para identificar bloqueos y optimizar consultas que podrían estar contribuyendo a bloqueos.
  Actualizaciones Concurrentes:

Considera el uso de la opción CONCURRENTLY en comandos CREATE INDEX para permitir actualizaciones concurrentes.

La verdad, no sé si lo hacen para gente sabe o lo hacen sin querer queriendo…

¡Hola! Estos serían los pasos:

1. Crear tabla llamada viajes_temp (misma estructura que viajes)
2. Crear una tabla viajes_temp_2 (misma estructura que viajes)
3. La tabla viajes seguirá recibiendo nuestros datos
4. Nuestras consultas y consolicaciones se crean en la tabla viajes_temp

El proceso de RENOMBRADO quedaría asi:
viajes —> viajes_temp —> viajes_temp_2 —> viajes

Este sería el proceso en SQL:

BEGIN TRANSACTION;
ALTER TABLE viajes RENAME TO viajes_temp;
ALTER TABLE viajes_temp_2 RENAME TO viajes;
ALTER TABLE viajes_temp RENAME TO viajes_temp2;
COMMIT;

¡Saludos!

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 “vaso 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 “vaso 2”. Una vez que decidimos que el agua fluya hacia el vaso 2, ahora lo llamamos “vaso 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 “cortar, 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 “estática”, borramos los datos y renombramos las tablas, haciendo “está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.

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