[JSS 2013] Session : SSAS ROLAP sur Column Store Index (CSI)

Avec les possibilités offertes par SQL Server 2012, il est peut-être temps de repenser la place des bases SSAS dans les systèmes d’informations. Nous vous proposons de détailler les modes de conception et les performances de deux architectures : le ROLAP sur du XVelocity SQL Server d’un côté et du Tabular de l’autre.

 Level : 400
Speaker(s) : Patrice Harel, Charles-Henri Sauget

Le principal problème du ROLAP est un problème de performance car ce mode attaque directement la base relationnelle.

L’idée est d’utilise ici le CSI permettant d’améliorer grandement les performances des requêtes sur une base relationnelle.

– Pour le test : a été récupérée la base Wikipedia. La plus grosse table de faits contient 250 millions de lignes. La base fait 120 Go.

– Le CSI : la donnée est stockée en colonne et pas en ligne. Elle est compressée. Chaque requête ramène moins de données : on ne sélectionne qu’une partie de la table (le reste des colonnes n’est pas ramené).

Les tables sont séparées en partitions, les partitions en segments. Chaque segment étant rempli par un thread, les partitions peuvent être remplies en multithreading : gain de performance.

3 ajouts sur la version 2014 de SQL Server :dictionnaire secondaire et le delta store. Le plus important pour nous : insertion, suppression et mise à jour sur les tables avec le CSI !

Best practice : si plusieurs champs sont présents dans le CSI, il faut toujours partir du champ qui a le moins de données vers celui qui en a le plus.

Les avantages du CSI :

  • Cluster CSI en lecture/écriture dorénavant
  • BLOB
  • Segment Elimination
  • Batch Mode
  • Compression Archive.

Le CSI permet un gain de place énorme sur le disque : facteur 17 sur la base de démo des speakers.

Les intérêts du ROLAP :

  • Pas ou peu de temps de process
  • Temps réel
  • Partitionnement côté SQL

Les optimisations principales à apporter sur le ROLAP :

  • Eviter le Spill (quand il n’y a pas assez de mémoire sur le poste, la requête s’exécute en tempDB.
  • Création de statistiques
  • Dans le plan d’exécution, on doit être en batch et pas en row sur le CSI. L’option OPTION HASH JOIN sur une requête permet de supprimer les Nested Loop.
  • Optimiser les many to many

Les speakers ont ensuite présenté un tableau comparatif entre ROLAP, MOLAP et Tabular.

Dans 2 tests sur 3, le ROLAP s’est montré le plus rapide. Le tabular étant dernier, ce qui peut s’expliquer par la quantité de données chargées en mémoire provoquant des accès disque.

Pour être honnêtes, les 2 speakers ont aussi annoncé que le MOLAP  n’était pas optimisé.

Les limites du CSI :

  • Des types non supportés (varchar(max), XML,…)
  • 2 types de CSI : Clustered et non clustered. Le clustered doit être unique dans la table.

Conclusion :

2 super speakers qui maitrisent leur sujet sur le bout des doigts.

Le ROLAP reprend ici toutes ses lettres de noblesse grâce au CSI.

Il était tout simplement quasi inutilisable en l’état à cause de ses lenteurs. D’ailleurs la dernière fois que je l’avais vu « en vrai », c’était en 2009.

Couplé à la rapidité du CSI, la solution redevient viable en termes de performance.

Frédéric – Consultant décisionnel MCNEXT

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s