¿Qué herramienta de compresión debería usar para las copias de seguridad de mi base de datos? (Parte II: descompresión)

En mi entrada de la semana pasada, analizaba algunos de las herramientas y formatos de compresión más comunes, así como su velocidad y ratio de compresión. Aunque ello podría darnos una buena idea del rendimiento de estas herramientas, el análisis estaría incompleto sin investigar la descompresión. Esto es particularmente cierto para backups de base de datos ya que, en aquellos casos en los que el proceso de compresión se realice fuera de las máquinas de producción puede que no te importe tanto los tiempos de compresión. En tal caso, incluso si es relativamente lento, no afectará al rendimiento de tu servidor MySQL (o aquello que estés usando). El tiempo de descompresión, sin embargo, puede ser crítico, ya que podría influir en muchos casos en el MTTR (tiempo medio de recuperación) de todo tu sistema.

Entorno de pruebas

Utilicé el mismo dump MySQL de nodos de OpenStreetMap en formato CSV que mencioné en mi anterior post, y -dado que algunas de las herramientas usan el mismo formato (y deberían ser compatibles entre sí), pero resultaban en ratio de compresión distintos- elegí el fichero más pequeño de cada uno de ellos. He aquí una tabla con el tamaño comprimido por formato, como recordatorio:

formatotamaño (bytes)
.csv original (sin compresión)3700635579
gzip585756379
bzip2508276130
bzip2 (pbzip2-compressed)508782016
7z354107250
lzip354095395
lzo782234410
lz4816582329

Tenga en cuenta que aunque p7zip y lzip/plzip usan el mismo algoritmo, el formato de fichero es diferente. También tenga en cuenta que se han usando dos ficheros comprimidos distintos para bzip2: la razón de ello será aclarada más adelante.

El hardware era el mismo que en el último post: un Intel Quad Core i7-3770@3.40GHz con hyper threading y sin carga, exponiendo 8 cpus al kernel. 32 GB de ram. 2 discos duros clásicos (no SSD) de 3 TB en RAID 1. El sistema de archivos era ext4 con las opciones por defecto del sistema operativo. El sistema operativo ha cambiado, sin embargo, a CentOS 7.

La metodología fue similar a la utilizada anteriormente, para cada herramienta se ejecutaba el siguiente comando varias veces:

Excepto en el caso de dd y 7za, donde la sintaxis varía ligeramente.

El archivo final se almacenaba en una partición diferente del mismo RAID. De este fichero se comprobaba su corrección (que el archivo sin comprimir fuera exactamente igual al original) y borrada tras cada ejecución. No repetiré aquí mi disclaimer sobre el uso de la cache del sistema de archivos, pero he añadido los resultados de dd como referencia.

Resultados globales

Esta es mi tabla de resultados finales; el análisis y discusión de los mismo siguen a continuación:

Estos datos pueden verse más fácilmente, como es habitual, en un gráfico bidimensional. En este caso, el eje X axis representa la mediana de la velocidad de descompresión en MB/s (más es mejor) y el eje Y representa el porcentaje del tamaño comprimido sobre el tamaño original (menos es mejor):

Análisis de las diferentes herramientas de compresión: ratio de compresión vs. velocidad de descompresión
(no está representado dd, ya que el aparecería con un ratio de compresión del 100%)

El uso de CPU se monitorizó cada segundo, así como el uso de memoria, que en ningún test para ninguna de las herramientas fue superior a 1MB.

En este caso he representado la función y = x*0.01+12 sobre los puntos y, aunque hay una clara tendencia de que mejores ratios de compresión requieren más tiempo de descompresión, la correlación es más débil que en el caso de la compresión.

La última cosa que me gustaría remarcar sobre los resultados globales es que no se han probado variaciones en los parámetros para la descompresión ya que en la mayoría de los casos hay pocas o ninguna opción para este proceso, y los algoritmos harán esencialmente los mismo para un archivo que fue creado con --fast que para otro que fue creado con --best.

Descomprimiendo los formatos gzip y bzip2

