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

Question

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 para discos rígidos rápidos RAID 5 e super-duper (o que não é barato, a propósito), por que não apenas 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 coisas como 100 GB de RAM em um servidor? Em seguida, basta usar um disco rígido SCSI regular com o RAID 1. Isso não seria muito mais barato e rápido?

    

Answer 1

A sua análise está bem - até certo ponto - em que absolutamente tornará as coisas mais rápidas. No entanto, você ainda precisa levar em consideração alguns outros problemas:

1. Nem todos podem ter memória suficiente; Quando você tem vários terabytes de dados, você tem que colocá-lo no disco algum tempo. Se você não tem muitos dados, tudo é rápido o suficiente.

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

Se você tiver um pequeno conjunto de dados ou não precisar persistir no disco, não há nada de errado com sua ideia. Ferramentas como o VoltDB estão trabalhando para reduzir as sobrecargas que as suposições mais antigas nas implementações do RDBMS fizeram que limitam o desempenho puro da memória.

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

    

Answer 2

Versão resumida: 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 2TB de RAM agora, e isso não é tão grande quanto um conjunto de dados. Se você não pode comprar uma máquina grande o suficiente para abrigar todo o seu conjunto de trabalho na RAM, você é forçado a resolver problemas com seu cérebro, não com sua carteira.

    

Answer 3

Se você quer velocidade:

• Aumente a RAM para que pelo menos os índices usados com frequência possam caber totalmente 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 necessários na RAM, não em dados brutos)
• Use o RAID10 com qualquer disco (discos mais rápidos são melhores)
• Evite RAID5
• Divida mdf, ldf e temp DB em conjuntos de spindles discretos (exemplo: tempdb em seu próprio conjunto RAID1, ldf em seu próprio conjunto de spindles RAID1 ou RAID10, mdf em um conjunto RAID 10 com pelo menos 4 discos no total)

Siga essas etapas e o SQL Server voará.

Então, se você quiser, adicione mais RAM ... mas faça o acima primeiro, e você pode achar que está pronto.

    

Answer 4

RAM is the new disk, disk is the new tape.

Em link . Note que foi há seis anos. Sim, temos sistemas de banco de dados que tentam (e tentam muito) manter todo o conjunto de dados na RAM e, em vez disso, shard em várias máquinas do que usar o disco, porque o disco é de qualquer maneira mais lento. Você precisa gravar o conjunto de dados no disco, mas, como no lema acima, é mais parecido com uma tarefa de backup em segundo plano do que uma operação on-line. A durabilidade é alcançada através do acréscimo de logs apenas com esses bancos de dados (estou pensando no MongoDB e no Redis, mas existem muito mais).

    

Answer 5

Esta questão é semelhante a uma básica que levou a muita pesquisa e desenvolvimento em arquiteturas de banco de dados nos últimos 5-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 em torno do trabalho na RAM, em vez de simplesmente aplicar arquiteturas herdadas mais antigas ao armazenamento baseado em RAM.

Assim como muitas línguas menores e mais especializadas têm sido amplamente adotadas nos últimos anos, estamos entrando em uma era em que serão necessários mais bancos de dados para propósitos especiais.

Para algumas leituras adicionais 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 essa questão era especificamente sobre o SQL Server. O pôster original deve esclarecer isso.

Daniel Pittman escreveu:

If you have a small data set, or don't need to persist it on disk, there is nothing wrong >with your idea. Tools like VoltDB are working to reduce the overheads that older assumptions >in RDBMS implementations made which constrain pure in-memory performance.

Reduzir os overheads de suposições mais antigas em implementações de RDBMS era exatamente o objetivo do projeto VoltDB , mas é dimensionável horizontalmente, sem limite de arquitetura no tamanho dos dados, e pode persistir no disco para maior durabilidade usando snapshot e registro de comandos.

    

Answer 6

Se você conseguir um servidor com RAM suficiente para manter, pelo menos, a parte mais interessante do seu conjunto de dados, você ficará bem. Além disso, o RAID 1 e 5 não são o modo mais rápido 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 elimina seu banco de dados. . Você pode RAID 1 ou RAID 5 seu array RAID 0, desde que você tenha drives e controladores suficientes.

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

Infelizmente, os RDBMSs parecem estar no reino do ferro grande - eles não são tão fáceis de crescer horizontalmente.

    

Answer 7

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!

Eu concordo com você que RAM extra ajudará muito, especialmente se você for capaz de ler todo o conjunto de trabalho na RAM. Sim, ele ainda terá que gravar dados, mas se você ler principalmente, as gravações não terão contenção para E / S de disco.

No entanto, o desempenho do disco costuma ser um gargalo nos servidores SQL e mais difícil do que outras coisas, como RAM, para atualização posterior (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 nem sempre é esse o caso, por isso tome cuidado antes de fazer declarações extensas. Servidores realmente sofisticados com cartões RAID rápidos e muitos BBWC às vezes são muito mais rápidos em RAID5 (ou RAID50 com discos > 4) do que no RAID10 ...

Ao longo dos anos, experimentei arrays RAID5 lentos, mas depois de fazer o benchmark de um DL360 G5 com 4 discos SAS 146G em 2009, tivemos que checar novamente nossos testes. De fato, o array foi mais rápido com o RAID5 do que o RAID10 em quase todos os testes. O BBWC e os cálculos de paridade rápida permitiram que o servidor pudesse usar os 4 discos com muito mais eficácia como um array RAID5 do que o 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 foram apenas 5-10% de desconto.

Gostaria de alertar as pessoas que fazem declarações genéricas de que o RAID5 é lento, todo mundo diz isso on-line, mas isso simplesmente não é verdadeiro em todos os casos.

    

Answer 8

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

1. Os bancos de dados terão configuração para armazenar consultas em cache e onde esse cache existir, 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 é praticamente a mesma.
3. O RAID 1 não melhorará sua velocidade, é apenas um espelho.
4. O desempenho do SQL é baseado em Indexação e é a primeira coisa a verificar. Muito importante em bancos de dados relacionais.
5. Não indexe tudo, mas a indexação também pode reduzir a velocidade porque sua indexação fica sobrecarregada.
6. Às vezes, com o SQL Joins, o banco de dados fica mais lento. Usar a programação para repetir um conjunto de resultados indexados mínimos melhora a velocidade.
7. Os servidores virtuais são um pesadelo na velocidade, se você não pagar os dólares.

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

Os absolutos O disco rígido 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. Um processador de núcleo com bom cache l1, l2, l3 ajudará no gargalo de processamento. posso ouvi-lo por Xeon!

    

Answer 9

No geral, você deve manter o tamanho e a escalabilidade em mente. Embora pareça começar com pequenas necessidades de armazenamento, seus dados crescerão muito rapidamente e de forma exponencial. Os DBs são melhores usando dados atômicos, que são dados divididos no menor tamanho possível. Por causa do tamanho pequeno, ele viaja mais rápido dentro do data warehouse. Então, você também considera a estrutura do banco de dados. No futuro, você poderia estar ligando a um DB externo, e é por isso que a estrutura também é crucial. Nesse cenário, faria pouca diferença para sua consulta se metade dos dados residisse fora de 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 ao acessar e retornar dados.

• Você nem sempre usa o RAID 5 para dados. Depende dos dados & sua importância, além do que foi mencionado anteriormente sobre backups. O RAID 1 pode ser usado e é.
• Você teria que atualizar todos os servidores dentro do seu intervalo de consulta para melhorar a velocidade. Como grande parte dos dados está fora de seu controle, ele vai afunilar em algum lugar fora do seu data mart. (No caso de você atualizar seu próprio)