Compressão de páginas do MariaDB: poupar espaço de armazenamento com perdas mínimas de desempenho

Página do MariaDB A compressão reduz as necessidades de memória física, comprimindo as páginas do InnoDB antes de serem gravadas no disco, o que diminui significativamente os volumes de E/S. Vou mostrar-lhe como poupar memória e manter a latência baixa, quais são os pré-requisitos e quais as configurações que têm maior impacto na prática.

Pontos centrais

Estes pontos-chave concisos apresentam os aspetos mais importantes.

• Página a página A compressão reduz o espaço ocupado e as operações de E/S.
• Não comprimido O buffer pool limita a carga da CPU na RAM.
• Flexível Ativação por tabela com PAGE_COMPRESSED.
• sistema de ficheiros- O suporte para Sparse/Hole Punching é obrigatório.
• Escolha do algoritmo controla a taxa, a latência e o consumo de CPU.

Como funciona, do ponto de vista técnico, a compressão de páginas do InnoDB

Compacto cada página InnoDB imediatamente antes de esta ser gravada no disco, de modo a que o espaço de tabela ocupe apenas os bytes efetivamente reduzidos e o sistema de ficheiros marque as áreas livres como «sparse». No Pool de buffer Continuo a manter as páginas não comprimidas, o que mantém baixo o consumo de CPU na memória principal e garante que os acessos de leitura frequentes continuem a ser rápidos. Por predefinição, as páginas InnoDB têm 16K, mas os blocos armazenados ficam variavelmente menores após a compressão, o que poupa muito espaço, especialmente em campos de texto ou JSON. Durante a leitura, descompacto a página logo após o carregamento na RAM, ou seja, exatamente no limite de E/S, onde a poupança na transmissão é mais significativa. Desta forma, transfiro a carga de E/S em relação à CPU, mas apenas nos casos em que tal se justifica.

Compressão de páginas vs. compressão clássica de tabelas InnoDB

A compressão clássica baseia-se em ROW_FORMAT=COMPRESSED e KEY_BLOCK_SIZE, o que cria um formato de página comprimido fixo e implica uma carga de decisão adicional durante a gravação ou atualização. Eu prefiro a Página Compressão, porque mantém a flexibilidade: se uma compressão não for bem-sucedida, o InnoDB pode armazenar a página sem compressão, sem alterar todo o formato do ficheiro. O buffer pool continua a funcionar com páginas de 16K sem compressão, o que agiliza os acertos na cache e mantém os percursos da CPU simples. Em cargas de trabalho OLTP típicas, com muitas inserções e atualizações moderadas, a compressão de páginas proporciona um melhor equilíbrio entre poupança de espaço e latência. Como resultado, obtenho frequentemente uma vantagem perceptível em termos de E/S, sem um overhead elevado em cada Atualização ao risco.

Requisitos e configuração básica

Para a compressão de páginas, assumo que o InnoDB está instalado e ativo innodb_file_per_table, para que cada tabela utilize o seu próprio espaço de tabela. O sistema de ficheiros é determinante: tem de suportar ficheiros esparsos e a técnica de «hole-punching», o que é o caso do ext4 e do XFS e que, em regra, está presente nos volumes modernos da nuvem. Para a escolha do algoritmo, defino o parâmetro `innodb_compression_algorithm`, normalmente `zlib`, `lz4` ou `lzo`, dependendo da taxa desejada e do perfil da CPU. Quem ponderar a camada de armazenamento beneficia de um formato compacto Comparação de sistemas de ficheiros e tem também em conta as opções de controladores e de volume. Desta forma, obtém-se uma Configuração, que poupa espaço, reduz as operações de E/S e funciona de forma fiável.

Ativação ao nível da tabela

Ativo a compressão de páginas por tabela, depois de verificar se as variáveis globais estão corretas, para poder abordar especificamente os registos que proporcionam o maior benefício possível. Para tabelas novas, defino as opções diretamente no DDL; no caso das tabelas existentes, um comando ALTER TABLE efetua a alteração através da reescrita. Defino o nível de compressão com PAGE_COMPRESSION_LEVEL; o comportamento depende do Algoritmo . Como a transição leva tempo, prevejo janelas de manutenção e verifico o espaço necessário com e sem compressão, com base em excertos de dados reais. É assim que verifico Despesas e um resultado sem surpresas.

