Aproximadamente quanto uso você poderia esperar extrair de um servidor MySQL de ~ $ 1000?

Question

Eu sei que essa é uma pergunta horrível e generalizada, sem uma boa resposta, e peço desculpas antecipadamente, mas me pergunto se alguém poderia fazer uma estimativa muito ampla.

Digamos que você tenha um servidor MySQL dedicado rodando em cerca de $ 1K em hardware moderno.

Digamos que o usuário médio faça 20 solicitações de leitura e 5 solicitações de gravação por minuto - todas as consultas diretas, sem junções; principalmente ao longo das linhas de 'selecione esta linha por UUID' fora de uma tabela indexada de ~ 10.000.000 linhas.

Muito, muito, muito, muito mais ou menos quantos usuários simultâneos você esperaria que um servidor como esse manipulasse antes de "empurrá-lo".

    

Answer 1

Como você observou, essa é uma estimativa muito ampla.

A grande questão é o que você usa que $ 1000 para comprar. Desde que você gere um pouco mais de memória e menos poder de processamento com um disco rígido médio, eu diria que um aplicativo razoavelmente codificado (onde razoável = principalmente usando qualquer biblioteca de abstração fornecida pela sua linguagem) com esses parâmetros deve ser capaz de lidar com cerca de 500 Usuários concorrentes. Eu teria imaginado mais, exceto pelo tamanho do conjunto de linhas (uma vez que quanto mais linhas se encaixam diretamente na RAM, menos vai para o disco que você precisa fazer mesmo para gravações imediatas).

O tipo de dados que estão nas linhas e a quantidade de RAM que você pode pagar serão absolutamente os maiores fatores neste cenário. Se você pudesse se dar com menos gravações e diminuir o tamanho da tabela indexada, eu pensaria que você poderia usar 1.000 usuários simultaneamente.

Os dois problemas que você verá:

1. A quantidade de dados que você pode armazenar em cache na RAM e, portanto, a quantidade de RAM acima do mínimo necessário para executar as operações básicas do sistema operacional e do servidor de banco de dados determinará com o que você pode se safar. Mais RAM, menos necessidades de SO e uma quantidade menor de dados úteis que devem ser mantidos na RAM para consultas e gravações, significarão a diferença entre desempenho e lotes aceitáveis e muita surra.

2. O design do seu aplicativo é absolutamente crítico aqui. Uma gravação espalhada por 500 a 1000 usuários tem um impacto enorme e enorme. Da mesma forma, se suas chamadas não forem simples e eficientes, você irá causar um acidente de trem rapidamente. Eu baseei minha estimativa em vários aplicativos mySQL que vi em jogo, com um pouco de conhecimento de como eles funcionam. Se o aplicativo tiver problemas fundamentais, talvez você nem consiga 40 usuários. Se você codificá-lo de forma eficiente e levar em conta os limites de hardware, poderá escalar além de 2.000 facilmente.

Answer 2

Eu posso responder isso. Eu acabei de sair desse passeio, vou andar de novo.

US $ 650 - US $ 800 comprarão uma AMD quad-core com velocidade moderada de 8 GB de RAM e uma unidade SATA2 de 1TB. $ 170 comprará uma segunda unidade relativamente rápida de 1TB. Tenha em mente que este é o hardware da prateleira da maioria dos locais do tipo eletrônicos / loja de escritório / melhor compra. Você pode obter mais estrondo em outro lugar, mas não é ruim para o dinheiro. Você pode obter um quad core mais rápido para um pouco mais.

Agora, com relação ao aplicativo, vou assumir que você está executando o linux / BSD / unix para o sistema operacional e evitar o debate ms vs unix. Aqui está o que eu encontrei:

Não temos problemas em especificar mais de 200 usuários / sessões ativos em qualquer um de nossos aplicativos sem piscar, não importa o quão fraco seja o aplicativo. Na verdade, não conseguimos descartar / travar / dificultar um aplicativo em qualquer servidor quad-core que já executamos há algum tempo ... mas aprendemos algumas lições nos dias de núcleo único de 200 mhz.

Por exemplo, nossa empresa irmã vende vários sistemas de monitoramento de comunicações baseados em mysql com mais de 1300 usuários por máquina e, em média, várias centenas de sessões simultâneas por hora. O registro e o relatório são feitos em tempo real (bem, ocorre algum buffer) e eles estão rodando em máquinas dual-core 3Ghz em unidades de PATA lentas… Na verdade, unidades de 133 Mhz P-ata. O maior atraso da interface do usuário foi de aproximadamente 2 segundos. Eles despejaram o MSSQL for MySQL há uma década e imediatamente obtiveram resultados.

Tenha em mente que essas máquinas estão executando webapps + bancos de dados ... então você faz as contas. Apenas funciona. Além disso, eu substituí um número de aplicativos oracle / MS / xxxx com estes, e nunca chego perto de ficar sem energia. Além disso, deixe-me expandir o que o outro cara disse de uma perspectiva de dba ... Aqui estão 6 dicas das trincheiras.

1. As gravações eliminarão o desempenho, especialmente se a penalidade de bloqueio for um conceito estranho para seus codificadores.
2. Fazer tudo em uma mesa enorme vai te matar.
3. A normalização excessiva não é sua amiga. Se os seus codificadores estiverem preenchendo a terceira forma normal, seu aplicativo será executado incorretamente. Os dados desordenados ocupam mais espaço, mas permitem realizar grandes coisas com consultas simples.
4. Uma grande mesa vai sufocar com gravações frequentes. Veja 1.
5. Se você escrever seu aplicativo para usar uma (ou mais) tabelas para exibição de dados e uma tabela diferente para gravações que podem ser sincronizadas com as tabelas de leitura quando os carregamentos do sistema permitirem, você poderá usar todo tipo de coisas. Usamos um pequeno número de tabelas para gravar em buffer e podemos lidar com um número incrível de transações porque ninguém está sendo pisado.
6. Use índices. Se você souber quais partes das consultas são usadas como chaves, de qualquer maneira.
7. Ajuste a instalação do banco de dados com base na memória. Veja os documentos do MySQL online. Na verdade, se você tem menos de 1000 sessões ativas, muitas vezes você pode apenas aumentar o número de conexões e ir em frente. link

Você pode ver SQL estúpido em ação, olhando para a maioria dos wordpress / etc. plugins. A maioria é escrita por pessoas que não recebem sql, e eles vão trazer um servidor para seus joelhos em nenhum momento com apenas um punhado de usuários.

    

Answer 3

Servidor de US $ 884, RAM de 8 GB, dual xcore quadcore, unidade SATA de 300 gb e 7200 rpm, 40% de inatividade, 5% de iowait

Uptime: 780727  Threads: 276  Questions: 1884267879  Slow queries: 3964303  Opens: 60474
Flush tables: 1  Open tables: 440  Queries per second avg: 2413.478

ao servir 220mb / seg