Considérations sur les performances et approches dans les scénarios et solutions de planification de l’aide à la décision

Article
03/04/2017

S’applique à : SharePoint Server 2010 Enterprise

Dernière rubrique modifiée : 2016-11-30

Dans cet article :

Considérations sur les performances
Sécurité et rôles

Considérations sur les performances

Conception et configuration

Conservez les tailles de dimension aussi petites que possibles pour le processus de planification.
Maintenez le nombre de dimensions utilisées dans un cube au minimum requis pour la planification.
Évitez les calculs MdxScript autant que possible et utilisez au maximum les calculs côté client tels que les calculs Excel sur feuille ou les calculs relationnels planifiés pour s’exécuter périodiquement (conversion monétaire).
Lors de l’utilisation de règles MdxScript, veillez à vérifier non seulement l’exactitude logique mais aussi les performances. Parfois l’instruction MdxScript peut être modifiée pour des gains importants de performances par une écriture légèrement différente mais avec la même équivalence logique.
Évitez les hiérarchies d’ordinateurs très profondes.
Évitez les requêtes MDX complexes lorsque vous concevez des rapports et des formulaires de saisie. Les requêtes qui contiennent l’instruction WITH et d’autres membres calculés causeront une logique de mise en cache limitée sur l’ordinateur Microsoft SQL Server Analysis Services (SSAS) et par conséquent un facteur d’échelle et des performances moindres.
Si vous travaillez avec un ensemble de données important, créez plusieurs partitions pour une meilleure gestion des données statiques et volatiles.
Évitez la sécurité au niveau de la cellule à l’intérieur des définitions de sécurité des rôles car la logique de mise en cache sera limitée lorsque la sécurité s’applique au niveau de la cellule.

Taille, mise en page et utilisation des formulaires

