SSD vs HDD para bancos de dados

Estou tentando comprar um novo servidor para executar o MySQL Server. Este novo servidor será escravo da minha máquina principal. No entanto, este servidor será dedicado a reportar apenas "Muitas leituras e consultas complexas".

Agora, estou pensando em investir em discos rígidos de estado sólido, mas queria saber se realmente vale o preço. A diferença entre um SSD e um disco rígido SATA 7200 é de cerca de US $ 1500 e o SSD tem menos espaço em disco. Se eu investir em SSD, a velocidade será perceptível?

Posso comprar 4 (500GB SATA 7200) por US $ 1500 a menos que comprar 2 (SSD de 500GB)

Você pode me ajudar a tomar a decisão de ver se vale a pena a atualização ou não?

Mais uma coisa que gostaria de mencionar é que não estou usando, query_cacheportanto haverá muitas leituras de disco.

Este servidor terá 32 GB de RAM e executará o Ubuntu 12.04

Sim, com muitas leituras e relatórios de um SSD fará uma enorme diferença. A partir de uma unidade de 7200 RPM, você não pode esperar mais do que 100 IOPS, enquanto o SSD mais barato pode ser o mínimo 5x mais rápido que isso. Com um bom SSD, você pode obter 20000 IOPS ou até mais.

Também as gravações aleatórias no SSD são muito mais rápidas, pois o disco não precisa se mover sempre.

Há três fatores que você precisa considerar aqui:

1. O tamanho do seu banco de dados
2. A quantidade de memória que você tem no servidor
3. Sua configuração my.cnf, especificamente innodb_buffer_pool_size

Se houver memória disponível> tamanho do banco de dados , seu servidor provavelmente poderá manter todos os seus dados na memória e, portanto, um SSD pode ser um desperdício de dinheiro. O buffer do InnoDB não tem nada a ver com as query_cacheopções.

Se a memória disponível <tamanho do banco de dados , é possível que as consultas precisem recuperar dados do disco. Para consultas extremamente complexas, ou se muitos usuários estiverem executando consultas ao mesmo tempo, isso pode começar a causar estresse no disco.

Em geral, os bancos de dados mantêm os dados mais usados ​​na memória - se 80% dos seus dados raramente / nunca são usados, você precisará manter apenas 20% do banco de dados na memória para manter o desempenho.

A quantidade exata de memória que você precisa não será imediatamente óbvia, mas, a menos que seu banco de dados tenha mais de 200 GB, eu recomendaria muito seguir os conselhos de Up_One e gastar dinheiro extra em memória em vez de SSDs.

Nota: Se o seu banco de dados estiver usando o MyISAM (você pode verificar isso show table status;), considere mudar para o InnoDB. O MyISAM key_buffer_cachearmazena apenas blocos de índice, enquanto o InnoDB Buffer Pool armazena blocos de dados inteiros. Na maioria dos casos, o InnoDB provará ser um mecanismo melhor para trabalhar.

Não acho que seja uma boa ideia!
Meu conselho:
aumentar o tamanho do seu buffer pool InnoDB é a melhor maneira de acelerar o MySQL. Se você pode adicionar mais RAM, faça-o. Isso colocará a maioria dos seus dados quentes na memória, então imagine! Disco vs Memória!
O cenário perfeito é ter sua memória do tamanho do
SSD do seu banco de dados - é ótimo, mas ficará caro! e só é bom para trabalhos intensivos de leitura.

Confira este link para obter um bom artigo sobre isso de Vadim Tkachenko

Para dar uma alternativa: você pode usar ambos, um disco rígido grande (idealmente, RAID1 com três discos) para manter os dados e um SSD menor para manter os índices.

Fundamentação da petição:

• os índices são razoavelmente pequenos, então você pode usar um SSD menor
• consultas comuns devem atingir principalmente os índices de qualquer maneira
• o RAID1 oferece tolerância a falhas
• o RAID1 fornece balanceamento de carga para leituras aleatórias
• três discos deixa tolerância a falhas se um disco falhar
• os índices podem ser reconstruídos se o SSD falhar

Faça.

Você mencionou que possui uma carga de trabalho com muita leitura, portanto já evitou o grande problema ao usar SSDs em bancos de dados: desgaste. Sem gravação significa sem desgaste, então você é dourado.

