Qual o tamanho que um banco de dados MySQL pode atingir antes que o desempenho comece a diminuir

Question

Em que ponto um banco de dados MySQL começa a perder desempenho?

• O tamanho físico do banco de dados é importante?
• O número de registros importa?
• Qualquer degradação de desempenho é linear ou exponencial?

Tenho o que acredito ser um grande banco de dados, com cerca de 15 milhões de registros que ocupam quase 2 GB.Com base nesses números, há algum incentivo para eu limpar os dados ou estou seguro para permitir que continuem a escalar por mais alguns anos?

Answer 1

O tamanho físico do banco de dados não importa.O número de registros não importa.

Na minha experiência, o maior problema que você enfrentará não é o tamanho, mas o número de consultas que você pode lidar por vez.Muito provavelmente você terá que mudar para uma configuração mestre/escravo para que as consultas de leitura possam ser executadas nos escravos e as consultas de gravação sejam executadas no mestre.No entanto, se ainda não estiver pronto para isso, você sempre pode ajustar seus índices para as consultas que está executando para acelerar os tempos de resposta.Além disso, há muitos ajustes que você pode fazer na pilha de rede e no kernel do Linux que ajudarão.

O meu chegou a 10 GB, com apenas um número moderado de conexões e ele atendeu perfeitamente às solicitações.

Eu me concentraria primeiro em seus índices, depois pediria a um administrador de servidor que analisasse seu sistema operacional e, se tudo isso não ajudar, talvez seja hora de implementar uma configuração mestre/escravo.

Answer 2

Em geral, esta é uma questão muito sutil e nada trivial.Eu encorajo você a ler mysqlperformanceblog.com e MySQL de alto desempenho.Eu realmente acho que não há uma 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 uma quantidade razoável de solicitações com uma máquina média.

O número de registros é importante, dependendo da aparência das suas tabelas.É uma diferença ter muitos campos varchar ou apenas alguns inteiros 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á muitas questões envolvidas e, como em muitos casos, o diabo está nos detalhes.

Answer 3

O tamanho do banco de dados importa.Se você tiver mais de uma tabela com mais de um milhão de registros, o desempenho começará a diminuir.É claro que o número de registros afeta o desempenho: 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 em "instruções WHERE" ou "condições ON" em 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.Atualizações de hardware - adicionando mais memória e mais potência de processador, especialmente memória - geralmente ajudam a reduzir os problemas mais graves, aumentando novamente o desempenho, pelo menos até certo ponto.Por exemplo 37 sinais passaram de 32 GB de RAM para 128 GB de RAM para o servidor de banco de dados Basecamp.

Answer 4

Eu me concentraria primeiro em seus índices, depois em um administrador de servidor para examinar 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 é apenas reduzir a quantidade de dados com os quais se trabalha repetidamente.Se você tem "dados antigos" e "dados novos" e 99% das suas consultas funcionam com dados novos, basta mover todos os dados antigos para outra tabela - e não olhar para eles;)

-> Dê uma olhada particionamento.

Answer 5

2 GB e cerca de 15 milhões de registros são um banco de dados muito pequeno - executei bancos muito maiores em um Pentium III (!) E tudo ainda funcionou bem rápido.Se o seu for lento, é um problema de design de banco de dados/aplicativo, não de mysql.

Answer 6

É meio inútil falar sobre "desempenho do banco de dados", "desempenho de consulta" é um termo melhor aqui.E a resposta é:depende da consulta, dos dados em que opera, dos índices, do hardware, etc.Você pode ter uma ideia de quantas linhas serão verificadas e quais índices serão usados ​​com a sintaxe EXPLAIN.

Na verdade, 2 GB não contam como um banco de dados "grande" - é mais um tamanho médio.

Answer 7

Cuidado também com junções complexas.A complexidade das transações pode ser um grande fator além do volume de transações.

A refatoração de consultas pesadas às vezes oferece um grande aumento de desempenho.

Answer 8

Certa vez fui chamado para olhar um mysql que havia "parado de funcionar".Descobri que os arquivos do banco de dados residiam em um arquivador do Network Appliance montado com NFS2 e com 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 no que diz respeito à curva de desempenho, disseram-me que estava a funcionar como um campeão até deixar de funcionar!Essa experiência sempre serve para mim como um bom lembrete de que sempre existem dimensões acima e abaixo daquela que você naturalmente suspeita.

Answer 9

Um ponto a considerar também é a finalidade do sistema e dos dados no dia a dia.

Por exemplo, para um sistema com monitoramento GPS de carros não é relevante consultar dados das posições do carro nos meses anteriores.

Assim os dados podem ser repassados ​​para outras tabelas históricas para possível consulta e reduzir os tempos de execução das consultas do dia a dia.

Answer 10

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 ser automatizado, várias escolhas precisaram ser feitas para priorizar a estabilidade em detrimento do desempenho.Se alguma vez tivéssemos que nos recuperar de um desastre usando um backup SQL, ficaríamos inativos por dias.

O escalonamento horizontal do SQL também é bastante doloroso e, na maioria dos casos, leva ao seu uso de maneiras que você provavelmente não pretendia quando optou por colocar seus dados no SQL.Shards, read slaves, multi-master, etc., são todas soluções realmente ruins que adicionam complexidade a tudo que você faz com o banco de dados, e nenhuma delas resolve o problema;apenas atenua isso de algumas maneiras.Eu sugiro fortemente que você mova alguns de seus dados para fora do MySQL (ou de qualquer SQL) quando você começar a se aproximar de um conjunto de dados de tamanho onde esses tipos de coisas se tornem um problema.

Answer 11

O desempenho pode diminuir em questão de 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 MyISAM onde vários DMLs são esperados), use particionamento, aloque memória correta dependendo do uso e, claro, tenha uma boa configuração de servidor, o MySQL pode lidar com dados mesmo em terabytes!

Sempre há maneiras de melhorar o desempenho do banco de dados.

Answer 12

Depende da sua consulta e validação.

Por exemplo, trabalhei com uma tabela de 100.000 medicamentos que possui uma coluna nome genérico onde possui mais de 15 caracteres para cada medicamento daquela tabela. Coloquei uma consulta para comparar o nome genérico dos medicamentos entre duas tabelas. mais minutos para correr. O mesmo, se você comparar os medicamentos usando o índice de medicamentos, usando uma coluna de id (como dito acima), leva apenas alguns segundos.

Answer 13

O tamanho do banco de dados importa 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.Uma vez meu aplicativo travou porque coloquei imagens binárias dentro de campos em vez de manter imagens em arquivos no disco e colocar apenas nomes de arquivos no banco de dados.Por outro lado, iterar um grande número de linhas não é gratuito.

Answer 14

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 dimensionar um pouco