Compresión en Teradata

By | 24/10/2013

Introducción

La compresión de datos consiste en la aplicación de alguna técnica para reducir el volumen de los mismos, siendo el espacio ganado denominado beneficio de compresión. La aplicación de alguna técnica de compresión requiere a su vez de un tiempo de procesamiento al que podemos denominar costo de compresión.

Desde el punto de vista de la compresión, los datos pueden clasificarse en: redundantes (aquellos que traen información repetida), irrelevantes (aquellos cuya eliminación no afecta el contenido del mensaje) y básicos (aquellos que no son ni redundantes ni irrelevantes, o sea que son la parte fundamental del dato).

Históricamente la compresión en bases de datos estuvo limitada a técnicas que no tengan pérdidas reales de información y que además tengan un bajo costo de compresión, en otras palabras, limitadas a eliminar la información redundante (multi-value compression por ejemplo). Pero cada día existen más técnicas que, manteniendo la nula pérdida real de información, aplican técnicas avanzadas de codificación (algorithmic compression o block-level compression, por ejemplo) para obtener un beneficio de compresión, favorecidas por el hecho de que cada día se acentúa más la diferencia entre el tiempo de procesamiento (para comprimir/descomprimir) y el tiempo de lectura/escritura, tal como puede apreciarse en el siguiente gráfico:

Fuente

 

Esta situación implica que pasemos de una ganancia neta por compresión igual a beneficio – costo a una ganancia dada por beneficio + reducción del costo ya que pasamos a tener una reducción del volumen de datos y en paralelo una reducción del tiempo de procesamiento. Si bien la tendencia es clara, la distribución de los datos en disco limita la aplicación de los algoritmos pudiendo generalizarse una limitación en la aplicación de las nuevas técnicas de compresión a bases de datos con almacenamiento por columnas. Además el costo de CPU siempre debe ser tenido en cuenta.

A lo largo de este artículo se analizará la compresión de nulos y la compresión por diccionario (MVC o multi-value compression) en Teradata y se compararán sus características con los otros mecanismos disponibles. Al final también se hará una breve reseña de las nuevas técnicas de compresión (orientadas a almacenamiento por columnas) disponibles a partir de Teradata v14.

Funcionamiento de la compresión MVC en Teradata

La compresión MVC en Teradata v13 no es un algoritmo de reducción de datos sino que su función es eliminar el almacenamiento de nulos y de un conjunto limitado de valores constantes los cuales deben ser definidos por el usuario (información redundante). Si bien a priori parece un recurso muy limitado, en la práctica demuestra excelente resultados.

El funcionamiento es sencillo: para cada valor que se establezca en la definición del compress (además del nulo), Teradata establecerá un valor el cual se almacenará en el encabezado de la tabla. Cada vez que se requiera leer o escribir alguno de estos valores, Teradata apuntará al encabezado de la tabla el cual al encontrarse en memoria es de muy rápido acceso.

Reglas y limitaciones del compress

Existen algunas importantes consideraciones a tener en cuenta a la hora de aplicar la compresión MVC, las cuales se detallan a continuación:

  • Las columnas no pueden ser parte del índice primario
  • Por defecto no se comprime ningún campo
  • Agregar la cláusula compress a un campo automática comprime los nulos del mismo
  • La compresión es case sensitive. Esto quiere decir que si comprimo el string ‘HOLA’, no se va a comprimir el string ‘hola’
  • El límite de ancho del campo está establecido en 510 caracteres en la v13. En las anteriores se limita a 255
  • En la v13 Se pueden comprimir casi todos los tipos de datos, incluyendo los de longitud variable (se agregaron varchar y graphic por ejemplo). En versiones anteriores sólo se pueden comprimir campos de ancho fijo
  • Se pueden comprimir hasta 255 valores, además del null
  • Hay una limitación de 64KB en el encabezado de la tabla para almacenar los valores a comprimir

 

Caso de estudio: aplicación del compress MVC

Las pruebas fueron realizadas en un servidor de desarrollo con la v13 de Teradata instalada. Se trabajó con una tabla de 36.625.783 registros, 15 campos y un peso de 5388,52 MB. El objetivo del caso de estudio fue identificar el ahorro real de espacio de la aplicación del compress y su impacto en la performance.

Análisis de espacio

Se tomaron 4 campos candidatos de la tabla, elegidos por tipo de dato y no definidos como NOT NULL a fines de, en primera instancia, evaluar la capacidad de compresión del compress para nulos. Los resultados se reflejan en la siguiente tabla:

Tipo de dato Cantidad de
registros nulos
Tamaño de la tabla
(postcompresión – MB)

Ahorro por registro
(bytes) 
Decimal(12,0) 30.493.118 5152,34  8,12
Integer 1.302.263 5375,68 10,34
Date (c/format) 545.495 5381,32 13,84
Char(25) 3.656.6278 4548,28 24,09

