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

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

Thank you Sponsors You are Community

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

Moteurs de Tabulaire

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

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

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

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

Les outils

Profiler - Spool = Data from cache

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 !

DMV - VertiPaq Analyzer http://www.sqlbi.com/tools/vertipaq-analyzer/

Démo

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.

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

http://www.sqlbi.com/wp-content/uploads/DAX-Query-Plans.pdf https://www.sqlbi.com/articles/costs-of-relationships-in-dax/ https://www.sqlbi.com/articles/optimizing-dax-expressions-involving-multiple-measures/ https://www.microsoftpressstore.com/articles/article.aspx?p=2449192&seqNum=3 http://www.sqlbi.com/articles/optimizing-high-cardinality-columns-in-vertipaq/ https://sqlbits.com/Sessions/Event16/Optimizing_multi-billion_row_tables_in_Tabular

Ajouter nb row vs compression / partitionnement