Recomendaciones de Amazon Redshift Advisor - Amazon Redshift

Recomendaciones de Amazon Redshift Advisor

Amazon Redshift Advisor ofrece recomendaciones sobre cómo optimizar el clúster de Amazon Redshift para mejorar el rendimiento y ahorrarse costos operativos. Puede encontrar explicaciones sobre cada recomendación en la consola, tal y como se describe anteriormente. Encontrará más detalles sobre estas recomendaciones en las secciones siguientes.

Comprimir objetos de archivos de Amazon S3 cargados con COPY

El comando COPY aprovecha la arquitectura del procesamiento masivo en paralelo (MPP) de Amazon Redshift para leer y cargar datos en paralelo. Puede leer archivos de Amazon S3, tablas de DynamoDB y texto generado en uno o más alojamientos remotos.

Cuando cargue grandes cantidades de datos, es muy recomendable ejecutar el comando COPY para cargar archivos de datos comprimidos desde S3. Comprimir grandes conjuntos de datos ahorra tiempo al cargar los archivos a Amazon S3. COPY también puede acelerar el proceso de carga al descomprimir los archivos a medida que se leen.

Análisis

Los comandos COPY de ejecución prolongada que cargan grandes conjuntos de datos sin comprimir a menudo tienen la oportunidad de mejorar el rendimiento considerablemente. El análisis de Advisor identifica los comandos COPY que cargan grandes conjuntos de datos sin comprimir. En dicho caso Advisor genera una recomendación para comprimir los archivos de origen en Amazon S3.

Recomendación

Asegúrese de que cada COPY que cargue una cantidad significativa de datos o se ejecute durante un periodo de tiempo significativo consuma objetos de datos comprimidos desde Amazon S3. Puede identificar los comandos COPY que cargan grandes conjuntos de datos sin comprimir desde Amazon S3 ejecutando el comando SQL siguiente como superusuario.

SELECT wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files, ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs, ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb, SUBSTRING(querytxt,1,60) copy_sql FROM stl_s3client s JOIN stl_query q USING (query) JOIN stl_wlm_query wq USING (query) WHERE s.userid>1 AND http_method = 'GET' AND POSITION('COPY ANALYZE' IN querytxt) = 0 AND aborted = 0 AND final_state='Completed' GROUP BY 1, 2, 3, 7 HAVING SUM(transfer_size) = SUM(data_size) AND SUM(transfer_size)/(1024*1024) >= 5 ORDER BY 6 DESC, 5 DESC;

Si los datos transitorios permanecen en Amazon S3 después de cargarlos, lo que es habitual en las arquitecturas de lago de datos, almacenar estos datos de forma comprimida puede reducir los costos de almacenamiento.

Consejos de implementación

  • El tamaño ideal de los objetos está comprendido entre 1 MB y 128 MB después de la compresión.

  • Puede comprimir archivos con formato gzip, lzop o bzip2.

Aislar varias bases de datos activas

Como práctica recomendada, es conveniente aislar entre sí las bases de datos en Amazon Redshift. Las consultas se ejecutan en una base de datos específica y no pueden obtener acceso a datos de otras bases de datos del clúster. No obstante, las consultas que ejecute en todas las bases de datos de un clúster comparten el mismo espacio de almacenamiento de clúster y los mismos recursos de computación subyacentes. Cuando un único clúster contiene varias bases de datos activas es habitual que sus cargas de trabajo no estén relacionadas.

Análisis

El análisis de Advisor revisa todas las bases de datos del clúster para detectar cargas de trabajo activas que se ejecutan al mismo tiempo. Si hay cargas de trabajo activas ejecutándose al mismo tiempo, Advisor genera una recomendación para considerar la migración de las bases de datos a clústeres independientes de Amazon Redshift.

Recomendación

Estudie la posibilidad de trasladar cada una de las bases de datos en las que se realizan consultas activas a un clúster exclusivo independiente. El uso de un clúster independiente puede reducir la contención de recursos y mejorar el rendimiento de las consultas. Esto se consigue porque permite establecer el tamaño de cada clúster en función de las necesidades de almacenamiento, costo y rendimiento de cada carga de trabajo. Asimismo, las cargas de trabajo no relacionadas a menudo se benefician de configuraciones de administración de cargas de trabajo diferentes.

