Como grande pode um banco de dados MySQL começar antes que o desempenho começa a degradar

votos
253

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

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

Eu tenho o que eu acredito ser um grande banco de dados, com cerca de registros 15M que ocupam quase 2GB. Com base nesses números, não há qualquer incentivo para eu limpar os dados para fora, ou estou seguro para permitir que ele continue escalando por mais alguns anos?

Publicado 04/08/2008 em 15:31
fonte usuário
Em outras línguas...                            


14 respostas

votos
169

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 que você vai correr para não é o tamanho, mas o número de consultas que você pode segurar em um tempo. O mais provável é que você vai ter que se deslocar para uma configuração master / slave para que as consultas de leitura pode correr contra os escravos e as consultas de escrita correm contra o mestre. No entanto, se você não está pronto para isso ainda, você sempre pode ajustar seus índices para as consultas que você está executando para acelerar os tempos de resposta. Também há uma série de ajustes você pode fazer para a pilha de rede e do kernel em Linux que vai ajudar.

Eu tive a minha obter até 10GB, com apenas um número moderado de ligações e movimentou os pedidos apenas multa.

Gostaria de concentrar primeiro em seus índices, em seguida, ter um olhar administrador do servidor no seu sistema operacional, e se tudo isso não ajuda que poderia ser tempo para implementar uma configuração master / slave.

Respondeu 04/08/2008 em 16:26
fonte usuário

votos
71

Em geral, isso é uma questão muito sutil e não trivial que seja. Encorajo-vos a ler mysqlperformanceblog.com e alta MySQL desempenho . Eu realmente acho que não há uma resposta geral para este.

Eu estou trabalhando em um projeto que tem um banco de dados MySQL com quase 1TB de dados. O fator escalabilidade mais importante é RAM. Se os índices de suas tabelas caber na memória e suas consultas são altamente otimizadas, você pode servir uma quantidade razoável de pedidos com uma máquina de média.

O número de registros são importantes, dependendo de como suas tabelas de parecer. É uma diferença de ter um monte de campos varchar ou apenas um par de ints ou longs.

O tamanho físico das matérias de banco de dados bem: pensar em backups, por exemplo. Dependendo do seu motor, seus arquivos db físicos em crescer, mas não encolher, por exemplo, com o InnoDB. Assim, a exclusão de um monte de linhas, não ajuda a diminuir seus arquivos físicos.

Há muito para este problemas e, como em muitos casos, o diabo está nos detalhes.

Respondeu 04/08/2008 em 19:44
fonte usuário

votos
33

O tamanho do banco de dados não importa . Se você tem mais de uma tabela com mais de um milhão de discos, o desempenho começa de fato a se degradar. O número de registros não é claro afetar o desempenho: MySQL pode ser lento com grandes mesas . Se você bater um milhão de registros que você vai ter problemas de desempenho se os índices não estão definidas direita (por exemplo, nenhum índice para campos em "declarações onde" ou "ON condições" na junta). Se você acertar 10 milhões de registros, você vai começar a ter problemas de desempenho, mesmo se você tem todos os seus índices direita. Upgrades de hardware - adicionando mais memória e mais potência do processador, especialmente memória - muitas vezes ajudam a reduzir os problemas mais graves, aumentando o desempenho novamente, pelo menos até certo ponto. Por exemplo37 sinais passou de 32 GB RAM 128 GB de RAM para o servidor de banco de dados Basecamp.

Respondeu 26/01/2012 em 11:33
fonte usuário

votos
20

Gostaria de concentrar primeiro em seus índices, do que ter um olhar administrador do servidor no seu sistema operacional, e se tudo isso não ajuda que poderia ser tempo para uma configuração master / slave.

Isso é verdade. Outra coisa que normalmente funciona é apenas reduzir a quantidade de dados que são repetidamente trabalhei. Se você tem "dados antigos" e "novos dados" e 99% de suas consultas trabalhar com novos dados, basta mover todos os dados antigos para outra mesa - e não olhar para ele;)

-> Dê uma olhada no particionamento .

Respondeu 11/08/2008 em 20:19
fonte usuário

votos
19

2GB e cerca de 15M registros é um pequeno banco de dados - Já corri os muito maiores em um Pentium III e tudo ainda foi executado muito rápido .. Se o seu caso é lento, é um problema de design de banco de dados / aplicação, não um mysql (!) 1.

Respondeu 05/08/2010 em 10:03
fonte usuário

votos
16

