Ao projetar um esquema de dados do servidor SQL e as consultas subsequentes, sprocs, exibições, etc., a noção de um índice clusterizado e a ordem dos dados no disco faz algum sentido a considerar para projetos de banco de dados feitos explicitamente para serem implantados em plataformas SSD?
http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"Um índice agrupado determina a ordem física dos dados em uma tabela."
Em uma plataforma de disco físico, o design para considerá-los faz sentido para mim, pois uma varredura física dos dados para recuperar linhas "sequenciais" pode ter mais desempenho do que uma busca na tabela.
Em uma plataforma SSD, todos os acessos de leitura de dados usam uma busca idêntica. Não há conceito de "ordem física" e as leituras de dados não são "sequenciais" no sentido de que os bits são armazenados no mesmo pedaço de silício.
Portanto, no processo de design de um banco de dados de aplicativo , a consideração do índice clusterizado é relevante para esta plataforma?
Meu pensamento inicial é que não é porque a ideia de "dados ordenados" não se aplica ao armazenamento de SSDs e à otimização de busca/recuperação.
EDIT: Eu sei que o SQL Server criará um, só estou filosofando se faz sentido pensar nisso durante o design/otimização.
Faça a si mesmo outra pergunta: se todo o banco de dados estiver na memória e eu nunca precisar mexer no disco, quero armazenar meus dados em uma árvore B ordenada ou quero armazenar meus dados em uma pilha não ordenada?
A resposta a esta pergunta dependerá do seu padrão de acesso. Na maioria dos casos, seu acesso requer pesquisa de linha única (ou seja, buscas) e varreduras de intervalo. Esses padrões de acesso requerem um B-Tree, caso contrário, eles são ineficientes. Alguns outros padrões de acesso, comuns em DW e OLAP, sempre fazem agregações em toda a tabela de ponta a ponta e não se beneficiam das varreduras de intervalo. À medida que você avança, outros requisitos vêm à tona, como a velocidade de inserção e alocação em um heap versus a árvore B pode desempenhar um papel importante para grandes trabalhos de transferência de ETL. Mas, na maioria das vezes, a resposta realmente se resume a uma pergunta: você procura ou faz uma varredura de alcance? O número esmagador de vezes que a resposta é SIM. E, portanto, o número esmagador de vezes que o design requer um índice agrupado.
Em outras palavras: só porque é barato lê-lo do disco em ordem aleatória, não significa que você pode destruir seus TLBs e linhas L2 em uma bonança de varredura de RAM de 64 Gb ...
Se você usar um índice clusterizado bem escolhido, é mais provável que obtenha todos os dados relacionados necessários em menos páginas de dados. Ou seja, você pode armazenar os dados necessários em menos memória. Isso oferece um benefício, independentemente de você usar discos giratórios ou SSD.
Mas você está certo de que o outro benefício de um índice clusterizado - para ler/gravar dados relacionados sequencialmente em vez de muitas buscas de disco - não é um benefício significativo para o SSD, onde as buscas não são uma sobrecarga de desempenho tão grande quanto estão com discos giratórios.
Refiro-me ao comentário de @Matthew PK.
É claro que o local A na RAM é tão rápido quanto o local B na RAM. Essa não é a questão. Estou falando sobre o caso em que todos os dados de que você precisa não cabem na RAM se os dados estiverem espalhados por muitas páginas. Qualquer página pode conter apenas uma pequena quantidade de dados nos quais você está interessado. Portanto, o RDBMS precisa continuar carregando e limpando as páginas conforme você acessa A, B e outras linhas. É aí que você obtém a penalidade de desempenho.
Seria melhor que cada página estivesse cheia de dados nos quais você está interessado, na esperança de que todas as solicitações de linha subsequentes sejam atendidas a partir de páginas na RAM. Usar um índice clusterizado é uma boa maneira de garantir que seus dados sejam agrupados em menos páginas.
Sim, absolutamente ainda faz sentido. Você está pensando em um nível muito baixo em sua abordagem. O SQL Server (em uma explicação muito simplificada ) armazena dados agrupados em uma arquitetura de árvore B. Isso permite a recuperação rápida de dados com base nos valores de chave de índice clusterizado.
Um heap (sem índice clusterizado) não possui ordem sequencial de dados. A coisa mais importante a considerar aqui é que as páginas de dados não estão vinculadas em uma lista vinculada .
Portanto, a resposta é sim, ainda faz sentido criar índices clusterizados em tabelas, mesmo em um SSD. Tudo se baseia na quantidade de dados que o SQL Server precisa filtrar para chegar aos dados resultantes. Com uma busca de índice clusterizado, ela é minimizada.
Referência: http://msdn.microsoft.com/en-us/library/ms189051.aspx