Eu preciso converter meu aplicativo da web do MySQL para executar no DB2. Eu preciso saber de antemão se vou precisar de um servidor de alta especificação para garantir que o aplicativo da web tenha a mesma velocidade que agora no MySQL.
O aplicativo é um aplicativo de análise de dados muito intensivo de banco de dados com uma interface de navegador. Ele está usando apenas cerca de 20% da energia disponível da CPU e 30% da memória no servidor agora. Seria necessário mais CPU ou memória se fosse convertido para o DB2? Eu precisaria de um servidor de alta especificação?
Estou apenas procurando por qualquer sensação geral de se uma atualização do servidor seria necessária para uma conversão do MySQL para o DB2, se tudo o mais permanecesse igual (tamanho do banco de dados, tráfego, etc).
você está usando isam ou innodb?
normalmente, o DB2 requer menos recursos do sistema que as versões atuais do mysql. no entanto, se o desempenho que você está procurando e o tamanho do (s) banco (s) de dados não for muito grande, você pode querer mudar para o postgresql, já que é consideravelmente menos "cheio de recursos" (leia-se: inchado) do que o mysql . Às vezes você precisa do mysql, mas se não, geralmente é uma idéia melhor ir com o pgsql.
Eu não acho que fará uma grande diferença se você executar o mysql ou o DB2. No entanto, você não terá certeza sobre o desempenho, a menos que você realmente tente você mesmo. Eu recomendo que você experimente em um ambiente de teste similar ao seu sistema atual.
O DB2 deve fazer uso bastante eficiente de memória no servidor se você deixar seu recurso de gerenciamento de memória de autoajuste (STMM) ativado, desde que os processos fora do DB2 estejam alocando e liberando sua memória de uma maneira bem comportada. O STMM ajusta o tamanho de vários buffers e heaps de memória de alto impacto para acomodar uma carga de trabalho de banco de dados em constante mudança. Esse recurso foi habilitado por padrão para as duas últimas liberações principais do DB2 e geralmente chega às configurações de memória que são quase idênticas a um banco de dados ajustado manualmente por um especialista do DB2. Uma ressalva do STMM é que é proibido pelo design fazer oscilações em seus tamanhos de memória, o que significa que o STMM pode precisar fazer vários ajustes incrementais para acomodar um pico selvagem ou queda na utilização do banco de dados. O DB2 oferece diversos recursos integrados de monitoramento para ajudá-lo a controlar os padrões de eficiência e crescimento das estruturas de memória interna, para que você possa obter rapidamente uma ideia do que é "normal" para uma carga de trabalho específica.
No lado da CPU, um dos maiores riscos para um bom desempenho e escalabilidade é a varredura, que queima os ciclos da CPU mesmo quando todas as páginas de dados necessárias já estão armazenadas em cache na memória do buffer pool. Entender como os índices funcionam e quando eles serão usados ou ignorados para instruções SQL específicas é particularmente importante à medida que as tabelas crescem e as consultas se ampliam. Às vezes, a varredura inaceitável ocorre não devido à má indexação ou privilégios de junção, mas porque as estatísticas de cardinalidade e distribuição da tabela coletadas por RUNSTATS estão desatualizadas, o que engana o otimizador de consulta baseado em custo do DB2 em subestimar as conseqüências do uso de varredura parcial ou completa . O utilitário db2expln mostrará o plano de acesso para uma consulta proposta, considerando as estatísticas atuais. No tempo de execução, também é possível monitorar o número de linhas lidas (verificadas) em comparação com as linhas realmente selecionadas, o que pode dar uma idéia de quanto de rotatividade está ocorrendo para chegar aos conjuntos de resultados da sua carga de trabalho.