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

Evaluando algoritmos de ordenamiento

17/33
Recursos

Aportes 8

Preguntas 0

Ordenar por:

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

¿Pero por qué aún apagando el caché la segunda consulta es muchísimo más rápida? Me daría la impresión de que el siguiese haciendo uso del caché

set enable_result_cache_for_session to off;

SELECT max(lo_revenue), min(lo_revenue) 
FROM cust_sales_simple
WHERE c_custkey < 100000; --349ms ,237ms

SELECT max(lo_revenue), min(lo_revenue) 
FROM cust_sales_compuesto
WHERE c_custkey < 100000; --125ms ,146ms

SELECT max(lo_revenue), min(lo_revenue) 
FROM cust_sales_intercalado
WHERE c_custkey < 100000; --397 ms ,179ms
-------------------------------

set enable_result_cache_for_session to off;


SELECT max(lo_revenue), min(lo_revenue) 
FROM cust_sales_simple
WHERE c_region = 'ASIA'
AND c_mktsegment = 'FURNITURE'; --1.468ms, 1.369 ms

SELECT max(lo_revenue), min(lo_revenue) 
FROM cust_sales_compuesto
WHERE c_region = 'ASIA'
AND c_mktsegment = 'FURNITURE';--2.586s, 770ms

SELECT max(lo_revenue), min(lo_revenue) 
FROM cust_sales_intercalado
WHERE c_region = 'ASIA'
AND c_mktsegment = 'FURNITURE';--303ms, 104 ms


-----------
set enable_result_cache_for_session to off;


SELECT max(lo_revenue), min(lo_revenue)
FROM cust_sales_simple
WHERE d_date BETWEEN '01/01/1996' AND '01/14/1996'
AND c_mktsegment = 'FURNITURE'
AND c_region = 'ASIA';--1.415s, 115ms

SELECT max(lo_revenue), min(lo_revenue)
FROM cust_sales_compuesto
WHERE d_date BETWEEN '01/01/1996' AND '01/14/1996'
AND c_mktsegment = 'FURNITURE'
AND c_region = 'ASIA';--806 ms, 326ms

SELECT max(lo_revenue), min(lo_revenue)
FROM cust_sales_intercalado
WHERE d_date BETWEEN '01/01/1996' AND '01/14/1996'
AND c_mktsegment = 'FURNITURE'
AND c_region = 'ASIA';--236 ms, 112ms

La sentencia ENABLE_RESULT_CACHE_FOR_SESSION opera de la siguiente forma:

Si su valor es ON busca en cache algún resultado previamente calculado para el query ejecutado. Si su valor es OFF ejecuta el query directamente y obtiene un resultado nuevo.

ENABLE_RESULT_CACHE_FOR_SESSION - STACKOVERFLOW

### Evaluando Algoritmos de Ordenamiento en Amazon Redshift El uso de **llaves de ordenamiento (**`SORT KEYS`**)** es crucial para optimizar las consultas en Redshift, especialmente en tablas grandes y con consultas complejas. Los algoritmos de ordenamiento disponibles en Redshift incluyen **COMPOUND** e **INTERLEAVED**, cada uno diseñado para diferentes casos de uso. Evaluarlos correctamente asegura un rendimiento óptimo para tus necesidades específicas. ### **1. Tipos de Algoritmos de Ordenamiento** #### **a. Llave de Ordenamiento Compuesta (COMPOUND SORTKEY)** Ordena físicamente los datos en el disco de manera secuencial, basándose en las columnas especificadas. * **Ventajas:** * Ideal para consultas que filtran o agrupan por la primera columna de la llave. * Bajo costo de mantenimiento. * **Desventajas:** * Menos eficiente si las consultas dependen de columnas secundarias en la llave. * No es flexible para patrones de consulta variados. #### **b. Llave de Ordenamiento Entrelazada (INTERLEAVED SORTKEY)** Distribuye el ordenamiento entre todas las columnas especificadas, optimizando el acceso a cualquiera de ellas. * **Ventajas:** * Más flexible para patrones de consulta variados. * Beneficia consultas que filtran por cualquier combinación de columnas en la llave. * **Desventajas:** * Mayor costo de mantenimiento (especialmente con inserciones y cargas masivas). * Menor eficiencia si la mayoría de las consultas dependen de una sola columna. ### **2. Métodos de Evaluación de Algoritmos** #### **a. Pruebas de Rendimiento** Evalúa cada algoritmo mediante pruebas de rendimiento específicas para tu carga de trabajo. 1. **Crea Tablas de Prueba:**CREATE TABLE ventas\_compound ( venta\_id INT, fecha DATE, cliente\_id INT, total DECIMAL(10, 2) ) COMPOUND SORTKEY (fecha, cliente\_id); CREATE TABLE ventas\_interleaved ( venta\_id INT, fecha DATE, cliente\_id INT, total DECIMAL(10, 2) ) INTERLEAVED SORTKEY (fecha, cliente\_id); * Una con llave compuesta. * Otra con llave entrelazada. 2. **Carga los Datos:** Utiliza datos representativos de tu carga de trabajo.COPY ventas\_compound FROM 's3://mi-bucket/ventas.csv' CREDENTIALS 'aws\_access\_key\_id=XXX;aws\_secret\_access\_key=YYY' CSV; COPY ventas\_interleaved FROM 's3://mi-bucket/ventas.csv' CREDENTIALS 'aws\_access\_key\_id=XXX;aws\_secret\_access\_key=YYY' CSV; 3. **Ejecuta Consultas de Prueba:** Ejecuta las consultas más comunes y mide los tiempos de respuesta.EXPLAIN SELECT \* FROM ventas\_compound WHERE fecha = '2025-01-01'; EXPLAIN SELECT \* FROM ventas\_interleaved WHERE fecha = '2025-01-01'; #### **b. Monitoreo de Uso** Utiliza las vistas del sistema de Redshift para monitorear el uso de las columnas en las consultas. * Consulta columnas utilizadas en escaneos:SELECT table\_id, column, sum(scan\_count) AS total\_scans FROM svl\_query\_summary GROUP BY table\_id, column ORDER BY total\_scans DESC; * Evalúa la distribución de datos y el rendimiento:SELECT table\_id, diststyle, sortkey1, skew\_sortkey1, rows FROM svv\_table\_info WHERE table\_name = 'ventas'; ### **3. Casos de Uso de Cada Algoritmo** **CriterioCOMPOUND SORTKEYINTERLEAVED SORTKEYConsultas Secuenciales**Alta eficienciaEficiencia moderada**Consultas con Múltiples Columnas**Menos eficienteAlta eficiencia**Mantenimiento**Bajo costoAlto costo**Flexibilidad**BajaAlta ### **4. Consideraciones Adicionales** #### **a. Tamaño de la Tabla** * Tablas pequeñas no se benefician significativamente de llaves de ordenamiento. * Tablas grandes con patrones de acceso predecibles suelen usar `COMPOUND SORTKEY`. #### **b. Frecuencia de Cargas de Datos** * Si realizas muchas inserciones o cargas masivas, el costo de mantenimiento de `INTERLEAVED SORTKEY` puede ser prohibitivo. #### **c. Reclamo de Espacio y Optimización** Usa `VACUUM` y `ANALYZE` para optimizar la disposición física de los datos después de cambios significativos. VACUUM ventas\_compound; ANALYZE ventas\_compound; ### **Conclusión** La elección del algoritmo de ordenamiento depende de tus patrones de acceso y la flexibilidad que necesitas. Realiza pruebas y monitorea el impacto en el rendimiento para seleccionar la mejor estrategia para tu carga de trabajo en Amazon Redshift.

