Configurando o SQL para desempenho ideal… SSD ou HDD?

8

Alguém sabe de alguma comparação que mostre como os SSDs se comparam aos HDDs para desempenho em um ambiente SQL?

Estou tentando entender que tipo de benefício de desempenho pode ser obtido ao mudar para o SSD.

    
por spoon16 27.09.2009 / 02:50

10 respostas

14

Se você está fazendo uma grande quantidade de pequenas leituras, os SSDs são muito mais rápidos. Aqui está uma das poucas comparações sobre o desempenho do banco de dados. Veja no gráfico inferior a resposta curta. p>

Para desempenho bruto, os SSDs oferecem muitas vantagens, sendo a principal delas que o tempo de busca é efetivamente 0, o que significa que todos os pequenos hits de HD de um banco de dados são tratados com muito mais rapidez.

No entanto, existem algumas preocupações com a geração atual no tempo de gravação, já que depois de tantas gravações, um bloco não é mais utilizável. Eles podem escrever um pouco, eu acredito que as informações da Intel digam em torno de um petabyte de bytes para seus drives de 32GB antes que eles atinjam níveis perigosos de ware ... isso só vai melhorar com o tempo.

Para entender melhor o por que eles têm um desempenho muito melhor, leia isto artigo do Anandtech em SSDs . Ele entra em grandes detalhes de drives, o que é bom, o que não é, e os prós e contras de como eles funcionam. Na parte superior, há também um link para artigos de acompanhamento que abordam as mais recentes séries de unidades.

    
por 27.09.2009 / 05:00
4

Você pode instalar o seu sistema operacional e o software SQL em um disco rígido padrão e adicionar um SSD para manter os arquivos do banco de dados. Isso deve limitar o número de gravações que a unidade SSD experimenta e também maximizar a quantidade de espaço disponível para seus dados na unidade.

    
por 27.09.2009 / 09:19
3

Eu recomendo que você leia o seguinte documento Migrando o armazenamento do servidor para SSDs: Análise of Tradeoffs , é uma boa leitura.

Na minha opinião, ainda não há benefícios suficientes dos SDDs na área do servidor. Talvez em alguns anos eles possam valer a pena comprar, bot por enquanto HDD são a melhor escolha.

    
por 28.09.2009 / 23:50
2

A resposta de Nick Craver é boa; Eu só quero adicionar duas ressalvas a SSDs que eu acho que as pessoas devem estar cientes:

a) Os problemas do SSD com o desgaste da gravação não estão desaparecendo, eles são fundamentais para as células flash usadas. As células SLC têm uma resistência à gravação muito maior do que a MLC, portanto, o OP deve considerar a obtenção de um drive SLC através do MLC. Claro, o SLC também é significativamente mais caro.

b) A unidade atual armazena em cache os dados na unidade antes de gravá-la. Assim, existe um risco de dados perda se a energia for cortada durante uma operação de gravação. É algo que você pode contornar, mas o cache está lá tanto para o desempenho quanto para reduzir a amplificação de gravação.

IMHO nenhum dos acima são dealbreakers. Eu estaria pronto para implantar SSDs na produção hoje, mas com algum planejamento primeiro.

  1. Se um pequeno risco de perda de dados for inaceitável, os discos rígidos SAS convencionais com o cache de dados desativado poderão ser uma opção melhor.
  2. Acho que você deve medir a quantidade de dados gravados na unidade SSD em um dia normal. Com base nisso e os fabricantes usam especificações, calcule o tempo de vida esperado do SSD com seu padrão de uso. Se o tempo de vida esperado for menor do que o tempo de vida planejado dos servidores, defina uma data de substituição preventiva para o SSD. Assim como as peças de avião, troque-as antes que se torne provável que elas falhem.
por 28.09.2009 / 21:28
1

Alguma coisa para ter em mente.

Se você estiver acessando o banco de dados o suficiente para que suas leituras estejam ficando mais lentas e você precise de SSDs, será necessário corrigir seus índices ou adicionar mais RAM ao servidor.

A maioria dos servidores de banco de dados, uma vez totalmente ajustados, não precisa que os SSDs funcionem bem.

    
por 28.09.2009 / 23:09
1

Leia este artigo (antigo - 2009):

Resumo: substitua as unidades SAS de 24 x 15k RPM por SSDs 6 (sim seis) e ainda obtenha um desempenho 35% maior. Isso foi com a Intel X25Ms, que não é mais o melhor cão para SSDs.

Para pessoas de banco de dados, isso é fantástico, pois você pode ter servidores menores e mais rápidos usando menos energia.

    
por 02.03.2011 / 10:48
1

Uma coisa a considerar é ter o registro de transcrição em um HDD e seu MDF em um SSD. A vida útil também depende muito do tipo de aplicativo. O OLTP pode queimar rapidamente onde os dados razoavelmente estáticos não devem ter problemas.

    
por 04.04.2011 / 22:12
1

Minha própria experiência foi misturada aqui ...

Teste no windows 7 com o sql server 2008 express r2. Correndo em um i7 Desktop com um Sandy Bridge e 12G ram instalado (DDR3 eu acho?). Desculpem a configuração sendo desktop, eu estava apenas depois de ver quantos registros eu posso gerenciar na plataforma i7 antes de construir um servidor.

Primeiro, executei esses testes na unidade instalada de 1.5TB 7200rpm para obter os tempos de base.

