> Tech > Requêtes et goulots d’étranglement

Requêtes et goulots d’étranglement

Tech - Par iTPro - Publié le 24 juin 2010
email

La vitesse à laquelle Analysis Services répond aux requêtes est fonction de la complexité de ces dernières. Par exemple, un cube MOLAP créé en acceptant la partition par défaut dans Analysis Manager répondra à une requête simple telle que celle du listing 1 en retournant près de 2000 enregistrements en

Requêtes et goulots d’étranglement

seulement 5 secondes.

Si vos requêtes portent uniquement sur des pré-agrégations dans quelques enregistrements ou colonnes, n’importe quel cube MOLAP sera performant, indépendamment du pourcentage d’agrégation (même de seulement 5 pour cent). Toutefois, dans le cas d’une requête comme celle illustrée au listing 2, qui comporte six membres calculés, un cube MOLAP à partition unique et agrégé à 30 pour cent nécessitera 52 secondes pour renvoyer seulement 331 intersections.

Ces résultats disparates suggèrent que les goulots d’étranglement en termes de performances ne dépendent pas de la taille de l’ensemble de résultats ou du pourcentage d’agrégation dans le cube. En fait, mon expérience montre que des agrégations au-delà de 30 pour cent ne servent à rien, car le surcroît de travail résultant n’améliore en rien les performances. Pour des requêtes simples, vous n’avez pas besoin d’un taux élevé d’agrégation et lorsque les requêtes deviennent complexes, un niveau important d’agrégation n’est d’aucune utilité.

Dans Analysis Services, les goulots d’étranglement en matière de performances sont généralement dus aux membres calculés qui analysent plusieurs n-uplets et les agrègent à la volée.

Les ingénieurs de la circulation de la ville de Portland posent généralement des questions ad hoc, sans caractère hiérarchique par rapport à la dimension Time.

Ainsi, un ingénieur peut me demander de calculer le nombre total d’accidents au cours des 3 dernières années, des 5 dernières années ou sur toute période comprise entre 1985 et 2001. Il ne suffit pas d’agréger les années en créant un niveau au-dessus du niveau Year dans la dimension Time car ce nouveau niveau ne permettra de répondre qu’à une seule combinaison d’années. Cette limitation signifie que pour toutes les requêtes portant sur une combinaison d’années, il est nécessaire d’utiliser des membres calculés afin d’effectuer les agrégations correspondant aux années spécifiées.

La requête du listing 2 retourne le nombre d’accidents en fonction des membres des dimensions Time, Occupant_ Severity (gravité des blessures corporelles des occupants) et Streets. La figure 2 illustre les membres des dimensions Time et Occupant_Severity. La requête du listing 2 utilise six membres calculés, à savoir Accident_Count, Fatal_ Injury_A (blessures mortelles), Injury_B, Injury_C et PDO (Property Damage Only, dommages matériels seulement), afin de synthétiser les accidents survenus au cours des années 1998, 1999 et 2000 pour les cinq membres de la dimension Occupant_Severity. La requête demande un ensemble de résultats filtré et trié portant sur le nombre d’accidents pour chaque intersection ([Street]. [Street_List]) dans chacun des six membres calculés. A d’établir une comparaison sur les performances d’une telle agrégation à la volée, j’ai inclus le listing 3, qui accède uniquement aux pré-agrégations et ne comporte pas de membres calculés. J’ai utilisé le listing 2 et le listing 3 pour mes tests de partitionnement de cube, présentés plus loin dans cet article.

Lorsque vous devez améliorer les performances de requêtes comportant des membres calculés, la conception du cube est essentielle. Par expérience, je sais que l’aspect le plus important en la matière est le mode de partitionnement du cube. Les autres considérations telles que la quantité de mémoire, le nombre de disques ou le nombre de threads processeur disponibles, ou encore le fait d’utiliser des nombres entiers uniques pour les clés des membres, voire le recours au Usage-Based Optimization Wizard sont à cet égard secondaires.

Le partitionnement est l’opération qui consiste à découper un cube (tranches) le long d’un n-uplet tel que ([Occupant_ Severity]. [Fatal], [Time]. [2000]), lequel spécifie un membre pour chaque dimension. Lorsque la dimension n’est pas précisée dans le n-uplet, elle est intégralement prise en compte par la partition. Analysis Services conserve dans la structure du cube un pointeur direct ou un index sur la partition pour ce n-uplet. Que la requête référence le nuplet en question ou un sous-ensemble de celui-ci, Analysis Services peut accéder à la partition correspondante sans analyser l’ensemble du cube. Il existe un nombre quasiment infini de méthodes de partitionnement d’un cube et Analysis Services gère autant de partitions que nécessaire. Mais sans une règle claire de création des partitions, vous pouvez générer trop de tranches ou de tranches inappropriées sur un cube et aboutir à de moins bonnes performances qu’avec une seule partition par défaut.

Téléchargez gratuitement cette ressource

Cloud hybride : 4 Stratégies de réussite

Cloud hybride : 4 Stratégies de réussite

Que vous souhaitiez développer ou renforcer votre approche du Cloud hybride, évaluer les meilleures options ou encore enrichir votre processus de prise de décision, découvrez dans ce Guide, 4 stratégies de Cloud hybride alignées avec vos objectifs business & technologiques.

Tech - Par iTPro - Publié le 24 juin 2010