Posteriormente se realizó un update de los nulos, asignándoles a todos un valor con el objetivo de evaluar como se comporta la tabla. Los resultados fueron los esperados y el tamaño de la tabla aumentó con respecto al original. Luego de modificar los 4 campos la tabla pasó a pesar 5388,52 MB.

Por último se aplicó nuevamente el compress pero agregando en la definición los valores fijos que habían sido utilizados para reemplazar los nulos. Los resultados fueron exactamente los mismos que se obtuvieron para la compresión de nulos. Esto demuestra que Teradata da el mismo tratamiento a todos los valores que se establezcan en el compress (255 como máximo, más el nulo).

El ahorro de espacio es sumamente interesante y debería considerarse su uso en prácticamente todo escenario. Más allá de esto hay que evitar un uso indiscriminado ya que el compress realiza una sobrecarga de CPU (mínima pero sobrecarga al fin) y por eso sólo debería usarse en los casos en los que la cantidad de registros lo amerite.

Análisis de performance

Para analizar la performance de la tabla con compress se ejecutaron las siguientes consultas:

  • Sample de 200o: con el objetivo de evaluar si el compress genera un esfuerzo adicional a la hora de traer un conjunto de datos
  • Join con una tabla de 10000 registros tomados al azar: realizándose el join por el campo en cuestión para forzar al motor acceder a los valores comprimidos la mayor cantidad de veces posibles
  • Insert de 1 millón de registros e insert de 5 millones de registros: a fines de evaluar el impacto del compress en los I/O. El insert se realizó a través de otra tabla.

Los resultados obtenidos (tiempos en segundos, promediando 3 ejecuciones) fueron los siguientes:

Tipo de dato Sample 2000 Join c/10k
sin compress con compress sin compress con compress
Decimal(12,0) 2 3 26,66 26,33
Integer 2 2,33 7 6,66
Date (c/format) 2 2,33 7,66 7
Char(25) 3 3 31 32,33

Y para los insert:

Tipo de dato Insert 1M Insert 5M
sin compress con compress sin compress con compress
Decimal(12,0) 1 1 23 23
Integer 1 1 23 21
Date (c/format) 1 1 23 22
Char(25) 1 1 23 21

En las tablas puede observarse que en todas las operaciones existe algún tipo de impacto en la aplicación del compress y que en algunos casos resulta beneficiosa y en otros no. El impacto fue negativo en el caso del sample, pero en el resto de las operaciones el tiempo de procesamiento se mantuvo o incluso disminuyo (a excepción del join por char).

Analizando la documentación de Teradata, vemos que se indica explícitamente que la performance no debería verse afectada negativamente por el compress, pero que si se incurriría en un query con mayor dependencia de la CPU. La fuente además indica implícitamente que la reducción del tamaño de cada fila permitiría traer una mayor cantidad de registros en la lectura de un bloque en disco, situación que ya se contempló en la introducción.

 

Comparativas con otras técnicas de compresión

Multi-value Compression Algorithmic Compression Block-level Compression
Análisis Se requiere análisis de datos para identificación de valores Se requiere análisis de datos para identificación de patrones No requiere análisis de datos
Flexibilidad Funciona en varias situaciones Se invoca automáticamente para valores no comprimidos por MVC Se puede combinar con los otros tipos de compresión
Performance No usa CPU Depende del algoritmo Se reducen accesos a disco pero se aumenta el uso de CPU
Aplicabilidad Para valores con muchas repeticiones Para CHAR, VARCHAR, BYTE y VARBYTE principalmente Para tablas específicas

Fuente

 

Compresión en Teradata v14

Si bien la versión 14 de Teradata agrego más de 100 características y funcionalidades nuevas, lo principal de la nueva versión es la capacidad de ofrecer almacenamiento híbrido (por filas y por columnas), siguiendo la clara tendencia del mercado de orientarse al Big Data. En conjunto con el nuevo almacenamiento por columna, surgieron no sólo nuevas formas de compresión sino también una nueva forma de gestionarla.

Teradata v14 selecciona automáticamente el mejor método de compresión y dinámicamente adapta  el mecanismo según evolucionen los datos en el tiempo. Esto representa un gran cambio frente a la gestión manual de la compresión que había en versiones anteriores. Los 6 métodos de compresión disponibles para el almacenamiento por columnas son length, dictionary, trim, delta on mean, null y UTF8 aunque también se puede aplicar la compresión a  nivel de bloque en conjunto con alguna de estas.

Por último también se ofrece una compresión fría (Compress on Cold) que se monta sobre Teradata Virtual Storage y cuya función es comprimir automáticamente datos que no sean utilizados en el último tiempo (por ejemplo en una comparación año a año).

 

Resumen

A lo largo del artículo vimos que existen diferentes técnicas de compresión en Teradata y analizamos en particular la aplicación de la compresión MVC. Si bien esta técnica requiere de un análisis de datos, quedó demostrado que su aplicación es sumamente beneficiosa.

 

Más información