Sin ser precisamente sorpendente, el archivo gzip tardó menos tiempo en ser descomprimido que bzip con las herramientas GNU genéricas (56 segundos vs. 17). Utilicé GNU gzip 1.5 y bzip2 1.0.6. Ya comenté todo lo que quería comentar sobre las ventajas de y desventajas de usar las herramientas más estándar, así que no me volverá a repetir aquí, pero quería reiterar la idea de que gzip sigue siendo una buena utilidad para compresión rápida cuando no hay alternativa, ya que obtuvo un throughput de casi 203 MB/s al descomprimir nuestro fichero de pruebas.

Por supuesto, el siguiente paso era probar la descompresión en paralelo, y para ello disponía de pigz 2.3.1 y pbzip2 v1.1.6. Como nota al margen, me gustaría mencionar que, en el momento de escribir estas líneas, no había paquetes rpm para pbzip2 en CentOS 7 ni en la distribución base ni en EPEL (el cuál está actualmente en beta para la versión 7). Utilicé el paquete para RHEL6.

Sin embargo, cuando eché un vistazo a los resultados de pigz me pude dar cuenta de que, aunque ciertamente había una mejora en la velocidad (un poco más de 7 segundos), ésta no es tan dramática como la mejora 4x+ que observamos en la compresión. Además, si miramos al uso de la cpu, nos podemos dar cuenta de que el máximo uso de %CPU nunca supera el 170. Me dí cuenta que la razón de esto leyendo la documentación: aunque pigz usa varios hilos para la E/S de lectura y escritura, es incapaz de paralelizar el algoritmo básico de descompresión de gzip. Las mejora sobre el gzip estándar -en cualquier caso- están ahí, con casi 500 MB/s de ancho de banda de descompresión.

Cuando probé pbzip2, en mi primer intento, me di cuenta de que no había paralelización en absoluto, y que los tiempos eran esencialmente los mismos que el bzip2 normal. Buscando respuestas en la documentación encontré que la razón de ello era que la descompresión en paralelo era posible (al contrario que con gzip), pero sólo para archivos creados por el propio pbzip2.. En otras palabras, tanto bzip2 como pbzip2 crean archivos con un formato compatible (pueden ser descomprimidos por la otra utilidad), pero la paralelización sólo es posible si se crean y descomprimen con pbzip2. Para probar este segundo caso, utilicé el mejor archivo comprimido obtenido en mis resultados previos (que era ligeramente más grande que el creado con bzip2) y volví a probar los tests. Ésta es la razón por la cual hay dos filas diferentes en los resultados globales para pbzip2.

En ese segundo escenario, pbzip2 era una verdadera mejora sobre bzip2, obteniendo rates de descompresión de 356 MB/s, aproximadamente equivalentes a los resultados de una copia directa mediante el sistema de archivos.

Como era de esperar, el uso de múltiples hilos de descompresión es una clara ventaja en sistemas SMP, con los habituales avisos por los recursos extra consumidos y el hecho de que, en la realidad, como acabamos de ver, no siempre es posible para todos los formatos de archivo.

Descompresión Lzma

El siguiente grupo para poner a prueba son las herramientas basadas en lzma: Lzip 1.7, p7zip 9.20 y plzip 1.2-rc2. De nuevo, lzip no estaba disponible en EPEL-7, así que se usó la versión de RedHat6, y plzip fue compilado a partir del código fuente, tal y como hicimos anteriormente.

El algoritmo Lzma se había clasificado como lento pero con muy buena compresión en nuestros resultados anteriores. Se puede extrapolar un resultado similar para la descompresión: tanto lzip como 7za proporcionan tiempos de descompresión de unos 30 segundos, con anchos de banda cercanos a los 100 MB/s. Aunque p7zip parece un poco mejor paralelizado que lzip (con %cpu llegando a los 150), ambos proporcionan esencialmente un algoritmo de descompresión monohilo. Plzip proporciona una mejor paralelización, alcanzando un uso de la cpu del 290%, pero el throughput nunca supera los 200 MB/s.

La evaluación general es que son claramente mejores herramientas que los gzip y bzip2 monotarea, ya que proporcionan unos anchos de banda de descompresión similares pero con unos ratios de descompresión mucho mejores..

Herramientas “rápidas”: lzop y lz4

