Quando se trata do MySQL, não há comparação entre os mecanismos de armazenamento, exceto que ele se enquadra em duas categorias básicas:
O MySQL possui o uso de vários mecanismos de armazenamento
Quanto aos mecanismos de armazenamento listados, os únicos que têm conformidade com ACID são o InnoDB e o NDB. Por que isso é importante mencionar? Duas razões:
- Outros mecanismos de armazenamento simplesmente não são beneficiados com a presença de mais núcleos, exceto E / S básica de disco, uso da CPU e taxa de transferência geral.
- O código para cada mecanismo de armazenamento não transacional, que determina basicamente 14 operações internas, independentemente do mecanismo de armazenamento, não foi projetado para alavancar o acesso a vários núcleos.
O InnoDB no MySQL 5.5, o InnoDB Plugin) e o XtraDB do Percona Server têm opções que você pode definir para acessar vários núcleos (o Percona Server faz isso há mais tempo). De fato, a Percona injeta cerca de 30.000 linhas de código especificamente para melhorar o desempenho do InnoDB a cada nova versão GA do código-fonte do MySQL. Podemos ter certeza de que a Oracle incluiu seus próprios aprimoramentos em seu próprio think tank para executar no InnoDB para operação multicore (desde o MySQL 5.1.38).
Com a necessidade de executar o MVCC nos dados em conjunto com o bloqueio de linhas / páginas, o desempenho da transação agora pode ser instrumentado, medido e configurado.
Se há uma coisa que aprendi sobre o uso de múltiplos núcleos, é que você deve ajustar o InnoDB de forma eficaz e não confiar apenas no InnoDB imediatamente .
UPDATE 2011-09-20 08:03 EDT
Com relação ao InnoDB se beneficiando de todos os núcleos, precisamos manter as coisas em perspectiva. Os núcleos também devem cuidar de outros assuntos (SO, disco, memória, aplicativos, monitoramento etc.) no servidor de banco de dados. Para aqueles com orçamentos modestos, muitos tendem a ter um servidor de banco de dados que também fornece NFS, monitoramento da Munin, suporte a aplicativos para JBoss, PHP e a lista continua. Se você deseja que o MySQL, mais especificamente o InnoDB, use mais núcleos, o servidor de banco de dados deve ser dedicado exclusivamente ao MySQL e o SO / disco / memória deve tender apenas ao MySQL . Dada essa perspectiva, o InnoDB envolverá mais núcleos sem dúvida .
Quanto ao InnoDB Plugin, foi mencionado simplesmente para mostrar iniciativas anteriores para ter um InnoDB melhor por parte do MySQL (eh, Oracle. Desculpe, ainda não saiu do lugar ainda). Novas variáveis para convocar mais atividades principais tornaram-se evidentes no MySQL 5.1.38.
Por exemplo, innodb_read_io_threads e innodb_write_io_threads (ambos desde o MySQL 5.1.38) alocam o número especificado de threads para leituras e gravações. O padrão é 4 e o máximo é 64. As configurações padrão e máximo são tão diferentes (4 - 64) mostram que o InnoDB é tão multithread e intensivo quanto o núcleo que você o configura !!!
O atendimento das necessidades da comunidade MySQL de acessar mais núcleos com o InnoDB foi liderado pela Percona. Consequentemente, o MySQL começou a seguir o exemplo. Eu tenho que admitir que a Oracle (eca) fez as melhorias necessárias para mais atividades principais.