O advento do SSD tem alguma implicação na otimização do banco de dados?

Hoje eu estava navegando por um livro sobre otimização do SQL Server e parecia que uma certa quantidade de idéias se baseava em um modelo linear de armazenamento. Como os SSDs têm um modelo de armazenamento completamente diferente, eles mudam de alguma forma o jogo em relação à maneira como se pensa em ajuste ou otimização de banco de dados?

Sim, eles mudam o jogo. Otimizações baseadas nas características de discos magnéticos giratórios (como tempo de busca e atraso de rotação ) podem não ser relevantes em unidades SSD. Um artigo recente ^* publicado no FITME 2010 apresenta um novo algoritmo de otimização de consulta com base nas características dos SSDs.

No entanto, essas alterações provavelmente serão de baixo nível (para algoritmos de armazenamento e recuperação, por exemplo) que podem ser implementadas efetivamente pelos desenvolvedores de banco de dados. Eles provavelmente não afetarão tanto os usuários do banco de dados.

^* IEEE Xplore - Uma otimização de consulta de armazenamento orientada a colunas para banco de dados baseado em flash

atuação

Os SSDs têm desempenho: eles não precisam procurar e a taxa de transferência é impressionante. A maioria dos softwares que lidam com discos, na medida em que são otimizados, é otimizada para reduzir o número de pesquisas síncronas. Ao fazê-lo, eles introduzem inúmeras complexidades. Com o advento de gravações rápidas e sem busca no armazenamento persistente, novos sistemas de armazenamento de dados não precisarão mais dessas complexidades.

Durabilidade

Atualmente, os SSDs têm altas taxas de falhas. Seu SSD falhará. Seus SSDs falharão a uma taxa muito maior que os discos magnéticos. Você deve contornar isso com replicação, backups, etc. Isso introduz seu próprio conjunto de complexidades.

A redução geral no preço do armazenamento tem efeitos muito mais profundos.

Antes de termos o SQL, tínhamos bancos de dados hierárquicos e de rede super otimizados, nos quais os DBAs tinham que planejar cuidadosamente a localização dos dados de rastreamento e cilindro.

Os bancos de dados SQL são muito menos eficientes. Mas agora que os discos são baratos, enormes e rápidos, mal nos importamos.

Os bancos de dados NoSQL ("Documento") podem ser um pouco menos eficientes que o SQL, porque não há a mesma capacidade de mapeamento lógico para físico entre o esquema lógico SQL e o esquema físico subjacente de arquivos ou espaços de tabela ou qualquer outra coisa. E mal nos importamos.

É provável que as melhorias no desempenho do SSD sejam perdidas nas alterações causadas pelo uso de bancos de dados NoSQL na maneira como arquitetamos os sistemas em geral.

O principal problema da otimização de qualquer coisa para SSDs tem a ver com a forma como eles escrevem dados. Um disco rígido tradicional normalmente armazena dados em pequenos setores de cerca de 512 bytes e pode realmente manipular setores diretamente nesse nível ou mesmo abaixo desse nível.

Os SSDs têm algumas desvantagens em relação às gravações:

• Um tamanho mínimo de gravação de bloco de cerca de 4-8 KB.
• As gravações só podem ser executadas em uma página inteira, normalmente de 256 KB.
• Somente blocos vazios podem ser gravados.

Um cenário típico de pesadelo, conhecido como amplificação de gravação , é quando você deseja gravar um único byte em um local no disco que tenha alguns blocos já em uso. Para escrever lá, você precisa primeiro copiar a página inteira de 256 KB na memória, apagar o bloco inteiro, alterar o byte único na página e depois gravar novamente a página inteira de 256 KB modificada. Então, para escrever um único byte, houve cerca de meio megabyte de "tráfego"!

Existem muitas otimizações para esse problema implementadas no nível de SSD, controlador e até sistema operacional, mas, sem dúvida, os DBMSs podem se beneficiar adaptando essas otimizações ao seu trabalho específico.

No entanto, isso não é algo que os usuários de banco de dados (como em usar um banco de dados em seu aplicativo) precisam pensar, pois dependerão muito das decisões de design / implementação no nível do DBMS.

Pelo que entendi no blog ServerFault , os servidores de banco de dados precisam ter hardware robusto. O servidor de banco de dados dos sites de troca de pilhas está executando SSDs (consulte http://blog.serverfault.com/post/our-storage-decision/ ) e eu imaginaria que a otimização de consultas ainda é muito necessária. A CPU e a memória são afetadas pelas consultas ao banco de dados e também pelas E / S.

No entanto, o desempenho do banco de dados depende muito de E / S, portanto os SSDs certamente ajudariam.

Sim, pelas razões que todos declararam.

Eu estava ouvindo um podcast dizendo que grandes pedaços de RDBMSs como Oracle, SQL Server etc começarão a ser "excluídos" se puderem resolver a separação adequadamente. Detecte se é uma unidade SSD e otimize de acordo.

Há muito código extra incorporado ao armazenamento em cache e gravação de dados que simplesmente não são mais necessários.

Ainda mais interessante é o RAMSAN e suas variantes. Basicamente, uma unidade de disco rígido feita de chips de RAM com um no-break de X horas e a capacidade de gravar em segundo plano para armazenamento em HDD de longo prazo.