Para identificar qué bases de datos se usan activamente puede ejecutar este comando de SQL como superusuario.

SELECT database, COUNT(*) as num_queries, AVG(DATEDIFF(sec,starttime,endtime)) avg_duration, MIN(starttime) as oldest_ts, MAX(endtime) as latest_ts FROM stl_query WHERE userid > 1 GROUP BY database;

Consejos de implementación

  • Dado que un usuario tiene que conectarse con cada base de datos específicamente, y las consultas solo pueden obtener acceso a una única base de datos, el traslado de las bases de datos a clústeres independientes tiene repercusiones mínimas sobre los usuarios.

  • Una opción para trasladar una base de datos consiste en seguir los pasos siguientes:

    1. Restaure temporalmente una instantánea del clúster actual en un clúster del mismo tamaño.

    2. Elimine todas las bases de datos del nuevo clúster salvo la base de datos de destino que va a trasladar.

    3. Cambie el tamaño del clúster a un tipo de nodo y un recuento apropiados para la carga de trabajo de la base de datos.

Reasignar memoria de administración de la carga de trabajo (WLM)

Amazon Redshift dirige las consultas de los usuarios a Implementación de WLM manual para su procesamiento. La administración de cargas de trabajo (WLM) define el modo en que esas consultas se dirigen a las colas. Amazon Redshift asigna a cada cola una parte de la memoria disponible del clúster. La memoria de una cola se divide entre los slots de consultas de la cola.

Cuando se configura una cola con más ranuras de las necesarias para la carga de trabajo, la memoria asignada a dichas ranuras sin utilizar se infrautiliza. Si se reduce el número de ranuras configuradas para que se adapte a los requisitos de carga de trabajo punta, se redistribuirá la memoria infrautilizada a las ranuras activas y, como consecuencia, el rendimiento de las consultas mejora.

Análisis

El análisis de Advisor revisa los requisitos de simultaneidad de carga de trabajo para identificar las colas de consulta que tienen ranuras sin utilizar. Advisor genera una recomendación para reducir el número de ranuras de una cola cuando encuentra lo siguiente:

  • Una cola con ranuras que están completamente inactivas durante todo el análisis.

  • Una cola con más de cuatro ranuras con dos ranuras como mínimo inactivas durante todo el análisis.

Recomendación

Si se reduce el número de ranuras configuradas para que se adapte a los requisitos de carga de trabajo punta, se redistribuirá la memoria infrautilizada a las ranuras activas. Considere reducir el número de ranuras configuradas en el caso de las colas en las que las ranuras nunca se han utilizado plenamente. Para identificar dichas colas puede comparar los requisitos de ranuras por hora máximos de cada cola ejecutando el siguiente comando de SQL como superusuario.

WITH generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)), apex AS ( SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots FROM (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count FROM stl_wlm_query wq JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5) JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt) WHERE wq.userid > 1 AND wq.service_class > 5) iq GROUP BY iq.dt, iq.service_class, iq.num_query_tasks), maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots from apex group by apex.service_class, apex.dt, date_part(h,apex.dt)) SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots FROM apex JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots) GROUP BY apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h ORDER BY apex.service_class, maxes.d, maxes.dt_h;

La columna max_service_class_slots representa la cantidad máxima de ranuras de consulta de WLM en la cola de consulta de dicha hora. Si hay colas infrautilizadas, implemente la optimización de reducción de slots mediante la modificación de un grupo de parámetros, tal como se describe en la Guía de administración de Amazon Redshift.

Consejos de implementación

  • Si el volumen de su carga de trabajo es altamente variable, asegúrese de que el análisis capturó un periodo de utilización máxima. Si no capturó dicho periodo, ejecute el SQL anterior varias veces para supervisar los requisitos de simultaneidad máximos.

  • Para obtener detalles acerca de cómo interpretar los resultados de la consulta del código SQL anterior, consulte wlm_apex_hourly.sql script en GitHub.

