Em que momento um banco de dados MySQL começa a perder desempenho?
Eu tenho o que acredito ser um grande banco de dados, com aproximadamente 15 milhões de registros que ocupam quase 2 GB. Com base nesses números, existe algum incentivo para eu limpar os dados ou estou seguro para permitir que continue a escalar por mais alguns anos?
Respostas:
O tamanho do banco de dados físico não importa. O número de registros não importa.
Na minha experiência, o maior problema para o qual você vai se deparar não é o tamanho, mas o número de consultas que você pode manipular ao mesmo tempo. Muito provavelmente você precisará mudar para uma configuração mestre / escravo, para que as consultas de leitura possam ser executadas contra os escravos e as consultas de gravação contra o mestre. No entanto, se você ainda não estiver pronto para isso, poderá ajustar seus índices para as consultas em execução para acelerar os tempos de resposta. Também há muitos ajustes que você pode fazer na pilha de rede e no kernel no Linux que ajudarão.
Eu tive o meu até 10GB, com apenas um número moderado de conexões e ele tratou os pedidos muito bem.
Eu focaria primeiro nos seus índices e, em seguida, solicitaria que um administrador de servidor olhasse para o seu sistema operacional e, se tudo isso não ajudar, talvez seja hora de implementar uma configuração mestre / escravo.
Em geral, essa é uma questão muito sutil e não é trivial. Convido você a ler mysqlperformanceblog.com e MySQL de alto desempenho . Eu realmente acho que não há resposta geral para isso.
Estou trabalhando em um projeto que possui um banco de dados MySQL com quase 1 TB de dados. O fator de escalabilidade mais importante é a RAM. Se os índices de suas tabelas couberem na memória e suas consultas forem altamente otimizadas, você poderá atender a uma quantidade razoável de solicitações com uma máquina comum.
O número de registros é importante, dependendo da aparência de suas tabelas. É uma diferença ter muitos campos varchar ou apenas alguns ints ou longos.
O tamanho físico do banco de dados também é importante: pense em backups, por exemplo. Dependendo do seu mecanismo, seus arquivos db físicos aumentam, mas não diminuem, por exemplo, com o innodb. Portanto, excluir muitas linhas não ajuda a reduzir seus arquivos físicos.
Há muita coisa nessas questões e, como em muitos casos, o diabo está nos detalhes.
O tamanho do banco de dados é importante . Se você tiver mais de uma tabela com mais de um milhão de registros, o desempenho começará realmente a diminuir. É claro que o número de registros afeta o desempenho: o MySQL pode ser lento com tabelas grandes . Se você atingir um milhão de registros, terá problemas de desempenho se os índices não estiverem definidos corretamente (por exemplo, nenhum índice para campos nas "instruções WHERE" ou "condições ON" nas junções). Se você atingir 10 milhões de registros, começará a ter problemas de desempenho, mesmo que tenha todos os seus índices corretos. As atualizações de hardware - adicionando mais memória e mais potência do processador, especialmente memória - geralmente ajudam a reduzir os problemas mais graves, aumentando o desempenho novamente, pelo menos até certo ponto. Por exemplo37 sinais passaram de 32 GB de RAM para 128 GB de RAM para o servidor de banco de dados Basecamp.
Eu focaria primeiro nos seus índices, em vez de um administrador do servidor olhar para o seu sistema operacional e, se tudo isso não ajudar, talvez seja hora de uma configuração mestre / escravo.
Isso é verdade. Outra coisa que geralmente funciona é reduzir a quantidade de dados com os quais trabalhamos repetidamente. Se você tiver "dados antigos" e "novos dados" e 99% de suas consultas funcionarem com novos dados, basta mover todos os dados antigos para outra tabela - e não olhe para eles;)
-> Veja o particionamento .
É meio inútil falar sobre "desempenho do banco de dados", "desempenho da consulta" é um termo melhor aqui. E a resposta é: depende da consulta, dados em que opera, índices, hardware etc. Você pode ter uma idéia de quantas linhas serão verificadas e quais índices serão usados com a sintaxe EXPLAIN.
2GB não conta realmente como um banco de dados "grande" - é mais de tamanho médio.
Atualmente, estou gerenciando um banco de dados MySQL na infraestrutura de nuvem da Amazon, que cresceu para 160 GB. O desempenho da consulta está bom. O que se tornou um pesadelo são backups, restaurações, adição de escravos ou qualquer outra coisa que lide com todo o conjunto de dados ou mesmo DDL em tabelas grandes. Obter uma importação limpa de um arquivo de despejo tornou-se problemático. Para tornar o processo estável o suficiente para automatizar, várias escolhas precisavam ser feitas para priorizar a estabilidade sobre o desempenho. Se tivéssemos que nos recuperar de um desastre usando um backup SQL, ficaríamos inativos por dias.
A escalabilidade horizontal do SQL também é bastante dolorosa e, na maioria dos casos, leva a usá-lo de maneiras que você provavelmente não pretendia ao optar por colocar seus dados no SQL em primeiro lugar. Fragmentos, leitura de escravos, multimestre, etc, são soluções realmente de merda que adicionam complexidade a tudo o que você faz com o DB, e nenhuma delas resolve o problema; apenas o mitiga de algumas maneiras. Eu sugeriria fortemente que você movesse alguns dos seus dados para fora do MySQL (ou realmente qualquer SQL) quando começar a abordar um conjunto de dados de um tamanho em que esses tipos de coisas se tornem um problema.
Cuidado também com junções complexas. A complexidade da transação pode ser um grande fator, além do volume da transação.
A refatoração de consultas pesadas às vezes oferece um grande aumento de desempenho.
Uma vez fui chamado a olhar para um mysql que "parou de funcionar". Descobri que os arquivos do banco de dados residiam em um arquivador do Network Appliance montado com o NFS2 e com um tamanho máximo de arquivo de 2 GB. E, com certeza, a tabela que parou de aceitar transações tinha exatamente 2 GB em disco. Mas com relação à curva de desempenho, disseram-me que estava funcionando como um campeão até que não funcionou! Essa experiência sempre serve para mim como um bom lembrete de que sempre há dimensões acima e abaixo da que você naturalmente suspeita.
Um ponto a considerar também é o objetivo do sistema e os dados no dia a dia.
Por exemplo, para um sistema com monitoramento GPS de carros não há dados de consulta relevantes das posições do carro nos meses anteriores.
Portanto, os dados podem ser passados para outras tabelas históricas para possível consulta e reduzir o tempo de execução das consultas diárias.
O desempenho pode diminuir em alguns milhares de linhas se o banco de dados não for projetado corretamente.
Se você tiver índices adequados, use mecanismos adequados (não use o MyISAM onde vários DMLs são esperados), use o particionamento, aloque a memória correta dependendo do uso e, claro, tenha uma boa configuração do servidor, o MySQL pode manipular dados mesmo em terabytes!
Sempre há maneiras de melhorar o desempenho do banco de dados.
Depende da sua consulta e validação.
Por exemplo, trabalhei com uma tabela de 100.000 medicamentos que possui um nome genérico de coluna, onde há mais de 15 caracteres para cada medicamento nessa tabela. Coloquei uma consulta para comparar o nome genérico de medicamentos entre duas tabelas. mais minutos para executar. O mesmo, se você comparar os medicamentos usando o índice de medicamentos, usando uma coluna de identificação (como dito acima), leva apenas alguns segundos.
O tamanho do banco de dados é importante em termos de bytes e número de linhas da tabela. Você notará uma enorme diferença de desempenho entre um banco de dados leve e um preenchido com blob. Quando meu aplicativo ficou bloqueado, coloquei imagens binárias dentro dos campos, em vez de manter imagens em arquivos no disco e colocar apenas nomes de arquivos no banco de dados. A iteração de um grande número de linhas, por outro lado, não é de graça.
Não, isso realmente não importa. A velocidade do MySQL é de cerca de 7 milhões de linhas por segundo. Então você pode escalar bastante
O desempenho da consulta depende principalmente do número de registros que ele precisa verificar, os índices desempenham um papel importante e o tamanho dos dados do índice é proporcional ao número de linhas e ao número de índices.
As consultas com condições de campo indexadas, juntamente com o valor total, geralmente são retornadas em 1 ms, mas o begin_with, IN, Between, obviamente contém condições, pode levar mais tempo com mais registros a serem verificados.
Além disso, você enfrentará muitos problemas de manutenção com DDL, como ALTER, DROP, será lento e difícil com mais tráfego ao vivo, mesmo para adicionar um índice ou novas colunas.
Geralmente, é aconselhável agrupar o banco de dados em quantos clusters forem necessários (500 GB seria uma referência geral, como já foi dito por outros, depende de muitos fatores e pode variar de acordo com os casos de uso), dessa maneira, proporciona um melhor isolamento e independência para escalar clusters (mais adequados no caso de B2B)