Discussion :

[JGirardot]

Bonjour,

Nous avons une dimension adhérent qui comporte un nombre important de colonne (~150 ...), et une forte volumétrie (plusieurs millions de lignes).

Il y a un nouveau besoin sur ces adhérents, l'ajout des informations sur la loi Len, et donc l'arrivée massive de 40 colonnes supplémentaires !

Nous avons une architecture en flocon sur cette dimension afin de réduire la volumétrie globale mais les information sur la loi Len seront stockées directement dans la table de la dimension.

Cette dimension est utilisée un peu partout, dans la plupart des cubes et dans différents traitement pour construire les indicateurs

Pour l'instant les temps de traitements sont acceptable mais mieux vaut prévenir que guérir
Donc est-ce qu'il y a des bonnes pratiques / doc / conseils sur ce genre de dimension ? L'ajout des 40 colonnes dans cette même table est-il évitable via une autre modélisation ?

[Jester]

1- Pour les cubes (s'ils sont en MOLAP sous SSAS), ça n'a pas spécialement d'impact vu qu'il fait les hiérarchies à part. Il y a un peu de temps à gratter sur le processing, mais pas du significatif je pense.

2- Avec un stockage en colonne, le problème serait évité car le nombre de colonnes réelle ne rentre plus en ligne de compte mais le nombre de colonnes utilisée pour la requête donnée. SQL Server n'a pas de stockage colonne, mais sur la version 2012, il y a un index columnstore qui peut s'avérer utile.

3- Vérifier la taille, tant que toutes les dimensions font sensiblement moins que la RAM alloué au cache, ça passe. Normalement, le SGBD va lire la table de dimension avec les filtres et les projections (donc en garder un sous-ensemble) et faire une hashmap, puis lire séquentiellement la table de fait. Donc le temps de lecture de la dimension (possiblement en cache) est négligeable par rapport à la table de fait (forcément sur le disque). Oui il va perdre du temps à lire les colonnes inutiles, mais tant que c'est petit par rapport à la table de fait on s'en fiche.

4- Pour certaines requêtes, il n'y a que des petites tables et donc là la table de dim client est le bottleneck. Dans ce cas, il faut peut-être envisager une dimension additionnelle qui ne prendrais que les colonnes les plus fréquentes de la grosse dimension. Le point 2 devrait rendre cela inutile.

[JGirardot]

Merci pour la réponse, ça confirme l'impression que j'en avait donc ça me rassure.

Malheureusement, pas de SQL 2012, mais dans ma tête un index non cluster couvrant sur les principales requêtes coûteuses avait plus d'avantage que la séparation de la table.

Pour le sizing du serveur normalement c'est bon, j'ai fait gaffe au typage des colonnes pour être au plus juste en taille.