Optimización de Datos en Data Warehouses con Repsheet

### Buenas Prácticas para Diseñar Tablas en Amazon Redshift Diseñar tablas en Amazon Redshift implica optimizar tanto el almacenamiento como el rendimiento de las consultas. Esto requiere una planificación cuidadosa en cuanto a la distribución de datos, el ordenamiento, la compresión y otros aspectos clave. A continuación, se presentan las mejores prácticas para maximizar la eficiencia. ### **1. Selección del Estilo de Distribución** El estilo de distribución define cómo se almacenan los datos en los nodos del clúster. Una distribución adecuada minimiza el movimiento de datos entre nodos durante las consultas. #### **a. KEY** * Usa una columna común en las consultas para distribuir los datos. * Ideal para tablas con combinaciones frecuentes. * Ejemplo:CREATE TABLE ventas ( venta\_id INT, cliente\_id INT, fecha DATE ) DISTKEY (cliente\_id); #### **b. ALL** * Replica la tabla en todos los nodos. * Útil para tablas pequeñas utilizadas en muchas combinaciones. * Ejemplo:CREATE TABLE estados ( estado\_id INT, descripcion VARCHAR(50) ) DISTSTYLE ALL; #### **c. EVEN** * Distribuye filas uniformemente entre nodos. * Ideal para tablas grandes con accesos no predecibles. * Ejemplo:CREATE TABLE logs ( log\_id INT, mensaje VARCHAR(255), fecha DATE ) DISTSTYLE EVEN; ### **2. Definición de Llaves de Ordenamiento (**`SORTKEY`**)** Las llaves de ordenamiento optimizan el escaneo de datos en disco, reduciendo el tiempo de ejecución de consultas. #### **a. Llave Compuesta (COMPOUND)** * Ordena físicamente por las columnas definidas, en el orden especificado. * Útil para consultas que filtran por la primera columna. * Ejemplo:CREATE TABLE ventas ( venta\_id INT, fecha DATE, cliente\_id INT ) COMPOUND SORTKEY (fecha, cliente\_id); #### **b. Llave Entrelazada (INTERLEAVED)** * Distribuye el ordenamiento entre varias columnas. * Ideal para consultas con filtros en cualquier combinación de columnas. * Ejemplo:CREATE TABLE ventas ( venta\_id INT, fecha DATE, cliente\_id INT ) INTERLEAVED SORTKEY (fecha, cliente\_id); ### **3. Uso de Compresión (**`ENCODE`**)** Aplica compresión para reducir el espacio en disco y mejorar el rendimiento. Redshift selecciona automáticamente el mejor algoritmo al analizar los datos. #### **a. Compresión Manual** * Especifica el algoritmo si conoces el tipo de datos. * Ejemplo:CREATE TABLE ventas ( venta\_id INT ENCODE delta, fecha DATE ENCODE lzo, cliente\_id INT ENCODE zstd ); #### **b. Analiza y Optimiza** * Usa el comando `ANALYZE COMPRESSION` para determinar los mejores algoritmos.ANALYZE COMPRESSION ventas; ### **4. Partición de Tablas Grandes** Divide tablas muy grandes en subconjuntos manejables mediante claves de partición lógica, como fechas. #### **Ejemplo:** Crear tablas mensuales basadas en la fecha. CREATE TABLE ventas\_2025\_01 ( venta\_id INT, fecha DATE, cliente\_id INT ) DISTKEY (cliente\_id) SORTKEY (fecha); ### **5. Mantenimiento Regular** #### **a. VACUUM** * Reorganiza datos fragmentados y mejora la velocidad de lectura.VACUUM FULL ventas; #### **b. ANALYZE** * Actualiza las estadísticas de la tabla para optimizar el planificador de consultas.ANALYZE ventas; #### **c. DEEP COPY** * Realiza una copia profunda de tablas críticas para reorganizar los datos.CREATE TABLE ventas\_copy AS SELECT \* FROM ventas; DROP TABLE ventas; ALTER TABLE ventas\_copy RENAME TO ventas; ### **6. Índices y Optimización de Consultas** Aunque Redshift no utiliza índices tradicionales, puedes optimizar las consultas con: * **Llaves de ordenamiento:** Para reducir el escaneo de datos. * **Proyección de columnas:** Selecciona solo las columnas necesarias.SELECT cliente\_id, fecha FROM ventas WHERE fecha = '2025-01-01'; ### **7. Evitar Buenas Prácticas Comunes en Bases de Datos Relacionales** Redshift no es una base de datos relacional tradicional; evita: * Uso excesivo de normalización: Prioriza tablas desnormalizadas para evitar combinaciones costosas. * Inserciones individuales frecuentes: Utiliza cargas masivas con `COPY`.COPY ventas FROM 's3://mi-bucket/ventas.csv' IAM\_ROLE 'arn:aws:iam::123456789012:role/MyRedshiftRole' CSV; ### **8. Uso de Monitoreo y Ajuste** Monitorea las consultas para identificar cuellos de botella. * **Consultas más lentas:**SELECT query, starttime, endtime, substring FROM svl\_qlog WHERE aborted = 0 ORDER BY endtime - starttime DESC LIMIT 10; * **Tablas más usadas:**SELECT tbl, sum(scan\_count) AS scans FROM svv\_table\_info GROUP BY tbl ORDER BY scans DESC; ### Conclusión El diseño eficiente de tablas en Redshift requiere una planificación que tenga en cuenta la carga de trabajo y los patrones de consulta. Aplicando estas buenas prácticas, puedes garantizar un rendimiento óptimo y una experiencia más fluida con Redshift.

Es bueno resaltar que redshift permite definir restricciones más son solo informativas: "Las restricciones de unicidad, clave principal y clave externa son solo informativas, *Amazon Redshift* no las aplica al rellenar una tabla. Por ejemplo, si inserta datos en una tabla con dependencias, la inserción puede realizarse correctamente aunque infrinja la restricción. No obstante, las claves principales y externas se utilizan como sugerencias de planificación y deben estar declaradas si el proceso de Extract, Transform, Load (ETL, Extracción, transformación y carga) o algún otro proceso de su aplicación exige su integridad." <https://docs.aws.amazon.com/es_es/redshift/latest/dg/t_Defining_constraints.html>