CREATE TABLE log_entries (
    id BIGINT UNSIGNED PRIMARY KEY,
    created_at DATETIME NOT NULL,
    level VARCHAR(20),
    message TEXT
) ENGINE=InnoDB
  PAGE_COMPRESSED=1
  PAGE_COMPRESSION_LEVEL=6;

ALTER TABLE log_entries
  ENGINE=InnoDB,
  PAGE_COMPRESSED=1;

Poupança de espaço de armazenamento na prática

Quanto mais homogéneos e ricos em texto forem os dados, melhor será o efeito da Compressão; As tabelas de registo e de relatórios proporcionam, na maioria das vezes, efeitos significativos. Em cargas de trabalho típicas, vejo frequentemente uma redução de 40–60 % na memória ocupada com o zlib, enquanto o lz4 atende a muitos casos com 30–50 %, deixando assim mais largura de banda disponível. Os dados binários altamente distribuídos trazem menos benefícios, mas mesmo nesses casos os volumes de E/S e os custos reduzem-se frequentemente de forma notável. Faço sempre testes com instantâneos de produção no ambiente de staging, para obter rácios significativos e identificar picos de latência. O resultado: menos dados no suporte de armazenamento, tempos de transferência mais curtos, melhor Escalonamento.

Desempenho: Avaliar corretamente a relação entre E/S e CPU

Primeiro, verifico se o problema se encontra no suporte de dados ou no CPU é importante, pois é disso que depende a escolha do método de compressão. Em ambientes limitados em termos de E/S, os volumes de leitura e escrita diminuem significativamente, pelo que o desempenho efetivo aumenta, muitas vezes com apenas 5–10 % de carga adicional em comparação com tabelas não comprimidas, quando se utilizam algoritmos rápidos. Os sistemas limitados pela CPU beneficiam do lz4 ou do lzo, que funcionam muito rapidamente e atingem taxas apenas ligeiramente inferiores. Além disso, tenho em conta o Buffer de gravação dupla, porque influencia o comportamento de gravação e, juntamente com a compressão de páginas, determina as características de E/S. Uma vez que o conjunto de buffers permanece não comprimido, os acertos frequentes na cache quase não têm impacto na Latência de.

Escolha do algoritmo e nível de compressão

Eu decido o Algoritmo-Avalio com base em padrões de dados, velocidade de leitura/gravação e margem de CPU, em vez de me orientar apenas pela taxa de compressão. O Zlib proporciona frequentemente a maior poupança de espaço com um esforço computacional moderado, enquanto o lz4/lzo se destaca pela baixa latência. Utilizo o LZMA ou o bzip2 principalmente para arquivos ou tabelas que raramente são alteradas, uma vez que os custos de CPU são mais elevados. O nível de compressão (PAGE_COMPRESSION_LEVEL) regula a relação entre velocidade e esforço, embora com um utilidade marginal decrescente para além dos níveis médios. Uma breve série de medições com o conjunto de dados real permite identificar rapidamente a melhor Nível.

Algoritmo	Taxa típica	Custos da CPU	Adequação	Notas
zlib	40–60 %	Médio	Muitas tabelas OLTP/de relatórios	Bom Equilíbrio em termos de taxa/latência
lz4	30–50 %	Baixa	Elevados requisitos de rendimento	Muito rápido Descompressão
lzo	30–50 %	Baixa	Tarefas que envolvem muita escrita	Baixa latência nas inserções
lzma	50–70 %	Elevado	Arquivos/dados inativos	Para doenças raras Alterações
bzip2	50–70 %	Elevado	Histórias seletivas	Devagar, boa audiência

Manter-se a par do monitorização e das métricas

