Primeros pasos en la arquitectura no transaccional

1

Objetivos y presentación del proyecto

2

Aprende qué es un Data Warehouse

3

Bases de datos columnares y arquitectura orientada a optimización de consultas

4

¿Cómo funciona AWS Redshift?

Configura tu entorno de trabajo para Redshift

5

Creando nuestro entorno de trabajo en AWS

6

Configura tu primer cluster

7

Consumiendo Redshift: empieza la magia

8

Sentencias SQL en Redshift

Cómo diseñar tu base de datos para mejorar su desempeño

9

¿Qué es la compresión en Redshift?

10

Algoritmos de compresión con Redshift

11

Aplicando algoritmos de compresión

12

Análisis de desempeño con diferentes tipos de compresión

13

Estilos de distribución con Redshift

14

Evaluando los estilos de distribución

15

Llaves de ordenamiento para optimizar nuestras consultas

16

Aplicando ordenamiento de columnas

17

Evaluando algoritmos de ordenamiento

18

Buenas prácticas para diseñar tablas en Redshift

19

Tipos de datos en AWS Redshift

20

Reto: mejora el desempeño de tu base de datos

Manipular enormes cantidades de datos

21

Olvídate de los insert, el copy llego para quedarse

22

Cargando archivos tipo JSON

23

El comando copy a fondo

24

Manifiestos y uso de COMPUPDATE para carga con compresión automática

25

Métodos de carga alternativos al comando copy

26

¿Cómo ejecutar sentencias UPDATE y DELETE?

27

¿Cómo mantener el desempeño de tu base de datos?

28

Estadísticas y limpieza de las tablas

Buenas prácticas para diseñar y ejecutar consultas en tu base de datos

29

Agrupamiento, ordenamiento y subqueries

30

¿Qué es y cómo interpretar un explain plan?

Análisis de comportamiento y descarga de datos con Redshift

31

¿Cómo descargar datos eficientemente con UNLOAD?

32

Otras tablas útiles de Redshift para entender el comportamiento de nuestros datos

Conclusiones

33

Próximos pasos con AWS Redshift

No tienes acceso a esta clase

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

¿Qué es y cómo interpretar un explain plan?

30/33
Recursos

¿Cómo evaluar el rendimiento de las consultas SQL?

Cuando se trata de mejorar el rendimiento de tus consultas en bases de datos, medir su eficacia es crucial. Repsheet, una herramienta poderosa, ofrece el "explain plan" o plano de ejecución para analizar tus consultas SQL. El objetivo es evitar operaciones pesadas y optimizar las consultas. Veamos cómo funciona.

¿Qué es el plano de ejecución en SQL?

El plano de ejecución es una herramienta que te proporciona información detallada sobre la ejecución de una consulta SQL. Te dice qué tipo de operación se realiza (por ejemplo, bucles anidados o "nested loops") y te alerta sobre consultas que pueden ser pesadas o lentas. Esto te permite ajustar esas consultas para mejorar su rendimiento.

Ejemplo de uso del plano de ejecución

EXPLAIN SELECT event.event_id, event.event_name, venue.venue_name
FROM event, venue;

Al ejecutar este comando, el sistema no devuelve datos de inmediato, sino un plan de ejecución. Este plan muestra que se está usando un bucle anidado, una operación pesada que deberías evitar.

¿Qué significa un "nested loop" y cómo reducir su impacto?

Un "nested loop" o bucle anidado significa que se está realizando un producto cartesiano entre tablas, lo cual es ineficiente. Para minimizarlo, puedes cambiar a un "hash join" o incluso un "merge join", ambos más eficientes.

Optimización con "hash join"

Considera la siguiente consulta optimizada con un hash join:

EXPLAIN SELECT event.event_id, event.event_name, venue.venue_name
FROM event
JOIN venue ON event.venue_id = venue.venue_id;

Este cambio significativo reduce el número de filas resultantes, previene la duplicación de registros y disminuye el costo de procesamiento.

¿Cómo optimizar tablas con claves de distribución y ordenamiento?

Optimizar las tablas usando claves de distribución y de ordenamiento mejora la eficiencia de las consultas. Por ejemplo, distribuyendo datos en la tabla event mediante venue_id, y ordenándolos también por esta columna, se logra una ejecución de consultas mucho más efectiva.

Creación de tablas con claves de distribución y ordenamiento

CREATE TABLE event_two DISTKEY(venue_id) SORTKEY(venue_id) AS
SELECT * FROM event;

Al ejecutar una consulta optimizada como esta, la eficiencia de las transacciones se incrementa notablemente, minimizando costos y bytes transferidos.

¿Por qué es importante el uso de funciones de agregación y su evaluación?

Las funciones de agregación como SUM o GROUP BY son cruciales para resumir datos, pero deben usarse sabiamente para no aumentar desmedidamente los costos de ejecución.

