Amazon Redshift dejará de admitir la creación de UDF de Python después del 30 de junio de 2026. Empezaremos a aplicarlo por fases. Para obtener más información sobre los detalles del fin de vida de Python y las opciones de migración, consulte la entrada del blog
Mejora del rendimiento de las consultas
A continuación, se describen algunos problemas frecuentes que afectan al rendimiento de las consultas de Amazon Redshift y se detallan instrucciones acerca de cómo diagnosticarlos y resolverlos.
Temas
Faltan estadísticas de tablas o están desactualizadas
Si faltan estadísticas de tablas o si estas están desactualizadas, es posible que vea lo siguiente:
-
Un mensaje de advertencia en los resultados del comando EXPLAIN.
-
Un evento de alerta en STL_ALERT_EVENT_LOG que indica que faltan estadísticas. Para obtener más información, consulte Revisión de alertas de consultas.
Para reparar este problema, ejecute el comando ANALYZE.
Bucle anidado
Si hay un bucle anidado, es posible que vea un evento de alerta de bucle anidado en STL_ALERT_EVENT_LOG. También puede identificar este tipo de evento si ejecuta la consulta en Identificación de consultas con bucles anidados. Para obtener más información, consulte Revisión de alertas de consultas.
Para reparar esto, asegúrese de que su consulta no tenga combinaciones cruzadas o elimínelas de ser posible. Las combinaciones cruzadas son combinaciones sin una condición de combinación que dan lugar a un producto cartesiano de dos tablas. Por lo general, se ejecutan como uniones de bucles anidados, que son los tipos de unión posibles más lentos.
Combinación hash
Si hay una combinación hash, es posible que vea lo siguiente:
-
Operaciones hash y hash join en el plan de consulta. Para obtener más información, consulte Análisis del plan de consulta.
-
Un paso HJOIN en el segmento con el valor máximo de maxtime en SVL_QUERY_SUMMARY. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.
Para reparar este problema, puede optar por varios métodos:
-
Reescribir la consulta para usar una combinación de fusión de ser posible. Puede hacerlo si especifica cuáles son las columnas de combinación que son claves de distribución y claves de ordenación al mismo tiempo.
-
Si el paso HJOIN en SVL_QUERY_SUMMARY tiene un valor muy elevado en el campo rows en comparación con el valor de rows en el paso final RETURN de la consulta, compruebe si puede volver a escribir la consulta para combinarla en una única columna. Cuando una consulta no se combina en una única columna, como en el caso de una clave principal, aumenta la cantidad de filas involucradas en la combinación.
Filas fantasma o filas sin confirmar
Si hay filas fantasma o filas sin confirmar, es posible que vea un evento de alerta en STL_ALERT_EVENT_LOG que indique que hay demasiadas filas fantasma. Para obtener más información, consulte Revisión de alertas de consultas.
Para reparar este problema, puede optar por varios métodos:
-
Revise la pestaña Loads (Cargas) de la consola de Amazon Redshift para ver si hay operaciones de carga activas en cualquiera de las tablas de consultas. Si ve operaciones de carga activas, espere a que se completen antes de realizar cualquier medida.
-
Si no hay operaciones de carga activas, ejecute el comando VACUUM en las tablas de la consulta para quitar las filas eliminadas.
Filas desordenadas o mal ordenadas
Si hay filas desordenadas o mal ordenadas, es posible que vea un evento de alerta de filtro muy selectivo en STL_ALERT_EVENT_LOG. Para obtener más información, consulte Revisión de alertas de consultas.
También puede controlar si alguna de las tablas de su consulta tiene grandes áreas desordenadas si ejecuta la consulta en Identificación de tablas con sesgo de datos o con filas desordenadas.
Para reparar este problema, puede optar por varios métodos:
-
Ejecute el comando VACUUM en las tablas de la consulta para reordenar las filas.
-
Revise las claves de ordenación en las tablas de consulta para ver si puede hacer alguna mejora. Recuerde comparar el rendimiento de esta consulta con el rendimiento de otras consultas importantes y con el sistema en general antes de implementar cualquier cambio. Para obtener más información, consulte Claves de clasificación.
Distribución de datos poco óptima
Si la distribución de datos no es la óptima, es posible que vea lo siguiente:
-
Aparecerá un evento de alerta de ejecución en serie, difusión o distribución de gran tamaño en STL_ALERT_EVENT_LOG. Para obtener más información, consulte Revisión de alertas de consultas.
-
Los sectores no están procesando aproximadamente la misma cantidad de filas en un paso determinado. Para obtener más información, consulte Uso de la vista SVL_QUERY_REPORT.
-
Los sectores no están tardando aproximadamente el mismo tiempo en un paso determinado. Para obtener más información, consulte Uso de la vista SVL_QUERY_REPORT.
Si ninguna de las opciones anteriores es verdadera, también puede controlar si alguna de las tablas de su consulta tiene un sesgo en sus datos mediante la ejecución de la consulta en Identificación de tablas con sesgo de datos o con filas desordenadas.
Para solucionar este problema, consulte los estilos de distribución de las tablas de la consulta y determine si se puede hacer alguna mejora. Recuerde comparar el rendimiento de esta consulta con el rendimiento de otras consultas importantes y con el sistema en general antes de implementar cualquier cambio. Para obtener más información, consulte Distribución de datos para la optimización de consultas.
Memoria insuficiente asignada a la consulta
Cuando una consulta necesita más memoria de la que tiene asignada, Amazon Redshift escribe el exceso de resultados intermedios en el disco. Esto se llama derrame en el disco. Amazon Redshift escribe primero los datos filtrados en el disco local y, si superan la capacidad del disco local, los datos se desbordan en Amazon S3. Los pasos de consulta más frecuentes son las uniones mediante hash, las agregaciones (como GROUP BY y DISTINCT), las funciones de ventana y las ordenaciones (ORDER BY) en conjuntos de datos de gran tamaño.
El volcado en el disco ralentiza la consulta que se vierte, ya que el acceso al disco es mucho más lento que a la memoria. Como el disco local y el ancho de banda de E/S se comparten en todo el clúster, un volcado excesivo también puede ralentizar la ejecución de otras consultas al mismo tiempo. Al reducir el volcado, se mejora tanto la latencia de las consultas individuales como el rendimiento general del clúster.
Identifique las consultas que se desbordan. Consulte SYS_QUERY_DETAIL y revise las columnas spilled_block_local_disk y spilled_block_remote_disk. Las consultas con un valor spilled_block_remote_disk alto se extienden más allá del disco local y son las que más se benefician del ajuste. En un clúster aprovisionado, también puede revisar la métrica query_temp_blocks_to_disk en SVL_QUERY_METRICS_SUMMARY.
Cómo reducir el volcado en el disco
-
Reducción del volumen de datos intermedios. Filtre con antelación, seleccione solo las columnas que necesite y agréguelas previamente siempre que sea posible para que haya menos filas que se conviertan en uniones, agregaciones y clasificaciones.
-
Divida las consultas grandes en pasos. Materialice los resultados intermedios en tablas temporales (CREATE TEMP TABLE AS) para que cada paso se ejecute ocupando menos espacio en la memoria y sea menos probable que se desperdicie. Proporcione a la tabla temporal una distribución adecuada y clave de clasificación y ejecute ANALYZE para que los pasos posteriores se ejecuten de manera eficiente.
-
Dele más memoria a la consulta aumentando temporalmente su número de ranuras si utiliza WLM manual (consulte wlm_query_slot_count).
-
Agregue nodos o muévase a un tipo de nodo más grande cuando sea inevitable que el volumen de datos se desborde.
Supervise el volcado de forma proactiva. Cree una regla de supervisión de consultas (QMR) en la métrica query_temp_blocks_to_disk. Esta métrica mide el espacio temporal en disco utilizado para los resultados intermedios, en bloques de 1 MB. A continuación, elija una acción:
- registro
-
Registra la consulta para su revisión.
- abort
-
Detiene la consulta antes de que su extensión degrade otras cargas de trabajo.
Por ejemplo, query_temp_blocks_to_disk > 100000 (unos 100 GB) registra o anula las consultas que exceden cantidades inusualmente grandes. Ajuste el umbral al clúster o grupo de trabajo. En un clúster aprovisionado, configure QMR a través de las colas de WLM. En Redshift sin servidor, configúrelo mediante los límites de consultas de grupos de trabajo. Para obtener más información, consulte Reglas de monitoreo de consultas de WLM.
Cláusula WHERE poco óptima
Si su cláusula WHERE genera demasiados exámenes de tablas, es posible que vea un paso SCAN en el segmento con el valor máximo de maxtime en SVL_QUERY_SUMMARY. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.
Para reparar este problema, añada una cláusula WHERE a la consulta basada en la columna de ordenación principal de la tabla más grande. Este enfoque ayuda a reducir el tiempo de análisis. Para obtener más información, consulte Prácticas recomendadas de Amazon Redshift para el diseño de tablas.
Predicado poco restrictivo
Si su consulta tiene un predicado poco restrictivo, es posible que vea un paso SCAN en el segmento con el valor más alto de maxtime en SVL_QUERY_SUMMARY que tenga un valor de rows muy elevado, en comparación con el valor de rows en el paso final RETURN de la consulta. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.
Para reparar este problema, añada un predicado a la consulta o haga que el predicado existente sea más restrictivo para acotar la salida.
Conjunto de resultados muy grande
Si la consulta devuelve un conjunto de resultados muy grande, considere la posibilidad de reescribirla de forma que utilice UNLOAD para escribir los resultados en Amazon S3. Este método mejora el rendimiento del paso RETURN, ya que aprovecha el procesamiento en paralelo. Para obtener más información acerca de cómo controlar si hay conjuntos de resultados muy grandes, consulte Uso de la vista SVL_QUERY_SUMMARY.
Lista SELECT grande
Si su consulta tiene una lista SELECT excepcionalmente grande, es probable que vea un valor de bytes elevado, en comparación con el valor de rows en cualquier paso (con relación a otros pasos) en SVL_QUERY_SUMMARY. Este valor elevado de bytes puede indicar que está seleccionando muchas columnas. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.
Para reparar este problema, revise las columnas que está seleccionando y vea si se pueden eliminar.