Finalmente nos quedan las herramientas de compresión y descompresión rápidas, en nuestros tests, lzop v1.03 y lz4 r121. En este caso podemos testificar las afirmaciones de que lz4, aunque proporcionan unas velocidades de compresión similares a lzop, es más rápido en la descompresión: casi dobla la velocidad (580 MB/s de lzop contra los 1111 MB/s de lz4). Obviamente, la única razón por la cual estos resultados son posibles es porque el sistema de archivos está siendo utilizado, así que tomad estos resultados con la debida precaución. Pero muestran la clase de ancho de banda de descompresión que se puede obtener cuando la latencia de disco no es el cuello de botella.

Cuando el tiempo de los tests es tan pequeño, recomendaría repetirlo con tamaños de archivo mayores o limitando los efectos de la caché del sistema de archivos. Dejaré esto como un ejercicio a realizar por el lector.

Conclusiones

Aparte de las limitaciones encontradas en las distintas herramientas respecto a la paralelización en descompresión (pigz, pbzip2), no se han encontrado resultados muy extraños. Las herramientas de compresión rápida son rápidas en descompresión (me he vuelto un fan de lz4) y las herramientas de mejor compresión son más lentas (plzip parece funcionar muy bien si no se está restringido por el tiempo de ejecución y el uso de la CPU). Como siempre, mi recomendación es probar siempre en el propio entorno, con los archivos y máquinas propias, antes de sacar conclusiones prematuras.

¿Qué herramienta de compresión usas para MySQL (o cualquier otro sistema de base de datos)? Déjame un comentario aquí o en Twitter.

¿Qué herramienta de compresión debería usar para las copias de seguridad de mi base de datos? (Parte I: compresión)

Esta semana hablamos de tamaño, algo que debería preocuparle a cualquier administrador de sistemas a cargo del sistema de backups de cualquier proyecto, y en particular de los backups de una base de datos.

A menudo recibo preguntas sobre cuál es la mejor herramienta de compresión a aplicar en un sistema de copias de seguridad: ¿gzip? ¿bzip2? ¿algún otro?

El entorno de pruebas

Para poder probar diferentes formatos y herramientas, creé un archivo .csv (comma-separated values, valores separados por comas) de tamaño 3.700.635.579 bytes transformando un dump reciente de todos los nodos de la porción europea de España en OpenStreetMap. Tenía un total de 46.741.126 de filas y tenía la siguiente pinta:

De hecho, el fichero original es en realidad un tsv (tab-separated values, valores separados por tabuladores), y no un csv, pero sólo porque soy demasiado vago como para añadir el código extra FIELDS SEPARATED BY ',' cada vez que lo importo y exporto. Puede descargar este archivo en formato 7z, o crear el suyo propio desde los extractos de OpenStreetMap de Geofabrik.

Todos los tests se hicieron en un servidor casi inactivo con un Intel Quad Core i7-3770@3.40GHz con hyper threading, exponiendo 8 cpus al kernel. 32 GB de ram. 2 discos duros clásicos (no SSD) de 3 TB en RAID 1. Todo corriendo bajo CentOS 6.5 x86_64. El sistema de archivos era ext4 con las opciones por defecto del sistema operativo.

Tamaño en tabla

Para una importación a MySQL, propuse la siguiente estructura de tabla:

Y estos fueron los tamaños en la base de datos (una vez que nos aseguramos de que no había operaciones de escritura pendientes):

  • Archivo de datos MySQL en MyISAM (.MYD): 2,755,256,596 bytes.(*)
  • Espacio de tablas MySQL de InnoDB (.ibd): 3,686,793,216 bytes.
  • Espacio de tablas MySQL de InnoDB con formato de filas compressed (.ibd): 1,736,441,856 bytes.

¿Por qué ocupa más espacio en texto plano que en la base de datos? Aunque las bases de datos están optimizadas para acceso rápido, y no en ocupación de disco, estamos usando un conjunto de tipos de datos muy compacto (enteros y timestamps en vez de cadenas de texto), ahorrando espacio en el proceso. ¡Esta es la razón por la que un diseño adecuado de base de datos es crítico para el rendimiento!