Ejemplo de función de agregación con evaluación de costos

EXPLAIN SELECT event_id, SUM(price)
FROM sales
GROUP BY event_id;

Esta consulta revela cuántas filas se reducirán después de la agregación, optimizando el uso de la base de datos.

¿Qué papel juegan las alertas en el registro de eventos?

Las alertas en el registro de eventos STL (como stl_alert_event_log) notifican sobre potenciales problemas en las consultas, como la falta de estadísticas actualizadas o el uso de un next loop.

Ejemplo de consulta para revisar alertas

SELECT * 
FROM stl_alert_event_log 
WHERE query = <query_id>;

Esta tabla valiosa te muestra dónde hay errores y qué optimizar, usando alertas precisas.

¿Cómo activar la optimización continua con el plano de ejecución?

Debes asegurarte de mantener actualizadas las estadísticas y evitar operaciones costosas para asegurar una distribución eficiente de datos. Las alertas son un aliado clave en este proceso, permitiéndote identificar y corregir errores rápidamente.

No olvides explorar más sobre la optimización de queries, y no dudes en experimentar con diferentes funciones agregadas y sub queries. ¡Sigue practicando y optimizando tus consultas SQL para obtener los mejores resultados posibles! 🚀

Aportes 6

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Les comparto los querys por sino quieren escribirlos:

explain
SELECT eventid, eventname, event.venueid, venuename
FROM event, venue;

explain
SELECT eventid, eventname, event.venueid, venuename
FROM event, venue
WHERE event.venueid = venue.venueid;

SELECT *
FROM pg_table_def
WHERE tablename IN ('event', 'venue');

CREATE TABLE IF NOT EXISTS public.event_2
(
	eventid INTEGER NOT NULL  ENCODE az64
	,venueid SMALLINT NOT NULL  ENCODE az64 distkey sortkey
	,catid SMALLINT NOT NULL  ENCODE az64
	,dateid SMALLINT NOT NULL  ENCODE RAW
	,eventname VARCHAR(200)   ENCODE lzo
	,starttime TIMESTAMP WITHOUT TIME ZONE   ENCODE az64
);

INSERT INTO event_2 (SELECT * FROM event);

explain
SELECT eventid, eventname, event_2.venueid, venuename
FROM event_2, venue
WHERE event_2.venueid = venue.venueid;

analyze event_2;

explain
SELECT e.eventname, sum(pricepaid)
FROM sales s
INNER JOIN event e ON s.eventid = e.eventid
GROUP BY e.eventname;

explain
SELECT sum(pricepaid)
FROM sales s;

SELECT *
FROM pg_table_def
WHERE tablename IN ('event');

explain
SELECT *
FROM event;

explain
SELECT *
FROM event
ORDER BY eventid;

explain
SELECT *
FROM event
ORDER BY dateid;

SELECT *
FROM stl_alert_event_log;

SELECT *
FROM stl_query;

Explain Distribution

DS_DIST_NONE y DS_DIST_ALL_NONE son buenos indicadores. Indican que no fue necesario redistribuir para ese paso porque todas las combinaciones están ubicadas juntas.

DS_DIST_INNER implica que el paso probablemente tiene un costo relativamente alto porque se está redistribuyendo la tabla interna a los nodos. DS_DIST_INNER indica que la tabla externa ya está distribuida correctamente en la clave de combinación. Configure la clave de distribución de la tabla interna con la clave de combinación para convertirla en DS_DIST_NONE.

explain
SELECT eventid, eventname, event.venueid , venuename
FROM event, venue;

explain
SELECT eventid, eventname, event.venueid , venuename
FROM event, venue
WHERE event.eventid = venue.venueid;

SELECT * FROM pg_catalog.pg_table_def 
WHERE tablename IN ('event', 'venue');

CREATE TABLE IF NOT EXISTS public.event_2
(
	eventid INTEGER NOT NULL  ENCODE az64
	,venueid SMALLINT NOT NULL  ENCODE az64 distkey sortkey
	,catid SMALLINT NOT NULL  ENCODE az64
	,dateid SMALLINT NOT NULL  ENCODE RAW
	,eventname VARCHAR(200)   ENCODE lzo
	,starttime TIMESTAMP WITHOUT TIME ZONE   ENCODE az64
);

INSERT INTO event_2 (SELECT * FROM event);

explain
SELECT eventid, eventname, event_2.venueid , venuename
FROM event_2, venue
WHERE event_2.eventid = venue.venueid;

analyze event_2

explain
SELECT e.eventname , sum(pricepaid)
FROM sales s 
INNER JOIN event e
ON s.eventid = e.eventid
GROUP BY e.eventname; 

explain
SELECT sum(pricepaid)
 FROM sales s;

SELECT * FROM pg_catalog.pg_table_def 
WHERE tablename IN ('event');