Omitir el análisis de compresión durante la ejecución de COPY

Cuando carga datos en una tabla vacía con codificación de compresión que se declara con el comando COPY, Amazon Redshift aplica la compresión del almacenamiento. Esta optimización permite asegurarse de que los datos del clúster se almacenan de forma eficiente incluso cuando los cargan usuarios finales. El análisis necesario para aplicar una compresión puede requerir una cantidad significativa de tiempo.

Análisis

El análisis de Advisor busca si hay operaciones COPY que se hayan retrasado debido al análisis de compresión automático. El análisis determina las codificaciones de compresión muestreando los datos mientras estos se cargan. Este muestreo es similar al que ejecuta el comando ANALYZE COMPRESSION.

Cuando carga datos como parte de un proceso estructurado como, por ejemplo, un lote ETL (extracción, transformación, carga) de un día para el otro, puede definir previamente la compresión. También puede optimizar las definiciones de tabla para omitir esta fase permanentemente sin que tenga repercusiones negativas.

Recomendación

Para mejorar la capacidad de respuesta de COPY omitiendo la fase de análisis de compresión, implemente una de las dos opciones siguientes:

  • Use el parámetro ENCODE de columna cuando cree tablas que cargue usando el comando COPY.

  • Desactive la compresión suministrando el parámetro COMPUPDATE OFF en el comando COPY.

Normalmente la mejor solución consiste en usar la codificación de columnas durante la creación de la tabla, ya que este enfoque permite mantener el beneficio de almacenar los datos comprimidos en disco. Puede usar el comando ANALYZE COMPRESSION para sugerir codificaciones de compresión, pero tiene que volver a crear la tabla para aplicar estas codificaciones. Para automatizar este proceso, puede usar la utilidad AWSColumnEncodingUtility que se encuentra en GitHub.

Para identificar operaciones de COPY recientes que iniciaron el análisis de compresión automático, ejecute el comando de SQL siguiente.

WITH xids AS ( SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 AND querytxt = 'analyze compression phase 1' GROUP BY xid INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1) SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, a.copy_sec, a.copy_sql FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) starttime, substring(querytxt,1,100) as copy_sql, ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec FROM stl_query q JOIN xids USING (xid) WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') AND querytxt not like 'COPY ANALYZE %') a LEFT JOIN (SELECT xid, ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec FROM stl_query q JOIN xids USING (xid) WHERE (querytxt like 'COPY ANALYZE %' OR querytxt like 'analyze compression phase %') GROUP BY xid ) b ON a.xid = b.xid WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;

Consejos de implementación

  • Asegúrese de que todas las tablas de tamaño significativo creadas durante sus procesos de ETL (por ejemplo, tablas provisionales y tablas temporales) declaren una codificación de compresión para todas las columnas salvo para la primera clave de ordenación.

  • Calcule el tamaño del tipo de vida previsto de la tabla que se está cargando para cada uno de los comandos COPY que el comando de SQL anterior identifica. Si está convencido de que la tabla será muy pequeña, deshabilite la compresión junto con el parámetro COMPUPDATE OFF. O bien cree la tabla con una compresión explícita antes de cargarla con el comando COPY.

Dividir los objetos de Amazon S3 cargados con COPY

El comando COPY aprovecha la arquitectura del procesamiento masivo en paralelo (MPP) de Amazon Redshift para leer y cargar datos de los archivos de Amazon S3. El comando COPY carga datos desde archivos múltiples en paralelo y divide, así, la carga de trabajo entre los nodos de su clúster. Para conseguir un rendimiento óptimo es muy recomendable que divida los datos en distintos archivos para aprovechar los beneficios del procesamiento en paralelo.

Análisis

El análisis de Advisor identifica los comandos COPY que cargan grandes conjuntos de datos contenidos en un pequeño número de archivos almacenados en Amazon S3. Los comandos COPY de ejecución prolongada que cargan grandes conjuntos de datos a partir de unos cuantos archivos a menudo tienen la oportunidad de mejorar el rendimiento considerablemente. Cuando Advisor detecta que estos comandos COPY necesitan una cantidad considerable de tiempo, crea una recomendación para aumentar el paralelismo dividiendo los datos en archivos adicionales en Amazon S3.