Podemos ver que una de las pocas razones por las que la gente sigue utilizando MyISAM es porque es un formato muy simple y compacto. (*)Sin embargo, para ser justos, no estamos teniendo en cuenta los 674.940.928 bytes extra de la clave primaria (.MYI), haciendo que la diferencia no sea tan grande. Por otro lado, no estamos teniendo en cuenta que el tamaño de los índices en InnoDB puede crecer de manera bastante significativa cuando estamos usando múltiples claves secundarias (debido al almacenamiento de la clave privada, si ésta es lo suficientemente grande) y las múltiples otras estructuras (tablespace 0, transaction logs) que son necesarios para que InnoDB funciones adecuadamente, compartido con otras tablas. En general, es imposible realizar una comparación justa entre MyISAM e InnoDB porque estamos comparando peras con manzanas.

Lo que está claro es que la compresión (en este caso estamos usando el algoritmo por defecto de InnoDB con el nivel por defecto de compresión-6) está ayudando a reducir el espacio en disco, introduciendo potenciales mejoras en escenarios específicos: más tablas que pueden caber en SSDs, o menos IOPS en una base de datos cuyo cuello de botella es el disco. Por otro lado, la carga inicial aumentó muy significativamente. No quiero mostrar las mediciones de tiempo de las importaciones en las distintas tablas porque no es trivial registrar el tiempo real a disco debido a todo el buffering que ocurre a nivel de base de datos, y simplemente proporcionar el tiempo de ejecución de las sentencias SQL sería injusto. Hablo más sobre tiempos de importación en este post.

Resultados globales

Los tamaños en tabla sólo se mostraron como referencias, nuestro principal objetivo es testear las herramientas disponibles para comprimir el archivo original nodes.csv file. Me limité a mí mismo a algunas de las más populares, y en la siguiente tabla se pueden ver los resultados finales (el análisis, explicación y discusión sigue a continuación):

Como se puede ver, evalué varias herramientas en sus modos por defecto, así como un modo de “alta compresión” y un modo “rápido”. Para cada uno de ellos intenté evaluar 3 parámetros, importantes para la creación de archivos comprimidos: el tiempo de ejecución, el tamaño final y los recursos usados. Tened en cuenta que sólo evalué herramientas de compresión, y no de “archivado” (como tar o zip). Estas últimas herramientas pueden utilizar diversos algoritmos de compresión tanto para comprimir cada archivo individualmente como aplicarlo al archivado final.

La primera columna de datos muestra el número de segundos (wall-clock time) que tardó el proceso en escribir el archivo comprimido en una partición diferente del mismo conjunto de discos RAID. Se ejecutaron múltiples veces:

(excepto por 7z y dd, donde la sintaxis es diferente) y se tomó el valor de la mediana con el objetivo de minimizar errores debido a factores externos. Para cada ejecución, se comprobaba la corrección del archivo final (que el resultado era determinista y que podía extraerse de vuelta a su tamaño original sin errores ni diferencias) y después se borraba. Los resultados no son muy científicos, ya que se hacía uso del sistema de archivos de manera extensiva tanto para lecturas como para escrituras, pero mi objetivo era centrarme precisamente en ese escenario. Se muestra también una ejección de dd (copiado del archivo sin compresión) como valor de control.

Creo que la segunda y tercera columna de datos son autoexplicativas: el tamaño en bytes del archivo comprimido y cómo se compara respecto al archivo original.

La última columna intenta medir el uso de CPU máximo y mínimo, tal y como lo reporta el sistema operativo durante la compresión. Si embargo, debido al planficador de la CPU, y al hecho de que la mayoría de herramientas tienen un periodo de sincronización al principio o al final de la ejecución, unidos con el echo de que se obtuvo mediante polling en intervalos de tiempo, hace que no sea muy significativo excepto para la comprobación del uso del paralelismo en su algoritmo. Valores mayores que 100 indican que más de un core/hilo de ejecución se está usando para la compresión.

