Index de colonnes et clés étrangères en cluster

J'optimise les performances d'un entrepôt de données à l'aide d'index. Je suis assez nouveau sur SQL Server 2014.Microsoft décrit ce qui suit:

"Nous considérons l'index clusterstore clusterstore comme la norme pour le stockage de grandes tables de faits d'entreposage de données, et nous nous attendons à ce qu'il soit utilisé dans la plupart des scénarios d'entreposage de données. Étant donné que l'index clusterstore columnstore peut être mis à jour, votre charge de travail peut effectuer un grand nombre d'insertions, de mises à jour, et supprimer des opérations. " http://msdn.microsoft.com/en-us/library/gg492088.aspx

Cependant, si vous lisez plus loin dans la documentation, vous trouverez sous limitations et restrictions:

"Impossible d'avoir des contraintes uniques, des contraintes de clé primaire ou des contraintes de clé étrangère."

Cela me déroute beaucoup! C'est une bonne pratique (non obligatoire) d'avoir des clés étrangères dans l'entrepôt de données pour diverses raisons (intégrité des données, relations visibles pour la couche sémantique ...)

Microsoft préconise donc des index clusterstore groupés pour les scénarios d'entrepôt de données; cependant, il ne peut pas gérer les relations de clé étrangère?!

Ai-je raison là-dessus? Quelles autres approches conseilleriez-vous? Dans le passé, j'ai utilisé un index columnstore non clusterisé dans des scénarios d'entrepôt de données, avec suppression et reconstruction pour les chargements de données. Cependant, SQL Server 2014 n'ajoute alors aucune réelle nouvelle valeur pour les entrepôts de données ??

Vous avez beaucoup de questions ici:

Q: (Le manque de clés étrangères) me confond beaucoup! C'est une bonne pratique (non obligatoire) d'avoir des Fk dans le DWH pour diverses raisons (intégrité des données, relations visibles pour la couche sémantique, ....)

R: C'est exact, c'est généralement une bonne pratique d'avoir des clés étrangères dans un entrepôt de données. Cependant, les index clusterstore groupés ne le prennent pas encore en charge.

Q: Donc, MS préconise les index de magasins de colonnes en cluster pour les scénarios DWH, mais il ne peut pas gérer les relations FK?!

R: Microsoft vous donne des outils. C'est à vous de voir comment vous utilisez ces outils.

Si votre plus grand défi est un manque d'intégrité des données dans votre entrepôt de données, alors l'outil que vous voulez est des tables conventionnelles avec des clés étrangères.

Si votre plus grand défi est la performance des requêtes et que vous êtes prêt à vérifier l'intégrité de vos propres données dans le cadre du processus de chargement, l'outil que vous souhaitez est les index clusterstore columnstore.

Q: Cependant SQL 2014 n'ajoute aucune vraie nouvelle valeur pour DWH ??

R: Heureusement, le magasin de colonnes en cluster n'était pas la seule nouvelle fonctionnalité de SQL Server 2014. Par exemple, consultez le nouvel estimateur de cardinalité.

Q: Pourquoi suis-je si en colère et amer de la façon dont ma fonctionnalité préférée a été implémentée?

R: Vous m'avez attrapé - vous n'avez pas vraiment posé cette question - mais j'y répondrai quand même. Bienvenue dans le monde des logiciels tiers où tout n'est pas construit selon vos spécifications exactes. Si vous ressentez avec passion un changement que vous aimeriez voir dans un produit Microsoft, consultez Connect.Microsoft.com . C'est leur processus de rétroaction où vous pouvez soumettre un changement, d'autres personnes peuvent le voter, puis l'équipe produit le lit et vous explique pourquoi il ne le mettra pas en œuvre. Parfois. La plupart du temps, ils le marquent simplement comme "ne résoudra pas, fonctionne sur ma machine" mais bon, parfois vous obtenez des réponses.

Je peux comprendre que vous sentiez que certaines pièces auxquelles vous êtes habitué manquent. Mais c'est uniquement parce qu'ils manquent.

Néanmoins, SQL Server était utilisé avec succès lorsque les clés étrangères n'étaient qu'un concept (que nous avions implémenté via des déclencheurs à cette époque), et non une implémentation physique telle qu'une contrainte. L'intégrité référentielle déclarative était là au moins par SQL Server 7.0, mais beaucoup plus faible que l'implémentation actuelle.

En ce qui concerne la valeur de l'index de cluster de colonnes, il fournit un index et les lignes peuvent être mises à jour. Cette discussion peut vous être utile: http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj souligne qu'il existe un moyen de créer une vue indexée / matérialisée en haut de cette table, avec Clustering Key comme PK (1ère colonne de la table / vue). Que cela vous convienne, bien sûr, c'est une décision que vous devez prendre.

Mais, comme l'ont commenté Aaron Bertrand et TomTom, il s'agit de meilleures performances. Si vous pouvez gérer les autres problèmes qui vous concernent (et je pense qu'ils sont gérables), vous obtenez plusieurs avantages. Utilisez donc le ColumnStore pour ce qui est capable de faire et de gérer vous-même les fonctionnalités manquantes.

Cette question concerne SQL 2014, mais je veux fournir des informations supplémentaires à la lumière des modifications apportées dans SQL 2016 aux index columnstore, car il peut être difficile de trier les limitations dans différentes versions et cette question fait toujours surface assez haut sur Google:

Pour SQL 2016, Microsoft décrit une méthode pour utiliser des index btree non clusterisés (qui peuvent désormais être ajoutés en tant qu'index secondaires sur une table columnstore en cluster) pour appliquer les contraintes de clé étrangère, à condition que la contrainte soit ajoutée avant l'index columnstore: https: // docs .microsoft.com / fr-fr / sql / bases-de-données relationnelles / index / columnstore-indexes-design-guidance

Niko Neugebauer a également publié un blog à ce sujet; il est en fait possible de créer directement des contraintes uniques / étrangères sur les tables columnstore (j'ai appliqué cette approche dans mon travail): http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- plus-cluster-columnstore-améliorations-dans-sql-server-2016 /