Quais são alguns limites aproximados de desempenho (leitura/s, gravação/s) para um único servidor de banco de dados (sem arquitetura mestre-escravo), assumindo armazenamento em disco? Quantas leituras/s, gravações/s, dependendo do tipo de disco? (SSD vs não SSD), assumindo operações simples (selecionar uma linha por chave primária, atualizar uma linha, indexada corretamente). Presumo que esse limite dependa da busca/gravação do disco.
EDIT: Minha pergunta é mais sobre como obter métricas aproximadas do número de operações que um banco de dados suporta: para poder saber, por exemplo, se um novo recurso que aciona 300 inserções/s pode ser suportado sem expansão com servidores adicionais.
Responder1
Você pode ler muitos resultados de benchmarksaquicomo se o site fosse uma fonte confiável.
Responder2
Posso ser ousado a ponto de sugerir que você teste para obter a resposta para sua própria consulta. Se você tiver o Windows em execuçãoSSIO.exena sua caixa de desenvolvimento para testar o desempenho do disco e entender como ele funciona sem fazer nada.
Em seguida, execute o monitor de desempenho (supondo que você esteja no MS-SQL TKProf, talvez no Oracle - não use mysql ou outros, desculpe, haverá uma ferramenta semelhante). Execute sua consulta e veja quantas leituras/gravações e quanta CPU foi necessária para fazer isto. Você pode então comparar os números do SSIO e do Monitor de desempenho e dimensionar os requisitos de hardware para lidar com o número de usuários/frequência que esta atualização precisará com base no seu equipamento atual.
Dito isto, 300 linhas é um número muito pequeno de linhas a serem alteradas para qualquer SQL Server razoável, mesmo em discos bastante lentos. A menos que haja enormes índices compostos ou blobs, etc. Eu vivo em processos enquanto o usuário observa uma consulta que cria 1,5 milhões de linhas que são executadas em frações de segundo em hardware relativamente modesto.
Responder3
Vocênão podejulgar sem comparar seu aplicativo e carregar.
Tudo se resume a níveis de RAID, velocidades de fuso, tamanho de transações (não apenas "inserções"), gatilhos, chaves estrangeiras, hyperthreading, outros aplicativos no servidor, RAM no servidor, como os discos são organizados (volumes separados para tempdb, um por t-log de banco de dados, MDFs etc.), nível de service pack, configuração de cache do controlador RAID, cache CPU Ls + L3, número de núcleos, design de esquema, código...
A expansão é mais fácil do que a expansão: você adiciona sobrecarga se federar servidores ou tabelas de partição. Mais barato adicionar RAM e mais fusos.
Um bom artigo é35k TPS de Paul Nielson. Carga pelo menos 100 vezes maior do que 300 ou mais.