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.

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_INTERLEAVED_COLUMNS.

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.

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 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.

2. 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.

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.

Para determinar qué proporción de una tabla se volvió a fusionar, ejecute una consulta SVV_VACUUM_SUMMARY 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_increments 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.

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.

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.

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.