No registré el uso de memoria (el otro recurso importante) porque incluso en modos “ultra”, su uso no fue significativo para mi máquina con 32GB (menos de 1/2 GB en todos los casos, la mayoría mucho menos). Consideré que era algo que no debería preocuparnos mucho en un máquina que debería tener suficiente RAM como una base de datos. Lo que sí quizá debería tenerse en cuenta en un escenario real es la reserva de caché por el sistema de archivos, que podría impactar de manera directa al rendimiento de MySQL. Prevenir que las páginas leídas y escritas vayan a la caché del sistema de archivos es algo que se puede hacer jugando con el flag POSIX_FADV_DONTNEED. Me gustaría mencionar también que ciertas herramientas, como bzip, disponen de un modo de bajo consumo de recursos: bzip2 --small.

Los tiempos de descompresión los analizo en la segunda parte de este post.

Los resultados globales se pueden apreciar mucho más claramente dibujados en un grafo bidimensional. He representado los valores de tiempo de compresión en el eje X (menos es mejor) y el ratio de compresión en el eje Y (menos es mejor):

Comparativa de tiempo y ratio de compresión de gzip, bzip2, pigz, pbzip2, lzip, p7zip, plzip, lzop y lz4, con diferentes parámetros y niveles
Sin representación: dd (ratio de compresión del 100%), 7za “ultra” (21+ minutos para la compresión) y lzip (35+ minutos para la compresión).

En general, podemos ver que no hay herramientas mágicas, y que un mejor ratio de compresión requiere mas tiempo (el tamaño final es inversamente proporcional al tiempo de compresión). También he representado la función y = 200/x + 9. Ésta, o algo como y = 200/x+9.5 (es difícil encontrar una buena correlación con tan pocos resultados, la mayoría de ellos sin relación entre sí) parece indicarnos el límite inferior del ratio por unidad de tiempo, sugiriendo que un 9%-9.5% sería el máximo ratio de compresión obtenible para este archivo con las herramientas disponibles en este momento.

Analicemos los puntos fuertes y flacos de cada herramienta y formato de compresión.

Los famosos gzip y bzip2

Si lo que deseas es compatibilidad, gzip y bzip2 son los reyes. No sólo son formatos de compresión altamente reconocidos sino que las herramientas para compresión y descompresión están preinstaladas en la mayoría de sistemas operativos tipo unix. Probablemente Windows es el único sistema operativo que no soporta gzip por defecto. gzip y bzip2 son las únicas compresiones con su propia letra en tar (junto con compress en BSD y xz en GNU).

Si bien la compatibilidad y disponibilidad son los puntos fuertes de estas herramientas, mirando al grafo podemos apreciar que están lejos de la línea que mencionaba como ideal en ratio de tiempo/tamaño. bzip2 proporciona un mayor ratio de compresión que gzip a cambio de más ciclos de cpu, pero ambas herramientas son monohilo y no brillan en ningún aspecto en particular. Sorprendentemente, bzip2 -1 nos proporcionó un tiempo de compresión peor y un mejor ratio que la ejecución estándar de bzip2, y el manual de la versión gnu nos proporciona una explicación para ello:

(en español: los alias –fast y –best son primordialmente para compatibilidad con GNU gzip. En particular, –fast no hace las cosas significativamente más rápidas. Y –best simplemente selecciona el comportamiento por defecto)

Probablemente el mejor uso que recomendaría para estas herramientas sería gzip --fast (equivalente a gzip -1) que, aunque no proporcione un nivel de compresión espectacular, lo hace de manera relativamente rápida para una aplicación de un sólo hilo de ejecución. Por lo tanto, puede ser útil en aquellos casos en los que se desee maximizar la velocidad sin utilizar muchos recursos. En otros casos, donde la disponibilidad no es un problema, recomendaría utilizar otras herramientas con una mejor velocidad o nivel de compresión.

Para las pruebas utilicé las versiones GNU de gzip 1.3.12 y bzip2 1.0.6.

Herramientas de compresión paralela: pigz y pbzip2

Las cosas se ponen más interesantes si se usan alguna de las versiones paralelas de gzip o bzip2 en un sistema multi-core. Aunque hay más de una versión, elegí pigz 2.3.1 y pbzip2 1.1.6 para mis tests. Aunque no son parte oficial de los repositorios de Red Hat/CentOS, pueden encontrarse sin problemas en EPEL y Debian.

