#JSS2014 Les journées SQL Server 2014 Un événement organisé par GUSS.

Présentation au sujet: "#JSS2014 Les journées SQL Server 2014 Un événement organisé par GUSS."— Transcription de la présentation:

1 #JSS2014 Les journées SQL Server 2014 Un événement organisé par GUSS

2 #JSS2014 Les journées SQL Server 2014 Un événement organisé par GUSS Optimisation many-to-many SSAS Ricquebourg Thomas Sauget Charles-Henri

3 #JSS2014 Merci à nos sponsors

4 #JSS2014 Thomas Ricquebourg Développeur BI Charles-Henri Sauget Consultant Décisionnel depuis 2009 Qui sommes-nous www.sarenza.com

5 #JSS2014 Tour d’horizon des axes d’optimisation des M2M – Partitionnement – Agrégations Les matrices de compression en détails – Présentation du fonctionnement – Utilisation de BIDS Helper – Démonstrations Agenda

6 #JSS2014 Exemple – Des raisons d’achat et des achats – Des personnes et des comptes bancaires Gestions SSAS – Multi dim : Native – Tabulaire : Non Native Rappel des M2M

7 #JSS2014 Modèle de données DimPost DimPostType DimUser DimBadge DimDate DimComment FactPost FactComment FactBadge

8 #JSS2014 Croiser badge et commentaire – Connaitre le score et nombre de commentaires par badge Gérer les relations – Faire attention à ne pas sommer n’importe comment Performance et optimisation – Avoir un temps de réponse minimum Ce que l’on souhaite

9 #JSS2014 Par défaut 1 groupe de mesure = 1 partition Découpage d’un groupe de mesure – Par années – Par pays Application d’une clause WHERE Processing et requête plus rapides – Parallélisme – Scanne moins de données Les partitions

10 #JSS2014 Meilleure flexibilité – Partitions SSAS = Partitions SQL – Gestion de la dernière partition – Moins de 1000 partitions Script XMLA – Création de partition plus simple Alerte SSDT partition par défaut Supérieur à 20 millions de lignes ou +250 Mo Définir une agrégation Règles de base Pas de chevauchement, pas de “trous” 5 à 20 millions de lignes et 3 Go Une large partition mieux que plusieurs petites Les partitions : Bonnes pratiques GestionOptimisation

11 #JSS2014 Précalculs – Des résultats de requêtes en avance : GROUP BY Fonctionne sur des partitions Trois façons de faire – Assistant classique : Manuel, Semi-Manuel – Usage Based Optimization : automatique SSAS tabulaire : pas d’aggregation possible ! Les agrégations

12 #JSS2014 Méthode – Semi manuelle : Unrestricted – Gain de performance : 20% à 30 % Pourquoi pas 100 % ? – Temps de process important – Espace disque Nombre d’agrégations – 50 à 100 Les agrégations : Bonnes pratiques

13 #JSS2014 Récap 201320142012 Agrégation ∑ CacheCache Warming

14 #JSS2014 … la solution lorsque le partitionnement et les agrégations ne suffisent plus ? Les Matrices de compression …

15 #JSS2014 SELECT * FROM [dw].[DimComment] DC INNER JOIN [dw].[FactComment] FC ON DC.CommentId = FC.CommentId INNER JOIN [dw].[FactBadge] FB ON FB.UserId = FC.UserId INNER JOIN [dw].[DimBadge] DB ON DB.BadgeId = FB.BadgeId DimBadge DimComment FactComment FactBadge DimUser Axe d’analyse commun Plusieurs Badges pour un Commentaire 90 Lignes L’approche SQL

16 #JSS2014 Les M2M sont contre- performantes car leur résolution passe par le parcours de très nombreuses lignes (9M dans notre exemple) OBJECTIF : Réduire le nombre de lignes ! Matrice de compression 1 Ligne FactBadge - Matrix DimBadge - Matrix DimBadge DimComment FactComment FactBadge DimUser

17 #JSS2014 1.Estimer les gains 2.Modification du DataWarehouse 3.Modification du Cube 4.Implémentation dans l’ETL Un processus en 4 étapes

18 #JSS2014 BIDS Helper est là pour vous aiderOu en SQL Estimation des gains (1/4)

19 #JSS2014 2 tables à créer DimBadgeMatrix – BadgeMatrixId – MatrixList FactBadgeMatrix – BadgeMatrixId – UserId 1 colonne à ajouter – BadgeMatrixId dans la table FactComment Modification du DataWarehouse (2/4) FactBadge - Matrix DimBadge - Matrix DimBadge DimComment FactComment FactBadge DimUser 9 379 497 3 012 850

20 #JSS2014 Modification du DataWarehouse (2/4) BadgeMatrixId 2 2 2 2 1 1 FactBadge (Table intermédiaire initiale) FactBadgeMatrix (Table intermédiaire compressée) FactComment DimBadgeMatrix (Table contenant les Badges en lignes) Intégration de BadgeMatrixId dans FactComment 1

21 #JSS2014 La taille de la colonne BadgeMatrixKey va devenir un problème à gérer. Il n’est pas envisageable de passer BadgeMatrixKey en VARBINARY(MAX) or nous allons très vite dépasser les 8000 caractères maximum d’un varchar(max) Modification du DataWarehouse (2/4) DimBadgeMatrix (Table contenant les Badges en lignes)

22 #JSS2014 Les fonctions de hachage sont là pour nous aider On nomme fonction de hachage une fonction particulière qui, à partir d'une donnée fournie en entrée, calcule une empreinte servant à identifier rapidement, bien qu'incomplètement, la donnée initiale. Les fonctions de hachage sont utilisées en informatique et en cryptographie. Modification du DataWarehouse (2/4) Attention à bien estimer les chances de collisions http://preshing.com/20110504/hash-collision-probabilities/

23 #JSS2014 Modification du Cube – MD (3/4)

24 #JSS2014 Modification du Cube – TABULAR (3/4) Ajouter une mesure calculée de FactComment M2M Matrix := CALCULATE ( [COUNT Comment]; SUMMARIZE ( FactBadgeMatrix; DimBadgeMatrixSha256[BadgeMatrixId] )

25 #JSS2014 L’ETL doit : Alimenter DimBadgeMatrix Alimenter FactBadgeMatrix Mettre à jour la table FactComment Si votre liste d’identifiants dépasse 8000 caractères, l’ETL doit gérer le Hachage de la colonne. Modification ETL (4/4)

26 #JSS2014 Conclusion

27 #JSS2014