Recomendación

En este caso le recomendamos las siguientes acciones, enumeradas en orden de prioridad:

  1. Optimice los comandos COPY que carguen menos archivos que el número de nodos de clúster.

  2. Optimice los comandos COPY que carguen menos archivos que el número de sectores del clúster.

  3. Optimice los comandos de COPY donde el número de archivos no sea un múltiplo del número de sectores del clúster.

Algunos comandos COPY cargan una cantidad de datos significativa o se ejecutan durante una cantidad de tiempo significativa. Para estos comandos, le recomendamos que cargue una cantidad de objetos de datos de Amazon S3 que sea equivalente a un múltiplo del número de sectores del clúster. Para identificar cuántos objetos S3 ha cargado cada comando COPY, ejecute el siguiente código SQL como superusuario.

SELECT query, COUNT(*) num_files, ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs, ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb, SUBSTRING(querytxt,1,60) copy_sql FROM stl_s3client s JOIN stl_query q USING (query) JOIN stl_wlm_query wq USING (query) WHERE s.userid>1 AND http_method = 'GET' AND POSITION('COPY ANALYZE' IN querytxt) = 0 AND aborted = 0 AND final_state='Completed' GROUP BY query, querytxt HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2 ORDER BY CASE WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1 WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2 ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices)) END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;

Consejos de implementación

  • El número de sectores de un nodo depende del tamaño de nodo del clúster. Para obtener más información acerca de la cantidad de sectores en los diversos tipos de nodos, consulte Clústeres y nodos de Amazon Redshift en la Guía de administración de Amazon Redshift.

  • Puede cargar varios archivos especificando un prefijo común o el prefijo de clave del conjunto, o enumerando explícitamente los archivos en un archivo de manifiesto. Para obtener más información acerca de cómo cargar archivos, consulte Carga de datos desde archivos comprimidos y sin comprimir.

  • Amazon Redshift no tiene en cuenta el tamaño de los archivos a la hora de dividir la carga de trabajo. Divida los archivos de datos de carga de modo tal que sean de igual tamaño, entre 1 MB y 1 GB, después de la compresión.

Actualizar estadísticas de tablas

Amazon Redshift usa un optimizador de consultas basado en el costo para elegir el mejor plan de ejecución de consultas. El cálculo de costos se basa en las estadísticas de tabla reunidas al ejecutar el comando ANALYZE. Cuando faltan estadísticas o están obsoletas, la base de datos puede elegir un plan que sea menos eficiente para ejecutar la consulta, especialmente en el caso de las consultas complejas. Mantener las estadísticas actuales ayuda a que las consultas complejas se ejecuten en la menor cantidad de tiempo posible.

Análisis

El análisis de Advisor realiza el seguimiento de las tablas que carecen de estadísticas o cuyas estadísticas se han quedado obsoletas. Revisa los metadatos de acceso a la tabla asociados a consultas complejas. Si las tablas a las que se accede con frecuencia con patrones complejos carecen de estadísticas, Advisor crea una recomendación crítica para ejecutar ANALYZE. Si las tablas a las que se accede con frecuencia con patrones complejos tienen estadísticas obsoletas, Advisor crea una recomendación sugerida para ejecutar ANALYZE.

Recomendación

Cuando el contenido de una tabla cambia significativamente, actualice las estadísticas con ANALYZE. Recomendamos que ejecute ANALYZE siempre que se cargue un número significativo de filas de datos nuevas en una tabla ya existente con los comandos COPY o INSERT. También recomendamos ejecutar ANALYZE siempre que se modifique un número significativo de filas con los comandos UPDATE o DELETE. Para identificar las tablas que carecen de estadísticas o cuyas estadísticas están obsoletas, ejecute el siguiente comando de SQL como superusuario. Los resultados se ordenan de la tabla más grande a la más pequeña.

Para identificar las tablas que carecen de estadísticas o cuyas estadísticas están obsoletas, ejecute el siguiente comando de SQL como superusuario. Los resultados se ordenan de la tabla más grande a la más pequeña.