Ambas herramientas autodetectan el número de cores que dispongo y realizan la compresión en 8 hilos de ejecución, proporcionando ratios de compresión comparables pero en 4 veces menos de tiempo. El desventaja obvia es que en un entorno de alta demanda, como puede ser un servidor de MySQL bajo una carga considerable, puede que no desees/puedas otorgar los recursos completos de la CPU al proceso de backup. Pero si estás realizando la compresión en un servidor dedicado aparte, el paralelismo es algo de lo que deberías tomar ventaja, ya que en general, la CPU es el mayor cuello de botella en un algoritmo de compresión.

De nuevo, alguna cosa a destacar: pigz con los parámetros por defecto proporcionó un buen ratio de compresión (16,89%) en menos de 28 segundos- eso es comprimir a cerca de 130MB/s para mi modesto hardware (eso es más de un tercio de mi velocidad de copia, 350MB/s).

Como nota al margen, aunque pbzip2 acepta un nivel de compresión como parámetro, el nivel de compresión por defecto es -9.

Implementaciones de lzma: lzip, 7zip y plzip

Los siguientes test se realizados fueron distintas implementaciones de lzma, un algoritmo que tiene buena fama de proporcionar muy buenos ratios de compresión.

Comencé por lzip. No está en los repositorios oficiales, así que lo obtuve desde EPEL, instalando lzip 1.7. El ratio de compresión fue, efectivamente, el mejor de todos los algoritmos (cercano al 9.5%) pero tardó 35 minutos and 38 segundos en producir la salida. No sólo el algoritmo tenía la culpa en este caso: usaba un único hilo, de ahí el restraso.

Después de ello, utilizé p7zip 9.20, y en particular la herramienta unix 7za. Esta el la única aplicación de compresión probada que no es compatible con los parámetros de gzip. Tuve qe ejecutarla usando:

Tenga en cuenta que p7zip es una aplicación de archivado, pero hice una excepción para probar una implementación alternativa de lzma.

Los resultados fueron mejores: mientras que la herramienta proporcionó un ratio de compresión peor (10.29%), gracias a algún tipo de ejecución en mútiples hilos, el tiempo se redujo a menos de 14 minutos. También probé un sugerido modo “ultra” que encontré en el manual de 7za, con los siguientes parámetros:

En resumen: maximizar el uso de memoria, nivel de compresión y tamaño del diccionario -aparte de forzar el formato de archivado y el algoritmo de compresión. Aunque esto proporcionó un tamaño de archivo más pequeño (pero sólo 25MB más pequeño, menos del 1% del tamaño original), el tiempo se incrementó hasta más de 21 minutos.

Quise también probar una implementación paralela de lzma, y plzip era exactamente eso. No pude encontrar un paquete rpm en ninguna parte, así que descargué e instalé desde código fuente Lzlib 1.5 y plzip 1.2-rc2. Los resultados fueron muy buenos, tal y como esperaba. plzip proporciona resultados comparables a “pigz -9” cuando se ejecuta en “modo rápido”; pero por defecto, en sólo 3m37s obtuve un archivo comprimido de 359MB, o 10.17% del archivo original. Después, intenté emular las opciones “ultra” de p7zip (con -9 -m 64 -s 33554432) y obtuve el ganador en ratio de compresión (9.57%) en sólo 7 minutos y 6.486 seconds.

Obviamente, las mismas restricciones que mencioné para las otras herramientas paralelas se aplican aquí: el uso completo de múltiples cores se desaconseja en un servidor muy ocupado, pero si estás almacenando los backups a largo plazo en un servidor separado, probablemenete quieras contemplar esta posibilidad. En cualquier caso, la mayoría de herramientas paralelas tienen una manera de limitar el número de hilos creados (por ejemplo, con la opción --threads en lzip).

Herramientas de compresión rápida: lzop and lz4

No quise terminar mis pruebas sin echar un vistazo a algunas de las herramientas de compresión de alto ancho de banda, así que elegí 2: lzop and lz4. Aunque tuve que instalar lz4 r119 desde EPEL, lzop v1.02rc1 es parte de los paquetes base de Red Hat/CentOS.

