Como o tamanho do banco de dados afeta o desempenho: teoria versus realidade

Há muita coisa por aí que diz que o tamanho do banco de dados não deve afetar o desempenho em grande medida. Enquanto os índices nas tabelas couberem na memória, o banco de dados deve permanecer com bom desempenho.

No entanto, qual é a realidade? Se a arquitetura do banco de dados não é a melhor, os índices não cabem na memória e há potencialmente muitos dados redundantes. Há ganhos significativos a serem obtidos simplesmente pela exclusão de dados redundantes? Eu estimo que 60-80% dos dados no meu banco de dados possam ser excluídos.

Acredito que reduzir o tamanho do banco de dados e aumentar a RAM para que os índices possam caber na memória daria um aumento significativo no desempenho, o que daria algum espaço para respirar por alguns meses para re-projetar o sistema.

Também existem outros fatores como E / S, fragmentação, conjunto de dados de trabalho etc. que afetam o desempenho com base no tamanho do banco de dados?

Depende inteiramente do que você está fazendo com os dados.

Para transações básicas de inserção / atualização / exclusão que afetam apenas algumas linhas, o aumento no tamanho dos dados provavelmente não é uma grande consideração. O banco de dados usará índices na memória para acessar a página correta. Você obtém mais erros de cache quando as tabelas não se ajustam mais à memória. No entanto, a sobrecarga pode ser pequena - dependendo do banco de dados, das configurações do banco de dados e das configurações de hardware.

Se você estiver fazendo consultas que exigem varreduras de tabela completa, seu desempenho aumentará linearmente ou piorará com o tamanho dos dados. Os índices podem realmente piorar a situação, aleatorizando os acessos à página, o que garante praticamente falhas de cache.

Uma alternativa para mais memória é a velocidade aprimorada do disco - o disco de estado sólido pode proporcionar uma tremenda melhoria.

Apenas ter mais dados provavelmente não afetará o desempenho, a menos que as tabelas sejam usadas em consultas. Os dados são redundantes em uma tabela ou entre tabelas? Ter tabelas grandes que nunca são usadas é uma bagunça, mas tem um impacto mínimo no desempenho. É possível imaginar que, se você tiver zilhões de tabelas desnecessárias, a compilação de consultas poderá demorar mais tempo.

A regra de ajuste número um da AMM (Adicionar mais memória) é simples. Também é muito caro e, no final, não é eficaz quando há problemas de seletividade. Mesmo que um banco de dados caiba completamente na memória, o desempenho do aplicativo pode ser ruim. Na pior das hipóteses, devido ao bloqueio e travamento durante execuções SQL muito seletivas. Aqueles devem ser corrigidos primeiro. Um dos motivos é a simultaneidade, que é como pressionar - e manter - as quebras se todo SQL acessar todos os dados de uma tabela todas as vezes.

Verifique se o SQL acessa mais linhas do que o necessário. Essa é a maneira mais eficaz de manter o bom desempenho. Um banco de dados normal sabe como lidar com io e faz alguma forma de armazenamento em cache dos dados mais usados.

Se o seu aplicativo já minimizou todos os acessos possíveis e você já usa os sistemas de disco mais rápidos, considere o uso de matrizes de memória flash reais. Eles podem aumentar o desempenho em outro nível.

Consulte estas postagens:

• Qual o tamanho de um banco de dados MySQL antes que o desempenho comece a diminuir
• Por que o MySQL pode ser lento com tabelas grandes?

Dicas para tornar seus dados tão pequenos quanto possível:

Crie suas tabelas para minimizar seu espaço no disco. Isso pode resultar em grandes melhorias, reduzindo a quantidade de dados gravados e lidos no disco. Tabelas menores normalmente requerem menos memória principal enquanto seu conteúdo está sendo processado ativamente durante a execução da consulta. Qualquer redução de espaço para dados da tabela também resulta em índices menores que podem ser processados ​​mais rapidamente.

O MySQL suporta muitos mecanismos de armazenamento diferentes (tipos de tabela) e formatos de linha. Para cada tabela, você pode decidir qual método de armazenamento e indexação usar. Escolher o formato de tabela adequado para o seu aplicativo pode proporcionar um grande ganho de desempenho.

Você pode obter um melhor desempenho de uma tabela e minimizar o espaço de armazenamento usando as técnicas listadas aqui: - Use os tipos de dados mais eficientes (menores) possíveis. O MySQL possui muitos tipos especializados que economizam espaço em disco e memória. Por exemplo, use os tipos inteiros menores, se possível, para obter tabelas menores. MEDIUMINT geralmente é uma escolha melhor que INT, porque uma coluna MEDIUMINT usa 25% menos espaço.

• Declare as colunas como NOT NULL, se possível. Isso torna tudo mais rápido e você economiza um bit por coluna. Se você realmente precisa de NULL no seu aplicativo, definitivamente deve usá-lo. Apenas evite tê-lo em todas as colunas por padrão.

• Para tabelas MyISAM, se você não possui colunas de tamanho variável (colunas VARCHAR, TEXT ou BLOB), é utilizado um formato de linha de tamanho fixo.

• As tabelas do InnoDB usam um formato de armazenamento compacto. Nas versões do MySQL anteriores à 5.0.3, as linhas do InnoDB contêm algumas informações redundantes, como o número de colunas e o comprimento de cada coluna, mesmo para colunas de tamanho fixo. Por padrão, as tabelas são criadas no formato compacto (ROW_FORMAT = COMPACT). A presença do formato compacto de linha diminui o espaço de armazenamento de linha em cerca de 20%, com o custo de aumentar o uso da CPU em algumas operações. Se sua carga de trabalho for típica, limitada pelas taxas de acertos do cache e pela velocidade do disco, provavelmente será mais rápida. Se for um caso raro limitado pela velocidade da CPU, pode ser mais lento.

O formato compacto do InnoDB também altera como as colunas CHAR contendo dados UTF-8 são armazenadas. Com ROW_FORMAT = REDUNDANT, um UTF-8 CHAR (N) ocupa 3 × N bytes, considerando que o comprimento máximo de um caractere codificado em UTF-8 é de três bytes. Muitos idiomas podem ser escritos principalmente usando caracteres UTF-8 de byte único; portanto, um tamanho fixo de armazenamento geralmente desperdiça espaço. Com o formato ROW_FORMAT = COMPACT, o InnoDB aloca uma quantidade variável de armazenamento no intervalo de N a 3 × N bytes para essas colunas, removendo os espaços finais, se necessário. O comprimento mínimo de armazenamento é mantido como N bytes para facilitar as atualizações no local em casos típicos.

• O índice primário de uma tabela deve ser o mais curto possível. Isso torna a identificação de cada linha fácil e eficiente

• Crie apenas os índices que você realmente precisa. Os índices são bons para recuperação, mas ruins quando você precisa armazenar dados rapidamente. Se você acessar uma tabela principalmente pesquisando uma combinação de colunas, crie um índice nelas. A primeira parte do índice deve ser a coluna mais usada. Se você sempre usar muitas colunas ao selecionar na tabela, a primeira coluna no índice deverá ser a que tiver mais duplicatas para obter uma melhor compactação do índice.

• Em algumas circunstâncias, pode ser benéfico dividir em duas uma tabela que é verificada com muita frequência. Isso é especialmente verdadeiro se for uma tabela de formato dinâmico e for possível usar uma tabela de formato estático menor que possa ser usada para encontrar as linhas relevantes ao varrer a tabela.