Configurando o SQL para desempenho ideal ... SSD ou HDD?

Alguém conhece 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 mudando para SSD.

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

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

No entanto, existem algumas preocupações com a geração atual sobre a vida útil da gravação, pois após tantas gravações, um bloco não é mais utilizável. Eles podem escrever um pouco, acredito que as informações da Intel rondam um petabyte de bytes para seus drives de 32GB antes de começarem a atingir níveis perigosos de mercadorias ... isso só vai melhorar com o tempo.

Para entender melhor por que eles têm um desempenho muito melhor, leia este artigo da Anandtech sobre SSDs . Ele detalha as unidades, o que é bom, o que não é e os detalhes de como eles funcionam. Na parte superior, também há um link para artigos de acompanhamento que abrangem as últimas séries de unidades.

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

eu recomendo que você leia o documento a seguir Migrando o armazenamento do servidor para SSDs: Analysis of Tradeoffs , é uma ótima leitura.

Na minha opinião, ainda não existem benefícios suficientes dos SDDs na área de servidores. Talvez em alguns anos valha a pena comprar, o bot, por enquanto, o HDD é uma escolha melhor.

A resposta de Nick Craver é boa; Eu só quero adicionar duas advertências aos SSDs que acho que as pessoas devem estar cientes:

a) Os problemas do SSD com o desgaste da gravação não desaparecem, são fundamentais para as células flash usadas. As células SLC têm uma resistência de gravação muito maior que a MLC, portanto, o OP deve considerar obter uma unidade SLC sobre MLC. Obviamente, o SLC também é significativamente mais caro.

b) As unidades atuais armazenam em cache os dados na unidade antes de escrevê-los. Portanto, há um risco de perda de dados se a energia for cortada durante uma operação de gravação. É algo que você pode solucionar, mas o cache existe tanto para desempenho quanto para reduzir a amplificação de gravação.

IMHO nenhum dos itens acima são violadores. Eu estaria pronto para implantar SSDs na produção hoje, mas com um 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 podem ser uma escolha melhor.
2. Eu 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 a vida útil esperada do SSD com seu padrão de uso. Se a vida útil esperada for menor que a vida útil planejada dos servidores, defina uma data de substituição preventiva para o SSD. Assim como as peças do avião, troque-o antes que haja probabilidade de falha.

Alguma coisa a ter em mente.

Se você estiver acessando o banco de dados o suficiente para que suas leituras estejam mais lentas e precisar 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 de SSDs para funcionar bem.

Leia este artigo (bastante antigo - 2009):

Resumo: substitua as unidades SAS de 24 x 15k RPM por 6 (sim seis) SSDs e ainda obtenha 35% mais desempenho. Isso ocorreu com os Intel X25Ms, que não são mais os principais SSDs.

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

Uma coisa a considerar é ter o log de transação em um disco rígido e seu MDF em um SSD. Além disso, a vida útil dependerá muito do tipo de aplicativo. O OLTP pode queimar rapidamente, onde dados razoavelmente estáticos não devem ter problemas.

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

Teste no windows 7 com sql server 2008 express r2. Executando em um desktop i7 com um Sandy Bridge e uma ram instalada de 12G (DDR3, eu acho?). Com a configuração de desktop, eu estava logo após ver quantos registros eu posso gerenciar na plataforma i7 antes de criar um servidor.

Executei esses testes pela primeira vez na unidade de 1.5TB 7200rpm instalada para obter os tempos de base.

Registros de 10k com procs de atualização, otimizamos as tabelas para armazenar os dados relacionados anteriormente em uma tabela simples, adicionamos índices até que eu diminuísse o tempo de alguns segundos como ponto de partida, depois dupliquei os registros até 1,2 milhão e obtive 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 invasiva.

Dupar os registros de 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 12G instalada.

Instalou a unidade SSD e moveu os bancos de dados, o tempo aumentou para pouco mais de 20 minutos. Estou assumindo que isso ocorre porque os arquivos de paginação são por disco rígido e não havia nenhum por padrão na unidade SSD, pois ela não foi instalada como a unidade do SO (abundância de telas azuis quando tentei isso).

Adicionado um arquivo de paginação à unidade SSD e refazendo o teste 0: 5: 52 -m, para que o arquivo de paginação pareça ter funcionado, mas não tenho certeza se um arquivo de paginação é adequado para uma unidade SSD pelas razões acima, eles estão fortemente gravados e podem adicionar desgaste e desgaste indevidos na unidade.

Uma ressalva, também habilitei o Smartboost nessa unidade e que também pode ter influenciado os tempos, será executada novamente sem ela.

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

edit: desativou o arquivo de paginação no SSD e deixou o impulso inteligente fazer o seu trabalho, o tempo melhorou de 5:52 minutos para 4:55 minutos para 2,56 milhões de registros com uma série de 3 atualizações cada. Vou tentar o cache SSD 8G na unidade híbrida Seagate 750G a seguir. então se isso não é ruim, vou experimentá-los no ataque 0 + 1.

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

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

Por cerca de US $ 50 a mais (US $ 239 versus US $ 189 no momento), o híbrido fornece mais de 6x o armazenamento e quase o mesmo desempenho, sem executar nenhum software adicional para otimização. Em um ataque 0 + 1, espero que os tempos sejam muito melhorados e esta unidade tenha uma garantia de 5 anos, espero que eu não precise disso.

Pessoalmente, eu não usaria SSDs pelos motivos já mencionados; eles diminuirão gradualmente antes de eventualmente falhar. Ainda não sabemos realmente quando isso será - as estimativas atuais são apenas isso - estimativas. Lembra quando todos compramos esses CDs 'indestrutíveis' no início / meados dos anos 80? Alguns anos depois, consideramos o armazenamento de dados em CD tão insensato quanto o uso de disquetes.

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

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

O artigo da Microsoft Research se preocupa com o custo por Gb, e não com o ganho de desempenho. Na verdade, ele não cabe e testa as unidades, mas usa um algoritmo de retrocesso baseado nos arquivos de log dos 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, pois os tempos de busca aleatória são muito baixos.

2 / Os custos são muito baixos quando esse estudo foi realizado e, para pequenos aplicativos da Web, por exemplo, para executar o back-end de um aplicativo de telefone, não para servidores corporativos do Exchange, o desempenho poderia economizar despesas com a contratação de um consultor para ajustar o SQL Server.

3 / Um único drive SSD com cópia de sombra certamente deve ser mais barato do que um monte de eixos em um gabinete RAID, o controlador e as conexões. Sem mencionar a energia, aquecimento e espaço no rack.

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

5 / O desgaste é um problema, mas eles têm maneiras de gerenciá-lo (envolvendo blocos de dispersão), o que é possível porque dados fragmentados aleatoriamente não retardam 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 para fazer junções na camada intermediária. Isso pode realmente mudar as coisas: E / S para tabelas simples não indexadas em unidades SSD em shards sem penalidade no desempenho e com uma proposta de dimensionamento muito mais simples. Também economizando em licenças do SQL Server por shard.

7 / Tudo isso é teórico. Se alguém tiver testes de desempenho do mundo real contra eixos, eu adoraria ver.

Lucas