A questão diz tudo. Mas, é verdade? Alguém pode explicar qual é o fator diferenciador aqui (como um tipo de disco é melhor que outro para uma finalidade específica)?
(Para sua informação, tentei pesquisar e conseguium artigo, que foi escrito há cerca de 3 anos.)
Responder1
Não mais. Você também pode executar bancos de dados de discos SATA - os WD Velociraptors são bastante comparáveis a muitas unidades SAS, a menos que você obtenha desempenho REALMENTE alto (portanto, banco de dados! = banco de dados).
O passo maior é de 3,5 "a 2,5" - você economiza muito dinheiro (por GB) ao usar unidades grandes e lentas de 3,5 ".
Os fatores diferenciais são:
- Os discos SAS são normalmente mais rápidos e suportam filas de comandos mais longas que os SATA (limite de 32 vs. MUITO mais).
- SSD não é outra história. Falando em 60.000 IOPS versus 450.
Em geral os bancos de dados são de uso pesado quando ficam mais pesados, com IO totalmente aleatório, então você não conta gigabytes ou RPM, você conta IOPS (operações de IO por segundo).
Responder2
Embora eu não possa dizer que já ouvi falar da regra, o conteúdo estático tem vantagens que os servidores de banco de dados não conseguem fornecer com tanta facilidade.
As unidades SATA geralmente têm tempos médios de falha mais baixos, são mais lentas e apresentam pior desempenho em E/S aleatória. O resultado é que seu custo por GB é mais barato.
Quando você armazena mídia como conteúdo estático, o sistema normalmente armazena o conteúdo em cache, de modo que normalmente não lê muito do disco, o que elimina a necessidade de ter um disco de alta velocidade.
Isto é especialmente verdadeiro para sites onde 90% dos dados apresentados representam 99% das solicitações.
Os bancos de dados, por outro lado, normalmente têm um perfil de IO que é muito mais aleatório. Os bancos de dados também geralmente não dependem do subsistema de cache do kernel para gerenciar seu conteúdo, portanto, pode se beneficiar do uso de discos mais rápidos. Eles também tendem a realizar muito mais gravações do que conteúdo estático, e é aí que as unidades SAS podem realmente ajudar.
Tenha em mente que existem tantos tons de cinza que não é tão simples ou direto assim.
- Talvez seu banco de dados não seja muito usado?
- Talvez você saiba exatamente quais tabelas serão lidas e a probabilidade dos dados serem usados?
- Talvez as gravações no banco de dados quase nunca sejam feitas?
- Talvez os tempos de resposta e os números de simultaneidade que você possui possam ser alcançados de forma eficaz com o SATA?
Eu não diria que existe uma “regra prática”. Em vez disso, por que não obter algumas medições de E/S para sua aplicação agora e quais serão suas necessidades em 2 anos? Você acha que o SATA será adequado então? E quanto ao SAS, seria isso? Talvez o SSD seja melhor ainda? Se você está falando em tempos de recuperação 30 ms mais rápidos com SAS, realmente vale a pena gastar mais? Seus clientes exigem essa velocidade extra de 30 ms?
Na maior parte do trabalho que faço, os números gerados por nossa operação não justificam realmente o SAS. E - de qualquer forma, a margem de desempenho que você obtém em relação ao custo por GB não é tão atraente para mim. Agora, com o SSD no mercado, estou ainda menos impressionado com as ofertas SAS.
Quenão significaEstou dizendo que o SAS não é adequado para você. Mas calcule seu custo por GB, descubra quais provavelmente serão suas necessidades de desempenho agora e, em alguns anos, compare os resultados com as necessidades específicas de seus clientes.