Desde a versão 5.5 do MySQL o storage engine InnoDB vem configurado “de fábrica” como padrão.
O InnoDB é um storage engine transacional, 100% ACID, estável e robusto, e, inteiramente, grátis. Reconhecidamente, fez progressos notáveis desde o MySQL 4.x. Com destaques para as melhorias implementadas nas versões: 5.1, 5.5, 5.6, e, recentemente na 5.7.
O fato de o InnoDB vir de fábrica como padrão, nada nos impede de criarmos tabelas (ou alterarmos) utilizando a opção ENGINE, para que estas reflitam o storage engine que mais nos atende.
Os bancos de dados relacionais tradicionais, não utilizam o conceito de storage engine (tipo de tabela). Isto é uma inovação, e um mérito, do MySQL. Alguns acham que é uma falha, um bug. Mas, é uma poderosa funcionalidade (feature) muito bem vinda.
Declarar a morte do MyISAM é, em certa medida, declarar a morte de uma das características mais empolgantes do MySQL: o Storage Engine (motor de armazenamento).
É fato que a maioria das aplicações, ou em termos de banco de dados, a maioria das tabelas serão do tipo transacional, portanto InnoDB. Mas, há muito espaço para o MyISAM. E duvido, que estejamos presenciando a morte do MyISAM.
Gosto muito de compartilhar o exemplo do Zabbix, que é uma ferramenta excepcional de monitoramento. Certa vez, fiz uma manutenção em uma tabela de 700 gigas. Apenas alterando o Engine de InnoDB para MyISAM, o tamanho despencou para menos de 100 gigas. Pare e pense, se uma captura de monitoramento de servidor deixar de ser salva/registrada, isso afetará o negócio da empresa? Por que usar transação??
MyISAM pode ser utilizado de forma, digamos pouco nobre, para armazenar dados que podem sofrer de completude, ausência, redundância, e integridade. Mas, não pode deixar de ser, altamente, performático.
Entre MyISAM e InnoDB, qual deve ser escolhido? É mais simples do que parece, basta perguntar para suas entidades e/ou tabelas:
- Transação: Se os dados precisam estar protegidos e orquestrados por uma transação, InnoDB.
- Integridade Referencial (chave estrangeira): Se jamais será utilizado integridade referencial, MyISAM.
- Granularidade: travamentos a nível de linha (locks), e, leituras sem “locks”, InnoDB.
- Performance: ÜberSpeed! Alta performance em leituras e escritas, definitivamente, MyISAM.
- Recuperação automática: Quando houver algum problema em páginas de dados ou índices, uma recuperação online e rápida é bem-vinda, InnoDB.
- Footprint (espaço em disco): Cada linha do Innodb ocupa, pelo menos 1K. Imagine se voce tem um punhando de tabelas com menos de 500 bytes de comprimento? Se footprint é um requerimento: MyISAM.
O fato é que podemos ficar fazendo esse jogo de Spy vs Spy o artigo inteiro. InnoDB e MyISAM são diferentes animais. Para usos e casos diferentes.
Eu, prefiro adotar uma abordagem menos apaixonada e objetiva:
InnoDB: todas as tabelas transacionais, absolutamente todas!
MyISAM: Todas as tabelas não transacionais, tais como:
- Sumarizadas
- Log
- Ingestão de dados para futuro processamento e consumo
- Intermediárias (preparação para relatórios)
- Dashboards
- Filas
- Staging (ETL)
Portanto, eu escolho MyISAM se a maioria dos seguintes requisitos forem atendidos: pode ser reconstruída, não é a fonte primária dos dados, uso temporário ou dinâmico (staging), processo de ETL, alguma falta de dado e/ou integridade é aceitável.
A verdade é que existe muito espaço para MyISAM, e, não veremos sua morte tão cedo. Pode apagar as velas!
Visite nosso Blog
Saiba mais sobre bancos de dados
Aprenda sobre monitoramento com ferramentas avançadas
Tem dúvidas sobre nossos serviços? Acesse nosso FAQ
Quer ver como ajudamos outras empresas? Confira o que nossos clientes dizem nesses depoimentos!
Conheça a História da HTI Tecnologia
