{"id":289,"date":"2014-08-13T12:53:02","date_gmt":"2014-08-13T10:53:02","guid":{"rendered":"http:\/\/dbahire.com\/?p=289"},"modified":"2014-10-09T11:46:26","modified_gmt":"2014-10-09T09:46:26","slug":"que-herramienta-de-compresion-deberia-usar-para-las-copias-de-seguridad-de-mi-base-de-datos","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\/","title":{"rendered":"\u00bfQu\u00e9 herramienta de compresi\u00f3n deber\u00eda usar para las copias de seguridad de mi base de datos? (Parte I: compresi\u00f3n)"},"content":{"rendered":"<p>Esta semana hablamos de tama\u00f1o, algo que deber\u00eda 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.<\/p>\n<p>A menudo recibo preguntas sobre cu\u00e1l es la mejor herramienta de compresi\u00f3n a aplicar en un sistema de copias de seguridad: \u00bfgzip? \u00bfbzip2? \u00bfalg\u00fan otro?<\/p>\n<h2>El entorno de pruebas<\/h2>\n<p>Para poder probar diferentes formatos y herramientas, cre\u00e9 un archivo .csv (comma-separated values, valores separados por comas) de tama\u00f1o <strong>3.700.635.579 bytes<\/strong> transformando un dump reciente de <a href=\"http:\/\/download.geofabrik.de\/europe\/spain.html\">todos los nodos de la porci\u00f3n europea de Espa\u00f1a en OpenStreetMap<\/a>. Ten\u00eda un total de <strong>46.741.126 de filas<\/strong> y ten\u00eda la siguiente pinta:<\/p>\n<pre>\r\n171773  38.6048402      -0.0489871      4       2012-08-25 00:37:46     12850816        472193  rubensd\r\n171774  38.6061981      -0.0496867      2       2008-01-19 10:23:21     666916  9250    j3m\r\n171775  38.6067166      -0.0498342      2       2008-01-19 10:23:21     666916  9250    j3m\r\n171776  38.6028122      -0.0497136      5       2012-08-25 00:26:40     12850816        472193  rubensd\r\n171933  40.4200658      -3.7016652      6       2011-11-29 05:37:42     9984625 33103   sergionaranja \r\n<\/pre>\n<p>De hecho, el fichero original es en realidad un tsv (tab-separated values, valores separados por tabuladores), y no un csv, pero s\u00f3lo porque soy demasiado vago como para a\u00f1adir el c\u00f3digo extra <code>FIELDS SEPARATED BY ','<\/code> cada vez que lo importo y exporto. Puede <a href=\"http:\/\/dbahire.com\/nodes.osm.7z\">descargar este archivo en formato 7z<\/a>, o crear el suyo propio desde los <a href=\"http:\/\/download.geofabrik.de\">extractos de OpenStreetMap de Geofabrik<\/a>.<\/p>\n<p>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\u00e1sicos (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.<\/p>\n<h2>Tama\u00f1o en tabla<\/h2>\n<p>Para una importaci\u00f3n a MySQL, propuse la siguiente estructura de tabla:<\/p>\n<pre>\r\nCREATE TABLE `nodes` (\r\n  `id` bigint PRIMARY KEY,\r\n  `lat` decimal(9,7),\r\n  `lon` decimal(10,7),\r\n  `version` int,\r\n  `timestamp` timestamp,\r\n  `changeset` bigint,\r\n  `uid` bigint,\r\n  `user` varchar(255)\r\n);\r\n<\/pre>\n<p>Y estos fueron los tama\u00f1os en la base de datos (una vez que nos aseguramos de que no hab\u00eda operaciones de escritura pendientes):<\/p>\n<ul>\n<li><strong>Archivo de datos MySQL en MyISAM (.MYD)<\/strong>: 2,755,256,596 bytes.(*)<\/li>\n<li><strong>Espacio de tablas MySQL de InnoDB (.ibd)<\/strong>: 3,686,793,216 bytes.<\/li>\n<li><strong>Espacio de tablas MySQL de InnoDB con formato de filas compressed (.ibd)<\/strong>: 1,736,441,856 bytes.<\/li>\n<\/ul>\n<p>\u00bfPor qu\u00e9 ocupa m\u00e1s espacio en texto plano que en la base de datos? Aunque las bases de datos est\u00e1n optimizadas para acceso r\u00e1pido, y no en ocupaci\u00f3n 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. <strong>\u00a1Esta es la raz\u00f3n por la que un dise\u00f1o adecuado de base de datos es cr\u00edtico para el rendimiento!<\/strong><\/p>\n<p>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\u00f1o de los \u00edndices en InnoDB puede crecer de manera bastante significativa cuando estamos usando m\u00faltiples claves secundarias (debido al almacenamiento de la clave privada, si \u00e9sta es lo suficientemente grande) y las m\u00faltiples 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\u00f3n justa entre MyISAM e InnoDB porque estamos comparando peras con manzanas.<\/p>\n<p>Lo que est\u00e1 claro es que la compresi\u00f3n (en este caso estamos usando el algoritmo por defecto de InnoDB con el nivel por defecto de compresi\u00f3n-6) est\u00e1 ayudando a reducir el espacio en disco, introduciendo potenciales mejoras en escenarios espec\u00edficos: m\u00e1s 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\u00f3 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\u00f3n de las sentencias SQL ser\u00eda injusto. <strong><a href=\"http:\/\/dbahire.com\/probando-la-manera-mas-rapida-de-importar-una-tabla-en-mysql-y-unos-resultados-interesantes-del-rendimiento-de-5-7\/\" title=\"Probando la manera m\u00e1s r\u00e1pida de importar una tabla en MySQL (y unos resultados interesantes del rendimiento de 5.7)\">Hablo m\u00e1s sobre tiempos de importaci\u00f3n en este post.<\/a><\/strong><\/p>\n<h2>Resultados globales<\/h2>\n<p>Los tama\u00f1os en tabla s\u00f3lo se mostraron como referencias, <strong>nuestro principal objetivo es testear las herramientas disponibles para comprimir el archivo original nodes.csv file<\/strong>. Me limit\u00e9 a m\u00ed mismo a algunas de las m\u00e1s populares, y en la siguiente tabla se pueden ver los resultados finales (el an\u00e1lisis, explicaci\u00f3n y discusi\u00f3n sigue a continuaci\u00f3n):<\/p>\n<pre>\r\nTama\u00f1o original  3700635579 bytes\t\t\t\t\t\r\n\t\t\t\t\t\t\t\r\nm\u00e9todo         mediana del tiempo de  tama\u00f1o comprimido  ratio de compresi\u00f3n             uso de cpu de la\r\n               compresi\u00f3n (seconds)   (bytes)            (tama\u00f1o_nuevo\/tama\u00f1o_original)  compresi\u00f3n (unix %CPU)\r\ndd               10.146               3700635579         100.00%                          97 -  68\r\ngzip            113.796                614119104          16.59%                         100 -  89\r\ngzip -1          43.219                729259339          19.71%                         100 -  67\r\ngzip -9         266.991                585777285          15.83%                          97 -  77\r\nbzip2           294.568                525839069          14.21%                          95 -  89\r\nbzip2 -1        281.337                508276130          13.73%                         100 -  80\r\nbzip2 -9        295.510                585777285          15.83%                         100 -  95\r\npigz             27.325                614093952          16.59%                         770 - 547\r\npigz -1          25.982                728206796          19.68%                         231 - 159\r\npigz -9          51.821                585756379          15.83%                         773 - 659\r\npbzip2           74.874                526311578          14.22%                         794 - 663\r\npbzip2 -1        60.487                508782016          13.75%                         800 - 495\r\npbzip2 -9*       76.597                526311578          14.22%                         773 - 394\r\nlzip           2138.230                357788948           9.67%                         100 -  70\r\n7za             833.611                380728938          10.29%                         172 - 145\r\n7za \"ultra\"    1286.044                354107250           9.57%                         178 - 164\r\nplzip           216.942                376484712          10.17%                         768 - 373\r\nplzip -1         50.151                581552529          15.71%                         781 - 738\r\nplzip \"ultra\"   426.486                354095395           9.57%                         785 - 159\r\nlzop             15.505               1003908508          27.13%                          95 -  50\r\nlzop -1          13.080               1000938935          27.05%                          90 -  63\r\nlzop -9         487.850                782234410          21.14%                          99 -  89\r\nlz4               8.537               1043868501          28.21%                          93 -  65\r\nlz4 -1*           8.574               1043868501          28.21%                          94 -  65\r\nlz4 -9           96.171                816582329          22.07%                          99 -  66\r\n<\/pre>\n<p>Como se puede ver, evalu\u00e9 varias herramientas en sus modos por defecto, as\u00ed como un modo de &#8220;alta compresi\u00f3n&#8221; y un modo &#8220;r\u00e1pido&#8221;. Para cada uno de ellos intent\u00e9 evaluar 3 par\u00e1metros, importantes para la creaci\u00f3n de archivos comprimidos: el tiempo de ejecuci\u00f3n, el tama\u00f1o final y los recursos usados. Tened en cuenta que <strong>s\u00f3lo evalu\u00e9 herramientas de compresi\u00f3n, y no de &#8220;archivado&#8221; (como tar o zip)<\/strong>. Estas \u00faltimas herramientas pueden utilizar diversos algoritmos de compresi\u00f3n tanto para comprimir cada archivo individualmente como aplicarlo al archivado final.<\/p>\n<p>La primera columna de datos muestra el n\u00famero de segundos (<em>wall-clock time<\/em>) que tard\u00f3 el proceso en escribir el archivo comprimido en una partici\u00f3n diferente del mismo conjunto de discos RAID. Se ejecutaron m\u00faltiples veces:<\/p>\n<pre>time [application] -c < nodes.csv > \/output\/nodes.csv.[format]<\/pre>\n<p>(excepto por 7z y dd, donde la sintaxis es diferente) y se tom\u00f3 el valor de la mediana con el objetivo de minimizar errores debido a factores externos. Para cada ejecuci\u00f3n, se comprobaba la correcci\u00f3n del archivo final (que el resultado era determinista y que pod\u00eda extraerse de vuelta a su tama\u00f1o original sin errores ni diferencias) y despu\u00e9s se borraba. Los resultados no son muy cient\u00edficos, ya que se hac\u00eda 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\u00e9n una ejecci\u00f3n de <code>dd<\/code> (copiado del archivo sin compresi\u00f3n) como valor de control.<\/p>\n<p>Creo que la segunda y tercera columna de datos son autoexplicativas: el tama\u00f1o en bytes del archivo comprimido y c\u00f3mo se compara respecto al archivo original.<\/p>\n<p>La \u00faltima columna intenta medir el uso de CPU m\u00e1ximo y m\u00ednimo, tal y como lo reporta el sistema operativo durante la compresi\u00f3n. Si embargo, debido al planficador de la CPU, y al hecho de que la mayor\u00eda de herramientas tienen un periodo de sincronizaci\u00f3n al principio o al final de la ejecuci\u00f3n, unidos con el echo de que se obtuvo mediante <em>polling<\/em> en intervalos de tiempo, hace que no sea muy significativo excepto para la comprobaci\u00f3n del uso del paralelismo en su algoritmo. Valores mayores que 100 indican que m\u00e1s de un core\/hilo de ejecuci\u00f3n se est\u00e1 usando para la compresi\u00f3n.<\/p>\n<p>No registr\u00e9 el uso de memoria (el otro recurso importante) porque incluso en modos &#8220;ultra&#8221;, su uso no fue significativo para mi m\u00e1quina con 32GB (menos de 1\/2 GB en todos los casos, la mayor\u00eda mucho menos). Consider\u00e9 que era algo que no deber\u00eda preocuparnos mucho en un m\u00e1quina que deber\u00eda tener suficiente RAM como una base de datos. Lo que s\u00ed quiz\u00e1 deber\u00eda tenerse en cuenta en un escenario real es la reserva de cach\u00e9 por el sistema de archivos, que podr\u00eda impactar de manera directa al rendimiento de MySQL. Prevenir que las p\u00e1ginas le\u00eddas y escritas vayan a la cach\u00e9 del sistema de archivos es algo que se puede hacer jugando con el flag <code>POSIX_FADV_DONTNEED<\/code>. Me gustar\u00eda mencionar tambi\u00e9n que ciertas herramientas, como bzip, disponen de un modo de bajo consumo de recursos: <code>bzip2 --small<\/code>.<\/p>\n<p><strong>Los tiempos de descompresi\u00f3n <a href=\"http:\/\/dbahire.com\/que-herramienta-de-compresion-deberia-usar-para-las-copias-de-seguridad-de-mi-base-de-datos-parte-ii-descompresion\/\"> los analizo en la segunda parte de este post<\/a>.<\/strong><\/p>\n<p>Los resultados globales se pueden apreciar mucho m\u00e1s claramente dibujados en un grafo bidimensional. He representado los valores de tiempo de compresi\u00f3n en el eje X (menos es mejor) y el ratio de compresi\u00f3n en el eje Y (menos es mejor):<\/p>\n<p><a href=\"http:\/\/dbahire.com\/wp-content\/uploads\/2014\/08\/compression2.png\"><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/dbahire.com\/wp-content\/uploads\/2014\/08\/compression2.png\" alt=\"Comparativa de tiempo y ratio de compresi\u00f3n de gzip, bzip2, pigz, pbzip2, lzip, p7zip, plzip, lzop y lz4, con diferentes par\u00e1metros y niveles\" title=\"Comparativa de tiempo y ratio de compresi\u00f3n de gzip, bzip2, pigz, pbzip2, lzip, p7zip, plzip, lzop y lz4, con diferentes par\u00e1metros y niveles\" width=\"700\" height=\"450\" class=\"alignnone size-full wp-image-263\" \/><\/a><br \/>\nSin representaci\u00f3n: dd (ratio de compresi\u00f3n del 100%), 7za &#8220;ultra&#8221; (21+ minutos para la compresi\u00f3n) y lzip (35+ minutos para la compresi\u00f3n).<\/p>\n<p>En general, podemos ver que no hay herramientas m\u00e1gicas, y que <strong>un mejor ratio de compresi\u00f3n requiere mas tiempo<\/strong> (el tama\u00f1o final es inversamente proporcional al tiempo de compresi\u00f3n). Tambi\u00e9n he representado la funci\u00f3n <code>y = 200\/x + 9<\/code>. \u00c9sta, o algo como <code>y = 200\/x+9.5<\/code> (es dif\u00edcil encontrar una buena correlaci\u00f3n con tan pocos resultados, la mayor\u00eda de ellos sin relaci\u00f3n entre s\u00ed) parece indicarnos el l\u00edmite inferior del ratio por unidad de tiempo, sugiriendo que un 9%-9.5% ser\u00eda el m\u00e1ximo ratio de compresi\u00f3n obtenible para este archivo con las herramientas disponibles en este momento.<\/p>\n<p>Analicemos los puntos fuertes y flacos de cada herramienta y formato de compresi\u00f3n.<\/p>\n<h2>Los famosos gzip y bzip2<\/h2>\n<p>Si lo que deseas es compatibilidad, gzip y bzip2 son los reyes. No s\u00f3lo son formatos de compresi\u00f3n altamente reconocidos sino que las herramientas para compresi\u00f3n y descompresi\u00f3n est\u00e1n preinstaladas en la mayor\u00eda de sistemas operativos tipo unix. Probablemente Windows es el \u00fanico sistema operativo que no soporta gzip por defecto. gzip y bzip2 son las \u00fanicas compresiones con su propia letra en tar (junto con <code>compress<\/code> en BSD y <code>xz<\/code> en GNU). <\/p>\n<p>Si bien la compatibilidad y disponibilidad son los puntos fuertes de estas herramientas, mirando al grafo <strong>podemos apreciar que est\u00e1n lejos de la l\u00ednea que mencionaba como ideal en ratio de tiempo\/tama\u00f1o<\/strong>. bzip2 proporciona un mayor ratio de compresi\u00f3n que gzip a cambio de m\u00e1s ciclos de cpu, pero ambas herramientas son monohilo y no brillan en ning\u00fan aspecto en particular. Sorprendentemente, <code>bzip2 -1<\/code> nos proporcion\u00f3 un tiempo de compresi\u00f3n peor y un mejor ratio que la ejecuci\u00f3n est\u00e1ndar de bzip2, y el manual de la versi\u00f3n gnu nos proporciona una explicaci\u00f3n para ello:<\/p>\n<pre>\r\nThe --fast and --best aliases are primarily for  GNU  gzip\r\ncompatibility.   In  particular,  --fast doesn't make things significantly faster.  And --best\r\nmerely selects the default behaviour.\r\n<\/pre>\n<p>(en espa\u00f1ol: <em>los alias &#8211;fast y &#8211;best son primordialmente para compatibilidad con GNU gzip. En particular, &#8211;fast no hace las cosas significativamente m\u00e1s r\u00e1pidas. Y &#8211;best simplemente selecciona el comportamiento por defecto<\/em>)<\/p>\n<p>Probablemente el mejor uso que recomendar\u00eda para estas herramientas ser\u00eda <code>gzip --fast<\/code> (equivalente a gzip -1) que, aunque no proporcione un nivel de compresi\u00f3n espectacular, lo hace de manera relativamente r\u00e1pida para una aplicaci\u00f3n de un s\u00f3lo hilo de ejecuci\u00f3n. Por lo tanto, puede ser \u00fatil 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\u00eda utilizar otras herramientas con una mejor velocidad o nivel de compresi\u00f3n.<\/p>\n<p>Para las pruebas utilic\u00e9 las versiones GNU de gzip 1.3.12 y bzip2 1.0.6.<\/p>\n<h2>Herramientas de compresi\u00f3n paralela: pigz y pbzip2<\/h2>\n<p>Las cosas se ponen m\u00e1s interesantes si se usan alguna de las versiones paralelas de gzip o bzip2 en un sistema multi-core. Aunque hay m\u00e1s de una versi\u00f3n, eleg\u00ed 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.<\/p>\n<p><strong>Ambas herramientas autodetectan el n\u00famero de cores que dispongo y realizan la compresi\u00f3n en 8 hilos de ejecuci\u00f3n, proporcionando ratios de compresi\u00f3n comparables pero en 4 veces menos de tiempo<\/strong>. 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\u00e1s realizando la compresi\u00f3n en un servidor dedicado aparte, el paralelismo es algo de lo que deber\u00edas tomar ventaja, ya que en general, la CPU es el mayor cuello de botella en un algoritmo de compresi\u00f3n.<\/p>\n<p>De nuevo, alguna cosa a destacar: pigz con los par\u00e1metros por defecto proporcion\u00f3 un buen ratio de compresi\u00f3n (16,89%) en menos de 28 segundos- eso es comprimir a cerca de 130MB\/s para mi modesto hardware (eso es m\u00e1s de un tercio de mi velocidad de copia, 350MB\/s). <\/p>\n<p>Como nota al margen, aunque pbzip2 acepta un nivel de compresi\u00f3n como par\u00e1metro, el nivel de compresi\u00f3n por defecto es -9.<\/p>\n<h2>Implementaciones de lzma: lzip, 7zip y plzip<\/h2>\n<p>Los siguientes test se realizados fueron distintas implementaciones de lzma, un algoritmo que tiene buena fama de proporcionar muy buenos ratios de compresi\u00f3n. <\/p>\n<p>Comenc\u00e9 por lzip. No est\u00e1 en los repositorios oficiales, as\u00ed que lo obtuve desde EPEL, instalando lzip 1.7. El ratio de compresi\u00f3n fue, efectivamente, el mejor de todos los algoritmos (cercano al 9.5%) pero tard\u00f3 35 minutos and 38 segundos en producir la salida. No s\u00f3lo el algoritmo ten\u00eda la culpa en este caso: usaba un \u00fanico hilo, de ah\u00ed el restraso.<\/p>\n<p>Despu\u00e9s de ello, utiliz\u00e9 p7zip 9.20, y en particular la herramienta unix 7za. Esta el la \u00fanica aplicaci\u00f3n de compresi\u00f3n probada que no es compatible con los par\u00e1metros de gzip. Tuve qe ejecutarla usando:<\/p>\n<pre>\r\ntime 7za a \/output\/nodes.csv.7z nodes.csv\r\n<\/pre>\n<p>Tenga en cuenta que p7zip es una aplicaci\u00f3n de archivado, pero hice una excepci\u00f3n para probar una implementaci\u00f3n alternativa de lzma.<\/p>\n<p>Los resultados fueron mejores: mientras que la herramienta proporcion\u00f3 un ratio de compresi\u00f3n peor (10.29%), gracias a alg\u00fan tipo de ejecuci\u00f3n en m\u00fatiples hilos, el tiempo se redujo a menos de 14 minutos. Tambi\u00e9n prob\u00e9 un sugerido modo &#8220;ultra&#8221; que encontr\u00e9 en el manual de 7za, con los siguientes par\u00e1metros:<\/p>\n<pre>\r\n-t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on\r\n<\/pre>\n<p>En resumen: maximizar el uso de memoria, nivel de compresi\u00f3n y tama\u00f1o del diccionario -aparte de forzar el formato de archivado y el algoritmo de compresi\u00f3n. Aunque esto proporcion\u00f3 un tama\u00f1o de archivo m\u00e1s peque\u00f1o (pero s\u00f3lo 25MB m\u00e1s peque\u00f1o, menos del 1% del tama\u00f1o original), el tiempo se increment\u00f3 hasta m\u00e1s de 21 minutos.<\/p>\n<p>Quise tambi\u00e9n probar una implementaci\u00f3n paralela de lzma, y plzip era exactamente eso. No pude encontrar un paquete rpm en ninguna parte, as\u00ed que descargu\u00e9 e instal\u00e9 desde c\u00f3digo fuente Lzlib 1.5 y plzip 1.2-rc2. Los resultados fueron muy buenos, tal y como esperaba. plzip proporciona resultados comparables a &#8220;pigz -9&#8221; cuando se ejecuta en &#8220;modo r\u00e1pido&#8221;; pero por defecto, en s\u00f3lo 3m37s obtuve un archivo comprimido de 359MB, o 10.17% del archivo original. Despu\u00e9s, intent\u00e9 emular las opciones &#8220;ultra&#8221; de p7zip (con <\/code>-9 -m 64 -s 33554432<\/code>) y <strong>obtuve el ganador en ratio de compresi\u00f3n (9.57%) en s\u00f3lo 7 minutos y 6.486 seconds<\/strong>.<\/p>\n<p>Obviamente, las mismas restricciones que mencion\u00e9 para las otras herramientas paralelas se aplican aqu\u00ed: el uso completo de m\u00faltiples cores se desaconseja en un servidor muy ocupado, pero si est\u00e1s almacenando los backups a largo plazo en un servidor separado, probablemenete quieras contemplar esta posibilidad. En cualquier caso, la mayor\u00eda de herramientas paralelas tienen una manera de limitar el n\u00famero de hilos creados (por ejemplo, con la opci\u00f3n <code>--threads<\/code> en lzip).<\/p>\n<h2>Herramientas de compresi\u00f3n r\u00e1pida: lzop and lz4<\/h2>\n<p>No quise terminar mis pruebas sin echar un vistazo a algunas de las herramientas de compresi\u00f3n de alto ancho de banda, as\u00ed que eleg\u00ed 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.<\/p>\n<p>Ambos proporcionan lo que prometen: <strong>algoritmos de compresi\u00f3n muy r\u00e1pidos<\/strong> (en algunos casos, incluso m\u00e1s r\u00e1pidos que una simple copia de archivo, ya que el cuello de botella no est\u00e1 en la CPU y tienen que escribir menos cantidad de datos) <strong>a cambio de peores ratios de compresi\u00f3n<\/strong> (21-30%). Para el archivo de ejemplo, en mi m\u00e1quina, obtuve un mejor rendimiento con lz4 que con lzop, ofreciendo ratios similares pero en menor tiempo (8.5 vs. 15.5 segundos). As\u00ed que, si tuviera que elegir, probablemente usar\u00eda lz4 antes que lzop en mi caso particular. Adicionalmente, aunque no se ha probado, lz4 presume de proporcionar mejores velocidades de descompresi\u00f3n.<\/p>\n<p>Como resalte negativo, recomendar\u00eda no utilizar nunca lzop -9, ya que en ese caso dispondr\u00edamos de herramientas con un mejor ratio de compresi\u00f3n en la mitad de tiempo. lz4 no tuvo un buen rendimiento tampoco con un mayor nivel de compresi\u00f3n, as\u00ed que recomendar\u00eda ce\u00f1irse a los par\u00e1metros por defecto o con un nivel menor de compresi\u00f3n para estas herramientas (de hecho, lz4 por defecto es equivalente a <code>lz4 -1<\/code>).<\/p>\n<h2>Conclusi\u00f3n<\/h2>\n<p>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\u00f3n. <strong>Si lo que quieres es compresi\u00f3n r\u00e1pida, usa lz4. Si quieres un tama\u00f1o de archivo peque\u00f1o, utiliza una implementaci\u00f3n de lzma<\/strong>, como p7zip. Los formatos bzip y gzip son buenas opciones si la compatibilidad es importante (ej. publicar un fichero), pero cuando sea posible, <strong>utiliza una implementaci\u00f3n de compresi\u00f3n paralela para mejorar el rendimiento<\/strong> (plzip, pbzip2, pigz). Podemos incluso utilizar una combinaci\u00f3n 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\u00e1quina separada, convertirlos a lzma para almacenamiento a largo plazo.<\/p>\n<p>Tambi\u00e9n te aconsejar\u00eda probar los distintos m\u00e9todos de compresi\u00f3n para tu conjunto de datos en particular y tu propio hardware ya que podr\u00edas obtener distintos ratios de compresi\u00f3n 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\u00ed, sin embargo, es tener un punto de partida desde la cual cada uno pueda sacar sus propias conclusiones.<\/p>\n<p>\u00bfEst\u00e1s de acuerdo conmigo? \u00bfCrees que he cometido alg\u00fan error en alg\u00fan punto? \u00bfEchas en falta algo? Escribe un comentario o m\u00e1ndame una respuesta a <a href=\"http:\/\/twitter.com\/dbahire_es\">twitter<\/a> o mediate <a href=\"http:\/\/dbahire.com\/contact\/\" title=\"Contact\">email<\/a>.<\/p>\n<p><em>Echa una vistazo a <a href=\"http:\/\/dbahire.com\/que-herramienta-de-compresion-deberia-usar-para-las-copias-de-seguridad-de-mi-base-de-datos-parte-ii-descompresion\/\">la parte II de este art\u00edculo para mi an\u00e1lisis de estas herramientas para la descompresi\u00f3n<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Esta semana hablamos de tama\u00f1o, algo que deber\u00eda 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\u00e1l<\/p>\n","protected":false},"author":1,"featured_media":263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[85],"tags":[108,99,103,109,100,102,110,101,111,457,112,105,113,114,104,106,107,115],"class_list":["post-289","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mysql-es","tag-7z-es","tag-backup","tag-base-de-datos","tag-bzip2-es","tag-compresion","tag-copia-de-seguridad","tag-gzip-es","tag-lz4","tag-lzop-es","tag-mysql-es","tag-mysqldump-es","tag-p7zip","tag-pbzip2-es","tag-pigz-es","tag-plzip","tag-ratio","tag-velocidad","tag-zip-es"],"_links":{"self":[{"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts\/289","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=289"}],"version-history":[{"count":16,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts\/289\/revisions"}],"predecessor-version":[{"id":554,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/posts\/289\/revisions\/554"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/media\/263"}],"wp:attachment":[{"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/media?parent=289"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/categories?post=289"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jynus.com\/dbahire\/wp-json\/wp\/v2\/tags?post=289"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}