Medo a taxa de transferência, a latência, a utilização da CPU e Pool de buffer-Taxa de acertos, porque só a visão global revela o efeito real. Uma diminuição dos volumes de E/S com uma latência estável ou melhor indica que a configuração está a funcionar bem. Se a utilização da CPU ultrapassar um nível saudável, verifico o algoritmo e o nível e, se necessário, mudo para o lz4. Além disso, tenho em conta o tamanho do redo log e o comportamento dos checkpoints, uma vez que ambos influenciam o perfil de gravação. A longo prazo, identifico tendências e posso reagir de forma proativa às alterações Cargas de trabalho reagir.

Planear cuidadosamente as cópias de segurança e a manutenção

As cópias de segurança completas e incrementais beneficiam da menor volume de dados, porque são copiados menos bytes, enquanto os dumps lógicos mantêm, na maioria das vezes, o seu tamanho. Testo os tempos de recuperação com dados reais, para poder ponderar a poupança de espaço obtida em relação ao tempo prático de recuperação. Documento as alterações no algoritmo ou no nível e verifico a compatibilidade das ferramentas de cópia de segurança com a versão do MariaDB utilizada. Além disso, valido a integridade após grandes operações ALTER TABLE, especialmente quando muitas tabelas foram convertidas para a compressão de páginas. Desta forma, a Hora de arranque previsível e a estratégia de segurança fiável.

Compreender o sistema de ficheiros e o nível de armazenamento

Para que os ficheiros esparsos funcionem, o sistema de ficheiros necessita de Perfuração, o que está disponível no ext4 e no XFS e é amplamente utilizado em configurações de alojamento. Presto atenção às opções de montagem e à profundidade da fila, uma vez que influenciam significativamente as características de E/S. No caso do ext4, verifico, por exemplo, os intervalos de commit e os modos de journaling, e tenho em conta o efeito da recolha de lixo (garbage collection) em SSD/NVMe. Uma análise das opções adequadas Opções do ext4 ajuda a ajustar os efeitos da compressão de páginas às características do sistema de ficheiros. É assim que utilizo o espaço físico Armazenamento é eficaz e evita efeitos secundários.

Guia prático para a introdução

Começo por criar um ambiente de teste e copio dados representativos da produção, para obter os primeiros valores de medição relativos à taxa, à latência e Rendimento . Depois, ativo a compressão de páginas, em primeiro lugar, em tabelas grandes, utilizadas principalmente para leitura, ou em arquivos com poucas atualizações. Avalio os resultados com base em indicadores claros e comparo-os com o estado inicial, antes de aplicar a alteração a outras tabelas. A comunicação atempada com as equipas de aplicações evita surpresas durante as janelas de manutenção e garante expectativas claras. Após cada expansão, ajusto o nível e Algoritmo até que a poupança de memória e a latência se situem no intervalo alvo.

Combinação com outras otimizações

Bons índices reduzem o número de páginas lidas, por isso verifico Cobertura do índice e cardinalidades regularmente. Consultas bem formuladas, junções adequadas e a utilização específica do EXPLAIN reduzem as operações de E/S e mantêm elevada a taxa de acertos na cache. Um tamanho de buffer pool suficientemente grande evita cargas desnecessárias a partir do disco e torna a sobrecarga da compressão no hotset praticamente imperceptível. No que diz respeito ao hardware, os SSDs e o NVMe compensam pelo elevado número de IOPS e pela baixa latência, o que reforça as vantagens da compressão de páginas. Em suma, a compressão interage com o design das consultas, o trabalho de indexação e Ampliação da capacidade de armazenamento juntas, formando assim um percurso de dados simplificado.

Compatibilidade, versões e limitações

Fico atento aos ambientes que suportam a compressão de páginas e aos seus limites. Em sistemas de ficheiros Linux comuns, como o ext4 e o XFS, o «hole-punching» funciona de forma estável. O ZFS comporta-se de forma diferente: uma vez que o «punching» não está disponível de forma equivalente nesse sistema, no ZFS opto mais pelo nativo Ativo a compressão ZFS e não utilizo a compressão de páginas. Em configurações de contentores com OverlayFS, prefiro montar o diretório de dados como uma montagem Bind a partir do anfitrião, para que o «punching» e os ficheiros esparsos funcionem de forma fiável. Além disso, não combino a compressão de páginas com a encriptação de tabelas InnoDB ao nível do ficheiro: a encriptação torna os dados, em grande parte, aleatórios para os algoritmos de compressão e, em alguns casos, também bloqueia o «punching». Quem necessite de ambas as funcionalidades deve optar pela encriptação de volume/sistema de ficheiros abaixo do InnoDB.

