MariaDB / Implementando la compresion de InnoDB

Bienvenidos sean a este post, hoy veremos como se implementa la compresion y otros motores que permiten comprimir.

Un tema que no hemos mencionado hasta ahora es que la compresion soporta varios niveles, para establecerla se utiliza la variable innodb_compression_level con un valor entre 0 y 9, mientras mas alto el valor mejor sera la compresion pero sera mas lento, el valor preeterminado es de 6, y podemos modificarlo dinamicamente como a otras variables, como mencionamos en otros posts cuando se lee una entrada de indice desde el disco se escribe en el pool de buffers en sus formas comprimidas y descomprimidas, sin embargo InnoDB intenta evitar ejecutar una gran cantidad de operaciones de compresion y descompresion, por ejemplo se puede modificar una pagina comprimida sin comprimir los nuevos datos hasta que se descargue al disco.

Para lograr esto se mantiene un rastro de tales cambios en una area de pagina llamada log de modificacion, el cual esta descomprimido, por supuesto cada pagina del log de modificacion tiene un espacio limitado, cuando se intenta escribir un cambio dentro del log y este se queda sin espacio, se procede a descomprimir la pagina, los cambios en el log son aplicados y se comprime nuevamente la pagina, pero en algunos casos la pagina se vuelve demasiado grande despues que los cambios toman lugar, y se necesita que los datos se reorganicen nuevamente para que encajen en el tamaño de la pagina, y esto puede hacer que los resultados de la nueva pagina sean demasiados grandes generando un error de compresion.

Como se podran imaginar la reconstruccion de las paginas comprimidas toman tiempo, por esta razon InnoDB intenta evitarlo si los errores de compresion son demasiados frecuentes, otra situacion que podemos tener es que el ratio entre las fallas de compresion y los cambios aplicados excedan al valor de innodb_compression_failure_threshold_pct, en este caso InnoDB deja un espacio en blanco al final de cada nueva pagina comprimida, la variable comentada es un porcentaje y su valor predeterminado es de 5, tambien tenemos otra variable llamada innodb_compression_pad_pct_max la cual especifica el porcentaje maximo de espacio libre que se puede dejar en cada pagina comprimida, el rango de valores permitidos va de 0 a 75 y su valor predeterminado es de 50, si el valor es de 0 se desactiva la optimizacion.

Antes mencionamos que podemos tener errores de compresion muy frecuentes en una tabla, uno de los motivos puede ser que el KEY_BLOCK_SIZE de la tabla sea probablemente muy bajo, otro problema que podemos tener es que la performance de las tabla comprimidas sea baja y sea causada por las fallas de compresion, una solucion podria ser que se incremente el valor en innodb_compression_failure_threshold_pct, y otro inconveniente que podemos tener es que el tamaño de nuestras filas se incrementen drasticamente, para solucionarlo podemos establecer a innodb_compression_pad_pct_max en un valor mas alto.

Antes de terminar vamos a nombrar otros motores que tambien permiten compresion:

• TokuDB, este motor siempre comprime sus tablas y no hay forma de evitarlo, este es una forma de trabajar la cual apunta a alcanzar una alta performance reduciendo la salida al disco
• ARCHIVE, esta diseñado para tablas comprimidas con funcionalidades limitadas, se puede agregar nuevos datos pero no se pueden borrar ni actualizar, el soporte de indices es muy limitado
• MyIsam, mientras las tablas normales de este motor no se comprimen, pero si se puede usar una herramienta especial llamada myisampack pero las dejara como de solo lectura

Si bien de los tres comentados el mas interesante es TokuDB dado que tiene un rendimiento muy similar a InnoDB pero a la hora de trabajar este segundo tiene un mejor rendimiento y por esta razon se transformo en la forma predeterminada de trabajar en mariadb, sin embargo otra opcion existe y es bueno saber de la existencia de esta, veamos un ejemplo entre varios archivos de distintos motores:

root@this:/usr/local/mysql/data/test# ls -l customers*
-rw-rw---- 1 mysql mysql 201326592 mar 31 00:51 customers_non_comp.ibd
-rw-rw---- 1 mysql mysql 100663296 mar 31 01:03 customers_4.ibd
-rw-rw---- 1 mysql mysql  96468992 mar 31 00:56 customers_8.ibd
-rw-rw---- 1 mysql mysql 188743680 mar 31 00:54 customers_16.ibd
-rw-rw---- 1 mysql mysql    955044 mar 31 01:04 customers_arch.ARZ
-rw-rw---- 1 mysql mysql  82379202 mar 31 01:04 customers_myi.MYD
-rw-rw---- 1 mysql mysql  25600000 mar 31 01:13 customers_myi.MYI

Si bien la salida fue editada para ser mas leible, los tamaños de los archivos son reales, estos pueden variar dependiendo de los ejemplos que utilicemos pero en todos los casos los archivos contienen una tabla con muchas campos de textos cortos, una clave primaria que se auto incrementa y un campo de nombre de usuario indexaddo, veamos una descripcion de cada archivo:

• customers_non_comp.ibd, esta es una tabla de InnoDB no comprimida
• customers_*.ibd, estas son tablas de InnoDB comprimidas con key_block_size de 4, 8, 16 kb
• customers_arch.ARZ, esta es una tabla de ARCHIVE
• customers_myi.MYD, este es un archivo comprimido de datos de MyIsam
• customers_myi.MYI, este es un archivo comprimido de indices de MyIsam

Si comparamos entre los tres tipos, vemos que los archivos de MyIsam son un poco mas grande que el mejor comprimido de InnoDB y el que tiene la mejor compresion es ARCHIVE, con esto podemos pensar que este ultimo es la mejor opcion pero las ventajas de InnoDB sobre este demuestran que es mas util, veamos algunos casos:

• ARCHIVE no soporta transacciones y ya solo con esto lo deja muy por atras con respecto a InnoDB
• InnoDB tiene una mejor performance para ingresos y XtraDB es inclusive mejor
• Tipos de datos geometricos como LINESTRING o POLYGON no son soportados por ARCHIVE
• Mientras que las tablas comprimidas no estan preparadas para ser leidas a menudo pero si queremos indexarlas, ARCHIVE no soporta indexado excepto para claves primarias autoincrementables
• Tanto InnoDB como XtraDB fueron mejorados con los años pero ARCHIVE hace mucho tiempo que no recibe actualizaciones

Si nada de lo comentado anteriormente afecta a nuestra informacion la mejor opcion es ARCHIVE de lo contrario es mejor reajustar el valor de innodb_compression_level hasta llegar a un valor mas optimo de compresion.

En resumen, hoy hemos visto como es la implementacion de la compresion, como trabaja, como nos ayuda, algunas fallas que pueden surgir y una solucion para ayudarnos, por ultimo hemos visto otros motores que nos permiten la compresion, sus pros y contras, espero les haya sido util sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.