Le concept d'index clusterisé dans une conception de base de données est-il sensé lors de l'utilisation de disques SSD?

Lors de la conception d'un schéma de données serveur SQL et des requêtes, sprocs, vues, etc. suivants, la notion d'index clusterisé et l'ordre des données sur le disque ont-elles un sens à prendre en compte pour les conceptions de base de données conçues explicitement pour être déployées sur des plates-formes SSD?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"Un index en cluster détermine l'ordre physique des données dans une table."

Sur une plate-forme de disque physique, la conception pour les prendre en compte est logique dans la mesure où une analyse physique des données pour extraire des lignes "séquentielles" peut être plus performante qu'une recherche dans la table.
Sur une plate-forme SSD, tous les accès en lecture de données utilisent une recherche identique. Il n'y a pas de concept "d'ordre physique" et les lectures de données ne sont pas "séquentielles" dans le sens où les bits sont stockés sur le même morceau de silicium.

Ainsi, lors de la conception d'une base de données d'application, la prise en compte de l'index clusterisé est-elle pertinente pour cette plate-forme?

Ma pensée initiale est que ce n’est pas parce que l’idée de «données ordonnées» ne s’applique pas au stockage sur disque SSD ni à l’optimisation recherche / récupération.

EDIT: Je sais que SQL Server en créera un, je suis en train de me demander s'il est logique de penser à cela lors de la conception / optimisation.

Posez-vous une autre question: si toute la base de données est en mémoire et que je ne dois jamais toucher le disque, est-ce que je veux stocker mes données dans un arbre B commandé ou dois-je stocker mes données dans un segment non ordonné?

La réponse à cette question dépendra de votre modèle d'accès. Dans la plupart des cas, votre accès nécessite une recherche sur une seule ligne (c'est-à-dire une recherche) et des analyses de plage. Ces modèles d'accès nécessitent un arbre B, sinon ils sont inefficaces. Certains autres modèles d'accès, courants dans DW et OLAP, font toujours des agrégats de bout en bout sur la totalité du tableau et ils ne tirent aucun avantage des analyses de plage. Au fur et à mesure que vous explorez d'autres ressources, d'autres exigences deviennent évidentes, telles que la vitesse d'insertion et d'affectation dans un segment de mémoire par rapport à B-Tree peut jouer un rôle dans les tâches de transfert ETL énormes. Mais la plupart du temps, la réponse se résume en réalité à une question: cherchez-vous ou recherchez-vous une plage de balayage? Le nombre écrasant de fois où la réponse est OUI. Et par conséquent, le nombre écrasant de fois où la conception nécessite un index clusterisé.

En d'autres termes: le fait de lire le disque à partir d'un disque dans un ordre aléatoire ne signifie pas forcément que vous pouvez mettre à la corbeille vos TLB et vos lignes L2 dans un bonanza d'analyse à 64 Go de RAM ...

Si vous utilisez un index clusterisé bien choisi, vous aurez plus de chances d'obtenir toutes les données liées dont vous avez besoin dans moins de pages de données. Autrement dit, vous pouvez stocker les données dont vous avez besoin dans moins de mémoire. Cela présente un avantage, que vous utilisiez des disques ou des disques SSD.

Mais vous avez raison de dire que l’autre avantage d’un index clusterisé - lire / écrire des données liées en séquence plutôt qu’avec de nombreuses recherches de disques - n’est pas un avantage significatif pour SSD, où les recherches ne représentent pas une surcharge de performances, sont avec des disques en rotation.

Re commentaire de @Matthew PK.

Bien sûr, l'emplacement A dans la RAM est aussi rapide que l'emplacement B dans la RAM. Ce n'est pas le propos. Je parle du cas où toutes les données dont vous avez besoin ne rentrent pas dans la RAM si les données sont dispersées sur plusieurs pages. Une page donnée ne peut contenir que peu de données. Le SGBDR doit donc continuer à charger et à purger les pages lorsque vous accédez à A, B et à d'autres lignes. C'est là que vous obtenez la pénalité de performance.

Il serait préférable que chaque page soit remplie de données qui vous intéressent, dans l’espoir que toutes les demandes de rangées suivantes seront servies à partir de pages en mémoire vive. L'utilisation d'un index clusterisé est un bon moyen de vous assurer que vos données sont regroupées sur un nombre de pages inférieur.

Oui, cela a toujours du sens. Vous pensez trop bas dans votre approche. SQL Server (dans une explication très très simplifiée) stocke les données en cluster dans une architecture B-tree. Cela permet une récupération rapide des données en fonction des valeurs de clé d'index en cluster.

Un tas (pas d'index clusterisé) n'a pas d'ordre séquentiel de données. La chose la plus importante à considérer ici est que dans un tas, les pages de données ne sont pas liées dans une liste liée .

La réponse est donc oui, il est toujours judicieux de créer des index clusterisés sur des tables, même sur un disque SSD. Tout est basé sur la quantité de données que SQL Server doit filtrer pour accéder aux données résultantes. Avec un index clusterisé, il est minimisé.

Référence: http://msdn.microsoft.com/en-us/library/ms189051.aspx