Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Distribución de datos para la optimización de consultas Cuando carga datos en una tabla, Amazon Redshift distribuye las filas de la tabla a cada uno de los nodos de informática, en función del estilo de distribución de la tabla. Cuando ejecuta una consulta, el optimizador de consultas redistribuye las filas a los nodos de computación según se necesite para realizar combinaciones y agregaciones. El objetivo al elegir un estilo de distribución de tablas es reducir el impacto del paso de redistribución al localizar los datos en el lugar que deben estar antes de que se ejecute la consulta. **nota** En esta sección, se presentarán los principios de la distribución de datos en una base de datos de Amazon Redshift. Se recomienda que cree sus tablas con `DISTSTYLE AUTO`. De hacerlo así, Amazon Redshift utiliza la optimización automática de tablas para elegir el estilo de distribución de los datos. Para obtener más información, consulte [Optimización de tablas automática](t_Creating_tables.md). En el resto de esta sección, se proporcionan detalles sobre los estilos de distribución. **Topics** + [Conceptos de distribución de datos](#t_data_distribution_concepts) + [Estilos de distribución](c_choosing_dist_sort.md) + [Visualización de los estilos de distribución](viewing-distribution-styles.md) + [Evaluación de los patrones de consulta](t_evaluating_query_patterns.md) + [Designación de estilos de distribución](t_designating_distribution_styles.md) + [Evaluación del plan de consulta](c_data_redistribution.md) + [Ejemplo de plan de consulta](t_explain_plan_example.md) + [Ejemplos de distribución](c_Distribution_examples.md) ## Conceptos de distribución de datos A continuación, se exponen algunos conceptos de distribución de datos para Amazon Redshift. **Nodos y sectores** Un clúster de Amazon Redshift es un conjunto de nodos. Cada nodo del clúster tiene su propio sistema operativo, su propia memoria especializada y almacenamiento especializado en el disco. Hay un nodo que es el *nodo principal*, que administra la distribución de los datos y las tareas de procesamiento de consultas a los nodos de informática. Los *nodos de informática* proporcionan los recursos necesarios para realizar esas tareas. El almacenamiento en disco de un nodo de computación se divide en una serie de *sectores*. El número de sectores por nodo depende del tamaño de nodo del clúster. Todos los nodos participan en la ejecución de consultas en paralelo y trabajan en datos que se distribuyen de la manera más uniforme posible entre los sectores. Para obtener más información acerca de la cantidad de sectores que tiene cada tamaño de nodo, consulte [Acerca de clústeres y nodos](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) en la *Guía de administración de Amazon Redshift*. **Redistribución de datos** Cuando carga datos en una tabla, Amazon Redshift distribuye las filas de la tabla a cada uno de los sectores del nodo, en función del estilo de distribución de la tabla. Como parte de un plan de consulta, el optimizador determina dónde se deben ubicar los bloques de datos para ejecutar la consulta de la mejor manera. A continuación, los datos se mueven o se redistribuyen físicamente mientras se ejecuta la consulta. La redistribución puede implicar enviar filas específicas a los nodos para realizar una combinación, o bien para difundir una tabla entera a todos los nodos. La redistribución de datos puede representar una parte sustancial del costo de un plan de consulta y el tráfico de red que genera puede afectar otras operaciones de la base de datos y ralentizar el rendimiento general del sistema. En la medida en que pueda prever dónde conviene ubicar los datos inicialmente, puede reducir el impacto de la redistribución de datos. **Objetivos de la distribución de datos** Cuando carga datos en una tabla, Amazon Redshift distribuye las filas de la tabla a los nodos de informática y a los sectores, en función del estilo de distribución que se haya elegido al crearla. La distribución de datos tiene dos objetivos principales: + Distribuir la carga de trabajo de manera uniforme entre los nodos del clúster. Una distribución irregular, o un sesgo en la distribución de datos, exige que algunos nodos trabajen más que otros, lo que perjudica el rendimiento de las consultas. + Para minimizar el movimiento de datos durante la ejecución de una consulta. Si las filas que participan de uniones o de agregaciones ya están ubicadas junto a los nodos con las filas de las otras tablas con las que se unirán, el optimizador no necesita redistribuir tantos datos cuando se ejecutan las consultas. La estrategia de distribución que selecciona para su base de datos tiene consecuencias importantes en el rendimiento de la consulta, en los requisitos de almacenamiento, en la carga de datos y en el mantenimiento. Si selecciona el mejor estilo de distribución para cada tabla, puede equilibrar la distribución de sus datos y mejorar considerablemente el rendimiento general del sistema. # Estilos de distribución Cuando crea una tabla, puede designar uno de los siguientes estilos de distribución: AUTO, EVEN, KEY o ALL. Si no se especifica un estilo de distribución, Amazon Redshift usa la distribución AUTO. **Distribución AUTO** Con la distribución AUTO, Amazon Redshift asigna un estilo de distribución óptimo basado en el tamaño de los datos de la tabla. Por ejemplo, si se especifica el estilo de distribución AUTO, Amazon Redshift asigna inicialmente el estilo de distribución ALL a una tabla pequeña. Cuando la tabla crezca, Amazon Redshift podría cambiar el estilo de distribución a KEY y elegir la clave principal (o una columna de la clave primaria compuesta) como la clave de distribución. Si la tabla crece y ninguna de las columnas es adecuada para ser la clave de distribución, Amazon Redshift cambia el estilo de distribución a EVEN. El cambio en el estilo de distribución se produce en segundo plano y tiene un impacto mínimo en las consultas de los usuarios. Si desea consultar las acciones que Amazon Redshift realizó de forma automática para modificar la clave de distribución de una tabla, consulte [SVL\$1AUTO\$1WORKER\$1ACTION](r_SVL_AUTO_WORKER_ACTION.md). Si desea conocer las recomendaciones actuales relativas a la modificación de la clave de distribución de una tabla, consulte [SVV\$1ALTER\$1TABLE\$1RECOMMENDATIONS](r_SVV_ALTER_TABLE_RECOMMENDATIONS.md). Para ver el estilo de distribución aplicado a una tabla, consulte la vista de catálogo del sistema PG\$1CLASS\$1INFO. Para obtener más información, consulte [Visualización de los estilos de distribución](viewing-distribution-styles.md). Si no se especifica un estilo de distribución con la instrucción CREATE TABLE, Amazon Redshift aplica la distribución AUTO. **Distribución EVEN** El nodo principal distribuye las filas entre los sectores con un método de turnos rotativos, independientemente de los valores de cualquier columna en particular. La distribución EVEN resulta adecuada cuando una tabla no participa en las uniones. Además, resulta adecuada en los casos en que no hay una opción clara entre la distribución KEY y la distribución ALL. **Distribución KEY** Las filas se distribuyen según los valores de una columna. El nodo principal ubica juntos los valores que coinciden en el mismo sector del nodo. Si distribuye un par de tablas en las claves de unión, el nodo principal ubica las filas en los sectores según los valores de las columnas de unión. De este modo, los valores que coinciden de las columnas que tienen en común se almacenan juntos físicamente. **Distribución ALL** Se distribuye una copia de toda la tabla a cada nodo. Mientras que la distribución EVEN o la distribución KEY colocan solo una parte de las filas de la tabla en cada nodo, la distribución ALL garantiza que se coloque cada fila para cada combinación en la que participa la tabla. La distribución ALL multiplica el almacenamiento requerido por la cantidad de nodos del clúster, por lo que demanda más tiempo para cargar, actualizar o insertar datos en distintas tablas. La distribución ALL es adecuada solo para tablas con movimientos relativamente lentos, es decir tablas que no se actualizan con frecuencia ni de forma generalizada. Dado que el costo de redistribuir tablas pequeñas durante una consulta es bajo, no hay un beneficio significativo para definir tablas de dimensiones pequeñas como DISTSTYLE ALL. **nota** Una vez que haya especificado un estilo de distribución para una columna, Amazon Redshift se encarga de la distribución de datos en el nivel del clúster. Amazon Redshift no requiere ni admite el concepto de partición de datos dentro de los objetos de la base de datos. No es necesario crear espacios de tablas ni definir esquemas de partición para las tablas. En ciertas situaciones, puede cambiar el estilo de distribución de una tabla después de crearla. Para obtener más información, consulte [ALTER TABLE](r_ALTER_TABLE.md). En aquellas situaciones en las que no puede cambiar el estilo de distribución de una tabla después de crearla, puede volver a crear la tabla y rellenar la nueva tabla con una copia profunda. Para obtener más información, consulte [Realización de una copia profunda](performing-a-deep-copy.md) # Visualización de los estilos de distribución Para ver el estilo de distribución de una tabla, consulte la vista PG\$1CLASS\$1INFO o la vista SVV\$1TABLE\$1INFO. La columna RELEFFECTIVEDISTSTYLE en PG\$1CLASS\$1INFO indica el estilo de distribución actual de la tabla. Si la tabla usa una distribución automática, RELEFFECTIVEDISTSTYLE es 10, 11 o 12, lo que indica que el estilo de distribución efectivo es AUTO (ALL) o AUTO (EVEN) o AUTO (KEY). Si la tabla usa distribución automática, el estilo de distribución podría inicialmente mostrar AUTO (ALL), para a continuación mostrar AUTO (EVEN) o AUTO (KEY) cuando la tabla crezca. En la siguiente tabla, se proporciona el estilo de distribución para cada valor de la tabla RELEFFECTIVEDISTSTYLE: | RELEFFECTIVEDISTSTYLE | Estilo de distribución actual | | --- | --- | | 0 | EVEN | | 1 | KEY | | 8 | ALL | | 10 | AUTO (ALL) | | 11 | AUTO (EVEN) | | 12 | AUTO (KEY) | La columna DISTSTYLE en SVV\$1TABLE\$1INFO indica el estilo de distribución actual de la tabla. Si la tabla usa una distribución automática, DISTSTYLE es AUTO (ALL), AUTO (EVEN) o AUTO (KEY). En el siguiente ejemplo, se crean cuatro tablas usando los tres estilos de distribución y distribución automática, luego, se consulta la tabla SVV\$1TABLE\$1INFO para ver los estilos de distribución. ``` create table public.dist_key (col1 int) diststyle key distkey (col1); insert into public.dist_key values (1); create table public.dist_even (col1 int) diststyle even; insert into public.dist_even values (1); create table public.dist_all (col1 int) diststyle all; insert into public.dist_all values (1); create table public.dist_auto (col1 int); insert into public.dist_auto values (1); select "schema", "table", diststyle from SVV_TABLE_INFO where "table" like 'dist%'; schema | table | diststyle ------------+-----------------+------------ public | dist_key | KEY(col1) public | dist_even | EVEN public | dist_all | ALL public | dist_auto | AUTO(ALL) ``` # Evaluación de los patrones de consulta Seleccionar los estilos de distribución es solo un aspecto del diseño de la base de datos. Considere los estilos de distribución en el contexto de todo el sistema, equilibrando la distribución con otros factores importantes como el tamaño del clúster, los métodos de codificación de compresión, las claves de ordenación y las restricciones de tablas. Pruebe su sistema con datos que sean lo más próximos posibles a los datos reales. Para poder tomar buenas decisiones respecto a los estilos de distribución, debe comprender los patrones de consulta para su aplicación de Amazon Redshift. Identifique las consultas más costosas de su sistema y base el diseño inicial de su base de datos en las exigencias de esas consultas. Entre los factores que determinan el costo total de una consulta, se encuentran el tiempo de ejecución de esta y la cantidad de recursos de informática que consume. Asimismo, otros factores que determinan el costo de la consulta son la frecuencia con la que se ejecuta y el grado de interrupción que supone para las demás consultas y operaciones de la base de datos. Identifique las tablas que utilizan las consultas más costosas y evalúe su función en el tiempo de ejecución de las consultas. Tenga en cuenta cómo se combinan y agregan las tablas. Utilice las directrices de esta sección para seleccionar un estilo de distribución para cada tabla. Cuando lo haya hecho, cree las tablas y cárguelas con datos que sean lo más próximos posible a los reales. A continuación, pruebe las tablas para los tipos de consultas que prevé utilizar. Puede evaluar los planes de explicación de consultas para identificar oportunidades de ajuste. Compare los tiempos de carga, el espacio de almacenamiento y los tiempos de ejecución de las consultas para poder equilibrar los requisitos generales de su sistema. # Designación de estilos de distribución Las consideraciones y recomendaciones de esta sección para designar estilos de distribución utilizan un esquema Star como ejemplo. El diseño de la base de datos se debe basar en un esquema en estrella, en una variante de este esquema o en un esquema completamente diferente. Amazon Redshift está diseñado para funcionar de forma eficaz con cualquier diseño de esquema que elija. Los principios de esta sección se pueden aplicar a cualquier esquema de diseño. 1. **Especifique la clave principal y las claves externas de todas las tablas.** Amazon Redshift no impone restricciones de claves principales y externas, pero el optimizador de consultas las utiliza cuando genera planes de consulta. Si configura claves principales y externas, su aplicación debe conservar la validez de las claves. 1. **Distribuya la tabla de hechos y la tabla de mayor dimensión en sus columnas comunes.** Seleccione la tabla de mayor dimensión en función del tamaño del conjunto de datos que participa en la combinación más frecuente, no solo del tamaño de la tabla. Si hay una tabla que se filtra con frecuencia, con la cláusula WHERE, solo una parte de sus filas participan de la combinación. Dicha tabla tiene menos impacto en la redistribución que una tabla más pequeña que aporta más datos. Designe la clave principal de la tabla de dimensión y la clave externa correspondiente a la tabla de hechos como las claves DISTKEY. Si hay distintas tablas que usan la misma clave de distribución, también se ubican junto a la tabla de hechos. Su tabla de hechos solo puede tener una clave de distribución. Ninguna de las tablas que se unen a otra clave se ubica junto a la tabla de hechos. 1. **Designe las claves de distribución para las demás tablas de dimensión.** Distribuya las tablas en sus claves principales o externas, según cómo se combinan con mayor frecuencia con otras tablas. 1. **Valore si conviene cambiar algunas de las tablas de dimensión para utilizar la distribución ALL.** Si no se puede colocar una tabla de dimensión junto con la tabla de hechos u otra tabla de combinación de importancia, puede mejorar el rendimiento de las consultas de forma significativa distribuyendo la tabla completa a todos los nodos. El uso de la distribución ALL multiplica los requisitos de espacio de almacenamiento y aumenta los tiempos de carga y las operaciones de mantenimiento, por lo que debe analizar todos los factores antes de seleccionar la distribución ALL. En la siguiente sección, se explica cómo identificar posibles candidatos para la distribución ALL mediante una evaluación del plan EXPLAIN. 1. **Utilice la distribución AUTO para las tablas restantes.** Si una tabla se desnormaliza en gran parte y no participa en combinaciones o si no tiene una selección clara respecto a otro estilo de distribución, utilice la distribución AUTO. Para permitir a Amazon Redshift elegir el estilo de distribución adecuado, no especifique explícitamente un estilo de distribución. # 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\$1DIST\$1NONE** 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\$1DIST\$1NONE, la unión entre la tabla de hechos y una tabla de dimensión. **DS\$1DIST\$1ALL\$1NONE** 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\$1DIST\$1INNER** Se redistribuye la tabla interna. **DS\$1DIST\$1OUTER** Se redistribuye la tabla externa. **DS\$1BCAST\$1INNER** Se difunde una copia de toda la tabla interna a todos los nodos de computación. **DS\$1DIST\$1ALL\$1INNER** Se redistribuye toda la tabla interna a un único sector porque la tabla externa utiliza el atributo DISTSTYLE ALL. **DS\$1DIST\$1BOTH** Ambas tablas se redistribuyen. **DS\$1DIST\$1ERR** Cuando la tabla no tiene un estilo de distribución seleccionado. DS\$1DIST\$1NONE y DS\$1DIST\$1ALL\$1NONE son buenos indicadores. Indican que no fue necesario redistribuir para ese paso porque todas las combinaciones están ubicadas juntas. DS\$1DIST\$1INNER implica que el paso probablemente tiene un costo bastante alto debido a que se redistribuye la tabla interna a los nodos. DS\$1DIST\$1INNER 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\$1DIST\$1NONE. 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\$1DIST\$1ALL\$1INNER 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\$1BCAST\$1INNER y DS\$1DIST\$1BOTH 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\$1BCAST\$1INNER y DS\$1DIST\$1NONE. ``` -> 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\$1DIST\$1ALL\$1NONE en lugar de DS\$1BCAST\$1INNER. 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) ``` # Ejemplo de plan de consulta En este ejemplo, se muestra cómo evaluar un plan de consulta para encontrar oportunidades y optimización de las distribuciones. Ejecute la siguiente consulta con un comando EXPLAIN para producir un plan de consulta. ``` explain select lastname, catname, venuename, venuecity, venuestate, eventname, month, sum(pricepaid) as buyercost, max(totalprice) as maxtotalprice from category join event on category.catid = event.catid join venue on venue.venueid = event.venueid join sales on sales.eventid = event.eventid join listing on sales.listid = listing.listid join date on sales.dateid = date.dateid join users on users.userid = sales.buyerid group by lastname, catname, venuename, venuecity, venuestate, eventname, month having sum(pricepaid)>9999 order by catname, buyercost desc; ``` En la base de datos TICKIT, SALES es una tabla de hechos y LISTING la tabla de mayor dimensión. Para poder ubicar juntas las tablas, SALES se distribuye en LISTID, que es la clave externa para LISTING, y LISTING se distribuye en su clave principal, LISTID. En el siguiente ejemplo, se muestran los comandos CREATE TABLE para SALES y LISTING. ``` create table sales( salesid integer not null, listid integer not null distkey, sellerid integer not null, buyerid integer not null, eventid integer not null encode mostly16, dateid smallint not null, qtysold smallint not null encode mostly8, pricepaid decimal(8,2) encode delta32k, commission decimal(8,2) encode delta32k, saletime timestamp, primary key(salesid), foreign key(listid) references listing(listid), foreign key(sellerid) references users(userid), foreign key(buyerid) references users(userid), foreign key(dateid) references date(dateid)) sortkey(listid,sellerid); create table listing( listid integer not null distkey sortkey, sellerid integer not null, eventid integer not null encode mostly16, dateid smallint not null, numtickets smallint not null encode mostly8, priceperticket decimal(8,2) encode bytedict, totalprice decimal(8,2) encode mostly32, listtime timestamp, primary key(listid), foreign key(sellerid) references users(userid), foreign key(eventid) references event(eventid), foreign key(dateid) references date(dateid)); ``` En el siguiente plan de consulta, el paso de combinación de fusión para la combinación de SALES y LISTING muestra la etiqueta DS\$1DIST\$1NONE, que indica que no es necesario redistribuir en este paso. No obstante, si avanzamos en el plan de consulta, las otras combinaciones internas muestran la etiqueta DS\$1BCAST\$1INNER, que indica que la tabla interna se difunde como parte de la ejecución de la consulta. Como con la distribución de clave solo se pueden ubicar juntas un par de tablas, se deben volver a difundir cinco tablas. ``` QUERY PLAN XN Merge (cost=1015345167117.54..1015345167544.46 rows=1000 width=103) Merge Key: category.catname, sum(sales.pricepaid) -> XN Network (cost=1015345167117.54..1015345167544.46 rows=170771 width=103) Send to leader -> XN Sort (cost=1015345167117.54..1015345167544.46 rows=170771 width=103) Sort Key: category.catname, sum(sales.pricepaid) -> XN HashAggregate (cost=15345150568.37..15345152276.08 rows=170771 width=103) Filter: (sum(pricepaid) > 9999.00) -> XN Hash Join DS_BCAST_INNER (cost=742.08..15345146299.10 rows=170771 width=103) Hash Cond: ("outer".catid = "inner".catid) -> XN Hash Join DS_BCAST_INNER (cost=741.94..15342942456.61 rows=170771 width=97) Hash Cond: ("outer".dateid = "inner".dateid) -> XN Hash Join DS_BCAST_INNER (cost=737.38..15269938609.81 rows=170766 width=90) Hash Cond: ("outer".buyerid = "inner".userid) -> 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) -> XN Hash (cost=87.98..87.98 rows=8798 width=25) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=25) -> XN Hash (cost=2.02..2.02 rows=202 width=41) -> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=41) -> XN Hash (cost=499.90..499.90 rows=49990 width=14) -> XN Seq Scan on users (cost=0.00..499.90 rows=49990 width=14) -> XN Hash (cost=3.65..3.65 rows=365 width=11) -> XN Seq Scan on date (cost=0.00..3.65 rows=365 width=11) -> XN Hash (cost=0.11..0.11 rows=11 width=10) -> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=10) ``` Una solución es modificar las tablas para que tengan DISTSTYLE ALL. ``` ALTER TABLE users ALTER DISTSTYLE ALL; ALTER TABLE venue ALTER DISTSTYLE ALL; ALTER TABLE category ALTER DISTSTYLE ALL; ALTER TABLE date ALTER DISTSTYLE ALL; ALTER TABLE event ALTER DISTSTYLE ALL; ``` Ejecute nuevamente la misma consulta con el comando EXPLAIN y examine el plan de consulta nuevo. Las combinaciones ahora muestran la etiqueta DS\$1DIST\$1ALL\$1NONE, lo que indica que no es necesario redistribuir porque ya se distribuyeron los datos a cada nodo con el atributo DISTSTYLE ALL. ``` QUERY PLAN XN Merge (cost=1000000047117.54..1000000047544.46 rows=1000 width=103) Merge Key: category.catname, sum(sales.pricepaid) -> XN Network (cost=1000000047117.54..1000000047544.46 rows=170771 width=103) Send to leader -> XN Sort (cost=1000000047117.54..1000000047544.46 rows=170771 width=103) Sort Key: category.catname, sum(sales.pricepaid) -> XN HashAggregate (cost=30568.37..32276.08 rows=170771 width=103) Filter: (sum(pricepaid) > 9999.00) -> XN Hash Join DS_DIST_ALL_NONE (cost=742.08..26299.10 rows=170771 width=103) Hash Cond: ("outer".buyerid = "inner".userid) -> XN Hash Join DS_DIST_ALL_NONE (cost=117.20..21831.99 rows=170766 width=97) Hash Cond: ("outer".dateid = "inner".dateid) -> XN Hash Join DS_DIST_ALL_NONE (cost=112.64..17985.08 rows=170771 width=90) Hash Cond: ("outer".catid = "inner".catid) -> 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) -> XN Hash (cost=87.98..87.98 rows=8798 width=25) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=25) -> XN Hash (cost=2.02..2.02 rows=202 width=41) -> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=41) -> XN Hash (cost=0.11..0.11 rows=11 width=10) -> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=10) -> XN Hash (cost=3.65..3.65 rows=365 width=11) -> XN Seq Scan on date (cost=0.00..3.65 rows=365 width=11) -> XN Hash (cost=499.90..499.90 rows=49990 width=14) -> XN Seq Scan on users (cost=0.00..499.90 rows=49990 width=14) ``` # Ejemplos de distribución En los siguientes ejemplos, se muestra cómo se distribuyeron los datos según las opciones que definió en la instrucción CREATE TABLE. ## Ejemplos de DISTKEY Observe el esquema de la tabla USERS en la base de datos TICKIT. USERID se define como la columna SORTKEY y la columna DISTKEY: ``` select "column", type, encoding, distkey, sortkey from pg_table_def where tablename = 'users'; column | type | encoding | distkey | sortkey ---------------+------------------------+----------+---------+--------- userid | integer | none | t | 1 username | character(8) | none | f | 0 firstname | character varying(30) | text32k | f | 0 ... ``` USERID es una buena opción para la columna de distribución de esta tabla. Si consulta la vista de sistema SVV\$1DISKUSAGE, puede ver que la tabla está bien distribuida de manera uniforme. Los números de las columnas comienzan con cero, por lo que USERID es la columna 0. ``` select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage where name='users' and col=0 and rows>0 order by slice, col; slice| col | rows | minvalue | maxvalue -----+-----+-------+----------+---------- 0 | 0 | 12496 | 4 | 49987 1 | 0 | 12498 | 1 | 49988 2 | 0 | 12497 | 2 | 49989 3 | 0 | 12499 | 3 | 49990 (4 rows) ``` La tabla tiene 49 990 filas. En la columna rows (num\$1values), se ve que cada sector tiene, aproximadamente, la misma cantidad de filas. En las columnas minvalue y maxvalue, se ve el rango de valores en cada sector. Cada sector incluye prácticamente todo el rango de valores, por lo que es muy probable que todos los sectores participen de la ejecución de una consulta que filtre en busca de un rango de ID de usuarios. En este ejemplo, se muestra la distribución en un sistema pequeño de prueba. Por lo general, la cantidad total de sectores es mucho mayor. Si suele hacer combinaciones o agrupaciones con la columna STATE, puede seleccionar distribuir en la columna STATE. En el siguiente ejemplo, se muestra un caso en el que se crea una tabla nueva con los mismos datos que la tabla USERS, pero se establece DISTKEY en la columna STATE. En este caso, la distribución no es tan uniforme. El sector 0 (13 587 filas) dispone, aproximadamente, de un 30 % más de filas que el sector 3 (10 150 filas). En una tabla mucho más grande, este nivel de sesgo de distribución puede tener un impacto negativo en el procesamiento de las consultas. ``` create table userskey distkey(state) as select * from users; select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage where name = 'userskey' and col=0 and rows>0 order by slice, col; slice | col | rows | minvalue | maxvalue ------+-----+-------+----------+---------- 0 | 0 | 13587 | 5 | 49989 1 | 0 | 11245 | 2 | 49990 2 | 0 | 15008 | 1 | 49976 3 | 0 | 10150 | 4 | 49986 (4 rows) ``` ## Ejemplo de DISTSTYLE EVEN Si crea una nueva tabla con los mismos datos que la tabla USERS, pero configura DISTSTYLE como EVEN, las filas siempre se distribuyen de manera uniforme en todos los sectores. ``` create table userseven diststyle even as select * from users; select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage where name = 'userseven' and col=0 and rows>0 order by slice, col; slice | col | rows | minvalue | maxvalue ------+-----+-------+----------+---------- 0 | 0 | 12497 | 4 | 49990 1 | 0 | 12498 | 8 | 49984 2 | 0 | 12498 | 2 | 49988 3 | 0 | 12497 | 1 | 49989 (4 rows) ``` No obstante, como la distribución no está basada en una columna específica, el procesamiento de consultas puede empeorar, en especial si la tabla se combina con otras tablas. La falta de distribución en una columna de combinación suele influir en el rendimiento del tipo de operación de combinación por ejecutar. Las operaciones de combinación, agregación y agrupamiento están optimizadas cuando se distribuyen y ordenan ambas tablas en sus respectivas columnas de combinación. ## Ejemplo de DISTSTYLE ALL Si crea una tabla nueva con los mismos datos que la tabla USERS, pero configura DISTSTYLE como ALL, todas las filas se distribuyen al primer sector de cada nodo. ``` select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage where name = 'usersall' and col=0 and rows > 0 order by slice, col; slice | col | rows | minvalue | maxvalue ------+-----+-------+----------+---------- 0 | 0 | 49990 | 4 | 49990 2 | 0 | 49990 | 2 | 49990 (4 rows) ```