Como o edvinas.me mencionou, seu IOPS é muito mais rápido com o SSD do que com discos giratórios. Para um banco de dados, o IOPS se traduz em solicitações por segundo. Ignorando o cache da RAM, você atenderá cerca de 100x mais solicitações de um SSD do que de um disco de 7200RPM.

O TRIM não fará muita diferença, pois é uma carga de trabalho com muita leitura e parece que você planeja preencher o disco de qualquer maneira. Não se estresse.

Não sei de onde veio a coisa de US $ 1500. Verificando meu fornecedor (australiano) local, posso obter um SSD de 960 GB de marca respeitável por US $ 750 ( http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5-7mm-with- 9-5mm-adaptador-ssd-read-500mb-s-write-400mb-s / ). Os discos giratórios são mais ou menos gratuitos, mas US $ 750 ainda são muito mais agradáveis ​​do que US $ 1500.

(Ah, espere - você provavelmente está comprando de um fornecedor de grandes nomes, então eles estão cobrando o nariz pelo SSD? Eu sempre compro o SSD separadamente e o troco em mim, mas não sei se isso é permitido em seu ambiente.)

Você provavelmente também terá menos RAM, mas, sem conhecer sua carga de trabalho exata, é difícil julgar se você pode reduzir a RAM com segurança sem prejudicar o desempenho.

Se você ainda não tiver certeza, pode obter unidades grandes de 10k RPM, mas elas acabam custando quase o mesmo que o SSD, sendo muito mais lentas.

Se você precisar escalar muito além de 1 TB, os SSDs começarão a ficar muito caros, mas com 1 TB, diria que o SSD é uma vitória clara.

Definitivamente, concordo que o maior retorno do investimento vem do aumento do tamanho do seu innodb_db_bufferpool, mas infelizmente depende completamente do tamanho do seu conjunto de dados e da frequência com que diferentes blocos de disco são acessados. Eu mantenho vários bancos de dados que são razoavelmente grandes com mais de 200 GB ou mais, portanto, ajustar tudo na RAM não é realmente uma opção e, por esse motivo, recentemente mudamos para o armazenamento baseado em SSD. Eu fiz uma pesquisa bastante grande em termos do uso do IOPS para MySQL em diferentes matrizes RAID às quais tenho acesso. Aqui estão os resultados:

1.253 IOPS - 4 x disco SCSI 15k (3,5 ")

teste: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lido: io = 3071.7MB, bw = 5012.8KB / s, iops = 1253 , runt = 627475msec write: io = 1024.4MB, bw = 1671.7KB / s, iops = 417, runt = 627475msec cpu: usr = 0.63%, sys = 3.11%, ctx = 985926, majf = 0, minf = 22

2.558 IOPS - disco 8 x 10K RPM 900 GB SAS (2,5 ")

teste: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lido: io = 3071.7MB, bw = 10236KB / s, iops = 2558, runt = 307293msec write: io = 1024.4MB, bw = 3413.5KB / s, iops = 853, runt = 307293msec cpu: usr = 2.73%, sys = 8.72%, ctx = 904875, majf = 0, minf = 25

23.456 IOPS - Servidor SSD Rackspace Performance 2

teste: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lido: io = 3071.7MB, bw = 93708KB / s, iops = 23426, runt = 33566msec write: io = 1024,4MB, bw = 31249KB / s, iops = 7812, runt = 33566msec cpu: usr = 5,73%, sys = 35,83%, ctx = 181568, majf = 0, minf = 23

35.484 IOPS - 2 x MLC EDGE Boost de 480 GB 2,5 "espelhado ( http://www.edgememory.com )

teste: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lido: io = 3068.4MB, bw = 141934KB / s, iops = 35483, runt = 22137msec write: io = 1027,7MB, bw = 47537KB / s, iops = 11884, runt = 22137msec cpu: usr = 11,68%, sys = 69,89%, ctx = 24379, majf = 0, minf = 20

Portanto, está claro que o SSD de alta qualidade de hoje é um desempenho incrível. O dois SSD espelhado pode facilmente superar o gabinete de armazenamento SAN de 16 discos e isso é uma declaração convincente.

Se você estiver interessado em detalhes completos, o restante da redação é encontrado no meu blog:

http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html