Como você escolhe um mecanismo de banco de dados MySQL

16

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

Sempre se trata de tentar os dois e medir? Ou existem boas regras práticas 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 sobre a escolha típica?

mysql innodb myisam

— Tony Meyer
fonte

6

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 o "melhor" mecanismo de armazenamento para todas as cargas de trabalho.

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

Alguns dos mecanismos de armazenamento alternativos:

XtraDB (fork do InnoDB)
Plugin InnoDB
PBXT
TokuDB

Além disso, a Percona, o Google etc. contribuíram com patches que ajudam muito no desempenho do InnoDB. Pessoalmente, eu executo uma compilação OurDelta. Funciona muito bem para mim e incentivo a verificação das versões OurDelta e Percona.

— Jauder Ho
fonte

Se você estiver interessado em benchmarks, tente sysbench ou iibench.

— Jauder Ho 30/04/09

Algum dos mecanismos de armazenamento alternativos é estável o suficiente para ser adequado para um local de produção?

— 22710 Tony Meyer

Don MacAskill está pensando em colocar o XtraDB em produção. YMMV.

— Jauder Ho 30/04/09

O desempenho não é o único requisito - considerar questões operacionais, bem como (na verdade, eles são geralmente mais importante, na minha experiência)

— MarkR

Obviamente, o desempenho não é o único requisito, embora eu acredite que o pedido original estava perguntando mais sobre o desempenho. Outras considerações, como operacional (como você indica) e recursos, todos desempenharão um papel no processo de seleção.

— 21609 Jauder Ho

5

Se for apenas um sistema simples de armazenamento / relatório, utilizo o MyISAM para o desempenho bruto.

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

— Alnitak
fonte

11

Para qualquer carga de trabalho que combine leituras e gravações, o InnoDB é a única opção (atualmente remessa).

— Dave Cheney

4

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 ao bloqueio. O MyISAM executa o bloqueio de tabela, enquanto o InnoDB executa o bloqueio de linhas. Há uma variedade de coisas a considerar, não apenas números de desempenho absolutos.

— James B
fonte

4

Existem recursos que você achará muito úteis, por razões operacionais, mesmo que seu aplicativo não exija absolutamente:

O InnoDB possui MVCC, o que significa que você pode fazer backups consistentes sem bloqueio
O InnoDB possui recuperação automática, o que significa que não há operações demoradas REPAIR TABLE após um desligamento imundo
Com o InnoDB, os leitores nunca bloqueiam escritores e vice-versa, o que significa (geralmente falando) maior simultaneidade (embora isso não deva significar melhor desempenho no caso geral)
O InnoDB agrupa suas linhas na chave primária, o que PODE significar menos operações de 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 deseja usar o InnoDB de qualquer maneira.

é claro que se trata de ServerFault, não Stack Overflow, portanto a resposta correta é:

Você sempre deve usar o mecanismo escolhido pelos desenvolvedores de aplicativos
Se eles não escolheram um mecanismo específico, não levam muito a sério o uso do MySQL e provavelmente não sabem como usá-lo corretamente.
Você não pode mudar para um mecanismo diferente daquele em que seu aplicativo foi testado, pois pode apresentar erros.

— MarkR
fonte

2

Você realmente acha que o mecanismo de banco de dados é uma decisão do desenvolvedor, não dos administradores? Como desenvolvedor, quero dizer "Eu tenho esses dados, com os quais farei isso" e deixar a otimização (e o backup e ...) do banco de dados para o administrador.

— 1811 Tony Meyer

11

Sim, o desenvolvedor precisa ser capaz de desenvolver e testar seu aplicativo em um mecanismo específico; eles se comportam de maneira muito diferente, tanto funcionalmente quanto no desempenho.

— 277 MarkR MarkR

2

Meu provedor de hospedagem nos aconselhou a nos 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çava a aparecer algumas vezes a algumas vezes por dia, sempre exigindo REPAIR TABLE e comandos relacionados, que levavam anos em tabelas grandes.

Depois que convertemos (ou: fomos 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 ao longo do tempo por si só; foi substituído por uma solução baseada em Solr / Lucene que, de qualquer maneira, tem uma qualidade muito melhor)
As grandes tabelas com milhões de linhas que geralmente exigem COUNT (*) eram muito lentas, também não conseguimos alterná-las.

Mas observe: tudo isso é específico ao nosso ambiente, etc., portanto, geralmente não se aplica.

— marca
fonte

Somente selecionar count ( ) da tabela é mais rápido no MyISAM. Selecione count ( ) da tabela em que column = value tem desempenho semelhante no MyISAM e no InnoDB. mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables

— sumar