Indexation des données dans Vertipaq : magasin de lignes contre magasin de colonnes

Dans ce didacticiel, nous allons couvrir la différence de fonctionnement de l'indexation des données dans une base de données relationnelle par rapport à Vertipaq.

Les bases de données relationnelles stockent les données ligne par ligne. En revanche, Vertipaq le fait colonne par colonne.

Voyons comment ces deux méthodes de stockage et d'indexation des données peuvent avoir un impact sur votre processus de développement de rapports, en particulier lors de l'exécution de vos requêtes.

Table des matières

• Indexation des données par ligne
• Indexation des données par colonne
• Comparaison du temps d'exécution dans les requêtes simples
• Comparaison du temps d'exécution dans des requêtes plus complexes
• Conclusion

Indexation des données par ligne

Le stockage des données ligne par ligne est la méthode traditionnelle de stockage des données. Cependant, ce processus prend plus de temps, ce qui aura un impact sur les performances de votre requête.

Supposons que nous ayons un tableau contenant la marque, la couleur, le sexe, la quantité et le prix net.

Si nous stockons tout dans cette table dans une base de données, elle stockera les données ligne par ligne. C'est pourquoi la structure de stockage de données traditionnelle est également appelée magasin de lignes.

Tout d'abord, dans la même ligne, il stockera les en-têtes de colonne trouvés sur la première ligne - Marque, Couleur, Sexe, Quantité et Prix net. Ensuite, il passe à la ligne suivante pour stocker les premiers éléments sous chaque colonne - A. Datum, Azure, un blanc, 1 et 103.2. Cela continue ligne par ligne.

Alors, comment allons-nous calculer la de la quantité en utilisant cette méthode d'indexation des données ?

Tout d'abord, il commence par la première ligne, qui contient les en-têtes de colonne. Ensuite, il saute à la ligne suivante et saute les autres données jusqu'à ce qu'il arrive à la première quantité qu'il voit, qui est 1. Ensuite, il saute de ligne en ligne, parcourant toutes les données que chaque ligne contient et rassemble toutes les quantités est trouve.

Une fois qu'il a mis de côté toutes les quantités de chaque ligne, c'est la seule fois où le calcul est terminé.

Vous pouvez probablement imaginer à quel point le processus est fastidieux si vous préparez un rapport LuckyTemplates qui utilise une connexion DirectQuery à une source de données SQL. Dans ce cas, les services d'analyse vont convertir le code DAX en langage SQL, puis commencer à parcourir la structure de données ligne par ligne.

Indexation des données par colonne

Pour éviter le long processus impliqué, vous avez la possibilité de stocker les données colonne par colonne via Vertipaq lorsque vous choisissez le mode d'importation.

Lorsque vous utilisez le magasin de colonnes au lieu du magasin de lignes, la marque, la couleur, le sexe, la quantité et le prix net seront chacun stockés dans des structures de données différentes.

Disons que nous voulons obtenir la SOMME des valeurs dans la colonne Quantité. Il ne sera pas nécessaire de passer par la marque, la couleur et d'autres éléments de données en dehors de la colonne Quantité. En un seul balayage, il lit toute la colonne Quantité de haut en bas et résume toutes les valeurs.

Pour cette raison, les requêtes seront exécutées plus rapidement par rapport à le faire de gauche à droite.

Comparaison du temps d'exécution dans les requêtes simples

Pour vraiment voir l'énorme différence entre le magasin de lignes et le magasin de colonnes, faisons quelques requêtes de test dans SQL et Vertipaq. Le temps d'exécution devrait nous dire à quelle vitesse un processus est comparé à l'autre.

Commençons par une simple requête en SQL. Nous allons calculer la SOMME de la colonne Quantité dans la table Ventes.

Comme vous pouvez le voir, le temps d'exécution total est de 2,2 secondes.

Passons maintenant à DAX Studio et utilisons la fonction EVALUATE pour exécuter la même requête. Nous devons activer les horaires du serveur et attendre la fin de la trace.

Nous devons également nous assurer que l'option "Effacer le cache puis exécuter" est sélectionnée lorsque nous exécutons la requête.

Une fois la requête exécutée, vous verrez qu'il ne faut que 3 millisecondes pour terminer la même requête que nous avons faite en SQL plus tôt.

L'ensemble de résultats doit également correspondre pour SQL et DAX Studio. Si nous les mettons côte à côte, vous pouvez voir que nous renvoyons la même valeur.

Vous pouvez essayer d'exécuter la requête plusieurs fois pour voir à quel point le temps d'exécution est cohérent.

Comparaison du temps d'exécution dans des requêtes plus complexes

Cette fois, comparons le temps d'exécution lorsque nous exécutons des requêtes plus complexes.

Disons que nous voulons identifier la SOMME de la quantité de ventes pour chaque marque. Pour ce faire, nous pouvons utiliser sur les de la marque de chaque produit. Dans le contexte bas, nous allons également créer une nouvelle table appelée Quantité totale dans laquelle nous allons la SOMME de la quantité des ventes.

Si nous exécutons ce code, vous pouvez voir que le temps d'exécution total est de 7 millisecondes.

En arrière-plan, ce code exécute en fait deux requêtes. Le premier prend la colonne Brand de la table Products, puis exécute une OUTER JOIN sur les colonnes Product Key de la colonne Sales et de la colonne Products.

La deuxième requête récupère simplement la colonne Marque de la table Produits.

Si je vais à l'écran des résultats, vous pouvez voir que la mesure de la quantité totale a été divisée en fonction de chaque marque.

Passons maintenant au serveur SQL et écrivons la même requête.

Nous allons pousser la table DaxStudio Sales à la ligne suivante, en référençant la table Sales AS S. Ensuite, nous allons également exécuter un LEFT JOIN dans la table DaxStudio Products référencée AS P, avec la S.Product Key égale à la P. Clé de produit. Nous allons également utiliser P.Brand avec la somme de la quantité et de la quantité totale dans l' instruction SELECT . Enfin, nous allons utiliser pour P.brand.

Une fois que nous aurons exécuté ce code, nous obtiendrons un tableau contenant la quantité totale séparée par chaque marque, ce qui est la même chose que nous avions précédemment dans Vertipaq.

Quant au temps d'exécution total, il reste beaucoup plus lent à 2,5 secondes.

DAX pour LuckyTemplates : Optimisation à l'aide de moteurs de formule dans DAX Studio
Techniques et leçons d'optimisation des requêtes DAX
Performances des requêtes et configuration de DAX Studio

Conclusion

Il est évident à quel point le stockage de colonnes via Vertipaq est vraiment rapide par rapport au stockage de lignes dans une base de données SQL. Cela montre l'importance de bien connaître le fonctionnement de l'indexation des données sur différentes plateformes.

Cela peut sembler un petit sacrifice au début si vous choisissez toujours d'aller pendant les 2,5 secondes pendant lesquelles le magasin de lignes exécute votre requête contre 7 millisecondes. Mais nous exécutons tous plusieurs requêtes lorsque nous créons nos rapports et tous ces temps d'exécution s'additionnent, ce qui a un impact sur la productivité et l'expérience utilisateur à long terme.