ti-enxame.com

Como você escolhe um mecanismo de banco de dados MySQL

Em particular, como você escolhe entre Myisam e InnoDB, quando nem falta um recurso necessário (por exemplo, você não precisa de chaves estrangeiras).

Sempre desce para tentar ambos e medindo? Ou há boas regras de polegar em relação ao número e frequência de leituras versus gravações e outras medidas como essa? O tamanho da tabela tem algum efeito na escolha típica?

16
Tony Meyer

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 do aplicativo para app, é difícil dizer e, com toda a probabilidade impossível de determinar um "melhor" motor de armazenamento para todas as cargas de trabalho.

No entanto, existem 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 (garfo de innodb)
  2. Plugin InnoDB.
  3. Pbxt.
  4. Tokudb.

Além disso, o PERCONA, o Google, etc. contribuíram com patches que ajudam muito com o desempenho do InnoDB. Pessoalmente, eu corro uma construção de nossos créditos. Funciona muito bem para mim e encorajo a verificação da Ourdelta e PERCONA.

6
Jauder Ho

Se é apenas um sistema simples de loja/relatório, uso Myisam pelo seu desempenho bruto.

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

5
Alnitak

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 motores acima mencionados (Myisam e InnoDB) são suas abordagens para travar. Myisam realiza bloqueio de mesa, enquanto a InnoDB executa o bloqueio de linha. Há uma variedade de coisas a considerar, não só figuras de desempenho francamente.

4
James B

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

  • InnoDB tem MVCC, o que significa que você pode fazer backups consistentes sem bloqueio
  • InnoDB tem recuperação automática, o que significa que não há operações de mesa de reparo longas após um desligamento impuro
  • Com o InnoDB, os leitores nunca bloqueiam escritores e vice-versa, significando (geralmente falando) maior concorrência (isso não precisa significar melhor desempenho no caso geral embora)
  • InnoDB clustera suas linhas na chave primária, o que pode significar menos IO operações para operações de leitura se a chave primária foi escolhida suficientemente bem.

Portanto, não obstante as restrições de chave estrangeira, você provavelmente quer usar o InnoDB de qualquer maneira.

claro que este é o serverfault, não o estouro de pilha, então a resposta adequada é:

  • Você deve sempre usar o mecanismo que os desenvolvedores de aplicativos escolheram
  • Se eles não tiverem escolhido um motor específico, eles não são muito sérios em usar o MySQL, e provavelmente não sabem como usá-lo corretamente.
  • Você não pode mudar para um motor diferente para aquele que seu aplicativo foi testado, ele pode introduzir bugs.
4
MarkR

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

No nosso caso, estávamos tendo uma corrupção severa de dados que começou a aparecer a partir de algumas vezes para algumas vezes por dia, sempre exigindo tabela de reparos e comandos relacionados, que levavam as idades em grandes mesas.

Uma vez que convertemos (ou: foram convertidos) para InnoDB, os problemas instantaneamente foram embora. Downsides/advertências que tivemos:

  • Não é possível converter tabelas com índice completo (este problema foi embora ao longo do tempo; foi substituído por uma solução baseada em solr/luceno que tem muito melhor qualidade)
  • Big Tables com milhões de linhas que muitas vezes precisam de contagem (*) foram muito Slow, nós também não fomos capazes de mudar isso.

Mas note: tudo isso é específico para o nosso ambiente, etc., por isso não se aplica.

2
mark