SELECT ti.schema||'.'||ti."table" tablename, ti.size table_size_mb, ti.stats_off statistics_accuracy FROM svv_table_info ti WHERE ti.stats_off > 5.00 ORDER BY ti.size DESC;

Consejos de implementación

El umbral de ANALYZE predeterminado está establecido en 10 por ciento. Este valor predeterminado significa que el comando ANALYZE omite una tabla si menos del 10 por ciento de las filas de la tabla han cambiado desde la última vez que se ejecutó este comando. Por lo tanto puede escoger ejecutar comandos ANALYZE al final de cada proceso ETL. Adoptar este enfoque significa que ANALYZE se omite con frecuencia, aunque también garantiza que se ejecutará cuando sea necesario.

Las estadísticas de ANALYZE tienen su máxima repercusión en las columnas que se usan en uniones (por ejemplo JOIN tbl_a ON col_b) o como predicados (por ejemplo WHERE col_b = 'xyz'). De forma predeterminada ANALYZE recopila estadísticas de todas las columnas de la tabla especificada. Si es preciso, puede reducir el tiempo necesario para ejecutar ANALYZE ejecutando ANALYZE solo en las columnas donde tenga más repercusión. Puede ejecutar el siguiente comando de SQL para identificar las columnas usadas como predicados. También puede dejar que Amazon Redshift elija las columnas que deben analizarse mediante la especificación de ANALYZE PREDICATE COLUMNS.

WITH predicate_column_info as ( SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num, a.attname as col_name, CASE WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||') WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||') WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||') ELSE NULL::varchar END AS pred_ts FROM pg_statistic s JOIN pg_class c ON c.oid = s.starelid JOIN pg_namespace ns ON c.relnamespace = ns.oid JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum) SELECT schema_name, table_name, col_num, col_name, pred_ts NOT LIKE '2000-01-01%' AS is_predicate, CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use, CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze FROM predicate_column_info;

Para obtener más información, consulte Análisis de tablas.

Habilitar aceleración de consultas cortas

La aceleración de consultas cortas (SQA) da prioridad a una serie de consultas seleccionadas que se ejecutan rápidamente frente a consultas que tardan más en ejecutarse. SQA ejecuta las consultas cortas en un espacio dedicado, de forma que estas consultas no tienen que esperar en las colas detrás de otras consultas más largas. SQA solamente da prioridad a las consultas de corta ejecución y a las consultas que están en una cola definida por el usuario. Con SQA, las consultas cortas se ejecutan con mayor rapidez y los usuarios tardan menos en ver los resultados.

Si activa SQA, puede reducir o eliminar las colas de administración de cargas de trabajo (WLM) dedicadas a las consultas cortas. Además, las consultas de larga ejecución no necesitan competir con las consultas cortas por los slots de las colas, por lo que las colas de WLM se pueden configurar para que utilicen menos slots de consulta. Si se utiliza una simultaneidad más baja, el rendimiento de las consultas aumenta y el rendimiento de todo el sistema mejora con la mayoría de las cargas de trabajo. Para obtener más información, consulte Trabajo con aceleración de consultas cortas.

Análisis

Advisor comprueba los patrones de carga de trabajo y emite un informe con el número de consultas recientes sonde SQA debería reducir la latencia y el tiempo de cola diario para las consultas aptas para SQA.

Recomendación

Modifique la configuración de WLM para activar la aceleración de consultas cortas (SQA). Amazon Redshift utiliza un algoritmo de machine learning para analizar cada una de las consultas que reúnan los requisitos necesarios. Las predicciones mejoran, ya que SQA va aprendiendo de los patrones de consulta. Para obtener más información, consulte Configuración de la carga de trabajo.

Si se activa SQA, WLM establece en dynamic el tiempo de ejecución máximo de las consultas cortas de forma predeterminada. Le recomendamos que mantenga este valor para definir el tiempo de ejecución máximo de SQA.

Consejos de implementación