Concevez des formulaires (tableaux croisés dynamiques) qui se servent de filtres et de segments pour limiter le nombre de cellules et l’interrogation du formulaire (c’est-à-dire, ne concevez pas le formulaire avec toute entrée possible de données visible mais fournissez un filtre ou un segment pour que la disposition du formulaire (taille) reste cohérente du point de vue de la mise en page et s’adapte au changement du segment.
La présence de plusieurs tableaux croisés dynamiques augmentera le temps d’interrogation et de réponse. La prescription est de limiter le nombre de tableaux croisés dynamiques sur la même feuille et dans le même classeur.
Lorsque vous concevez des formulaires et des rapports, définissez les valeurs par défaut des filtres sur un membre du niveau le plus bas dans la hiérarchie. Ainsi les requêtes par défaut éviteront des calculs d’agrégations inutiles sur le cube.
Évitez les modifications importantes côté client (par exemple, dans les modifications d’écriture différée des tableaux croisés dynamiques Excel) mais publiez plutôt ces modifications de manière incrémentielle sur le serveur pour optimiser les performances de SQL Server Analysis Services au moment de l’exécution.

Prise en charge des utilisateurs distants

Les utilisateurs distants sur un réseau étendu peuvent subir une connexion réseau et des temps de réponse plus lents. Pour servir ces utilisateurs, il est conseillé de :
Leur fournir leur propre instance SQL/SharePoint à proximité de leur emplacement physique.
Leur fournir l’accès Services Bureau à distance à Excel sur un ordinateur à proximité du serveur SQL/SharePoint.

Pour plus d’informations, voir Livre blanc SQL Server 2008 : Guide des performances d’Analysis Services (éventuellement en anglais).

Considérations sur ETL

ETL est le processus d’extraction des données de systèmes sources, de transformation de ces données et de leur chargement dans le modèle de données. SQL Server Integration Services est la première technologie Microsoft pour le travail avec les processus ETL. Les intégrateurs de données conçoivent des packages SSIS à l’aide de Microsoft Business Intelligence Development Studio (BIDS), qui offre les avantages suivants :

Accès à une grande bibliothèque de logique ETL intégrée pour des choses comme fusion d’ensembles de données, recherches de colonnes, gestion des erreurs, etc.
Transferts rapides pour le chargement des données depuis la source vers la destination.
Interface utilisateur pour visualiser le processus ETL.

Les packages ETL peuvent se décliner dans les domaines suivants :

Importation de données pour les dimensions, hiérarchies et faits.
Exportation de données des tables de faits vers les systèmes sources.

Importation de données

Pour notre solution, nous allons créer une table intermédiaire pour chaque table de dimensions, hiérarchies et faits existant dans notre base de données relationnelle. Les tables intermédiaires serviront initialement de table cible pour le chargement des données à partir du système source. Le processus ETL est possible sans utiliser aucune table intermédiaire, car SSIS a la capacité de transformer la plupart des données en mémoire et de charger directement dans les tables de la solution. Mais, les tables intermédiaires offrent les avantages suivants :

Instantané des tables et des relations du système source pour faciliter l’élimination d’une version des données sans risque de future perte d’accès au système source ou pour parer aux modifications imprévisibles des données.
Audit facile des données intermédiaires avant de les mettre dans les tables de la solution. Par exemple, vous pouvez décider de faire un chargement en bloc dans toutes les tables de la solution seulement après qu’une personne vérifie l’exactitude des tables intermédiaires.

Une fois les données chargées dans les tables intermédiaires et les transformations nécessaires terminées, le processus de chargement des tables intermédiaires vers les tables de la solution peut commencer. En utilisant SSIS, le chargement des tables intermédiaires vers les tables de la solution peut se résumer à un mappage des colonnes de la table source aux colonnes de la table de destination. SSIS offre un ensemble de fonctionnalités très puissantes pour ETL, et le lecteur est encouragé à s’informer davantage sur ce sujet dans le Livre blanc : Introduction aux services d’intégration SQL Server 2008 (éventuellement en anglais).

Conseil

Simplifiez le modèle de récupération SQL au moyen d’ETL. Cela améliorera les performances en réduisant la surcharge d’une connexion inutile à la base de données.

Exportation de données

En général, dans la plupart des scénarios, une fois le processus de planification terminé, les résultats doivent être collectés et traités en vue de l’exportation vers le système source où les données sont maintenues et accessibles pour la génération des rapports.

Dans notre solution, comme les données sont déjà stockées dans des tables de faits de façon normalisée, la préparation des données pour l’exportation se résume à quelques simples jointures avec les tables de dimension.

Cependant, l’exportation de données peut devenir un peu plus délicate lorsque les données à exporter n’existent pas dans la table de faits mais existent uniquement en tant que calculs sur le cube. Comment aborder ce scénario ? La réponse est d’utiliser des requêtes distribuées ad-hoc par rapport au cube OLAP (pour plus d’informations, voir Guide de planification de la modélisation et de la création de rapports pour les scénarios et les solutions de planification d’aide à la décision).

Sécurité et rôles

La sécurité doit être définie sur la base de données SSAS via les rôles de sécurité. Pour des performances optimales, il est conseillé de simplifier la sécurité autant que possible.

Le niveau de sécurité le plus élevé est celui de la base de données, il est donc recommandé que chaque travailleur de l’information nécessitant l’accès au modèle de données ait au moins l’autorisation Lire la définition sur la base de données.

Le second niveau de sécurité le plus étendu est défini sur le cube ; il contrôle si des cubes particuliers sont en lecture seule, en lecture/écriture ou bien inaccessibles.

Le niveau de sécurité suivant s’applique aux dimensions. Vous pouvez choisir de rendre des membres particuliers d’une dimension visibles ou masqués. Il est recommandé de s’arrêter à la sécurité de dimension pour des performances optimales de SQL Server Analysis Services.

Si vous définissez la sécurité au niveau d’accès le plus bas, ce sera au niveau de la cellule. Les performances en pâtiront puisque la logique de mise en cache sera très limitée pour les demandes émanant d’utilisateurs ayant une sécurité définie au niveau de la cellule.

Vous pouvez créer des rôles de sécurité sur votre base de données SQL Server Analysis Services en utilisant Microsoft SQL Server Business Intelligence Development Studio (BIDS).

Sachez que BIDS permet d’effectuer des configurations très complexes en matière de sécurité et peut demander une plus grande expertise technique d’administration pour la configuration et la maintenance. Cependant, cela peut faire l’objet de personnalisations où la sécurité peut être définie ailleurs, soit avec une feuille de calcul structurée soit avec une table SharePoint associée qui peut alimenter ensuite un module de traduction et finalement mettre à jour la sécurité OLAP en conséquence.

Sécurité complexe

Il est également possible de configurer la sécurité dynamique de SQL Server 2008 Analysis Services dans les cas où les rôles SQL Server Analysis Services standard ne suffisent pas à couvrir toutes les relations complexes existantes. Ce scénario se produit lorsque :

Chaque travailleur de l’information requiert l’accès à un ensemble spécifique de membres de dimensions
Les exigences de sécurité dimensionnelle présentent des chevauchements, où plusieurs combinaisons uniques de membres de dimensions sont attribuées à différents travailleurs de l’information.