Cómo habilitar la compresión de datos transparente en MinIO

La mayoría de los datos se almacenan en formatos de archivo fáciles de leer para facilitar la interoperabilidad de las aplicaciones. Si bien existen formatos ampliamente utilizados para la compresión de imágenes, videos y sonido, la mayoría de los demás datos se almacenan como texto, como JSON, CSV u otros formatos similares basados en texto.

Los formatos como Parquet, Avro y ORC tienen compresión opcional, por lo que normalmente estos formatos ya están comprimidos cuando se almacenan. Los vídeos y las imágenes normalmente también se comprimen con algoritmos específicos de dominio que ofrecen una mejor compresión que los formatos genéricos.

Sin embargo, para los datos personalizados, es preferible mantener los datos en un formato sencillo que no incluya un paso de descompresión para acceder. Queremos ofrecer una opción para comprimir estos datos antes de almacenarlos en discos.

Compresión transparente a velocidad IO

La compresión para MinIO se ha desarrollado para permitir una compresión transparente sin afectar el rendimiento general del sistema.

MinIO utiliza un método de compresión basado en Snappy llamado S2. Es compatible con el contenido de Snappy, pero tiene dos extensiones de formato . En primer lugar, permite bloques más grandes que los bloques de 64 KB permitidos para las transmisiones Snappy. Esto mejora enormemente la compresión. En segundo lugar, agrega "compensaciones de repetición", que ofrecen mejoras de compresión principalmente para datos generados por máquinas, como archivos de registro, JSON y CSV. También permite codificar eficazmente coincidencias de más de 64 bytes, lo cual es un problema para Snappy.

S2 también permite la compresión simultánea de múltiples bloques cuando la entrada es más rápida de lo que un solo núcleo puede absorber. Esto es importante para mantener alta la capacidad de respuesta de las solicitudes individuales. Efectivamente, la limitación con más de 16 núcleos será la velocidad de la memoria.

Relaciones de compresión

Algunos proveedores de dispositivos prometen, o incluso asumen, una relación de compresión determinada al calcular el costo por TB. Con la compresión, no hay una relación garantizada superior a 1:1. Diferentes tipos de datos producen diferentes índices de compresión y, en nuestra opinión, no existe una forma significativa de proporcionar un índice de compresión promedio. Las relaciones de compresión nunca deben evaluarse en el vacío; siempre deben combinarse con la velocidad de compresión, ya que la compresión práctica es una compensación de estos dos factores.

Comparemos un solo tipo de datos para observar las diferencias. Comparamos las implementaciones Go de estos algoritmos en una plataforma AMD64, utilizando hasta 16 núcleos.

En primer lugar, el eje horizontal es una relación de compresión truncada, reducción lograda a partir del tamaño sin comprimir. Lo correcto es mejor. Para dar una referencia, se ha incluido el nivel 5 de gzip de un solo subproceso.

La velocidad de descompresión utiliza un solo núcleo, aunque S2 ofrece descompresión simultánea.

Para estos datos, Snappy está aproximadamente un 10% por debajo de la referencia de Gzip. Dado que estamos tratando con porcentajes de reducción, esto también significa que Snappy ocupa aproximadamente 1,6 veces el espacio de los datos comprimidos Gzip. Esto ignora el hecho de que Snappy se descomprime aproximadamente 4 veces más rápido que Gzip.

LZ4 suele considerarse superior a Snappy. Una implementación de LZ4 que permite la compresión en múltiples núcleos también aclara este punto. Pero la compresión base es mejor. El LZ4 Best, también denominado a veces LZ4-HC, ofrece una compresión cercana a gzip, pero aunque la descompresión es rápida, la compresión no se realiza a velocidades interactivas.

S2 ofrece tres niveles de compresión; S2 Default es el más rápido posible y puede verse como un competidor directo de Snappy en lo que respecta al uso de un solo núcleo. Con este tipo de datos funciona mejor que cualquier nivel LZ4 con un rendimiento significativamente mayor. MinIO utiliza este modo para plataformas donde una implementación de ensamblaje no está disponible.

S2 Better permite intercambiar un poco de CPU por una mayor compresión. Aquí la compresión rivaliza con Gzip, pero la velocidad de descompresión es mucho mejor. MinIO utiliza este modo en plataformas donde está disponible el ensamblaje (actualmente AMD64).

S2 Best es la mejor compresión que S2 puede hacer con el formato actual. Esto se puede utilizar en situaciones en las que la velocidad/los recursos de compresión no son los más importantes, pero aún se necesita una descompresión rápida. Actualmente MinIO no usa este modo, pero puede implementarlo como una opción de ciclo de vida para objetos que no han cambiado por un tiempo.

Para comparar, aquí hay algunas comparaciones de otros tipos de datos:

Objetos incompresibles

Una característica importante de la compresión moderna es que se comporta bien con datos precomprimidos. Tradicionalmente, los datos precomprimidos han sido un problema para los algoritmos de compresión. A menudo, los compresores se ralentizaban excesivamente cuando se enfrentaban a datos incompresibles.

Por eso, muchas personas saben instintivamente que es malo recomprimir datos ya comprimidos. Sin embargo, muchas implementaciones modernas ahora pueden, en un grado razonable, omitir rápidamente secciones incompresibles.

Para los compresores anteriores, estas son las velocidades de datos incompresibles de 2GiB (2.147.483.647 bytes):

Aquí también incluimos gzip de la biblioteca estándar de Go como representante de este "mal" comportamiento. Una implementación alternativa de gzip no muestra este problema. En todos los demás casos, el contenido se procesa bastante rápido y obtienen el visto bueno.