10k registra com procs de atualização, otimiza as tabelas para armazenar os dados relacionados anteriormente em uma tabela simples, adiciona índices até que eu tenha o tempo de alguns segundos como ponto de partida, então eu dupliquei os registros em até 1,2 milhão e tem um tempo de 0: 3: 37 para as mesmas atualizações. 3 1/2 minutos não são ruins para esta configuração não-raid.

Duping os recordes até 2,56 milhões me deu um tempo de 0:15:57 - quase um aumento de 5x. Provavelmente devido principalmente à paginação após a memória de 12G instalada.

Instalado o drive SSD e movido os bancos de dados, o tempo realmente aumentou para pouco mais de 20 minutos. Eu estou supondo que isso é porque os arquivos de paginação são por disco rígido e não havia nenhum por padrão na unidade SSD como não foi instalado como o drive do sistema operacional (bluescreens em abundância quando eu tentei isso).

Adicionado um arquivo de paginação ao drive SSD e reran o teste, 0: 5: 52 -m para que o arquivo de paginação pareça ter feito o truque, mas não tenho certeza se um arquivo de paginação é um bom ajuste para um drive SSD para todos os acima razões, eles são strongmente writtin e podem adicionar desgaste indevido na unidade.

Uma ressalva, também habilitei o SmartBoost nessa unidade e isso pode ter influenciado os timings, e será executado novamente sem ele.

Meu melhor sentido é que é mais fácil adicionar memória nos dias de hoje, e pelo custo, talvez um ataque 0 + 1 de discos híbridos faria um trabalho quase tão bom sem os problemas.

edite: desative o arquivo de paginação no SSD e deixe que o impulso inteligente faça a sua parte, o tempo melhorou de 5:52 minutos para 4:55 minutos para 2,56 milhões de registros com uma série de três atualizações cada. Vou tentar o cache SSD 8G na unidade híbrida Seagate 750G em seguida. então, se isso não for ruim, eu irei experimentá-los em raid 0 + 1.

última atualização sobre isso, já que este é um tópico antigo - mas eu queria colocar os resultados que consegui para que alguém possa encontrá-los.

Mover o banco de dados para o Seagate 750G Hybrid com um cache SSD de 8 G Executei o teste algumas vezes para que o cache de SSD possa aprender. Isso me dá um tempo de 5:15 m: s para o mesmo teste, atualizando 2,56 milhões de registros - isso é o suficiente para o desempenho do SSD (4:55 m: s com o Intel Smartboost) para eu considerar o custo.

Por cerca de US $ 50 a mais (US $ 239 versus US $ 189 atualmente), o híbrido oferece mais de 6x de armazenamento e quase o mesmo desempenho, sem executar qualquer software adicional para otimização. Em uma invasão 0 + 1, espero que os timings tenham sido muito melhorados e essa unidade tem uma garantia de 5 anos, e espero que eu não precise dela.

    
por 28.12.2011 / 15:50
0

Pessoalmente, eu não usaria SSDs pelas razões já mencionadas; eles vão diminuir gradualmente antes de eventualmente falhar. Ainda não sabemos quando isso será - estimativas atuais são apenas isso - estimativas. Lembra quando todos nós compramos esses CDs "indestrutíveis" no início dos anos 80? Alguns anos mais tarde, consideramos o armazenamento de dados no CD de maneira tão louca quanto o uso de disquetes.

Se você tiver o hardware, o sistema operacional e o banco de dados configurados corretamente, não será necessário apostar em SSDs.

Em alguns anos, quando os produtos amadurecerem um pouco, será um cenário diferente. Mas até então ...

    
por 28.09.2009 / 23:40
0

O artigo da Microsoft Research se preocupa com o custo por GB em vez do ganho de desempenho. Na verdade, ele não cabe e testa as unidades, mas usa um algoritmo de retroalimentação baseado em arquivos de log de servidores reais.

Algumas coisas que vêm à mente com SSD e SQL:

1 / Se você deixar de adicionar os índices corretos, o SSD será muito mais tolerante, já que os tempos de busca aleatória são muito baixos.

2 / Os custos estão diminuindo quando esse estudo foi feito e para pequenos aplicativos da Web, por exemplo, executar o back-end de um aplicativo de telefone, não servidores corporativos do Exchange, o desempenho poderia economizar na contratação de um consultor para ajustar o SQL Server .

3 / Uma única unidade SSD com cópia de sombra certamente tem que ser mais barata que um monte de fusos em um gabinete RAID e no controlador e nas conexões. Sem mencionar o poder e aquecimento e espaço em rack.

4 / Spindles são notórios por serem a parte que mais morre em um computador. O SSD não tem partes móveis e uma hora de inatividade pode custar o preço de um SSD de uma só vez.

5 / Desgaste é um problema, mas eles têm maneiras de gerenciá-lo (envolvendo blocos de dispersão), que são possíveis porque dados fragmentados aleatoriamente não retardarão um SSD. Além disso, um pequeno banco de dados em um disco grande provavelmente não se desgastará a tempo de comprar um novo mais barato no futuro.

6 / Há uma tendência para bancos de dados não relacionais e fazer junções na camada intermediária. Isso pode realmente mudar as coisas: E / S para simples tabelas não indexadas em drives SSD em shards sem penalidade de desempenho e com uma proposta de escalonamento muito mais simples. Também salvando em licenças do SQL Server por shard.

7 / Isso tudo é teórico. Se alguém tiver testes de desempenho do mundo real contra spindles, adoraria ver.

Luke

    
por 17.05.2010 / 12:18