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

Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

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

30/33
Recursos

Aportes 4

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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.

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;

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.

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;