Evaluación del plan de consulta - Amazon Redshift

Evaluación del plan de consulta

Puede utilizar planes de consulta para identificar candidatos para optimizar el estilo de distribución.

Después de tomar las primeras decisiones de diseño, cree sus tablas, cárguelas con datos y pruébelas. Utilice un conjunto de datos de prueba que sean lo más próximos posibles a los datos reales. Mida los tiempos de carga para utilizarlos como referencia para establecer comparaciones.

Evalúe las consultas que son representativas de las consultas más costosas que prevé ejecutar, específicamente aquellas que usan uniones y agregaciones. Compare los tiempos de ejecución de las diferentes opciones de diseño. Cuando compare los tiempos de ejecución, no tenga en cuenta la primera vez que se ejecuta la consulta, ya que el tiempo de la primera ejecución incluye el tiempo de compilación.

DS_DIST_NONE

No es necesario redistribuir porque los sectores correspondientes se ubican junto a los nodos de computación. Por lo general, solo tiene un paso DS_DIST_NONE, la unión entre la tabla de hechos y una tabla de dimensión.

DS_DIST_ALL_NONE

No es necesario redistribuir, porque la tabla de combinación interna utilizó el atributo DISTSTYLE ALL. Se ubica la tabla entera en cada nodo.

DS_DIST_INNER

Se redistribuye la tabla interna.

DS_DIST_OUTER

Se redistribuye la tabla externa.

DS_BCAST_INNER

Se difunde una copia de toda la tabla interna a todos los nodos de computación.

DS_DIST_ALL_INNER

Se redistribuye toda la tabla interna a un único sector porque la tabla externa utiliza el atributo DISTSTYLE ALL.

DS_DIST_BOTH

Ambas tablas se redistribuyen.

DS_DIST_NONE y DS_DIST_ALL_NONE son buenos indicadores. Indican que no fue necesario redistribuir para ese paso porque todas las combinaciones están ubicadas juntas.

DS_DIST_INNER implica que el paso probablemente tiene un costo bastante alto debido a que se redistribuye la tabla interna a los nodos. DS_DIST_INNER indica que la tabla externa ya está distribuida correctamente en la clave de combinación. Configure la clave de distribución de la tabla interna con la clave de combinación para convertirla en DS_DIST_NONE. En algunos casos, no es posible distribuir la tabla interna en la clave de unión dado que la tabla externa no está distribuida en la clave de unión. En este caso, se debe evaluar la posibilidad de utilizar la distribución ALL para la tabla interna. Si la tabla no se actualiza con frecuencia ni de forma generalizada, y tiene el tamaño suficiente para asumir un costo elevado de redistribución, se debe cambiar el estilo de distribución por ALL y volver a realizar la prueba. La distribución ALL genera un aumento en los tiempos de carga, por lo que cuando vuelva a hacer la prueba debe incluir el tiempo de carga en los factores de evaluación.

DS_DIST_ALL_INNER no es un buen indicador. Significa que la tabla interna completa se redistribuyó a un único sector debido a que la tabla externa usa DISTSTYLE ALL, por lo que se coloca una copia de la tabla externa completa en cada nodo. Esto genera un tiempo de ejecución en serie ineficaz de la combinación en un único nodo, en lugar de sacar provecho del tiempo de ejecución en paralelo utilizando todos los nodos. DISTSTYLE ALL está diseñado para utilizarse solo para la tabla de combinación interna. En lugar de ese atributo, especifique una clave de distribución o utilice una distribución uniforme para la tabla externa.

DS_BCAST_INNER y DS_DIST_BOTH no son bueno indicadores. Por lo general, estas redistribuciones ocurren porque las tablas no están combinadas en sus claves de distribución. Si la tabla de hechos aún no tiene una clave de distribución, especifique la columna de combinación como la clave de distribución para ambas tablas. Si la tabla de hechos ya tiene una clave de distribución en otra columna, debe evaluar si cambiar la clave de distribución para ubicar esta unión mejorará el rendimiento general. Si cambiar la clave de distribución de la tabla externa no es la mejor opción, puede lograr que se ubique mediante la especificación DISTSTYLE ALL para la tabla interna.

En el siguiente ejemplo, se muestra una parte de un plan de consulta con etiquetas DS_BCAST_INNER y DS_DIST_NONE.

-> XN Hash Join DS_BCAST_INNER (cost=112.50..3272334142.59 rows=170771 width=84) Hash Cond: ("outer".venueid = "inner".venueid) -> XN Hash Join DS_BCAST_INNER (cost=109.98..3167290276.71 rows=172456 width=47) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30) Merge Cond: ("outer".listid = "inner".listid) -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)

Después de cambiar las tablas de dimensión para usar DISTSTYLE ALL, el plan de consulta para la misma consulta muestra DS_DIST_ALL_NONE en lugar de DS_BCAST_INNER. Además, hay un cambio drástico en el costo relativo de los pasos de combinación. El coste total es 14142.59 en comparación con 3272334142.59 de la consulta anterior.

-> XN Hash Join DS_DIST_ALL_NONE (cost=112.50..14142.59 rows=170771 width=84) Hash Cond: ("outer".venueid = "inner".venueid) -> XN Hash Join DS_DIST_ALL_NONE (cost=109.98..10276.71 rows=172456 width=47) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30) Merge Cond: ("outer".listid = "inner".listid) -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)