Para comprobar si la aceleración de consultas cortas (SQA) está activada, ejecute la consulta siguiente. Si la consulta devuelve una fila, SQA está habilitado.

select * from stv_wlm_service_class_config where service_class = 14;

Para obtener más información, consulte Monitorización de SQA.

Claves de distribución modificadas en tablas

Amazon Redshift distribuye las filas de las tablas en todo el clúster según el estilo de distribución de la tabla. Las tablas con distribución KEY requieren una columna como la clave de distribución (DISTKEY). Una fila de tablas se asigna a un sector del nodo de un clúster en función del valor de su columna DISTKEY.

Una DISTKEY adecuada coloca un número similar de filas en cada sector del nodo y es referenciado con frecuencia en las condiciones de combinación. Una combinación optimizada ocurre cuando las tablas se unen en las columnas DISTKEY, acelerando el rendimiento de la consulta.

Análisis

Advisor analiza la carga de trabajo de su clúster para identificar la clave de distribución más apropiada para las tablas que pueden beneficiarse de forma significativa de un estilo de distribución KEY.

Recomendación

Advisor da a ALTER TABLE instrucciones que alteran el DISTSTYLE y la DISTKEY de una tabla en función de su análisis. Para conseguir un beneficio de rendimiento significativo, asegúrese de que todas las instrucciones SQL dentro de un grupo de recomendaciones se implementan.

Redistribuir una tabla grande con ALTER TABLE consume recursos del clúster y requiere un bloqueo temporal de tablas en varios tiempos. Implemente cada grupo de recomendación cuando la carga de trabajo de los otros clústeres sea ligera. Puede encontrar más detalles sobre cómo optimizar las propiedades de distribución de las tablas en la publicación de blog Amazon Redshift Engineering's Advanced Table Design Playbook: Distribution Styles and Distribution Keys.

Para más información sobre ALTER DISTSTYLE y DISTKEY, vea ALTER TABLE.

nota

Si no ve una recomendación no significa necesariamente que los estilos de distribución actuales sean los más apropiados. Advisor no proporciona recomendaciones cuando no hay suficientes datos o el beneficio esperado de la redistribución es pequeño.

Las recomendaciones de Advisor se aplican a una tabla particular y no se aplican necesariamente a una tabla que contiene una columna con el mismo nombre. Las tablas que comparten un nombre de columna pueden tener distintas características para dichas columnas, excepto si los datos contenidos en las tablas son los mismos.

Si ve recomendaciones para tablas de ensayo que son creadas o abandonadas por trabajos de ETL, modifique sus procesos ETL para utilizar las claves de distribución recomendadas de Advisor.

Modificar las claves de ordenación en tablas

Amazon Redshift ordena las filas de la tabla según la clave de ordenación de la tabla. Las filas de la tabla se ordenan en función de los valores de columna de la clave de ordenación.

Ordenar una tabla por una clave de ordenación adecuada puede acelerar el rendimiento de las consultas, especialmente aquellas con predicados que tienen intervalos restringidos, al requerir que se lean menos bloques de tabla desde el disco.

Análisis

Advisor analiza la carga de trabajo del clúster durante varios días para identificar una clave de ordenación beneficiosa para las tablas.

Recomendación

Advisor proporciona dos grupos de instrucciones ALTER TABLE que modifican la clave de ordenación de una tabla en función de su análisis:

  • Instrucciones que alteran una tabla que actualmente no tiene una clave de ordenación para agregar una clave de ordenación COMPOUND.

  • Instrucciones que alteran una clave de ordenación de INTERLEAVED a COMPOUND o ninguna clave de ordenación.

    El uso de claves ordenación compuestas reduce de forma significativa la sobrecarga de mantenimiento. Las tablas con claves de ordenación compuestas no necesitan las caras operaciones VACUUM REINDEX que son necesarias para las ordenaciones intercaladas. En la práctica, las claves de ordenación compuestas son más efectivas que las claves de ordenación intercaladas para la gran mayoría de las cargas de trabajo de Amazon Redshift. No obstante, si una tabla es pequeña, es más eficiente no tener una clave de ordenación para evitar la sobrecarga del almacenamiento de claves de ordenación.

