Para melhorar o desempenho do SQL, por que não colocar muita RAM em vez de ter discos rígidos mais rápidos?

As pessoas continuam me dizendo que, para melhorar o desempenho de um servidor SQL, compre os discos rígidos mais rápidos possíveis com o RAID 5, etc.

Então, eu estava pensando, em vez de gastar todo o dinheiro em discos rígidos rápidos RAID 5 e super-duper (o que não é barato, a propósito), por que não obter toneladas de RAM? Sabemos que um servidor SQL carrega o banco de dados na memória. A memória é muito mais rápida do que qualquer disco rígido.

Por que não colocar 100 GB de RAM em um servidor? Em seguida, basta usar um disco rígido SCSI comum com RAID 1. Isso não seria muito mais barato e rápido?

Sua análise é boa - até certo ponto -, pois absolutamente tornará as coisas mais rápidas. Você ainda precisa explicar alguns outros problemas:

1. Nem todos podem pagar memória suficiente; quando você tem vários terabytes de dados, é necessário colocá-los em disco por algum tempo. Se você não tiver muitos dados, tudo será rápido o suficiente.

2. O desempenho de gravação do seu banco de dados ainda será limitado pelos discos, para que você possa manter a promessa de que os dados foram realmente armazenados.

Se você tem um conjunto de dados pequeno ou não precisa persistir em disco, não há nada de errado com sua ideia. Ferramentas como o VoltDB estão trabalhando para reduzir os custos indiretos que as suposições mais antigas nas implementações do RDBMS criaram, que restringem o desempenho puro da memória.

(Como um aparte, as pessoas que dizem para você usar o RAID-5 para o desempenho do banco de dados provavelmente não são boas pessoas para ouvir sobre o assunto, pois quase nunca é a melhor escolha - ele possui bom desempenho de leitura, mas mau desempenho de gravação e gravação. quase sempre são as restrições de produção - porque você pode colocar a RAM no cache para resolver a maioria dos problemas de desempenho no lado da leitura.)

Versão curta: considere o tamanho do conjunto de trabalho. Versão longa: qual o tamanho dos seus dados? Se ele pode caber na memória de um servidor moderno, sim, você está absolutamente certo. Infelizmente, o maior Xeon pode endereçar 2 TB de RAM agora, e esse não é mais um conjunto de dados tão grande. Se você não pode comprar uma máquina grande o suficiente para abrigar todo o seu conjunto de trabalho na RAM, é forçado a resolver problemas com o cérebro, não com a carteira.

Se você quer velocidade:

• Aumente a RAM para que pelo menos os índices usados ​​com frequência possam caber inteiramente na RAM (por exemplo, em um sistema em que trabalho, 32 GB de RAM são suficientes para um banco de dados de 350 GB, porque os índices são o que você precisa na RAM, não os dados brutos)
• Use RAID10 com qualquer disco (discos mais rápidos são melhores)
• Evite RAID5
• Divida mdf, ldf e temp DB em conjuntos de eixos discretos (exemplo: tempdb em seu próprio conjunto RAID1, ldf em seu próprio conjunto de eixos RAID1 ou RAID10, mdf em um conjunto RAID 10 com pelo menos 4 discos totais)

Siga essas etapas e o SQL Server voará.

Então, se você quiser, adicione mais RAM ... mas faça o que precede primeiro, e você poderá descobrir que está pronto.

RAM é o novo disco, disco é a nova fita.

Em http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Note que foi há seis anos. Sim, temos sistemas de banco de dados que tentam (e tentam arduamente) manter todo o conjunto de dados na RAM e fragmentar várias máquinas do que usar o disco porque o disco tem magnitudes mais lentas. Você precisa gravar o conjunto de dados no disco, mas, como no lema acima, isso é mais parecido com uma tarefa de backup em segundo plano do que com uma operação online. A durabilidade é alcançada através do acréscimo de logs apenas nesses bancos de dados (penso no MongoDB e Redis, mas há muito mais).

Essa pergunta é semelhante a uma pergunta básica que levou a muita pesquisa e desenvolvimento em arquiteturas de banco de dados nos últimos 5 a 10 anos. Agora que é possível armazenar um banco de dados inteiro na RAM para muitos casos de uso, o banco de dados precisa ser projetado para trabalhar na RAM, em vez de simplesmente aplicar arquiteturas herdadas mais antigas ao armazenamento baseado em RAM.

Assim como muitas linguagens menores e com fins especiais foram amplamente adotadas nos últimos anos, estamos entrando em uma era em que serão necessários mais bancos de dados para fins especiais.

Para uma leitura mais aprofundada sobre esse tópico, recomendo o artigo acadêmico O fim de uma era arquitetônica (é hora de uma reescrita completa) . Não é uma leitura difícil.

Não está claro se esta pergunta foi especificamente sobre o SQL Server. O pôster original deve esclarecer isso.

Daniel Pittman escreveu:

Se você tem um conjunto de dados pequeno ou não precisa persistir em disco, não há nada de errado com a sua ideia. Ferramentas como o VoltDB estão trabalhando para reduzir as despesas gerais que as suposições mais antigas das implementações do RDBMS criaram que restringem o desempenho puro da memória.

Reduzir os custos indiretos de suposições mais antigas em implementações de RDBMS era exatamente o objetivo de design do VoltDB , mas é dimensionado horizontalmente sem limite arquitetônico no tamanho dos dados e pode persistir em disco para obter durabilidade total usando instantâneos e registro de comandos.

