La surface ?
C'est un terme que j'ai inventé qui, dans les data center, désigne la volumétrie que l'on aura à traiter.
Pourquoi ce terme de surface ?
Car il s'agit d'une multiplication de la largeur par la hauteur, concept que l'on retrouve dans beaucoup de domaines de la gestion de données.
Sur une table en relationnel par exemple, cette surface vaut :
- Nombre de lignes X TailleDeChaqueLigne Soit la somme des stockages de chaque colonne
Sur un flux SSIS :
- Nombre de lignes X TailleDeChaqueLigne Soit la somme des stockages de chaque colonne
Sur une dimension de cube :
- (Nombre de membres X TailleDeAttribut1) + (Nombre de membres X TailleDeAttribut… )+ (Nombre de membres X TailleDeAttributn)
Sur un groupe de mesures :
- (Nombre de ligne de faits X TailleDeMesure1) + (Nombre de ligne de faits X TailleDeMesure…) + (Nombre de ligne de faits X TailleDeMesuren)
On voit tout de suite que deux facteurs jouent :
- Le nombre de lignes
- La taille de chaque attribut/colonne
Seront donc confrontés à des problème, ceux qui ont beaucoup de lignes à gérer, ou/et des colonnes de taille importante
Il est très facile d'obtenir un diviseur 2 en 'soignant' la conception :
- Nombre d'attributs restreint : ce n'est pas pour rien que les assistants de SSAS 2008 ne proposent plus que l'attribut clé
- Taille de chacun d'eux limitée au maximum
Par exemple, chez un client cette semaine, je suis passé d'une surface de 380 Mo à 170 Mo en révisant les types de données.
Le nombre de lignes est quand à lui beaucoup plus difficile à réduire car il exprime le métier… mais tout le monde comprend que créer des dimensions sur des tables de fait fera forcément mal !
A noter que , sur les dimensions de cube, on peut largement réduire cette surface en jouant sur les relations fixes entre attibuts….
En parlant de performances, je pense d'ailleurs monter un cours sur l'aspect des performances pour la mise en œuvre des cubes….
Si cela vous intéresse, vous pouvez toujours m'envoyer un mail :
conseil@dominiqueverriere.com?subject='Optimisation des cubes'