O conceito de um índice clusterizado em um design de banco de dados é sensato ao usar SSDs?

Ao projetar um esquema de dados do servidor SQL e as consultas, sprocs, visualizações etc. subsequentes, a noção de um índice clusterizado e a ordem dos dados no disco fazem algum sentido para os projetos de banco de dados criados explicitamente para serem implementados nas 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 "seqüenciais" no sentido de que os bits são armazenados no mesmo pedaço de silício.

Portanto, no processo de designar um banco de dados de aplicativos, a consideração do índice em cluster é relevante para esta plataforma?

Meu pensamento inicial é que não é porque a idéia 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 irá criar um, eu só estou filosofando sobre se faz sentido pensar sobre isso durante o projeto / otimização.

Faça outra pergunta a si mesmo: se o banco de dados inteiro estiver na memória e nunca precisar tocar no disco, desejo armazenar meus dados em uma árvore B ordenada ou quero armazenar meus dados em um heap não ordenado?

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, pesquisas) e varreduras de intervalo. Esses padrões de acesso requerem uma árvore B, caso contrário, são ineficientes. Alguns outros padrões de acesso, comuns no DW e OLAP, estão sempre agregando toda a tabela de ponta a ponta sempre e eles 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 monte versus o B-Tree pode desempenhar um papel 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 a varredura? O grande número de vezes que a resposta é SIM. E, portanto, o grande número de vezes que o design requer um índice em cluster.

Em outras palavras: só porque é barato lê-lo do disco em ordem aleatória, não significa que você pode descartar suas linhas TLBs e L2 em uma pechincha de 64 GB de RAM ...

Se você usar um índice em cluster bem escolhido, é mais provável que obtenha todos os dados relacionados necessários em menos páginas. 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 em cluster - ler / gravar dados relacionados sequencialmente, em vez de com muitas buscas em disco - não é um benefício significativo para o SSD, onde as buscas não representam uma sobrecarga de desempenho tão grande quanto elas. estão com discos giratórios.

Re 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 do caso em que todos os dados necessários não caberão 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 deve continuar carregando e limpando páginas à medida que você acessa A, B e outras linhas. É aí que você recebe a penalidade de desempenho.

Seria melhor que todas as páginas estivessem cheias de dados de seu interesse, na esperança de que todas as solicitações de linha subseqüentes sejam atendidas a partir de páginas na RAM. O uso de um índice em cluster é 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 na sua abordagem. SQL Server (em um muito muito explicação simplificada) lojas agrupados dados em uma arquitetura de B-tree. Isso permite recuperação rápida de dados com base nos valores da chave de índice em cluster.

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 ter índices agrupados criados em tabelas, mesmo em um SSD. Tudo se baseia na quantidade de dados que o SQL Server precisa filtrar para acessar os dados resultantes. Com uma busca de índice em cluster, ela é minimizada.

Referência: http://msdn.microsoft.com/en-us/library/ms189051.aspx