Ambos proporcionan lo que prometen: algoritmos de compresión muy rápidos (en algunos casos, incluso más rápidos que una simple copia de archivo, ya que el cuello de botella no está en la CPU y tienen que escribir menos cantidad de datos) a cambio de peores ratios de compresión (21-30%). Para el archivo de ejemplo, en mi máquina, obtuve un mejor rendimiento con lz4 que con lzop, ofreciendo ratios similares pero en menor tiempo (8.5 vs. 15.5 segundos). Así que, si tuviera que elegir, probablemente usaría lz4 antes que lzop en mi caso particular. Adicionalmente, aunque no se ha probado, lz4 presume de proporcionar mejores velocidades de descompresión.

Como resalte negativo, recomendaría no utilizar nunca lzop -9, ya que en ese caso dispondríamos de herramientas con un mejor ratio de compresión en la mitad de tiempo. lz4 no tuvo un buen rendimiento tampoco con un mayor nivel de compresión, así que recomendaría ceñirse a los parámetros por defecto o con un nivel menor de compresión para estas herramientas (de hecho, lz4 por defecto es equivalente a lz4 -1).

Conclusión

No he probado otras herramientas como compress (Lempel-Ziv), xz (lzma2) o QuickLZ, pero no espero demasiadas desviaciones de los patrones que hemos visto: el tiempo es inversamente proporcional al nivel de compresión. Si lo que quieres es compresión rápida, usa lz4. Si quieres un tamaño de archivo pequeño, utiliza una implementación de lzma, como p7zip. Los formatos bzip y gzip son buenas opciones si la compatibilidad es importante (ej. publicar un fichero), pero cuando sea posible, utiliza una implementación de compresión paralela para mejorar el rendimiento (plzip, pbzip2, pigz). Podemos incluso utilizar una combinación de herramientas para nuestros backups, por ejemplo, exportar nuestras tablas en formato binario usando lz4 para sacarlas del servidor mysql, y luego, en una máquina separada, convertirlos a lzma para almacenamiento a largo plazo.

También te aconsejaría probar los distintos métodos de compresión para tu conjunto de datos en particular y tu propio hardware ya que podrías obtener distintos ratios de compresión y medidas de tiempo, sobre todo dependiendo de la memoria disponible para cache del sistema de archivos, tu(s) CPU(s) y la velocidad de lectura y escritura de tu almacenamiento secundario. Lo que he intentado hacer aquí, sin embargo, es tener un punto de partida desde la cual cada uno pueda sacar sus propias conclusiones.

¿Estás de acuerdo conmigo? ¿Crees que he cometido algún error en algún punto? ¿Echas en falta algo? Escribe un comentario o mándame una respuesta a twitter o mediate email.

Echa una vistazo a la parte II de este artículo para mi análisis de estas herramientas para la descompresión.

Cómo instalar MySQL 5.6 en CentOS 7

CentOS 7 and MySQL 5.6

Un poco de historia

La última versión de Red Hat Enterprise Linux, una de las distribuciones de Linux más populares y respetadas en el mercado de servidores, se publicó en junio de 2014, seguido por los lanzamientos de CentOS 7 y Oracle Linux en julio del mismo año.

Hay cambios muy interesantes para administradores de bases de datos en estas nuevas versiones, de las cuales me gustaría destacar el hecho de que el instalador oficial ahora selecciona XFS como el sistema de archivos por defecto, sustituyendo a ext4 como el formato preferido para almacenamiento local. Red Hat EL7 también incluye Btrfs como tech preview.

Respecto a paquetería, el cambio con mayor impacto es, en mi opinión, la actualización de las versiones de MySQL y PostgreSQL, en verdad necesitadas de un upgrade, ya que la anterior versión de Red Hat, 6.5, todavía utilizava versiones con 5 años de edad de ambos SGBBDD, los cuales se encontraban fuera de su ciclo de vida de soporte. La mayor sorpresa es que Red Hat ha optado por elegir MariaDB 5.5, y no Oracle, como el proveedor por defecto de MySQL (o compatible). Esto tiene la hilarante consecuencia de que Oracle Linux está distribuyendo en realidad la versión de su competidor, MariaDB a través de sus repositories, con el objetivo de ser 100% compatible. La diferencia, claro está, es que Oracle ofrece la última versión de MySQL en sus repositorios de yum y, por lo tanto, está disponible para su instalación en todas las distribuciones compatibles con Red Hat.

