Como você escolhe um mecanismo de banco de dados MySQL?

Question

Em particular, como você escolhe entre MyISAM e InnoDB, quando nenhum dos dois está faltando um recurso necessário (por exemplo, você não precisa de chaves estrangeiras).

Será sempre necessário tentar ambos e medir? Ou existem boas regras sobre o número e a frequência de leituras versus gravações e outras medidas como essa? O tamanho da tabela tem algum efeito na escolha típica?

    

Answer 1

A resposta é que você deve sempre medir, de preferência com seus próprios dados e carga de trabalho, se possível.

Como os padrões de acesso a dados podem variar muito de aplicativo para aplicativo, é difícil dizer e com toda a probabilidade impossível determinar um "melhor" mecanismo de armazenamento para todas as cargas de trabalho.

No entanto, há desenvolvimentos muito encorajadores no espaço do MySQL, tendo participado do MySQLConf / Percona Performance Conf na semana passada.

Alguns dos mecanismos de armazenamento alternativos:

1. XtraDB (fork do InnoDB)
2. Plugin InnoDB
3. PBXT
4. TokuDB

Além disso, Percona, Google, etc. contribuíram com patches que ajudam bastante no desempenho do InnoDB. Pessoalmente, eu corro uma construção OurDelta. Funciona muito bem para mim e eu encorajo a verificar as construções de OurDelta e Percona.

    

Answer 2

Se é apenas um simples sistema de armazenamento / relatório, eu uso o MyISAM para seu desempenho bruto.

Eu usaria o InnoDB se eu estivesse preocupado com vários acessos simultâneos com muitas gravações, para aproveitar o bloqueio em nível de linha.

    

Answer 3

Há um bom número de benchmarks por aí para diferentes mecanismos de banco de dados MySQL. Há um decente comparando MyISAM, InnoDB e Falcon no Percona MySQL Performance Blog , veja aqui .

Outra coisa a considerar entre os dois mecanismos mencionados acima (MyISAM e InnoDB) são suas abordagens de bloqueio. O MyISAM executa o bloqueio de tabelas, enquanto o InnoDB executa o bloqueio de linhas. Há uma variedade de coisas a serem consideradas, não apenas números absolutos de desempenho.

    

Answer 4

Existem recursos que você achará muito úteis, por motivos operacionais, mesmo que seu aplicativo não os exija de maneira absoluta:

• O InnoDB tem MVCC, o que significa que você pode fazer backups consistentes sem bloqueio
• O InnoDB tem recuperação automática, o que significa que não há operações demoradas do REPAIR TABLE após um desligamento não limpo
• Com o InnoDB, os leitores nunca bloqueiam escritores e vice-versa, o que significa (geralmente falando) uma maior simultaneidade (isso não significa necessariamente um melhor desempenho no caso geral)
• O InnoDB agrupa suas linhas na chave primária, o que PODE significar menos operações IO para operações de leitura SE a chave primária foi escolhida suficientemente bem.

Portanto, apesar das restrições de chave estrangeira, você provavelmente desejará usar o InnoDB mesmo assim.

é claro que isso é ServerFault, não estouro de pilha, então a resposta correta é:

• Você sempre deve usar o mecanismo que os desenvolvedores de aplicativos escolheram
• Se eles não tiverem escolhido um mecanismo específico, eles não são muito sérios sobre o uso do MySQL e provavelmente não sabem como usá-lo corretamente.
• Você não pode alternar para um mecanismo diferente daquele em que seu aplicativo foi testado, ele pode apresentar erros.

Answer 5

Meu provedor de hospedagem nos aconselhou a se livrar completamente do MyISAM e mudar para o InnoDB, a menos que isso não seja possível.

No nosso caso, estávamos com uma corrupção de dados grave, que começou a aparecer de algumas vezes a algumas vezes por dia, sempre exigindo REPAIR TABLE e comandos relacionados, o que levou muito tempo em tabelas grandes.

Uma vez convertidos (ou: convertidos) para o InnoDB, os problemas desapareceram instantaneamente. Desvantagens / advertências que tivemos:

• Não é possível converter tabelas com o índice FULLTEXT (esse problema desapareceu com o tempo por si só; ele foi substituído por uma solução baseada em Solr / Lucene que tem uma qualidade muito melhor)
• Tabelas grandes com milhões de linhas, que geralmente exigem COUNT (*), eram muito lentas. Também não pudemos alternar essas tabelas.

Mas observe: tudo isso é específico para o nosso ambiente, etc., portanto, geralmente não é aplicável.