par Herts Chen - Mis en ligne le 23/03/2006 - Publié en Décembre 2004
Analysis Services est un moteur de requête multidimensionnel haute performance. Il prend le relais du moteur SQL relationnel pour assurer le traitement des requêtes analytiques et statistiques. Lorsque ces requêtes sont simples ou comportent des pré-agrégations, Analysis Services peut vous faciliter la tâche. En revanche, dès que le niveau de complexité des requêtes augmente, il peut s’enliser. Par exemple, une requête SQL SELECT qui inclut une clause GROUP BY et agrège des fonctions peut nécessiter plusieurs minutes, voire plus. Il est possible de récupérer le même ensemble de résultats en quelques secondes seulement si vous exécutez une instruction MDX sur un cube MOLAP (Multidimensional OLAP) Analysis Services. L’astuce consiste à passer une requête MDX à un serveur Analysis Services lié à partir de SQL Server, en utilisant la fonction OPENQUERY dans une instruction SQL SELECT, comme l’explique la documentation en ligne de SQL Server. Analysis Services précalcule alors les agrégations nécessaires au cours du traitement et de la création du cube MOLAP, de sorte que les résultats sont disponibles en tout ou partie avant qu’un utilisateur demande à les consulter.Toutefois, il est impossible de précalculer toutes les agrégations imaginables. Même un cube MOLAP complètement traité ne peut précalculer des agrégations telles que celles présentes dans les cellules calculées, les membres calculés, les formules de cumul personnalisé, les formules de membres personnalisés, ainsi que dans les instructions FILTER et ORDER. Si vous êtes habitués aux performances associées à la seule récupération d’agrégations précalculées, les performances découlant d’une requête MDX qui intègre ces types de calcul au moment de l’exécution peut sembler beaucoup trop lentes. L’origine du problème ne réside peut-être pas dans l’impossibilité d’Analysis Services à gérer efficacement les calculs au moment de l’exécution, mais dans une conception non optimisée de votre cube MOLAP.
Au cours de mon travail de création et de gestion de data warehouse pour la ville de Portland, Oregon (Etats-Unis), j’ai optimisé Analysis Services afin que les ingénieurs de la circulation puissent accéder rapidement à une multitude de statistiques sur les accidents de la circulation en agglomération. Après de nombreux essais, j’ai découvert que l’une des clés de l’optimisation de MOLAP réside dans le partitionnement des cubes. L’objet de cet article est de présenter et de comparer différentes stratégies de partitionnement de cube MOLAP et leur incidence sur les performances d’exécution des requêtes. Il aborde ensuite quelques recommandations pour la conception de partitions
Amélioration des performances d’interrogation d’Analysis Services
La présente étude des performances d’interrogation s’appuie sur mon expérience d’un data warehouse dimensionnel réel chargé de gérer l’historique des accidents de la circulation. Au moment de l’étude, le data warehouse contenait des données compilées sur une période de 17 années (de 1985 à 2001) et documentant 250 000 cas uniques. La complexité de cet entrepôt de données ne réside pas dans sa table de faits relativement petite, mais dans ses nombreuses dimensions, comme le montre le schéma en flocon de la figure 1. Les ingénieurs de la circulation de la ville de Portland recherchent les intersections présentant le nombre le plus élevé d’incidents. Ensuite, ils cherchent des indices sur les facteurs susceptibles d’accroître le nombre et la gravité des accidents. Ils se penchent sur 14 facteurs (qui correspondent aux dimensions du data warehouse), parmi lesquels l’heure, la luminosité, les conditions météorologiques, le contrôle du trafic, le véhicule et la gravité des blessures corporelles aux occupants. Parmi ces dimensions, la dimension Streets (STREET_ DIM) est la plus importante ; elle répertorie près de 30 000 intersections dans l’agglomération de Portland. Le nombre total d’enregistrements source utilisés pour créer les agrégations est le résultat d’une jointure multiple comportant 14 relations un-à-plusieurs (1:M) ou plusieurs-à-plusieurs (M:N) entre la table de faits et les tables de dimensions. Le data warehouse d’accidents contient une seule mesure : le nombre d’accidents distincts (Incident_ Count). Cette mesure évite de comptabiliser plusieurs fois le même accident dans une relation plusieurs-à-plusieurs.
Heureusement, la dimension Streets n’est pas trop volumineuse et permet donc d’utiliser le stockage de cube MOLAP (Multidimensional OLAP), qui offre les meilleures performances en matière de requêtes. Dans la terminologie Analysis Services, une dimension est dite volumineuse dès lors qu’elle contient environ 10 millions de membres. Analysis Service prend en charge les dimensions volumineuses uniquement avec les cubes HOLAP (Hybrid OLAP) ou ROLAP (Relational OLAP).
Téléchargez cette ressource
Travail à distance – Guide complet pour les Directions IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
Les articles les plus consultés
- 9 défis de transformation digitale !
- ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
- Dark Web : où sont vos données dérobées ?
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- L’utilisation des données pour survivre !