Se você puder obter um servidor com RAM suficiente para armazenar, pelo menos, a parte quente do seu conjunto de dados, você estará bem. Além disso, o RAID 1 e 5 não são a maneira mais rápida de organizar seus dados - o RAID 0 é mais rápido, mas, então, você terá que considerar as chances mais altas de uma falha no sistema de arquivos que apaga o seu banco de dados - não é uma coisa agradável de acontecer. . Você pode RAID 1 ou RAID 5 sua matriz RAID 0, desde que tenha unidades e controladores suficientes.

Você pode até brincar com replicação aqui - faça suas gravações em um servidor com muito disco, que replica em um ou mais servidores com muita memória, onde você executa consultas complicadas.

Infelizmente, os RDBMSs parecem estar no domínio das grandes empresas - eles não são tão fáceis de crescer horizontalmente.

Este é um caso de "depende do que você está fazendo". Talvez o conselho "certo" seja evitar completamente o SQL e usar o memcache / redis / etc!

Concordo com você que a RAM extra ajudará muito, especialmente se você conseguir ler todo o conjunto de trabalho na RAM. Sim, ainda será necessário gravar dados, mas se você tiver principalmente leituras, as gravações não terão contenção para E / S do disco.

No entanto, o desempenho do disco geralmente é um gargalo nos servidores SQL e mais difícil do que outras coisas, como a RAM, para atualizar posteriormente (se você tiver um servidor que não esteja totalmente preenchido com DIMMs).

Houve vários comentários sobre o RAID5 ser lento, mas eu diria que esse nem sempre é o caso, portanto, tenha cuidado antes de fazer declarações abrangentes. Servidores realmente sofisticados com placas RAID rápidas e muitos BBWC às vezes são muito mais rápidos em RAID5 (ou RAID50 com> 4 discos) do que em RAID10 ...

Ao longo dos anos, experimentei pessoalmente matrizes RAID5 lentas, mas depois de comparar um DL360 G5 com 4 discos SAS 146G em ~ 2009, tivemos que verificar novamente nossos testes. De fato, o array foi mais rápido com o RAID5 do que o RAID10 em quase todos os testes. BBWC e cálculos rápidos de paridade permitiram que o servidor pudesse usar os 4 discos com muito mais eficiência como uma matriz RAID5 do que RAID10. Alguns dos testes mostraram uma taxa de transferência 50% melhor com o RAID5 e quase nenhum foi mais lento. Os testes que foram mais lentos tiveram apenas 5 a 10% de desconto.

Eu alertaria as pessoas que fazem declarações gerais de que o RAID5 é lento, todo mundo diz on-line, mas simplesmente não é verdade em todos os casos.

Você tem um pacote de doces para escolher e realmente depende do sabor que você deseja.

1. Os bancos de dados terão configuração para armazenar em cache as consultas e onde esse cache existe, memória ou disco rígido.
2. O RAID 5 nem sempre é o mais rápido, mas o RAID 0 (JBOD) é uma faixa e é rápido, já que o RAID 5 também é uma faixa, a ideia é a mesma.
3. O RAID 1 não melhorará sua velocidade, é apenas um espelho.
4. O desempenho do SQL é baseado na indexação e é a primeira coisa a verificar. Muito importante em bancos de dados relacionais.
5. Não indexe tudo, a indexação excessiva também pode reduzir a velocidade, porque sua indexação fica sobrecarregada.
6. Às vezes, com o SQL Junins, o banco de dados fica mais lento. Usar a programação para fazer um loop de um conjunto de resultados indexados mínimos melhora a velocidade.
7. Servidores virtuais são um pesadelo na velocidade, se você não pagar os dólares.

Basta investir no conhecimento (gratuito) antes de gastar dinheiro. 1. Aprenda as configurações do seu banco de dados e verifique sua configuração atual para otimizar. 2. Observe as instruções de programação e sql, teste de unidade com scripts simples que imitam as operações envolvidas; pode até não ser o que você acha que é o problema. Se os scripts simples ocuparem tempo usando o SQL Joins, divida-o e faça a mesma coisa com um loop programado para fazer o mesmo. É aqui que a memória pode ajudar 3. Veja o plano e o servidor de hospedagem. Use ps aux em um console linux e veja se há algo sugando sua memória e processador.

O disco rígido absoluto melhora a velocidade, mas não depende de você em um espaço de servidor virtual. A memória não melhora a velocidade, a menos que você configure os serviços para ela, ponto final. RAID listrado (0,5), RPM e leitura / gravação síncrona com um barramento rápido ajudam isso. Um processador principal com um bom cache l1, l2, l3 ajudará no processamento do gargalo. posso ouvir por Xeon!

No geral, você deve manter em mente o tamanho e a escalabilidade. Embora você pareça começar com pequenas necessidades de armazenamento, seus dados crescerão muito rapidamente e exponencialmente. Os bancos de dados são melhores usando dados atômicos, que são divididos no menor tamanho possível. Devido ao tamanho pequeno, ele viaja mais rapidamente dentro do data warehouse. Então, você também leva em consideração a estrutura do banco de dados. No futuro, você poderá vincular a bancos de dados externos, e é por isso que a estrutura também é crucial. Nesse cenário, faria pouca diferença para sua consulta se metade dos dados residir fora do seu data mart. Quando os dados são consultados, o objetivo é não manter os dados armazenados na RAM; em vez disso, a consulta deve ser rápida no acesso e no retorno de dados.

• Você nem sempre usa o RAID 5 para dados. Depende dos dados e de sua importância, além do que foi mencionado anteriormente sobre backups. O RAID 1 pode ser usado e é.
• Você precisaria atualizar todos os servidores dentro do seu intervalo de consultas para melhorar a velocidade. Como muitos dos dados estão fora do seu controle, eles vão se afogar em algum lugar fora do seu data mart. (No caso de você atualizar seu próprio)