No que diz respeito ao tamanho da página InnoDB (innodb_page_size), costumo manter o valor em 16K. Tamanhos de página mais pequenos podem dificultar a compressão e aumentar os custos de gestão. As tabelas temporárias ou as tabelas MEMORY/de trabalho não são afetadas pela compressão de páginas – o ganho ocorre apenas no respetivo espaço de tabela .ibd.

Ativação, desativação e reconstruções sem surpresas

A alteração através do comando ALTER TABLE implica sempre uma reconstrução da tabela. Por isso, pretendo:

• Janela de manutenção com SLAs claros e espaço de armazenamento suficiente para a cópia temporária.
• Verificação prévia com EXPLAIN para ALTER, para ver o procedimento esperado (INPLACE/COPY, nível de LOCK).
• Estratégia opcional de processamento em lotes: primeiro as tabelas grandes, que raramente são alteradas; depois, as de tamanho médio; e, por fim, as tabelas mais ativas – se for o caso.

Para desativar esta funcionalidade, sigo um procedimento simétrico e defino PAGE_COMPRESSED=0. Em seguida, executo um OPTIMIZE TABLE ou um novo ALTER-Rebuild, para que o tablespace volte a ser gravado sem lacunas e o consumo de espaço físico seja refletido de forma realista.

Carregamentos em massa, atualizações a quente e desfragmentação

No caso de grandes volumes de dados, ou faço o carregamento diretamente de forma comprimida, quando a E/S é limitada, ou acelero a importação carregando os dados sem compressão e, posteriormente, alterando o formato para PAGE_COMPRESSED com o comando ALTER TABLE. Posteriormente, a reconstrução impõe o layout ideal com o máximo efeito de «perfuração». No caso de tabelas com um grande número de atualizações no local (in-place), planeio reescritas regulares (OPTIMIZE TABLE ou rollovers de partição), pois as alterações repetidas podem reduzir as vantagens da compressão ao longo do tempo. Para colunas BLOB/TEXT, opto por um formato de linha moderno (por exemplo, DYNAMIC), para que os dados off-page de grande dimensão sejam geridos de forma eficiente e a vizinhança da página não aumente desnecessariamente.

Verificar e comprovar a eficácia

Para verificar se a compressão de páginas está a funcionar, utilizo comandos simples do sistema e vistas do MariaDB:

# Comparar tamanho aparente vs. blocos ocupados
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd

# Verificar a extensão da fragmentação (punching) por ficheiro
filefrag -v your_table.ibd | tail -n +1

# No MariaDB: verificar o estado das tabelas e as opções DDL
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G

O tamanho aparente (ls) mantém-se no volume lógico de dados, enquanto mostra os blocos efetivamente ocupados. Uma diferença percetível indica que o «hole-punching» está a funcionar corretamente. Correlaciono esta medição com métricas de E/S (leituras/gravações por segundo, profundidade da fila, latência) e a utilização da CPU, para avaliar o efeito global.

Detalhes da cópia de segurança: como efetuar uma cópia de segurança e restaurar ficheiros «sparse» corretamente

Para que as cópias de segurança respeitem a poupança de espaço, certifico-me de que as ferramentas suportam o formato „sparse“. Ao copiar ficheiros físicos, utilizo os parâmetros adequados para que os espaços vazios não sejam «preenchidos»:

# Copiar mantendo as áreas esparsas
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir

# Verificar se o destino continua a ser esparso
du -h dest.ibd
ls -ls dest.ibd