Prerequisitos

En este tutorial os mostraremos cómo instalar MySQL 5.6 en CentOS 7, útil para aquellos que prefieran desplegar la última versión GA de MySQL. 5.6 introduce una gran cantidad de mejoras sobre MySQL 5.5, y dado que Red Hat EL7 tiene un ciclo de soporte de al menos 10 años, es posible que se vuelva muy anticuada en el futuro. Vamos a mostrar el proceso en CentOS 7, pero éste será idéntico en RHEL 7 y, hasta cierto punto, en otras distribuciones basadas en yum como las últimas versiones de Fedora y Amazon Linux.

Por favor, tenga en cuenta que el siguiente tutorial supone que no hay una versión previamente instalada de MySQL o MariaDB. Puede utilizar el siguiente comando: rpm -qa | grep -i mysql para comprobar paquentes de MySQL que estén instalados con anterioridad, y borrarlos con el comando yum remove.

Tutorial

El primer paso es configurar el repositori de MySQL de Oracle; para ello, nos dirigimos a la web de mysql.com, pulse en “Downloads“, luego en “Yum repository” y finalmente en “Red Hat Enterprise Linux 7”. En el momento de escribir estas líneas, está versión del respositorio se encuentra todavía en beta, pero no tuve problemas para instalarlo en diversas conbinaciones de software y hardware. Seleccione “Download” y le aparecerá la opción de acceder o crear una cuenta de Oracle. Podemos omitir este paso y simplemente copiar el enlace en la parte inferior que dice “No thanks , just start my download”. Esto nos proporcionará la dirección del rpm para auto-configurar los repositorios de la versión Community del servidor de MySQL.

Ahora, si ejecuta en un terminal:

Podemos comprobar que los respositories están efectivamente activos ejecutando:

Acabamos de realizar la configuración (sólo es necesario hacerlo una vez) que nos permitirá instalar y mantener actualizada nuestra instalación de MySQL de manera fácil y sencilla.

El siguiente paso es instalar realmente los paquetes del servidor. Para ello, escribimos:

Como podrá apreciar, los paquetes del servidor Community hacen referencia a la última versión de MySQL 5.6. Durante el proceso de instalación, sólo dos interrupciones se producirán (aparte de la petición de contraseña de sudo), una para la confirmación de los cambios, y otra para la importación de la clave de releases de los ingenieros de Oracle en su sistema, que podremos aceptar sin problemas si su fingerprint conincide con el siguiente: a4a9 4068 76fc bd3c 4567 70c8 8c71 8d3b 5072 e1f5. Recuerde que, en el caso de procesos automatizados, podemos añadir la opción -y (decir sí a todo) a yum, pero quería mostrar el proceso completo, así como realizar el proceso con buenas prácticas de seguridad.

La instalación ya se ha completado, ahora sólo tenemos que ejecutarlo y probarlo. Recuerde que Red Hat Enterprise Linux 7 reemplaza la gestión de servicios por systemd, por lo que la manera “correcta” de iniciar el servicio de mysql es:

Puede comprobar que ha iniciado correctamente haciendo:

Y conectarse desde localhost haciendo:

Recuerda también activar el autoinicio en el arranque, ya que es algo que querrás en la mayoría de los casos (esto también ha cambiado comparado con CentOS 6):

Puede comprobar que se ha activado correctamente con el comando ‘status’ mostrado anteriormente; debería mostrarse ahora como “enabled” (activado).

Como buen administrador, los siguientes pasos son configurar las cuentas de usuario y securizar el servicio de mysql, pero eso está fuera de los objetivos de este tutorial.

Gracias a la instalación mediante respositorios, sus paquetes ahora pueden ser actualizados fácilmente tan sólo usando yum.

Para una documentación más detallada, puede revisar la documentación oficial. Los ingenieros de Oracle publicaron también una interestante historia sobr el proceso de pruebas de sus paquetes.

Espero que este tutorial haya sido de utilidad.