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

No se trata de lo que quieres comprar, sino de quién quieres ser. Invierte en tu educación con el precio especial

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

12 Días
8 Hrs
43 Min
26 Seg

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

20/33
Recursos

Aportes 13

Preguntas 5

Ordenar por:

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

Me siento solo, no hay nadie aquí… Ni modo, a darle!

Recomendaciones desde mi experiencia con el reto:

  • Paciencia: Son tiempos de procesamiento nunca antes visto durante el curso, si eres como yo que viene de campos distintos a la arquitectura de DBs, debemos entender que esto es pan de cada día y el ejercicio está super bien intencionado para este propósito.

  • Ajustar a los métodos de compresión no es suficiente: debes revisar cada tabla, como están distribuyendose sus slices, qué tipo de llave le resulta mejor y con esto vas a tener cambios enormes.

-¿ Problemas de conexión?: Revisa en los comentarios el aporte de Cesar Augusto Morales Godoy con el tutorial para este tipo de inconvenientes.

-Finalmente, pero no menos importante: éxitos con el reto 💙

Bueno, este fue el resultado final:

Segun la herramienta

analysis compression

ya no se puede reducir más.

Realice las queries de los ejercicios y cree las nuevas tablas haciendo la compresión recomendada por el “analize”, pero no disminuyeron los tiempos de ejecución al contrario aumentaron. Haciendo pruebas con la distribución mejoraron un poco los resultados.

Alguien mas le paso lo mismo? o como lo resolvieron?

Para los que tubieron problemas para encontrar las tablas y como se deben modificar, deben configurar la conexión con la database:

  1. Ver base de datos:
  2. Abrir cofiguración de conexión:
  3. Configurar para ver todas las tablas:
  4. Ya aparecen las tablas, continuar con el video:

Estos fueron mis resultados despues de aplicar la optimizacion de compresion:

Resumo como me fue en el reto: * Query # 1, se redujo el tiempo de ejecución alrededor de un 46 %. * Query # 2, aumento el tiempo de ejecución alrededor de un 36 %. * Query # 3, aumento el tiempo de ejecución alrededor de un 60 %. * Query # 4, se redujo el tiempo de ejecución alrededor de un 16 %. Creo que el reto más importante fue escoger **UNA columna en común** entre las dimensiones y la tabla de hechos para que esa columna fuera "dist key" y "sort key". En su caso, escogí el id del `supplier` pensando que usando esta tabla tendría un merge y por ende mejor performance. Pero no paso en las queries #2 y #3. Es un ejercicio interesante porque hay que considerar restricciones como la mencionada arriba o como mejorar "zone maps" o si al declarar alguna "sort key" que disminuye el costo de ordenamiento.

indicates distkey when the table is created: CREATE TABLE tale_name (column_name type constraint encoding distkey)

compupdate off evita que se compriman los datos una vez sean cargados a redshift

No puedo realizar el reto. Muchos problemas con mi DBeaver, se desconecta solo de la nada y no termina la ejecución de queries tan largos. Alguna sugerencia?

buena practica !!

CREATE TABLE part 
(
  p_partkey     INTEGER NOT NULL,
  p_name        VARCHAR(22) NOT NULL,
  p_mfgr        VARCHAR(6) NOT NULL,
  p_category    VARCHAR(7) NOT NULL,
  p_brand1      VARCHAR(9) NOT NULL,
  p_color       VARCHAR(11) NOT NULL,
  p_type        VARCHAR(25) NOT NULL,
  p_size        INTEGER NOT NULL,
  p_container   VARCHAR(10) NOT NULL
);

CREATE TABLE supplier 
(
  s_suppkey   INTEGER NOT NULL,
  s_name      VARCHAR(25) NOT NULL,
  s_address   VARCHAR(25) NOT NULL,
  s_city      VARCHAR(10) NOT NULL,
  s_nation    VARCHAR(15) NOT NULL,
  s_region    VARCHAR(12) NOT NULL,
  s_phone     VARCHAR(15) NOT NULL
);

CREATE TABLE customer 
(
  c_custkey      INTEGER NOT NULL,
  c_name         VARCHAR(25) NOT NULL,
  c_address      VARCHAR(25) NOT NULL,
  c_city         VARCHAR(10) NOT NULL,
  c_nation       VARCHAR(15) NOT NULL,
  c_region       VARCHAR(12) NOT NULL,
  c_phone        VARCHAR(15) NOT NULL,
  c_mktsegment   VARCHAR(10) NOT NULL
);

CREATE TABLE dwdate 
(
  d_datekey            INTEGER NOT NULL,
  d_date               VARCHAR(19) NOT NULL,
  d_dayofweek          VARCHAR(10) NOT NULL,
  d_month              VARCHAR(10) NOT NULL,
  d_year               INTEGER NOT NULL,
  d_yearmonthnum       INTEGER NOT NULL,
  d_yearmonth          VARCHAR(8) NOT NULL,
  d_daynuminweek       INTEGER NOT NULL,
  d_daynuminmonth      INTEGER NOT NULL,
  d_daynuminyear       INTEGER NOT NULL,
  d_monthnuminyear     INTEGER NOT NULL,
  d_weeknuminyear      INTEGER NOT NULL,
  d_sellingseason      VARCHAR(13) NOT NULL,
  d_lastdayinweekfl    VARCHAR(1) NOT NULL,
  d_lastdayinmonthfl   VARCHAR(1) NOT NULL,
  d_holidayfl          VARCHAR(1) NOT NULL,
  d_weekdayfl          VARCHAR(1) NOT NULL
);
CREATE TABLE lineorder 
(
  lo_orderkey          INTEGER NOT NULL,
  lo_linenumber        INTEGER NOT NULL,
  lo_custkey           INTEGER NOT NULL,
  lo_partkey           INTEGER NOT NULL,
  lo_suppkey           INTEGER NOT NULL,
  lo_orderdate         INTEGER NOT NULL,
  lo_orderpriority     VARCHAR(15) NOT NULL,
  lo_shippriority      VARCHAR(1) NOT NULL,
  lo_quantity          INTEGER NOT NULL,
  lo_extendedprice     INTEGER NOT NULL,
  lo_ordertotalprice   INTEGER NOT NULL,
  lo_discount          INTEGER NOT NULL,
  lo_revenue           INTEGER NOT NULL,
  lo_supplycost        INTEGER NOT NULL,
  lo_tax               INTEGER NOT NULL,
  lo_commitdate        INTEGER NOT NULL,
  lo_shipmode          VARCHAR(10) NOT NULL
);

Despúes de realizar la mejora a la tabla customer, volví a ejecutar un ANALYSE COMPRESSION customer_pro; y ahora sugiere delta para la columna c_custkey.