Início / dba / Perguntas / 9791
Accepted
tarnfeld
Asked: 2011-12-28 15:43:27 +0800 CST

Tabelas/servidores de fragmentação do MySQL ou outros métodos para reduzir os tamanhos das tabelas?

  • 772

No momento, estou trabalhando com uma tabela que excede 12 milhões de linhas (com cerca de 3 GB quando exportada com mysqldump) e estou curioso sobre o tamanho real de uma tabela sem nenhum impacto sério no desempenho. A tabela está crescendo cerca de 100.000 a 200.000 linhas por dia ou mais.

Devo começar a pensar um pouco sobre a fragmentação desses dados em várias tabelas ou instâncias mysql agora, antes que os dados fiquem muito maiores? Atualmente, o servidor em que está rodando tem 1 GB de RAM (embora em breve esteja mudando para uma máquina com 3/4 GB).

Alguém tem alguma dica/leitura recomendada que me leve na direção certa, ou é algo com o qual não preciso me preocupar ainda?

Obrigado :)

mysql scalability

2 respostas

  1. Best Answer

    Um bom RDBMS pode crescer para acomodar dados extremamente grandes. Bancos de dados de 3 Gb são muito gerenciáveis ​​e, muito provavelmente, desde que você consiga um servidor com RAM suficiente, a maioria das consultas será executada rapidamente com pouco esforço.

    Mesmo quando você excede a RAM, os índices, o cache e o particionamento permitem que você tenha um bom desempenho. Muitas vezes, os aplicativos acessam um conjunto de trabalho relativamente pequeno - por exemplo, 90% das consultas podem ser limitadas aos dados do mês anterior - enquanto os 10% podem ser consultas sobre dados mais antigos. Os dados do "último mês" tendem a ser um tanto estáveis ​​- crescem quando você tem mais usuários, mas fora isso, não tendem a crescer com o tempo. Esse "conjunto de trabalho" geralmente cabe na RAM, é armazenado em cache e você ainda obtém um ótimo desempenho.

    Mas então, você pode novamente obter lentidão. Com monitoramento e análise adequados, você pode localizar as consultas que estão lentas e tomar medidas para resolvê-las.

    Isso geralmente é simples:

    • Consultas ou código incorreto: muitas vezes escrevemos consultas que recuperam informações desnecessárias, ou que executam várias consultas quando uma bastaria e seria mais rápida (o caso típico é uma operação que precisa exibir n linhas de uma tabela e executa n consultas quando 1 seria suficiente. A realização de agregações fora do banco de dados também é frequente). Isso é facilmente corrigido alterando seu código
    • Consultas que não são executadas com eficiência. EXPLAINé seu amigo aqui. Frequentemente, criar índices que a consulta possa usar é suficiente (aproximadamente, você desejará indexar nas colunas que aparecem na WHEREcláusula). Além disso, às vezes, ajustar a própria consulta produzirá bons resultados

    Outra abordagem que dá bons resultados é jogar o hardware no problema:

    • Comprando mais RAM
    • Obtendo mais e melhores discos (configurações RAID10 ficam mais rápidas se você adicionar mais discos, SSDs geralmente têm benefícios significativos, etc.)
    • Não é frequente, mas às vezes a CPU é o seu gargalo - você pode obter processadores mais rápidos e mais núcleos/processadores

    Em alguns outros casos, replicação e fragmentação podem ser um problema. A replicação é complicada, mas coisas como o Oracle RAC permitem que você construa clusters de monstros (por um preço). Sharding é outra opção, mas geralmente é uma das mais complexas de implementar - até mesmo aplicativos que fragmentam facilmente requerem muito trabalho para serem fragmentados, e alguns aplicativos podem ser notoriamente difíceis de fragmentar.

    • 2

  2. Acho que no minuto em que seu banco de dados atinge o disco - seu desempenho diminui, portanto, você precisa garantir que sua máquina tenha mais RAM do que o tamanho do seu banco de dados. Boas soluções para você está particionando ou sharding (para sharding, confira http://www.scalebase.com - eles fazem sharding transparente, por isso é fácil)

    • -2

relate perguntas