Quantos selects por segundo um servidor mysql pode executar?

Question

Estou escrevendo um plano de negócios e tenho que simular o custo quando meu site chegar a 500.000 visitantes únicos.

• visitantes: 500.000
• exibições de página: 1.500.000
• exibições de página da aranha: 500.000
• total de visualizações de página: 2.000.000

Cada página faz 50 consultas + -

• consultas por dia: 100 milhões
• por hora: 4 milhões
• por minuto: 70.000
• por segundo: 1.200
• pico: 3.000

Ao fazer esse cálculo, preciso de 3.000 consultas em segundo lugar ... que tipo de servidor pode lidar com isso?

O problema é: na verdade, meu site está fazendo 2.000 visitas diárias e tendo + 150/200 consultas / segundo ... a partir deste ponto, esperarei 50.000 consultas / segundo.

Quantos servidores eu preciso em cluster ou replicação gerenciam este trabalho?

    

Answer 1

Eu costumava trabalhar para uma empresa de comércio eletrônico com um site que tinha vários milhões de acessos por dia. Tivemos um único DELL PE 1750 com 2 CPUs de núcleo único e 2 GB de RAM, tamanho de banco de dados aprox. 4GB. Nos horários de pico, este servidor tratou de mais de 50 mil consultas por segundo.

Tendo dito isto: o banco de dados foi bem estruturado, todas as consultas foram afinadas (tivemos sessões semanais analisando os logs de consultas lentas e corrigindo consultas e índices) e a configuração do servidor também foi ajustada. O cache é definitivamente uma boa idéia, mas o MySQL faz isso de qualquer maneira, você só precisa analisar o desempenho e, em seguida, ajustar como sua memória é usada (cache de consulta versus outras opções).

A partir dessa experiência, posso dizer que o maior impacto é causado pela falta de índices, índices incorretos e design de banco de dados inválido (por exemplo, campos de cadeia longa como chaves primárias e sem sentido).

    

Answer 2

Tudo depende da complexidade da consulta e da quantidade de memória dos servidores e da velocidade dos discos.

Se as consultas forem muito simples ou muito bem ajustadas, um único servidor de banco de dados grande poderá lidar com isso. Se, no entanto, as consultas forem muito complexas (ou simples, mas mal ajustadas), você precisará de vários servidores.

    

Answer 3

Isso realmente não pode ser estimado sem saber nada sobre as consultas específicas que você está executando, o esquema do banco de dados e seu tamanho.

Um simples SELECT em uma coluna indexada é bastante uma besta diferente de um par de JOINs baseados em não-indexados ... e é claro que as coisas mudam muito se as tabelas envolvidas contiverem registros 1K ou 1M.

Além disso:

• Qual é a sua configuração atual de hardware?
• Quanto de seu poder (CPU, RAM, E / S de disco) seu servidor está usando sob a carga atual?

Answer 4

Como Ignacio observou, talvez você queira investigar o armazenamento em cache. No cms ou talvez até mesmo na frente da pilha. Mais de 50 consultas para cada (cada!) Página é realmente muito.

    

Answer 5

A julgar pelos seus comentários, o maior fator será o tamanho do seu conjunto de dados, ou pelo menos o tamanho do conjunto de dados "quente". 3.000qps ou até 8.000qps em um servidor de 16 núcleos não é um problema, desde que o servidor raramente tenha que ir ao disco para satisfazer a consulta. Uma vez que o conjunto de dados ativo excede a quantidade de memória que o InnoDB está usando para armazená-lo em cache, seu desempenho cairá rapidamente.

    

Answer 6

Para grandes conjuntos de dados "quentes", provavelmente vale a pena investir na hora de converter em um esquema de "big data", é para isso que servem. Por exemplo, se você tiver uma grande quantidade de dados para recuperar, mas nunca reescrever, mas apenas acrescentar novos dados, consulte o Apache Hive. Navegue por aí, geralmente é um sabor que você pode fazer interface com bastante facilidade com o código existente, o que também evita a azia de ficar sem espaço no cache.

    

Answer 7

Existem muitas coisas que podem afetar suas consultas por segundo, por favor, não confie em meus dados sem testar você mesmo. Eu postei meu resultado de teste de velocidade aqui para ajudar alguém a estimar o qps com o banco de dados e a máquina atuais do mysql (2018-09). No meu teste, o tamanho dos dados é menor que a memória do servidor (isso reduz drasticamente o IO e melhora muito o desempenho).

Eu uso uma CPU de 3.75GB de memória, 100GB ssd, instância do servidor gcp mysql em nuvem e recebo:

• 1 cliente, um sql uma linha lida: 799 sql / segundo.
• 50 clientes, um sql uma linha lida: 6403 sql / segundo.
• 50 clientes, um sql uma linha de gravação: 4341 linhas escritas, qps. 4341 sql / segundo.
• 1 cliente, 30k linha de gravação por sql: 92109 linhas / s escritas.