Apagar el cache: set enable_result_cache_for_session to off

Hice unas consultas para los registros con ID mayor a 500,000 de mayo de 1996, sector automóvil y con región de Medio Oriente y mientras más filtros se agregan más es la diferencia de las sort key tipo intercalado en el rendimiento

set enable_result_cache_for_session to off;

select sum(lo_revenue) 
from cust_sales_simple 
WHERE c_custkey > 500000
	AND d_date BETWEEN '1996/05/01' AND '1996/05/30'
	AND c_mktsegment = 'AUTOMOBILE'
	AND c_region = 'MIDDLE EAST' ; 
-- tiempo con cache desactivado 1.345 s

select sum(lo_revenue) 
from cust_sales_compound 
WHERE c_custkey > 500000
	AND d_date BETWEEN '1996/05/01' AND '1996/05/30'
	AND c_mktsegment = 'AUTOMOBILE'
	AND c_region = 'MIDDLE EAST' ; 
-- tiempo con cache desactivado 710 ms

select sum(lo_revenue) 
from cust_sales_interleaved 
WHERE c_custkey > 500000
	AND d_date BETWEEN '1996/05/01' AND '1996/05/30'
	AND c_mktsegment = 'AUTOMOBILE'
	AND c_region = 'MIDDLE EAST' ; 
-- tiempo con cache desactivado 277 ms

muy clara esta clase

Mis tiempos en las queries:

set enable_result_cache_for_session to off;

select max(lo_revenue), min(lo_revenue) 
from cust_sales_simple
where c_custkey < 100000;--420ms/ 232ms

select max(lo_revenue), min(lo_revenue) 
from cust_sales_compuesto
where c_custkey < 100000;--178ms/ 153ms

select max(lo_revenue), min(lo_revenue) 
from cust_sales_intercalable
where c_custkey < 100000;--326/ 234ms
-------------------------------------------------

select max(lo_revenue), min(lo_revenue)
from cust_sales_simple
where c_region = 'ASIA'
and c_mktsegment = 'FURNITURE';--8.847s/ 4.399s

select max(lo_revenue), min(lo_revenue)
from cust_sales_compuesto
where c_region = 'ASIA'
and c_mktsegment = 'FURNITURE';--7.931s/ 3.459s

select max(lo_revenue), min(lo_revenue)
from cust_sales_intercalable
where c_region = 'ASIA'
and c_mktsegment = 'FURNITURE';--4.761/539ms
---------------------------------------------------

set enable_result_cache_for_session to off;

select max(lo_revenue), min(lo_revenue)
from cust_sales_simple
where d_date between '01/01/1996' and '01/14/1996'
and c_mktsegment = 'FURNITURE'
and c_region = 'ASIA';--1.254s/ 1.103s

select max(lo_revenue), min(lo_revenue)
from cust_sales_compuesto
where d_date between '01/01/1996' and '01/14/1996'
and c_mktsegment = 'FURNITURE'
and c_region = 'ASIA';--9.191s/ 4.590s

select max(lo_revenue), min(lo_revenue)
from cust_sales_intercalable
where d_date between '01/01/1996' and '01/14/1996'
and c_mktsegment = 'FURNITURE'
and c_region = 'ASIA';--5.221/ 404ms```