Esto significa que se puede esperar que MinIO maneje bien los datos precomprimidos.

Buscando archivos comprimidos

Una desventaja típica de la compresión es que se pierde la capacidad de saltar dentro de un archivo. La solución para esto es comprimir bloques de forma independiente y mantener un índice que asigne una cantidad de desplazamientos sin comprimir a desplazamientos comprimidos donde puede comenzar la descompresión.

La compresión de bloques independientes reducirá ligeramente la compresión, pero menos con bloques más grandes. Snappy/S2 comprime transmisiones como bloques independientes por diseño.

Para MinIO, esto es relevante ya que las solicitudes GetObject de S3 pueden incluir rangos opcionales para recuperar. Esto permite recuperar partes de objetos y queremos que sea lo más eficiente posible.

A partir de RELEASE.2022-07-13T23-29-44Z ahora generamos un índice para cada parte del archivo cargado que tenga más de 8 MB. Luego, el índice se adjunta internamente a los metadatos. Esto nos permite avanzar de manera efectiva y solo decodificar la parte del objeto necesaria para devolver los datos solicitados.

El índice suele ser de 16 bytes + aproximadamente 3 bytes por MB de datos. Esto permite a MinIO entregar cualquier byte desde un archivo comprimido a la misma velocidad que recupera el primer byte.

Compresión + cifrado en reposo

De forma predeterminada, se requiere un parámetro adicional para que MinIO comprima los datos que se cifrarán en el disco. Esto es para garantizar que usted sea consciente de las implicaciones de esto.

Al comprimir datos obtienes dos números; el tamaño sin comprimir y el tamaño comprimido. Sin compresión, cualquiera que obtenga sus datos solo podrá ver uno de ellos: el tamaño sin comprimir.

Si bien esto todavía no le brinda acceso a ningún dato dentro del archivo comprimido, sí le brinda algunas pistas sobre los datos. Puede indicarle algunos tipos de datos que es imposible que existan. Si ve un archivo comprimido al 50%, es muy poco probable que contenga video comprimido MP4.

De manera similar, un archivo comprimido a sólo unos pocos bytes probablemente contendrá una secuencia repetida muy simple. No es posible saber cuál es la secuencia, pero reduce las posibilidades. MinIO de RELEASE.2022-07-13T23-29-44Z rellenará la salida comprimida a un múltiplo de 256 bytes. Este relleno no está registrado en ninguna parte. No consideramos que esto sea una solución completa al problema, pero reduce en gran medida la utilidad de la información de tamaño filtrada para los adversarios.

Esta es la razón principal por la que MinIO no devuelve ninguna información sobre los tamaños comprimidos a los clientes. Por lo tanto, cualquier información sobre esto requeriría acceso al almacenamiento de backend o a la comunicación de red de backend.

Con esta información, ahora tiene el conocimiento suficiente para determinar si considera seguro habilitar la compresión y el cifrado.

Los ataques de estilo CRIME no son posibles en MinIO, ya que no permitimos modificar ni agregar a ningún flujo comprimido. Tampoco deduplicamos/comprimimos entre versiones de objetos, ya que esto filtraría demasiada información sobre los archivos.

Configurar la compresión en MinIO

De forma predeterminada, la compresión en disco está deshabilitada en MinIO. La compresión en disco se puede habilitar o deshabilitar en cualquier momento. Para habilitar la compresión en el disco, utilice mc admin config set myminio compression enable=on .

Esto permitirá la compresión para un número preestablecido de extensiones y tipos MIME. Por defecto estos incluirán:

Puede inspeccionar la configuración actual con mc admin config get myminio compression .

Puedes modificar esta lista en cualquier momento modificando:

 mc admin config set myminio compression \ extensions=.txt,.log,.csv,.json,.tar,.xml,.bin \ mime_types=text/*,application/json,application/xml,binary/octet-stream

De forma predeterminada, MinIO excluye por la fuerza las extensiones de datos comúnmente incompresibles, como archivos gzip, audio, video e imágenes.

Es posible habilitar la compresión para todos los objetos, excepto los excluidos, configurando la lista de extensiones y los tipos mime en vacío:

 mc admin config set myminio compression enable=on extensions= mime_types=

La configuración final es allow_encryption=on , que permite la compresión incluso para objetos que serán cifrados. Configure esto solo cuando haya leído la sección anterior y comprenda las implicaciones.

Conclusión

MinIO ofrece el mejor esquema de compresión de su clase que permite una compresión totalmente transparente de datos en el disco. En muchos escenarios, esto puede conducir a una reducción de los costos de almacenamiento, simplemente habilitando la compresión.

El rendimiento GET y PUT debería permanecer en todos los casos casi igual cuando la compresión está habilitada. De hecho, en situaciones en las que el rendimiento está limitado por la velocidad de lectura del disco, la compresión puede ofrecer rendimiento adicional ya que es necesario leer menos datos.

Seguiremos agregando nuevas funciones. Actualmente estamos evaluando opciones de configuración a nivel de depósito/prefijo, así como la compresión mediante ciclo de vida, que comprimirá los archivos a medida que alcancen una determinada antigüedad.

Si está interesado en estas funciones, descargue MinIO y pruébelo usted mismo. Si tiene alguna pregunta o desea contarnos sobre las excelentes aplicaciones que está creando con MinIO, envíenos un mensaje de correo electrónico a [email protected] , únase a la comunidad de Slack , siga nuestro blog o suscríbase a nuestro boletín.