É uma espécie de inútil para falar sobre "o desempenho do banco de dados", "o desempenho da consulta" é um termo melhor aqui. E a resposta é: depende da consulta, de dados que atua em, índices, hardware, etc Você pode ter uma idéia de quantas linhas vão ser digitalizados e que os índices estão indo para ser usado com EXPLICAR sintaxe.

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

Respondeu 06/08/2008 em 20:53
fonte usuário

votos
9

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

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

Portanto, os dados podem ser passados ​​para outras tabelas históricos para eventual consulta e reduzir os tempos de execução do dia para consultas dia.

Respondeu 06/12/2012 em 06:13
fonte usuário

votos
9

Eu uma vez foi chamado para olhar para um mysql que tinha "parou de funcionar". Eu descobri que os arquivos DB residiam em um arquivador Network Appliance montado com NFS2 e com um tamanho máximo de arquivo de 2 GB. E com certeza, a tabela que tinha parado de aceitar transações era exatamente 2GB no disco. Mas com relação à curva de desempenho que me disseram que ele estava trabalhando como um campeão direito até que não deu certo em tudo! Esta experiência serve sempre para mim como um bom lembrete de que há está sempre dimensões acima e abaixo o que você naturalmente suspeito.

Respondeu 06/08/2008 em 05:27
fonte usuário

votos
8

Também atente para junções complexas. complexidade da transação pode ser um grande fator, além de volume de transações.

Refatoração consultas pesados, por vezes, oferece um grande aumento de desempenho.

Respondeu 04/08/2008 em 20:01
fonte usuário

votos
4

Estou actualmente a gerir uma base de dados MySQL na infraestrutura de nuvem da Amazon que tem crescido a 160 GB. O desempenho de consulta é bom. O que se tornou um pesadelo é backups, restaurações, escravos acrescentando, ou qualquer outra coisa que lida com todo o conjunto de dados, ou mesmo DDL em tabelas grandes. Obtendo uma importação limpa de um arquivo de despejo tornou-se problemática. A fim de tornar o processo estável o suficiente para automatizar, várias escolhas precisam ser feitas para priorizar a estabilidade sobre o desempenho. Se alguma vez teve de se recuperar de um desastre usando um backup SQL, estaríamos para baixo por dias.

Horizontalmente escalar SQL também é muito doloroso, e na maioria dos casos leva a usá-lo de maneiras que você provavelmente não tinha a intenção quando você escolheu colocar seus dados em SQL em primeiro lugar. Shards, leia escravos, multi-master, et al, são soluções tudo realmente merda que acrescentam complexidade de tudo o que você faz com o DB, e não um deles resolve o problema; única atenua-lo em alguns aspectos. Gostaria de sugerir olhando para mover alguns dos seus dados fora do MySQL (ou realmente qualquer SQL) quando você começar a se aproximar de um conjunto de dados de um tamanho em que estes tipos de coisas tornam-se um problema.

Respondeu 30/06/2017 em 16:25
fonte usuário

votos
4

O desempenho pode degradar em questão de alguns milhares de linhas, se banco de dados não é projetado adequadamente.

Se você tem índices adequados, utilize motores adequados (não utilizar MyISAM onde são esperados vários LMG), o uso de particionamento, alocar memória correto, dependendo do uso e, claro, ter boa configuração do servidor, MySQL pode manipular dados mesmo em terabytes!

Há sempre maneiras de melhorar o desempenho do banco de dados.

Respondeu 19/09/2013 em 12:26
fonte usuário

votos
2

o tamanho do banco de dados faz diferença em termos de bytes e número de linhas da tabela. Você vai notar uma diferença de desempenho enorme entre um banco de dados leve e uma bolha encheu um. Uma vez que a minha candidatura ficou preso porque eu coloquei imagens binárias dentro campos em vez de manter as imagens em arquivos no disco e colocar apenas nomes de arquivos no banco de dados. Iteração de um grande número de linhas por outro lado, não é de graça.

Respondeu 05/06/2017 em 10:27
fonte usuário

votos
2

Depende da sua consulta e validação.

Por exemplo, eu trabalhei com uma mesa de 100 000 drogas que tem um nome genérico coluna onde ele tem mais de 15 caracteres para cada droga na tabela .Eu colocar uma consulta para comparar o nome genérico de drogas entre dois consulta tables.The leva mais minutos para run.The Same, se você comparar as drogas que utilizam o índice de droga, utilizando uma coluna de identificação (como dito acima), leva apenas alguns segundos.

Respondeu 29/11/2016 em 12:05
fonte usuário

votos
0

Sem ele doesnt realmente importa. A velocidade MySQL é de cerca de 7 milhões de linhas por segundo. Assim você pode escalá-lo um pouco

Respondeu 25/05/2019 em 12:18
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more