Eu tenho lido sobre os formatos de arquivo do MySQL Antelope e Barracuda há algum tempo, e me pergunto se poderia me beneficiar com Barracuda e Compression.
Atualmente, meu servidor está usando o Antelope, pois é o padrão do MySQL.
Muitas vezes tive problemas com memória devido ao grande banco de dados que tenho. Meu banco de dados está aumentando a cada dia.
Parece que a compactação está trazendo benefícios para algumas pessoas, como:
http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/
Entendo que a memória e o espaço em disco podem ser menores, mas não tenho certeza se entendi isso (citado do artigo):
"~ 5% de carga da CPU de acordo com o topo (de 80 a 100%, principalmente aguardando E/S)
0,01 segundo tempo médio de pesquisa por chave primária (de 1 a 20 segundos antes da conversão)"
Achei que essas duas coisas NÃO melhorariam, porque se os dados forem compactados, o servidor terá que descompactar para obter os dados originais novamente, então não faz sentido que o uso da CPU aumente?
Isso beneficia você em aplicativos intensivos de leitura/gravação? Você me recomendaria mudar para Barracuda e Compression?
Você está ciente de algum problema do Barracuda?
Parece que a resposta da seguinte pergunta aponta alguns problemas, mas como é de 2011, eu diria que eles já estão corrigidos: https://serverfault.com/questions/258022/mysql-innodb-how-to-switch -para-barracuda-formato
Em relação ao "Dynamic" , o formato não compactado somente do Barracuda, muito pouco mudou do compacto, principalmente em como os blobs (e quaisquer campos muito dinâmicos) são armazenados . Nunca tive problemas com compacto versus dinâmico, então posso recomendar com segurança o dinâmico do Barracuda. Lembre-se de que o Barracuda também oferece suporte a formatos de linha redundantes e compactos antigos .
O artigo que você está mencionando é provavelmente muito antigo (5.1) e, como Peter Z., CEO da Percona, menciona nos comentários, pode ser um pouco enganador. Isso não significa que a compactação não possa ser um grande ganho dependendo das cargas de trabalho. No entanto, eu recomendaria que você o experimentasse em versões >= 5.6, pois tanto o Facebook quanto o Oracle fizeram muitas melhorias nele.
Como materiais de referência mais recentes, eu recomendaria:
Em particular, gosto dos materiais do Facebook, pois são de terceiros (sem necessidade de agenda) e possuem uma das maiores implantações de MySQL do mundo. Como você pode ver, eles tiveram configurações muito bem-sucedidas combinando tecnologia SSD com compactação.
Será que vai beneficiar você? Isso dependerá de sua carga de trabalho, conjunto de trabalho e configuração (IOPS, memória) . Dependendo se você está vinculado a IO, CPU ou memória, a compactação pode afetar negativamente em alguns casos, adicionando CPU extra, requisitos de memória (as páginas compactadas e não compactadas são armazenadas no pool de buffer InnoDB) ou gerando muitas falhas de compactação, aumentando a latência. Também depende do tipo de dados: a compactação pode ajudar muito com grandes blobs de texto, mas pode ser inútil com dados já compactados.
Na minha experiência, na prática, existem pessoas para quem a compressão era o santo graal do desempenho e estão muito felizes com isso, mas em outros casos, tivemos que reverter para dados descompactados porque nenhum ganho foi obtido. Embora uma carga de trabalho de gravação muito pesada possa parecer um ambiente ruim para compactação, se no seu caso específico você não estiver vinculado à CPU e à memória, mas ao IOPs, isso pode ser útil.
Em geral, é muito difícil prever resultados, geralmente você deve configurar um ambiente de teste para benchmarking e então descobrir porque você obtém resultados melhores ou piores (e assim você pode jogar com tamanhos de bloco diferentes, etc.). Barracuda é totalmente seguro. A compressão pode ou não ser para você. E você sempre pode experimentar outros métodos de compactação, como compactação de blobs no lado do cliente (por exemplo, se você acabar vinculado à CPU) ou outros mecanismos de terceiros, como RocksDB e TokuDB , nos quais a compactação é uma grande prioridade, pois é focada no desempenho para conjuntos de dados maiores do que o InnoDB pode suportar.
Resumindo: Os principais motivos para usar o Barracuda são manipulação de BLOB,
innodb_large_prefixcompatibilidade (índices grandes) e compactação. Dinâmico, no MySQL 8.0 agora é o formato de arquivo padrão.