SSAS Tabulaire Optimisation

Présentation au sujet: "SSAS Tabulaire Optimisation"— Transcription de la présentation:

1 SSAS Tabulaire Optimisation
Sauget Charles-Henri MVP Data Platform SSAS Tabulaire Optimisation

2 SAUGET Charles-Henri www.sauget-ch.fr @SaugetCh chsauget@scop-it.com
Consultant décisionnel depuis 2009 BLOG TWITTER @SaugetCh MAIL

3 Thank you Sponsors You are Community

4 SSAS Tabulaire - Optimisation
1/ Les moteurs de Tabulaire 2/ Les outils 3/ Pistes d’optimisations

5 Moteurs de Tabulaire

6 Les moteurs de Tabulaire
SE - Storage Engine Xvelocity - Vertipaq FE – Formula Engine SE - Query FE – Query - DAX Dax query SE - Cache SSAS Tabulaire 1 Thread Permet d’effectuer des requêtes complexes Multi Thread 1 cœur par segment Les plans de requêtes de sont pas basés sur el coût

7 Stockage des données (Storage Engine)
Table Dictionnaire (.dictionary) S1 S2 Partition 1 (0.idf) = S3 Hiérarchies (GUID.hidx, .tbl.xml) Relations (.idf, .tbl.xml) Base Tabular Partition 2 (1.idf) C1 C2

8 Encodage Table initiale Distinct Dictionary Data Data_ID Ligne Cmd 1 2
N° Cmd 10 SO1510 11 SO6589 12 SO1574 13 SO5985 Dictionary N° Cmd Ligne Cmd SO1510 1 2 SO6589 SO1574 SO5985 N° Cmd SO1510 SO6589 SO1574 SO5985 Encode Data_ID 1 2 Data_ID 10 11 12 13 Ligne Cmd 1 2 R.L.E. => Run Length Encode Le run-length encoding, appelé en français le codage par plages, est un algorithme de compression de données sans perte en informatique. Data

9 Optimisations DefaultSegmentRowCount ProcessingTimeboxSecPerMRow
Partitionnement /!\ Attention de ne pas limiter la taille des segments avec les partitions VERTIPAQ /DefaultSegmentRowCount => nombre de ligne maximum par segment défault 8M Doit être une puissance de deux, plus la valeur est importante, plus la compression et donc les requêtes seront optimisé mais plus le temps de processing sera important. VertiPaq\ProcessingTimeboxSec PerMRow => Temps maximum pour trouver le meilleur algo de tri défault 10S Plus la valeur est importante plus le temps de processing augmente mais meilleurs est le taux de compression et donc meilleur perf de requêtage (à changer lorsque que le nombre de colonne est important) Si vous avez des segments de 8M et des partitions de 1M … cela n’est pas efficace de la même façon Une partition de 9M de ligne dégrade les performances

10 Les outils

11 Profiler - Spool = Data from cache

12 Dax studio Facilite la lecture du profiler
Permet de voir rapidement la répartition entre FE et SE L’option Merge XML sauve un temps précieux lors d’optimisation SSRS !

13 DMV - VertiPaq Analyzer

14 Démo

15 Attention En fonction de votre machine et de la taille de vos tables, les règles ne sont pas les mêmes Rappelez-vous 8 Millions de lignes par segment, 1 Cœur par segment. Il n’y a pas de règle immuable, utilisez les plans d’exécution afin de déduire des actions à prendre.

16 Conclusion Déplacer au maximum le calcul sur le Storage Engine
SE est Multi-Thread, FE est Mono-Thread Le Cache SE est le seul cache réutilisé par les requêtes Réduire la précision lorsque non nécessaire Eviter les DateTime / séparer Date et Time Attention aux colonnes calculées Ne pas sur-partitionner

17

18 Ajouter nb row vs compression / partitionnement