explain
SELECT * FROM event;

explain
SELECT * FROM event
ORDER BY eventid;

explain
SELECT * FROM event
ORDER BY dateid;

SELECT * FROM pg_catalog.stl_alert_event_log ;

SELECT * FROM pg_catalog.stl_query 
WHERE query = 24375;

Puede utilizar el plan de consulta para obtener información acerca de las operaciones individuales necesarias para ejecutar una consulta. Antes de trabajar con un plan de consulta, le recomendamos que primero comprenda cómo Amazon Redshift administra el procesamiento de consultas y crea planes de consultas. Para obtener más información, consulte Flujo de trabajo de planificación y ejecución de consultas.

Para crear un plan de consulta, ejecute el comando EXPLAIN seguido del texto real de la consulta. En el plan de consulta, se proporciona la siguiente información:

Las operaciones que realizará el motor de ejecución, leyendo los resultados de abajo arriba.

El tipo de paso que realiza cada operación.

Las tablas y las columnas que se utilizan en cada operación.

La cantidad de datos que se procesa en cada operación, en cuanto a la cantidad de filas y al ancho de datos en bytes.

El costo relativo de la operación. El costo es una medida que compara los tiempos relativos de ejecución de los pasos de un plan. El costo no proporciona información precisa acerca de los tiempo de ejecución reales ni sobre el consumo de memoria, como tampoco proporciona una comparación significativa entre los planes de ejecución. El costo le da una idea de cuáles son las operaciones de una consulta que están consumiendo la mayor cantidad de recursos.

El comando EXPLAIN no ejecuta propiamente la consulta. Solo muestra el plan que Amazon Redshift ejecuta si la consulta se ejecuta en las condiciones de funcionamiento actuales. Si cambia el esquema o los datos de una tabla y ejecuta nuevamente el comando ANALYZE para actualizar los metadatos estadísticos, el plan de consulta podría ser diferente.

La salida del plan de consulta que genera el comando EXPLAIN es una vista general simplificada de la ejecución de consultas. No muestra los detalles del procesamiento en paralelo de las consultas. Para ver información detallada, ejecute la consulta en cuestión y, luego, obtenga información resumida de la consulta desde la vista SVL_QUERY_SUMMARY o SVL_QUERY_REPORT. Para obtener más información acerca de cómo usar estas vistas, consulte Análisis del resumen de consultas.

### ¿Qué es un **Explain Plan**? Un **Explain Plan** es una herramienta utilizada en bases de datos para analizar y entender cómo se ejecuta una consulta SQL. Proporciona detalles sobre cada paso del proceso para llegar al resultado final, incluyendo: * Cómo se seleccionan y filtran los datos. * Cómo se usan índices. * Las operaciones de acceso a datos (como scans de tablas, joins, etc.). * Las agrupaciones y filtros aplicados. * La eficiencia de la ejecución (tiempos, coste estimado). ### Componentes de un Explain Plan: 1. **Select Step**: Representa los pasos involucrados en la obtención de datos. 2. **Join Steps**: Detalla cómo se unen las tablas en la consulta. 3. **Filter**: Filtros aplicados a los datos. 4. **Projection**: La selección de columnas. 5. **Sort/Group**: Ordenamientos o agrupamientos. 6. **Access Methods**: Cómo se accede a los datos, ya sea por Full Table Scan, Index Scan, o Access mediante índices. 7. **Cost**: Estimación del costo de cada paso según recursos utilizados (I/O, CPU). ### Cómo interpretar un Explain Plan: 1. **Operation**: Muestra qué tipo de operación se está realizando (SELECT, JOIN, FILTER, INDEX SCAN, etc.). 2. **Cost**: Mide la complejidad o costo estimado de la operación, generalmente en términos de recursos (CPU, lectura/escritura, etc.). Menor costo indica mejor eficiencia. 3. **Rows**: Número de filas que se procesarán en esa operación. 4. **Filter/Condition**: Detalles sobre los filtros o condiciones aplicadas en cada paso. 5. **Access Path**: Tipo de acceso que se usa, como **Index Scan**, **Table Scan**, **Nested Loop Join**, etc. ### Ejemplo de Explain Plan: EXPLAIN PLAN FOR SELECT nombre, direccion FROM clientes WHERE ciudad = 'Bogotá' AND edad > 30 ORDER BY nombre; **Ejemplo Interpretación**: * `Index Scan` o `Table Scan` nos indica cómo los datos son accedidos. * `Nested Loop Join` se usa para operaciones relacionadas entre tablas. * El `Cost` nos indica la eficiencia: valores más bajos son mejores. Este plan ayuda a identificar problemas como accesos innecesarios a índices o tablas, filtrados lentos, o ineficiencias en el proceso de datos.
Que son las llaves de distribicion? para que las voy a usar??