Al ordenar una tabla grande con ALTER TABLE, se consumen recursos de clúster y se requieren bloqueos de tabla en varios momentos. Implemente cada recomendación cuando la carga de trabajo de un clúster sea moderada. Podrá encontrar más detalles sobre cómo optimizar las configuraciones de las claves de ordenación de las tablas en la publicación de blog Amazon Redshift Engineering's Advanced Table Design Playbook: Compound and Interleaved Sort Keys.

Para obtener más información acerca de ALTER SORTKEY, consulte ALTER TABLE.

nota

Si no ve una recomendación para una tabla, eso no significa necesariamente que la configuración actual sea la mejor. Advisor no proporciona recomendaciones cuando no hay suficientes datos o el beneficio esperado de la ordenación es pequeño.

Las recomendaciones de Advisor se aplican a una tabla en particular y no se aplican necesariamente a una tabla que contiene una columna con el mismo nombre y tipo de datos. Las tablas que comparten nombres de columna pueden tener diferentes recomendaciones en función de los datos de las tablas y de la carga de trabajo.

Modificar las codificaciones de compresión en columnas

La compresión es una operación que se produce en el nivel de las columnas que reduce el tamaño de los datos cuando se almacenan. La compresión se utiliza en Amazon Redshift para ahorrar espacio de almacenamiento y mejorar el rendimiento de las consultas mediante la reducción de la cantidad de operaciones E/S en el disco. Recomendamos una codificación de compresión óptima para cada columna en función de su tipo de datos y sus patrones de consulta. Con una compresión óptima, las consultas pueden ejecutarse de manera más eficiente, y la base de datos puede ocupar la menor cantidad de espacio de almacenamiento posible.

Análisis

Advisor realiza de manera continua análisis de la carga de trabajo y el esquema de la base de datos del clúster para identificar la codificación de compresión óptima que corresponde a cada columna de la tabla.

Recomendación

Advisor proporciona instrucciones ALTER TABLE que modifican la codificación de compresión de determinadas columnas en función de su análisis.

Cambiar las codificaciones de compresión de las columnas con ALTER TABLE consume recursos del clúster y requiere bloqueos en las tablas en distintos momentos. Es mejor implementar las recomendaciones cuando no es pesada la carga de trabajo del clúster.

Como referencia, Ejemplos de ALTER TABLE muestra varias instrucciones que cambian la codificación de una columna.

nota

Advisor no proporciona recomendaciones cuando no hay suficientes datos ni cuando es pequeño el beneficio que se espera del cambio en la codificación.

Recomendaciones de tipos de datos

Amazon Redshift tiene una biblioteca de tipos de datos SQL para varios casos de uso. Estos incluyen tipos enteros como INT y tipos para almacenar personajes, como VARCHAR. Redshift almacena los tipos de forma optimizada para proporcionar un acceso rápido y un buen rendimiento de las consultas. Además, Redshift proporciona funciones para tipos específicos, que se pueden utilizar para dar formato o realizar cálculos en los resultados de las consultas.

Análisis

Advisor realiza análisis de la carga de trabajo y el esquema de la base de datos del clúster de manera continua para identificar columnas que pueden beneficiarse considerablemente de un cambio de tipos de datos.

Recomendación

Advisor proporciona una instrucción ALTER TABLE que agrega una nueva columna con el tipo de datos sugerido. Una instrucción UPDATE asociada copia los datos de la columna existente en la nueva columna. Después de crear la columna y cargar los datos, cambie las consultas y los scripts de ingesta para acceder a la nueva columna. A continuación, utilice las características y funciones especializadas en el nuevo tipo de datos, que se encuentra en Referencia de funciones SQL.

Copiar los datos existentes en la nueva columna puede llevar tiempo. Le recomendamos que implemente cada recomendación de Advisor cuando la carga de trabajo del clúster sea ligera. Consulte la lista de tipos de datos disponibles en Tipos de datos.

Tenga en cuenta que Advisor no proporciona recomendaciones cuando no hay suficientes datos ni cuando es pequeño el beneficio que se espera del cambio en el tipo de datos.