{"id":342,"date":"2014-08-20T18:49:38","date_gmt":"2014-08-20T16:49:38","guid":{"rendered":"http:\/\/dbahire.com\/?p=342"},"modified":"2014-08-20T18:49:38","modified_gmt":"2014-08-20T16:49:38","slug":"que-herramienta-de-compresion-deberia-usar-para-las-copias-de-seguridad-de-mi-base-de-datos-parte-ii-descompresion","status":"publish","type":"post","link":"https:\/\/jynus.com\/dbahire\/que-herramienta-de-compresion-deberia-usar-para-las-copias-de-seguridad-de-mi-base-de-datos-parte-ii-descompresion\/","title":{"rendered":"\u00bfQu\u00e9 herramienta de compresi\u00f3n deber\u00eda usar para las copias de seguridad de mi base de datos? (Parte II: descompresi\u00f3n)"},"content":{"rendered":"

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

Entorno de pruebas<\/h2>\n

Utilic\u00e9 el mismo dump MySQL de nodos de OpenStreetMap en formato CSV<\/a> que mencion\u00e9 en mi anterior post, y -dado que algunas de las herramientas usan el mismo formato (y deber\u00edan ser compatibles entre s\u00ed), pero resultaban en ratio de compresi\u00f3n distintos- eleg\u00ed el fichero m\u00e1s peque\u00f1o de cada uno de ellos. He aqu\u00ed una tabla con el tama\u00f1o comprimido por formato, como recordatorio:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
formato<\/strong><\/td>\ntama\u00f1o (bytes)<\/strong><\/td>\n<\/tr>\n<\/thead>\n
.csv original (sin compresi\u00f3n)<\/td>\n3700635579<\/td>\n<\/tr>\n
gzip<\/td>\n585756379<\/td>\n<\/tr>\n
bzip2<\/td>\n508276130<\/td>\n<\/tr>\n
bzip2 (pbzip2-compressed)<\/td>\n508782016<\/td>\n<\/tr>\n
7z<\/td>\n354107250<\/td>\n<\/tr>\n
lzip<\/td>\n354095395<\/td>\n<\/tr>\n
lzo<\/td>\n782234410<\/td>\n<\/tr>\n
lz4<\/td>\n816582329<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Tenga en cuenta que aunque p7zip y lzip\/plzip usan el mismo algoritmo, el formato de fichero es diferente. Tambi\u00e9n tenga en cuenta que se han usando dos ficheros comprimidos distintos para bzip2: la raz\u00f3n de ello ser\u00e1 aclarada m\u00e1s adelante.<\/p>\n

El hardware era el mismo que en el \u00faltimo 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\u00e1sicos (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.<\/p>\n

La metodolog\u00eda fue similar a la utilizada anteriormente, para cada herramienta se ejecutaba el siguiente comando varias veces:<\/p>\n

\r\n$ time [tool] -d -c < nodes.csv.[format] > nodes.csv\r\n<\/pre>\n
Excepto en el caso de dd<\/code> y 7za<\/code>, donde la sintaxis var\u00eda ligeramente.<\/p>\n
El archivo final se almacenaba en una partici\u00f3n diferente del mismo RAID. De este fichero se comprobaba su correcci\u00f3n (que el archivo sin comprimir fuera exactamente igual al original) y borrada tras cada ejecuci\u00f3n. No repetir\u00e9 aqu\u00ed mi disclaimer<\/em> sobre el uso de la cache del sistema de archivos, pero he a\u00f1adido los resultados de dd<\/code> como referencia.<\/p>\n
Resultados globales<\/h2>\n
Esta es mi tabla de resultados finales; el an\u00e1lisis y discusi\u00f3n de los mismo siguen a continuaci\u00f3n:<\/p>\n
\r\nm\u00e9todo de                  tama\u00f1o        ratio de    mediana del tiempo  velocidad de   Uso %CPU\r\ncompresi\u00f3n                 comprimido    compresi\u00f3n  de descompresi\u00f3n \t descompresi\u00f3n\r\n                           (bytes)       (%)         (segundos)          (MB\/s)\r\ndd                         3700635579    100.00%       9.996              353.061       100 -  43\r\ngzip                        585756379     15.83%      17.391              202.933        99 -  26\r\nbzip2                       508276130     13.73%      55.616               63.457       100 -  45\r\npigz                        585756379     15.83%       7.115              496.023       172 -  62\r\npbzip2 (bzip2-compressed)   508276130     13.73%      50.760               69.527       170 -  64\r\npbzip2 (pbzip2-compressed)  508782016     13.75%       9.904              356.341       794 - 185\r\nlzip                        354095395      9.57%      38.682               91.236       100 -  47\r\n7za                         354107250      9.57%      28.070              125.729       157 -  95\r\nplzip                       354095395      9.57%      19.791              178.324       345 - 177\r\nlzop                        782234410     21.14%       6.094              579.127       136 -  47\r\nlz4                         816582329     22.07%       3.176             1111.209       100 -  78\r\n<\/pre>\n
Estos datos pueden verse m\u00e1s f\u00e1cilmente, como es habitual, en un gr\u00e1fico bidimensional. En este caso,  el eje X axis representa la mediana de la velocidad de descompresi\u00f3n en MB\/s (m\u00e1s es mejor) y el eje Y representa el porcentaje del tama\u00f1o comprimido sobre el tama\u00f1o original (menos es mejor)<\/strong>:<\/p>\n
\"An\u00e1lisis<\/a>
\n(no est\u00e1 representado dd<\/code>, ya que el aparecer\u00eda con un ratio de compresi\u00f3n del 100%)<\/em><\/p>\n
El uso de CPU se monitoriz\u00f3 cada segundo, as\u00ed como el uso de memoria, que en ning\u00fan test para ninguna de las herramientas fue superior a 1MB.<\/p>\n
En este caso he representado la funci\u00f3n y = x*0.01+12<\/code> sobre los puntos y, aunque hay una clara tendencia de que mejores ratios de compresi\u00f3n requieren m\u00e1s tiempo de descompresi\u00f3n, la correlaci\u00f3n es m\u00e1s d\u00e9bil que en el caso de la compresi\u00f3n.<\/p>\n
La \u00faltima cosa que me gustar\u00eda remarcar sobre los resultados globales es que no se han probado variaciones en los par\u00e1metros para la descompresi\u00f3n ya que en la mayor\u00eda de los casos hay pocas o ninguna opci\u00f3n<\/strong> para este proceso, y los algoritmos har\u00e1n esencialmente los mismo para un archivo que fue creado con --fast<\/code> que para otro que fue creado con --best<\/code>. <\/p>\n
Descomprimiendo los formatos gzip y bzip2<\/h2>\n
Sin ser precisamente sorpendente, el archivo gzip tard\u00f3 menos tiempo en ser descomprimido que bzip<\/strong> con las herramientas GNU gen\u00e9ricas (56 segundos vs. 17). Utilic\u00e9 GNU gzip 1.5 y bzip2 1.0.6. Ya coment\u00e9 todo lo que quer\u00eda comentar sobre las ventajas de y desventajas de usar las herramientas m\u00e1s est\u00e1ndar, as\u00ed que no me volver\u00e1 a repetir aqu\u00ed, pero quer\u00eda reiterar la idea de que gzip sigue siendo una buena utilidad para compresi\u00f3n r\u00e1pida cuando no hay alternativa, ya que obtuvo un throughput de casi 203 MB\/s al descomprimir nuestro fichero de pruebas.  <\/p>\n
Por supuesto, el siguiente paso era probar la descompresi\u00f3n en paralelo, y para ello dispon\u00eda de pigz 2.3.1 y pbzip2 v1.1.6. Como nota al margen, me gustar\u00eda mencionar que, en el momento de escribir estas l\u00edneas, no hab\u00eda paquetes rpm para pbzip2 en CentOS 7 ni en la distribuci\u00f3n base ni en EPEL (el cu\u00e1l est\u00e1 actualmente en beta para la versi\u00f3n 7). Utilic\u00e9 el paquete para  RHEL6.<\/p>\n
Sin embargo, cuando ech\u00e9 un vistazo a los resultados de pigz me pude dar cuenta de que, aunque ciertamente hab\u00eda una mejora en la velocidad (un poco m\u00e1s de 7 segundos), \u00e9sta no es tan dram\u00e1tica como la mejora 4x+ que observamos en la compresi\u00f3n. Adem\u00e1s, si miramos al uso de la cpu, nos podemos dar cuenta de que el m\u00e1ximo uso de %CPU nunca supera el 170. Me d\u00ed cuenta que la raz\u00f3n de esto leyendo la documentaci\u00f3n: aunque pigz usa varios hilos para la E\/S de lectura y escritura, es incapaz de paralelizar el algoritmo b\u00e1sico de descompresi\u00f3n de gzip<\/strong>. Las mejora sobre el gzip est\u00e1ndar -en cualquier caso- est\u00e1n ah\u00ed, con casi 500 MB\/s de ancho de banda de descompresi\u00f3n.<\/p>\n
Cuando prob\u00e9 pbzip2, en mi primer intento, me di cuenta de que no hab\u00eda paralelizaci\u00f3n en absoluto, y que los tiempos eran esencialmente los mismos que el bzip2 normal. Buscando respuestas en la documentaci\u00f3n encontr\u00e9 que la raz\u00f3n de ello era que la descompresi\u00f3n en paralelo era posible (al contrario que con gzip), pero s\u00f3lo para archivos creados por el propio pbzip2.<\/strong>. En otras palabras, tanto bzip2 como pbzip2 crean archivos con un formato compatible (pueden ser descomprimidos por la otra utilidad), pero la paralelizaci\u00f3n s\u00f3lo es posible si se crean y descomprimen con pbzip2. Para probar este segundo caso, utilic\u00e9 el mejor archivo comprimido obtenido en mis resultados previos (que era ligeramente m\u00e1s grande que el creado con bzip2) y volv\u00ed a probar los tests. \u00c9sta es la raz\u00f3n por la cual hay dos filas diferentes en los resultados globales para pbzip2.<\/p>\n
En ese segundo escenario, pbzip2 era una verdadera mejora sobre bzip2, obteniendo rates de descompresi\u00f3n de 356 MB\/s, aproximadamente equivalentes a los resultados de una copia directa mediante el sistema de archivos.<\/p>\n
Como era de esperar, el uso de m\u00faltiples hilos de descompresi\u00f3n es una clara ventaja en sistemas SMP<\/strong>, 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.<\/p>\n
Descompresi\u00f3n Lzma<\/h2>\n
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\u00ed que se us\u00f3 la versi\u00f3n de RedHat6, y plzip fue compilado a partir del c\u00f3digo fuente, tal y como hicimos anteriormente.<\/p>\n
El algoritmo Lzma se hab\u00eda clasificado como lento pero con muy buena compresi\u00f3n en nuestros resultados anteriores. Se puede extrapolar un resultado similar para la descompresi\u00f3n: tanto lzip como 7za proporcionan tiempos de descompresi\u00f3n 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\u00f3n monohilo. Plzip proporciona una mejor paralelizaci\u00f3n, alcanzando un uso de la cpu del 290%, pero el throughput nunca supera los 200 MB\/s.<\/p>\n
La evaluaci\u00f3n general es que son claramente mejores herramientas que los gzip y bzip2 monotarea, ya que proporcionan unos anchos de banda de descompresi\u00f3n similares pero con unos ratios de descompresi\u00f3n mucho mejores.<\/strong>.<\/p>\n
Herramientas “r\u00e1pidas”: lzop y lz4<\/h2>\n
Finalmente nos quedan las herramientas de compresi\u00f3n y descompresi\u00f3n r\u00e1pidas, 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\u00f3n similares a lzop, es m\u00e1s r\u00e1pido en la descompresi\u00f3n<\/strong>: casi dobla la velocidad (580 MB\/s de lzop contra los 1111 MB\/s de lz4). Obviamente, la \u00fanica raz\u00f3n por la cual estos resultados son posibles es porque el sistema de archivos est\u00e1 siendo utilizado, as\u00ed que tomad estos resultados con la debida precauci\u00f3n. Pero muestran la clase de ancho de banda de descompresi\u00f3n que se puede obtener cuando la latencia de disco no es el cuello de botella.<\/p>\n
Cuando el tiempo de los tests es tan peque\u00f1o, recomendar\u00eda repetirlo con tama\u00f1os de archivo mayores o limitando los efectos de la cach\u00e9 del sistema de archivos. Dejar\u00e9 esto como un ejercicio a realizar por el lector.<\/p>\n
Conclusiones<\/h2>\n
Aparte de las limitaciones encontradas en las distintas herramientas respecto a la paralelizaci\u00f3n en descompresi\u00f3n (pigz, pbzip2), no se han encontrado resultados muy extra\u00f1os. Las herramientas de compresi\u00f3n r\u00e1pida son r\u00e1pidas en descompresi\u00f3n (me he vuelto un fan de lz4) y las herramientas de mejor compresi\u00f3n son m\u00e1s lentas (plzip parece funcionar muy bien si no se est\u00e1 restringido por el tiempo de ejecuci\u00f3n y el uso de la CPU).<\/strong> Como siempre, mi recomendaci\u00f3n es probar siempre en el propio entorno, con los archivos y m\u00e1quinas propias, antes de sacar conclusiones prematuras.<\/p>\n
\u00bfQu\u00e9 herramienta de compresi\u00f3n usas para MySQL (o cualquier otro sistema de base de datos)? D\u00e9jame un comentario aqu\u00ed o en Twitter<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
En mi entrada de la semana pasada, analizaba algunos de las herramientas y formatos de compresi\u00f3n m\u00e1s comunes, as\u00ed como su velocidad y ratio de compresi\u00f3n. Aunque ello podr\u00eda darnos una buena idea del rendimiento de estas herramientas, el an\u00e1lisis<\/p>\n","protected":false},"author":1,"featured_media":324,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[85],"tags":[108,135,136,109,100,133,132,110,101,137,134,138,111,457,105,113,114,139,106,140,107,115],"class_list":["post-342","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mysql-es","tag-7z-es","tag-7za-es","tag-7zip-es","tag-bzip2-es","tag-compresion","tag-decompresion","tag-descompresion","tag-gzip-es","tag-lz4","tag-lzip-es","tag-lzma","tag-lzo-es","tag-lzop-es","tag-mysql-es","tag-p7zip","tag-pbzip2-es","tag-pigz-es","tag-rate-es","tag-ratio","tag-sql-es","tag-velocidad","tag-zip-es"],"_links":{"self":[{"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts\/342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/comments?post=342"}],"version-history":[{"count":6,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts\/342\/revisions"}],"predecessor-version":[{"id":360,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts\/342\/revisions\/360"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/media\/324"}],"wp:attachment":[{"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/media?parent=342"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/categories?post=342"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/tags?post=342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}