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/). # Limpieza de tablas Amazon Redshift puede ordenar y realizar una operación VACUUM DELETE de forma automática en las tablas en segundo plano. Para limpiar las tablas tras una carga o una serie de actualizaciones incrementales, también puede ejecutar el comando [VACUUM](r_VACUUM_command.md), ya sea en la base de datos completa o en tablas individuales. **nota** Solo los usuarios con los permisos de tabla necesarios pueden vaciar una tabla de forma eficaz. Si se ejecuta VACUUM sin los privilegios de tabla necesarios, la operación se completa correctamente pero no tiene ningún efecto. Para obtener una lista de los permisos de tabla válidos para ejecutar VACUUM de forma eficaz, consulte [VACUUM](r_VACUUM_command.md). Por esta razón, recomendamos realizar una limpieza de tablas individual según sea necesario. También recomendamos esta opción porque es probable que una limpieza de la base de datos completa sea una operación costosa. ## Clasificación automática de tablas Amazon Redshift ordena los datos en segundo plano de forma automática para mantener los datos de la tabla en el orden de su clave de ordenación. Amazon Redshift realiza un seguimiento de sus consultas de análisis para determinar las secciones de la tabla que se beneficiarán de la ordenación. Amazon Redshift también realiza un seguimiento de las consultas de análisis de los clústeres que escalan de forma simultánea. En el caso de arquitecturas de varios clústeres que utilizan el uso compartido de datos de Amazon Redshift, Amazon Redshift también rastrea las consultas de análisis que se originan en los clústeres o grupos de trabajo de consumidores de la malla de datos, incluidos los clústeres/grupos de trabajo de diferentes regiones. Las estadísticas de análisis del clúster principal, los clústeres de escalado simultáneos y los clústeres de los consumidores se agregan para determinar qué secciones de la tabla se beneficiarán de la ordenación. Según la carga en el sistema, Amazon Redshift inicia de forma automática la ordenación. La ordenación automática disminuye la necesidad de ejecutar el comando VACUUM para mantener los datos en orden de clave de ordenación. Si necesita que los datos estén ordenados en clave de ordenación, por ejemplo después de una gran carga de datos, puede ejecutar manualmente el comando VACUUM. Para determinar si su tabla se beneficia al ejecutar VACUUM SORT, monitorice la columna `vacuum_sort_benefit` en [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Amazon Redshift realiza un seguimiento de las consultas de análisis que utilizan la clave de ordenación en cada tabla. Amazon Redshift calcula el porcentaje máximo de mejora al analizar y filtrar los datos de cada tabla (si la tabla estaba completamente ordenada). Esta estimación está visible en la columna `vacuum_sort_benefit` en [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Puede utilizar esta columna junto con la columna `unsorted` para determinar si las consultas pueden beneficiarse de la ejecución manual de VACUUM SORT en una tabla. La columna `unsorted` refleja el orden de clasificación físico de una tabla. La columna `vacuum_sort_benefit` especifica el impacto que tiene ordenar una tabla mediante la ejecución de VACUUM SORT de forma manual. Por ejemplo, fíjese en la consulta siguiente: ``` select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1; ``` ``` table | unsorted | vacuum_sort_benefit -------+----------+--------------------- sales | 85.71 | 5.00 event | 45.24 | 67.00 ``` Para la tabla “sales”, aunque la tabla está físicamente desordenada un 86 %, la repercusión del rendimiento de la consulta de la tabla estando desordenada un 86 % es de solo un 5 %. Esto puede ser porque solo se puede acceder a una pequeña parte de la tabla por consultas o porque muy pocas consultas accedieron a la tabla. Para la tabla “event”, la tabla está desordenada físicamente un 45 %. Pero la repercusión del rendimiento de la consulta de un 67 % indica que se puede acceder a una gran parte de la tabla por consultas o que la cantidad de consultas que accedieron a la tabla fue grande. La tabla “event” se puede beneficiar potencialmente de ejecutar VACUUM SORT. ## Eliminación de limpieza automática Cuando se realiza una eliminación, las filas se marcan para eliminarse, pero esto no sucede. Amazon Redshift ejecuta de forma automática una operación VACUUM DELETE en segundo plano en función de la cantidad de filas eliminadas en las tablas de base de datos. Amazon Redshift programa la operación VACUUM DELETE para que se ejecute durante periodos de carga reducida y pone en pausa la operación durante periodos de carga elevada. **Topics** + [Clasificación automática de tablas](#automatic-table-sort) + [Eliminación de limpieza automática](#automatic-table-delete) + [Frecuencia de ejecución de VACUUM](#vacuum-frequency) + [Fase de ordenación y fase de fusión](#vacuum-stages) + [Umbral de limpieza](#vacuum-sort-threshold) + [Tipos de limpieza](#vacuum-types) + [Cómo minimizar los tiempos de limpieza](vacuum-managing-vacuum-times.md) ## Frecuencia de ejecución de VACUUM Debe limpiar con tanta frecuencia como sea necesario para mantener un rendimiento de consultas coherente. Al determinar con cuánta frecuencia debe ejecutar el comando VACUUM, considere los siguientes factores: + Ejecute VACUUM durante periodos en los que espera actividad mínima en el clúster, como por la noche o durante ventanas de administración de la base de datos designadas. + Ejecute los comandos VACUUM fuera de los periodos de mantenimiento. Para obtener más información, consulte [Programación de periodos de mantenimiento](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html). + Una región grande sin ordenar da como resultado tiempos de limpieza más prolongados. Si retrasa la limpieza, esta demorará más porque se necesitará reorganizar más datos. + VACUUM es una operación con muchas E/S, por lo que cuanto más demore en completarse la limpieza, más efecto tendrá sobre las consultas simultáneas y otras operaciones de base de datos que se ejecuten en su clúster. + VACUUM demora más en tablas con ordenación intercalada. Para evaluar si las tablas intercaladas necesitan reordenarse, consulte la vista [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). ## Fase de ordenación y fase de fusión Amazon Redshift realiza una operación de limpieza en dos fases: primero, ordena las filas de la región no ordenada y, luego, de ser necesario, fusiona las filas recién ordenadas con las filas ya existentes en el final de la tabla. Al limpiar una tabla grande, la operación de limpieza avanza en una serie de pasos que consisten en ordenaciones incrementales seguidas de fusiones. Si se produce un error en la operación o si Amazon Redshift se desconecta durante una limpieza, la tabla o la base de datos limpiada de forma parcial se encontrarán en estado consistente, pero debe reiniciar la operación de limpieza de forma manual. Las ordenaciones incrementales se pierden, pero las filas fusionadas confirmadas antes del error no necesitar limpiarse de nuevo. Si la región sin ordenar es grande, el tiempo perdido podría ser significativo. Para obtener más información acerca de las fases de ordenación y fusión, consulte [Reducción del volumen de filas fusionadas](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows). Los usuarios pueden obtener acceso a las tablas mientras se limpian. Puede realizar consultas y escribir operaciones mientras se limpia una tabla, pero cuando se ejecutan DML y una limpieza de manera simultánea, ambas operaciones podrían demorar más de lo usual. Si se ejecutan las instrucciones UPDATE y DELETE durante una limpieza, el rendimiento del sistema podría reducirse. Las fusiones incrementales bloquean temporalmente las operaciones UPDATE y DELETE simultáneas, y estas últimas, a su vez, bloquean temporalmente los pasos de fusión incrementales en las tablas afectadas. Las operaciones DDL, como ALTER TABLE, se bloquean hasta que la operación de limpieza finaliza con la tabla. **nota** Hay varios modificadores de VACUUM que controlan la forma en que funciona. Puede utilizarlos para adaptar la operación de limpieza a las necesidades actuales. Por ejemplo, el uso de VACUUM RECLUSTER acorta la operación de limpieza, ya que no se realiza una operación de fusión completa. Para obtener más información, consulte [VACUUM](r_VACUUM_command.md). ## Umbral de limpieza De manera predeterminada, VACUUM omite la fase de ordenación para cualquier tabla que tenga más del 95 por ciento de las filas de la tabla ordenadas. La omisión de la fase de ordenación puede mejorar significativamente el rendimiento de VACUUM. Para cambiar el umbral de ordenación predeterminado de una tabla única, incluya el nombre de la tabla y el parámetro TO *threshold (umbral)* PERCENT cuando ejecute el comando VACUUM. ## Tipos de limpieza Para obtener más información acerca de los distintos tipos de limpieza, consulte [VACUUM](r_VACUUM_command.md). # Cómo minimizar los tiempos de limpieza Amazon Redshift ordena los datos de forma automática y ejecuta VACUUM DELETE en segundo plano. Esto disminuye la necesidad de ejecutar el comando VACUUM. La limpieza es un proceso que puede durar mucho tiempo. Según la naturaleza de los datos, le recomendamos las siguientes prácticas para minimizar los tiempos de limpieza. **Topics** + [Decisión de si se debe reindexar](#r_vacuum-decide-whether-to-reindex) + [Reducción del tamaño de la región no ordenada](#r_vacuum_diskspacereqs) + [Reducción del volumen de filas fusionadas](#vacuum-managing-volume-of-unmerged-rows) + [Carga de los datos en orden de clave de clasificación](#vacuum-load-in-sort-key-order) + [Uso de tablas de series temporales para reducir los datos almacenados](#vacuum-time-series-tables) ## Decisión de si se debe reindexar A menudo puede mejorar de manera significativa el rendimiento de consultas al usar un estilo de ordenación intercalada, pero, con el tiempo, el rendimiento podría degradarse si cambia la distribución de los valores en las columnas con claves de ordenación. Cuando inicialmente se carga una tabla intercalada vacía mediante COPY o CREATE TABLE AS, Amazon Redshift crea el índice intercalado de forma automática. Si carga inicialmente una tabla intercalada mediante INSERT, necesita ejecutar VACUUM REINDEX a continuación para inicializar el índice intercalado. Con el tiempo, a medida que agrega filas con valores de clave de ordenación nuevos, el rendimiento podría degradarse si cambia la distribución de los valores en las columnas con claves de ordenación. Si las filas nuevas caen principalmente dentro del rango de los valores de clave de ordenación existentes, la reindexación no es necesaria. Ejecute VACUUM SORT ONLY o VACUUM FULL para restaurar el orden de ordenación. El motor de consultas puede usar el orden de ordenación para seleccionar de manera eficiente qué bloques de datos deben analizarse para procesar una consulta. En caso de una ordenación intercalada, Amazon Redshift analiza los valores en las columnas con clave de ordenación para determinar el orden óptimo. Si la distribución de los valores de clave cambia o se sesga a medida que se agregan filas, la estrategia de ordenación ya no será óptima y el beneficio en rendimiento brindado por la ordenación se degradará. Para volver a analizar la distribución de claves de ordenación se puede ejecutar VACUUM REINDEX. La operación de reindexación lleva mucho tiempo; en consecuencia, para decidir si una tabla se beneficiará de una reindexación, ejecute una consulta en la vista [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). Por ejemplo, la siguiente consulta muestra los detalles de las tablas que usan claves de ordenación intercalada. ``` select tbl as tbl_id, stv_tbl_perm.name as table_name, col, interleaved_skew, last_reindex from svv_interleaved_columns, stv_tbl_perm where svv_interleaved_columns.tbl = stv_tbl_perm.id and interleaved_skew is not null; tbl_id | table_name | col | interleaved_skew | last_reindex --------+------------+-----+------------------+-------------------- 100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45 100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45 100072 | part | 0 | 1.65 | 2015-04-22 22:05:45 100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45 (4 rows) ``` El valor de `interleaved_skew` es una relación que indica el grado de sesgo. Un valor de 1 indica que no existe sesgo. Si el sesgo es mayor que 1,4, VACUUM REINDEX usualmente mejorará el rendimiento a menos que el sesgo en el conjunto subyacente sea inherente. Puede usar el valor de fecha en `last_reindex` para determinar cuánto tiempo ha pasado desde la última reindexación. ## Reducción del tamaño de la región no ordenada La región no ordenada aumenta cuando se cargan grandes cantidades de datos nuevos en tablas que ya tienen datos o cuando no se limpian las tablas como parte de las operaciones de mantenimiento de rutina. Para evitar las operaciones de limpieza prolongadas, aplique las siguientes prácticas: + Ejecutar las operaciones de limpieza según un programa regular. Si carga tablas en incrementos pequeños (como actualizaciones diarias que representan un bajo porcentaje de la cantidad total de filas de la tabla), el ejecutar VACUUM con regularidad lo ayudará a asegurarse de que las operaciones de limpieza individuales se realicen con rapidez. + Ejecutar la carga más grande primero. Si necesita cargar una tabla nueva con distintas operaciones COPY, ejecute la carga más grande primero. Cuando se ejecuta una carga inicial en una tabla nueva o truncada, todos los datos se cargan directamente en la región ordenada, por lo que no se requiere limpieza alguna. + Truncar una tabla en lugar de eliminar todas las filas. Eliminar las filas de una tabla no recupera el espacio que estas ocupaban sino hasta que se realiza una operación de limpieza; no obstante, el truncar una tabla la vacía y recupera el espacio en el disco, por lo que no se requiere limpieza alguna. De manera alternativa, elimine la tabla y recréela. + Truncar o eliminar las tablas de prueba. Si carga una cantidad pequeña de filas en una tabla con fines de prueba, no elimine las filas una vez que termine. En cambio, trunque la tabla y vuelva a cargar las filas como parte de la operación de carga de producción subsecuente. + Realizar una copia profunda. Si una tabla que usa una tabla con clave de ordenación compuesta tiene una región no ordenada grande, una copia profunda es mucho más rápida que una limpieza. Una copia profunda recrea y vuelve a completar una tabla mediante una operación de inserción masiva, que vuelve a ordenar la tabla de manera automática. Si una tabla tiene una gran región no ordenada, una copia profunda es mucho más rápida que una limpieza. La diferencia es que durante una operación de copia profunda no se pueden hacer actualizaciones simultáneas, lo cual sí puede hacerse durante una limpieza. Para obtener más información, consulte [Prácticas recomendadas de Amazon Redshift para el diseño de consultas](c_designing-queries-best-practices.md). ## Reducción del volumen de filas fusionadas Si una operación de limpieza necesita fusionar filas nuevas en la región ordenada de una tabla, el tiempo requerido para una limpieza aumentará a medida que la tabla aumente. Puede mejorar el rendimiento de la limpieza al reducir la cantidad de filas que deben fusionarse. Antes de una limpieza, una tabla consta de una región ordenada en la parte superior, seguida de una región no ordenada que aumenta cada vez que se agregan o actualizan filas. Cuando se agrega un conjunto de filas mediante una operación COPY, el conjunto nuevo de filas se ordena en la clave de ordenación a medida que se agrega a la región no ordenada que se encuentra al final de la tabla. Las filas nuevas se ordenan dentro de su propio conjunto, pero no dentro de la región no ordenada. En el siguiente diagrama, se ilustra la región no ordenada luego de dos operaciones COPY sucesivas, donde la clave de ordenación es CUSTID. Para mayor simpleza, en este ejemplo se muestra una clave de ordenación compuesta, pero los mismos principios se aplican a las claves de ordenación intercaladas, excepto que, para las tablas intercaladas, el impacto de la región no ordenada es mayor. ![\[Una tabla sin clasificar que contiene los registros de dos operaciones COPY.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-unsorted-region.png) Una operación de limpieza restaura el orden de la tabla en dos fases: 1. Ordena la región no ordenada en una región recién ordenada. La primera fase es relativamente poco costosa, porque solo se rescribe la región no ordenada. Si el rango de valores de clave de clasificación de la región recién ordenada es mayor que el rango existente, solo se deben rescribir las filas nuevas y la limpieza se completa. Por ejemplo, si la región ordenada tiene valores de ID de 1 a 500 y las operaciones de copia subsecuentes agregan valores de clave mayores que 500, solo se debe rescribir la región no ordenada. 1. Fusiona la región recién ordenada con la región anteriormente ordenada. Si las claves de la región recién ordenada se superponen con las claves de la región ordenada, VACUUM necesita fusionar las filas. Desde el comienzo de la región recién ordenada (en la clave de ordenación más baja), la limpieza escribe las filas fusionadas de las regiones anteriormente y recién ordenadas en un nuevo conjunto de bloques. El grado de superposición del nuevo rango de claves de ordenación en relación con las claves de ordenación existentes determina hasta dónde es necesario rescribir la región antes ordenada. Si las claves no ordenadas se encuentran esparcidas por todo el rango de ordenación existente, podría necesitarse una limpieza que rescriba partes de la tabla. En el siguiente diagrama, se muestra cómo una limpieza ordenaría y fusionaría las filas agregadas a una tabla en la que CUSTID es la clave de ordenación. Como cada operación de COPY agrega un nuevo conjunto de filas con valores de clave que se superponen con las claves existentes, se debe rescribir casi toda la tabla. En el diagrama, se muestra una única ordenación y fusión, pero, en la práctica, una operación de limpieza grande consiste en una serie de pasos incrementales de ordenación y fusión. ![\[Una operación VACCUM en la tabla de ejemplo en dos pasos. Primero se ordenan las nuevas filas y, a continuación, se fusionan con las filas existentes.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png) Si el rango de las claves de ordenación en un conjunto de filas nuevas se superpone con el rango de claves existentes, el costo de la fase de fusión continúa aumentando de manera proporcional al tamaño de la tabla, a medida que la tabla aumenta mientras el costo de la fase de ordenación se mantiene proporcional al tamaño de la región no ordenada. En tal caso, el costo de la fase de fusión supera el costo de la fase de ordenación, como lo muestra el diagrama a continuación. ![\[Diagrama que muestra cómo la etapa de fusión se vuelve más costosa cuando las filas nuevas tienen claves de clasificación superpuestas a las filas existentes.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-example-merge-region-grows.png) Para determinar qué proporción de una tabla se volvió a fusionar, ejecute una consulta SVV\$1VACUUM\$1SUMMARY una vez terminada la operación de limpieza. La siguiente consulta muestra el efecto de seis limpiezas consecutivas, a medida que CUSTSALES aumenta cada vez más con el paso del tiempo. ``` select * from svv_vacuum_summary where table_name = 'custsales'; table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_ | | partitions | increments | time | delta | delta | delta | partitions -----------+------+------------+------------+------------+-------+------------+---------+--------------- custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47 custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47 custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47 custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47 custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47 custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47 (6 rows) ``` La columna merge\$1increments indica la cantidad de datos fusionados en cada operación de limpieza. Si la cantidad de incrementos de fusión durante las limpiezas consecutivas aumenta de manera proporcional al crecimiento en el tamaño de la tabla, indica que cada operación de limpieza vuelve a fusionar una cantidad cada vez mayor de filas en la tabla, debido a que las regiones ordenadas ya existentes y las nuevas se superponen. ## Carga de los datos en orden de clave de clasificación Si carga los datos en orden de clave de clasificación mediante un comando COPY, es posible que reduzca o incluso elimine la necesidad de ejecutar una limpieza. COPY agrega automáticamente filas nuevas a la región ordenada de la tabla cuando se satisfacen todas las siguientes condiciones: + La tabla usa una clave de ordenación compuesta con solo una columna de ordenación. + La columna de ordenación es NOT NULL. + La tabla está 100 por ciento ordenada o vacía. + Todas las filas nuevas son mayores en cuanto al orden de ordenación que las filas existentes, entre ellas las filas marcadas para eliminación. En esta instancia, Amazon Redshift usa los primeros ocho bytes de la clave de ordenación para determinar el orden. + El comando COPY no desencadena determinadas optimizaciones de carga. Al cargar grandes volúmenes de datos, Amazon Redshift puede optimizar el rendimiento mediante la creación de nuevas particiones ordenadas en lugar de agregar filas a la región ordenada de la tabla. Suponga, por ejemplo, que tiene una tabla que registra los eventos de los clientes con un ID de cliente y la hora. Si ordena a partir del ID de cliente, es probable que el rango de clave de ordenación de las filas nuevas agregadas con cargas incrementales se superponga con el rango existente, como se observa en el ejemplo anterior, lo cual conduce a una operación de limpieza costosa. Si establece la clave de clasificación en una columna de marca temporal, las filas nuevas se anexarán en orden de ordenación al final de la tabla, como lo muestra el diagrama a continuación, lo que reducirá o incluso eliminará la necesidad de ejecutar una limpieza. ![\[Una tabla que utiliza una columna de marca temporal como clave de clasificación, con lo que se obtienen nuevos registros que no es necesario ordenar.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png) ## Uso de tablas de series temporales para reducir los datos almacenados Si mantiene datos durante un periodo acumulativo, use una serie de tablas, como se ilustra en el siguiente diagrama. ![\[Cinco tablas con datos de cinco trimestres. La tabla más antigua se suprime para mantener un año de tiempo continuo.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png) Cree una tabla nueva cada vez que agrega un conjunto de datos y, luego, elimine la tabla más antigua de la serie. Se obtiene un beneficio doble: + Se evita el costo adicional de eliminar filas, porque una operación DROP TABLE es mucho más eficiente que una operación DELETE masiva. + Si las tablas se ordenan por marca temporal, no se necesita una limpieza. Si cada tabla tiene los datos correspondientes a un mes, una limpieza deberá, cuanto mucho, rescribir los datos de todo un mes, incluso si las tablas no se ordenan por marca temporal. Puede crear una vista UNION ALL para usar al informar consultas, lo cual oculta el hecho de que los datos se almacenan en distintas tablas. Si una consulta filtra según la clave de ordenación, el planificador de consultas puede omitir de manera eficiente todas las tablas que no se usan. UNION ALL puede ser menos eficiente para otros tipos de consultas, por lo que debería evaluar el rendimiento de consultas en el contexto de todas las consultas que usan las tablas.