A maioria dos dados é armazenada em formatos de arquivo fáceis de ler para facilitar a interoperabilidade dos aplicativos. Embora existam formatos amplamente usados para compactação de imagem, vídeo e som, a maioria dos outros dados é armazenada como texto, como JSON, CSV ou outros formatos semelhantes baseados em texto.
Formatos como Parquet, Avro e ORC têm compactação opcional, portanto, normalmente, esses formatos já estão compactados quando armazenados. Vídeos e imagens também são normalmente compactados com algoritmos específicos de domínio que oferecem melhor compactação do que formatos genéricos.
No entanto, para dados personalizados, é preferível manter os dados num formato descomplicado que não inclua uma etapa de descompressão para acesso. Queremos oferecer uma opção para compactar esses dados antes de serem armazenados em discos.
A compactação para MinIO foi desenvolvida para permitir compactação transparente sem afetar o desempenho geral do sistema.
MinIO usa um método de compactação baseado em Snappy chamado S2. É compatível com conteúdo Snappy, mas possui duas extensões de formato . Em primeiro lugar, permite blocos maiores do que os blocos de 64 KB permitidos para fluxos Snappy. Isso melhora muito a compactação. Em segundo lugar, adiciona “compensações repetidas”, que oferecem melhorias de compactação principalmente para dados gerados por máquina, como arquivos de log, JSON e CSV. Ele também permite que correspondências com mais de 64 bytes sejam efetivamente codificadas, o que é um problema para o Snappy.
S2 também permite a compactação simultânea de vários blocos quando a entrada é mais rápida do que um único núcleo pode absorver. Isso é importante para manter alta a capacidade de resposta das solicitações individuais. Efetivamente, a limitação com mais de 16 núcleos será a velocidade da memória.
Alguns fornecedores de dispositivos prometem, ou até mesmo assumem, uma determinada taxa de compactação ao calcular o custo por TB. Com a compressão, não há proporção garantida acima de 1:1. Diferentes tipos de dados geram diferentes taxas de compactação e, em nossa opinião, não existe uma maneira significativa de fornecer qualquer taxa de compactação média. As taxas de compressão nunca devem ser avaliadas no vácuo – elas devem sempre ser combinadas com a velocidade de compressão, uma vez que a compressão prática é uma compensação entre esses dois fatores.
Vamos comparar um único tipo de dados para observar as diferenças. Comparamos implementações Go desses algoritmos em uma plataforma AMD64, usando até 16 núcleos.
Em primeiro lugar, o eixo horizontal é uma taxa de compressão truncada, redução obtida a partir do tamanho não comprimido. Certo é melhor. Para dar uma referência, o gzip nível 5 de thread único foi incluído.
Compressor | Velocidade MB/s | Tamanho | Redução | Dezembro MB/s |
---|---|---|---|---|
Padrão S2 | 15148 | 1043196283 | 83,37% | 2378 |
S2 melhor | 11551 | 954430842 | 84,79% | 2300 |
S2 Melhor | 680 | 832855431 | 86,73% | 2572 |
LZ4 mais rápido | 5645 | 1280414160 | 79,59% | 2680 |
LZ4 Melhor | 1552 | 1091826460 | 82,60% | 2694 |
Rápido | 946 | 1525176492 | 75,69% | 1828 |
Gzip L5 | 206 | 942726276 | 84,97% | 557 |
A velocidade de descompressão usa um único núcleo, embora o S2 ofereça descompressão simultânea.
Para esses dados, o Snappy fica cerca de 10% abaixo da referência Gzip. Como estamos lidando com porcentagens de redução, isso também significa que o Snappy ocupa cerca de 1,6x o espaço dos dados compactados Gzip. Isso ignora o fato de que o Snappy descompacta cerca de 4x mais rápido que o Gzip.
LZ4 é normalmente visto como superior ao Snappy. Uma implementação do LZ4 que permite a compactação em múltiplos núcleos também torna esse ponto mais claro. Mas a compactação básica é melhor. O LZ4 Best, às vezes também chamado de LZ4-HC, oferece compactação próxima ao gzip, mas embora a descompactação seja rápida, a compactação não ocorre em velocidades interativas.
S2 oferece três níveis de compactação; S2 Default é o mais rápido possível e pode ser visto como um concorrente direto do Snappy no que diz respeito ao uso de núcleo único. Com esse tipo de dados, ele apresenta desempenho melhor do que qualquer nível LZ4, com uma taxa de transferência significativamente maior. Este modo é usado pelo MinIO para plataformas onde uma implementação de montagem não está disponível.
S2 Better permite a troca de um pouco de CPU por maior compactação. Aqui a compressão rivaliza com o Gzip, mas a velocidade de descompressão é muito melhor. Este modo é usado pelo MinIO em plataformas onde o assembly está disponível – atualmente AMD64.
S2 Best é a melhor compactação que o S2 pode fazer com o formato atual. Isso pode ser usado em situações onde a velocidade/recursos de compactação não são os mais importantes, mas a descompactação rápida ainda é necessária. Atualmente o MinIO não usa este modo, mas pode implementá-lo como uma opção de ciclo de vida para objetos que não mudam há algum tempo.
Para comparar, aqui estão algumas comparações de outros tipos de dados:
Uma característica importante da compactação moderna é que ela se comporta bem com dados pré-compactados. Tradicionalmente, os dados pré-compactados têm sido um problema para algoritmos de compressão. Freqüentemente, os compressores desaceleravam de forma irracional quando confrontados com dados incompressíveis.
Portanto, muitas pessoas sabem instintivamente que é ruim recomprimir dados já compactados. No entanto, muitas implementações modernas agora são capazes, em um grau razoável, de pular rapidamente seções incompressíveis.
Para os compressores acima, estas são as velocidades em dados incompressíveis de 2GiB (2.147.483.647 bytes):
Compressor | Velocidade MB/s | Tamanho | Redução |
---|---|---|---|
Padrão S2 | 13045 | 2147487753 | 0,00% |
S2 melhor | 9894 | 2147487753 | 0,00% |
S2 Melhor | 3938 | 2147487753 | 0,00% |
LZ4 Rápido | 6400 | 2147485710 | 0,00% |
LZ4 Melhor | 12488 | 2147745841 | -0,01% |
Rápido | 6564 | 2147745801 | -0,01% |
Gzip (Ir) L5 | 63 | 2148139030 | -0,03% |
Gzip (alt) L5 | 5535 | 2147647512 | -0,01% |
Aqui também incluímos o gzip da biblioteca padrão Go como um representante desse “mau” comportamento. Uma implementação alternativa do gzip não mostra esse problema. Em todos os outros casos, o conteúdo é processado com bastante rapidez e eles são aprovados.
Isso significa que se espera que o MinIO lide bem com dados pré-compactados.
Uma desvantagem típica da compactação é que a capacidade de pular um arquivo é perdida. A solução para isso é compactar os blocos de forma independente e manter um índice que mapeia uma série de deslocamentos não compactados para deslocamentos compactados onde a descompactação pode começar.
A compactação de blocos independentes reduzirá ligeiramente a compactação, mas menos com blocos maiores. Snappy/S2comprime fluxos como blocos independentes por design.
Para MinIO, isso é relevante, pois as solicitações GetObject do S3 podem incluir intervalos opcionais para recuperação. Isso permite recuperar partes de objetos e queremos que isso seja o mais eficiente possível.
A partir de RELEASE.2022-07-13T23-29-44Z , agora geramos um índice para cada parte do arquivo carregada com mais de 8 MB. O índice é então anexado internamente aos metadados. Isso nos permite avançar efetivamente e decodificar apenas a parte do objeto necessária para retornar os dados solicitados.
O índice normalmente tem 16 bytes + aproximadamente 3 bytes por MB de dados. Isso permite que o MinIO sirva qualquer byte de um arquivo compactado na mesma velocidade que a recuperação do primeiro byte.
Por padrão, um parâmetro extra é necessário para o MinIO compactar os dados a serem criptografados no disco. Isso é para garantir que você esteja ciente das implicações disso.
Ao compactar dados você obtém dois números; o tamanho não compactado e o tamanho compactado. Sem compactação, qualquer pessoa que obtiver seus dados poderá ver apenas um deles: o tamanho não compactado.
Embora isso ainda não dê acesso a nenhum dado dentro do arquivo compactado, dá algumas dicas sobre os dados. Ele pode fornecer alguns tipos de dados que não podem ser. Se você vir um arquivo compactado em 50%, é extremamente improvável que ele contenha vídeo compactado em MP4.
Da mesma forma, um arquivo compactado em apenas alguns bytes provavelmente conterá uma sequência repetida muito simples. Não é possível dizer qual é a sequência, mas reduz as possibilidades. MinIO de RELEASE.2022-07-13T23-29-44Z preencherá a saída compactada para um múltiplo de 256 bytes. Este preenchimento não é registrado em lugar nenhum. Não consideramos isso uma solução completa para o problema, mas reduz bastante a utilidade das informações de tamanho vazadas para os adversários.
Este é o principal motivo pelo qual o MinIO não retorna nenhuma informação sobre os tamanhos compactados aos clientes. Portanto, qualquer informação sobre isso exigiria acesso ao armazenamento de back-end ou à comunicação de rede de back-end.
Com essas informações, você agora está equipado com conhecimento suficiente para determinar se considera seguro ativar a compactação e a criptografia.
Ataques do tipo CRIME não são possíveis no MinIO, pois não permitimos modificar ou anexar qualquer fluxo compactado. Também não desduplicamos/compactamos versões de objetos, pois isso vazaria muitas informações sobre os arquivos.
Por padrão, a compactação em disco está desabilitada no MinIO. A compactação no disco pode ser ativada ou desativada a qualquer momento. Para ativar a compactação no disco, use mc admin config set myminio compression enable=on
.
Isso permitirá a compactação para um número predefinido de extensões e tipos MIME. Por padrão, eles incluirão:
Extensões | Tipos de mímica |
---|---|
.txt.log.csv.json.tar.xml.bin | texto/*aplicativo/jsonapplication/xmlbinary/octet-stream |
Você pode inspecionar as configurações atuais com mc admin config get myminio compression
.
Você pode modificar esta lista a qualquer 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
Por padrão, o MinIO exclui à força extensões de dados comumente incompressíveis, como gzip, áudio, vídeo e arquivos de imagem.
É possível habilitar a compactação para todos os objetos, exceto os excluídos, definindo a lista de extensões e os tipos MIME como vazios:
mc admin config set myminio compression enable=on extensions= mime_types=
A configuração final é allow_encryption=on
, que permite a compactação mesmo para objetos que serão criptografados. Defina isso apenas depois de ler a seção acima e compreender as implicações.
MinIO oferece o melhor esquema de compactação que permite compactação totalmente transparente de dados em disco. Em muitos cenários, isso pode levar a uma redução nos custos de armazenamento, simplesmente habilitando a compactação.
O desempenho de GET e PUT deve, em todos os casos, permanecer próximo do mesmo quando a compactação estiver habilitada. Na verdade, em situações em que o desempenho é limitado pela velocidade de leitura do disco, a compactação pode oferecer desempenho adicional, pois é necessário ler menos dados.
Continuaremos adicionando novos recursos. No momento, estamos avaliando opções de configuração em nível de bucket/prefixo, bem como compactação por ciclo de vida, que compactará os arquivos à medida que eles atingirem uma determinada idade.
Se você estiver interessado nesses recursos, baixe o MinIO e experimente você mesmo. Se você tiver alguma dúvida ou quiser nos contar sobre os ótimos aplicativos que está criando usando o MinIO, envie um email para [email protected] , junte-se à comunidade Slack , siga nosso blog ou assine nosso boletim informativo.
Também publicado aqui .