No caso das cópias de segurança do tipo «snapshot» (por exemplo, ao nível do dispositivo de bloco), a poupança varia consoante o fornecedor. No caso dos dumps lógicos (mysqldump, mariadb-dump), o tamanho da exportação praticamente não se altera, mas os tempos de restauração diminuem se a reconstrução subsequente reativar a compressão de páginas, reduzindo assim os volumes de E/S durante a reconstrução.

Replicação, HA e implementações em ambiente de produção

A compressão de páginas funciona de forma transparente para a replicação e os binlogs, uma vez que são replicadas as alterações SQL e não as páginas comprimidas. Prefiro aplicar primeiro as alterações DDL nas réplicas e observar a latência e a E/S antes de alterar a configuração do servidor primário. Em topologias multi-fonte ou em cascata, certifico-me de que está definido um algoritmo adequado (innodb_compression_algorithm) em todos os pontos, para que um DDL idêntico tenha o mesmo comportamento. Para implementações sem tempo de inatividade, combino a mudança com planos de switchover/failover.

Ajuste mais aprofundado: perfis de E/S e pontos de verificação

Como a compressão altera o número e o tamanho dos blocos a gravar, ajusto os parâmetros de E/S do InnoDB de acordo com o novo perfil. Um valor realista para innodb_io_capacity (e *_max) ajuda a gerar checkpoints limpos, sem picos repentinos de flush. Verifico se o buffer de dupla gravação está em sintonia com a nova característica de gravação e monitorizo a relação entre páginas sujas e taxa de fsync. Em dispositivos com elevado paralelismo (NVMe), dimensiono os threads de gravação e a profundidade da fila do dispositivo de bloco, para que a menor quantidade de dados se traduza numa redução real da latência.

Resolução de problemas e dificuldades típicas

• Picos de utilização da CPU após a ativação: Mudar o algoritmo para lz4/lzo ou reduzir moderadamente o PAGE_COMPRESSION_LEVEL; aumentar os conjuntos ativos no buffer pool.
• A E/S diminui, mas a latência oscila: Verificar o checkpointing e a taxa de páginas sujas; os registos de redo demasiado pequenos provocam flushes frequentes.
• Poupança de espaço inesperadamente reduzida: Verificar a estrutura dos dados (muitos campos binários/aleatórios), forçar a reconstrução, analisar os padrões BLOB/TEXT e, se necessário, mudar para o zlib.
• Sem impacto no tamanho do ficheiro: Verificar se o sistema de ficheiros suporta a função „Hole-Punching“, evitar a camada de contentores, não «despreencher» a cópia esparsa.
• Tabelas muito comentadas: Utilizar a compressão de páginas de forma seletiva; avaliar alternativas (comprimir apenas as tabelas de arquivo/registo).

Exemplos práticos de configuração

Para começar de forma organizada, considero que a configuração global deve ser sucinta e fácil de gerir:

[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib   # ou lz4/lzo, dependendo do perfil
# ajustar outros parâmetros de E/S de acordo com a plataforma
# innodb_io_capacity=...
# innodb_io_capacity_max=...

Para cada tabela, defino explicitamente a compressão, para evitar efeitos colaterais indesejados. Após grandes importações ou muitas atualizações, utilizo o comando OPTIMIZE TABLE de forma seletiva, para recalibrar os espaços vazios e reduzir a fragmentação acumulada ao longo do tempo.

Brevemente resumido

A compressão de páginas do InnoDB reduz significativamente o consumo de memória e alivia a carga de E/S para a CPU, sem alterar o buffer pool. Algoritmos bem escolhidos, como o lz4 ou o zlib, proporcionam uma redução de 30 a 60 % em muitas cargas de trabalho e mantêm a latência dentro dos limites aceitáveis. São fundamentais um sistema de ficheiros com «hole-punching», a opção innodb_file_per_table e uma ativação correta ao nível da tabela. Quem realizar testes com dados reais, integrar monitorização e ajustar com precisão os níveis e os algoritmos, consegue custos baixos de forma sustentável, com um desempenho fiável Desempenho. Desta forma, poupa espaço, mantém os seus sistemas ágeis e ganha capacidade para lidar com conjuntos de dados cada vez maiores.