Optimisation des performances des cubes OLAP

1. L’indexation

Comme évoqué dans les chapitres précédents, un cube OLAP doit être capable d’encaisser de très gros volumes de données, plusieurs millions de lignes sont fréquentes, tout en restant utilisable au quotidien. Et ce n’est pas un luxe : les volumes évoluent au rythme de l’entreprise, et un cube mal pensé peut vite devenir un cauchemar à interroger.

Pour garder un minimum de confort côté utilisateur, il faut recourir à différentes techniques d’optimisation. Les deux plus répandues sont l’indexation et le partitionnement. On pourrait dire que ce sont les deux piliers qui permettent d’éviter que le cube ne s’écroule sous son propre poids.

L’indexation (cf. chapitre Optimiser les relations faits et dimensions - Réduction des jointures complexes et optimisation des performances) reste un mécanisme central dans les SGBD. L’idée est assez intuitive : au lieu de balayer toute une table ligne par ligne, on s’appuie sur une structure de recherche qui donne accès directement aux enregistrements visés. C’est un peu comme une table des matières, il n’est pas nécessaire de relire chaque page pour retrouver un chapitre.

Dans un entrepôt de données, deux types d’index reviennent très souvent :

Index sur les clés primaires et étrangères

Les requêtes OLAP reposent presque toujours sur des jointures entre la table de faits et les tables de dimensions. Sans index, ces jointures deviennent vite très coûteuses. L’index sur clé primaire (généralement créé automatiquement par le SGBD) permet déjà de pointer rapidement vers une ligne précise. Mais ce n’est pas suffisant dans des scénarios complexes : il faut aussi indexer les clés étrangères dans la table de faits. Cela évite au moteur de parcourir des millions de lignes pour retrouver, par exemple, l’identifiant d’un produit dans sa dimension associée.Dans ce contexte, les index B-TREE sont les plus répandus. Ils conviennent particulièrement bien aux colonnes avec une forte cardinalité (par exemple...

1. Pré-agrégation

Lors du paragraphe précédent, nous avons parlé d’indexation et de partitionnement : deux leviers classiques qui changent déjà le quotidien d’un entrepôt. L’indexation raccourcit le chemin vers les lignes utiles, le partitionnement réduit le volume scanné en calant les lectures sur des tranches de temps, de région ou de tout autre axe dominant. Bien utile mais rarement suffisant, dès que les requêtes multiplient les jointures, les fenêtres temporelles et les granularités hétérogènes. C’est précisément à ce moment-là que la pré-agrégation et le stockage en cache entrent en scène.

La pré-agrégation consiste en le calcul en amont des totaux, moyennes, comptes distincts, percentiles … sur des niveaux de détail choisis, pour éviter de repasser en permanence sur des centaines de millions de lignes. Le cache, lui, évite de recommencer quand la même chose est redemandée. L’un réduit le travail, l’autre supprime la répétition. Ils n’ont pas la même utilité ni les mêmes challenges.

Pour mettre en place une pré-agrégation pertinente, les étapes suivantes seront essentielles.

1. Indexation des structures multidimensionnelles

La structure OLAP, quel que soit la technologie utilisée, propose un ensemble de mécanismes d’indexation interne qui influencent directement sur les temps de réponse des requêtes MDX. Ils tiennent surtout à la façon dont le moteur OLAP voit les données : pré-agrégations, relations hiérarchiques internes, élimination de partitions, et aussi (en ROLAP/ HOLAP) aux index du SGBD sous-jacent.

<Batch xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Commands>
    <!-- 1) Créer (ou écraser) un AggregationDesign vide -->
    <Create AllowOverwrite="true">
      <ObjectDefinition>
        <AggregationDesign>
          <ID>Agg_InternetSales_Year_Category</ID>
          <Name>Agg_InternetSales_Year_Category</Name>
          <Annotations/>...