Optimisation des performances d'une application
Il est possible d'améliorer les performances d'une application en réduisant sa taille, en simplifiant son modèle de données et en utilisant de façon stratégique l'analyse d'ensembles. Cette section vous aidera a éviter les problèmes de performances en vous montrant les domaines dans lesquels les performances peuvent être impactées et comment évaluer les performances des applications et en effectuer le suivi.
L'outil d'évaluation des performances permet de voir les performances de l'application. Pour plus d'informations, voir Évaluation des performances des applications.
Complexité des applications
Voici quelques-unes des catégories qui peuvent faciliter le diagnostic des problèmes. Les applications les plus complexes sont les moins performantes.
Les applications simples :
- N'incluent pas d'instructions If() ou d'analyses d'ensembles complexes.
- N'incluent pas de tables de grandes tailles.
- Utilisent un modèle de données simple.
- Contiennent des calculs simples.
- Peuvent contenir de grands volumes de données.
Les applications modérément complexes :
- Ont un modèle de données avec de nombreuses tables, mais suivent les meilleures pratiques.
- Utilisent plusieurs instructions If() et l'analyse d'ensembles.
- Comportent des tables de grandes tailles ou larges sur des feuilles (15 colonnes ou plus).
Les applications complexes :
-
Ont un modèle de données très complexe.
- Se connectent à de grands volumes de données.
- Contiennent des calculs, des graphiques et des tables complexes.
Grands volumes de données
Lorsque vous vous connectez à de grands volumes de données, vous pouvez avoir recours à ces stratégies d'architecture.
Segmentation
Vous pouvez segmenter les fichiers QVDs en fonction de dimensions, par exemple, au niveau d'un cadre temporel, d'une région ou d'une agrégation. Par exemple, vous pouvez avoir :
- Un fichier QVD contenant les données des deux dernières années.
- Un fichier QVD contenant l'historique des données au-delà de deux ans.
Un fichier QVD contenant l'ensemble des données agrégées à un niveau supérieur. Par exemple, par mois au lieu de par date, ou par pays au lieu de par client.
- Un grand fichier QVD contenant toutes les données, uniquement utilisée par un petit sous-ensemble d'utilisateurs.
Vous pouvez segmenter les applications de la même manière. Les applications plus petites répondront aux besoins analytiques de la plupart des utilisateurs. Cela permet d'économiser de la mémoire.
Vous pouvez également avoir plusieurs applications axées sur différentes régions. Ainsi, les utilisateurs n'ouvriront pas une application contenant des données qui ne les intéressent pas ou auxquelles ils n'ont pas le droit d'accéder. Les données non accessibles via l'accès de section affectent tout de même la mémoire.
Génération d'applications On-demand (ODAG)
Les applications On-demand Qlik Sense permettent aux utilisateurs d'agréger les vues de magasins de données volumineux. Ils peuvent identifier et charger les sous-ensembles de données qui les intéressent pour les analyser en détail.
D'un point de vue de l'utilisateur, il existe deux applications :
- Un panier contenant les données agrégées.
- Une application modèle vide utilisée pour afficher les détails.
L'utilisateur effectue des sélections dans l'application de type panier. Une fois un certain seuil atteint, un script LOAD personnalisé est créé et renseigne l'application modèle au moyen des détails demandés. Pour plus d'informations, voir Gestion du Big Data à l'aide des applications On-demand.
Chaînage d'applications
Le chaînage d'applications (connu sous le nom de chaînage de documents dans QlikView) signifie qu'il existe une application agrégée que les utilisateurs consomment régulièrement. Si un utilisateur nécessite plus de détails, ses sélections peuvent être transférées de l'application agrégée à une application détaillée, afin qu'il puisse afficher un niveau de granularité inférieur. Cela économise de la mémoire, car les utilisateurs ne chargent pas de détails inutiles. Le chaînage d'applications peut être effectué via l'ajout d'objets Bouton à une feuille. Pour plus d'informations, voir Chaînage d'applications.
Le chaînage d'applications est également pris en charge via APIs. Par exemple, vous pouvez utiliser l'API App Integration pour créer un chaînage d'applications personnalisé. Pour plus d'informations, voir API App Integration (uniquement en anglais).
Vues dynamiques
Les vues dynamiques permettent de créer des visualisations actualisées de grands volumes de données ou de scénarios de données en changement rapide. Lorsque vous utilisez des vues dynamiques, gardez à l'esprit les points suivants :
Lorsque vous actualisez des vues dynamiques, la source de données est chargée directement. Les performances de mise à jour sont affectées par celles de la source de données sous-jacente.
Des applications modèles de vue dynamique peuvent vous aider à créer des graphiques dynamiques.
Pour plus d'informations sur l'utilisation des vues dynamiques, voir Gestion des données avec des vues dynamiques.
Direct Query
Même s'il est recommandé d'utiliser des applications en mémoire, Direct Query vous permet de conserver les données dans leur source d'origine. Pour optimiser l'utilisation de Direct Query, gardez à l'esprit les points suivants :
Les performances de Direct Query sont lourdement affectées par celles de la source de données sous-jacente.
Gardez votre modèle de données Direct Query aussi simple que possible ; en effet, les requêtes complexes risquent d'entraîner des problèmes de performance.
Pour plus d'informations sur Direct Query, voir Accès aux bases de données cloud directement via Direct Query.
Performances du modèle de données
Il existe des indicateurs qui peuvent avoir un impact sur les performances d'un modèle de données. Chacun constitue une meilleure pratique qui améliore la facilité d'utilisation d'une application.
| Action | Description |
|---|---|
Suppression des clés synthétiques | Qlik Sense crée des clés synthétiques quand deux ou davantage de tables de données comportent deux ou davantage de champs en commun. Cela indique une erreur dans le script ou le modèle de données. Pour diagnostiquer les clés synthétiques, voir Clés synthétiques. |
Suppression des références circulaires du modèle de données | Il se produit des références circulaires quand deux champs comportent plus d'une association. Qlik Sense tente de les résoudre en changeant la connexion à l'une des tables. Cependant, tous les avertissements de référence circulaire doivent être résolus ; voir Principe et résolution des références circulaires. |
Granularité appropriée des données | Vous ne devriez charger que les données nécessaires. Par exemple : un groupe d'utilisateurs ne nécessite que les données divisées par semaine, mois et année. Vous pouvez soit charger les données agrégées, soit agréger les données au sein du script de chargement, pour économiser de la mémoire. Si un utilisateur a besoin de visualiser les données à un niveau de granularité inférieur, vous pouvez utiliser ODAG ou le chaînage de documents. |
Utilisation, autant que possible, de QVDs | Un fichier QVD est un fichier contenant une table de données exportée à partir de Qlik Sense. Le format de fichier est optimisé pour la vitesse de lecture des données à partir d'un script tout en demeurant très compact. La lecture de données à partir d'un fichier QVD est généralement 10 à 100 fois plus rapide qu'à partir d'autres sources de données. Pour plus d'informations, voir : Utilisation de fichiers QVD. |
Optimisation des fichiers QVD lors du chargement | Les fichiers QVD peuvent être lus dans deux modes : standard (rapide) et optimisé (plus rapide). Le mode sélectionné est déterminé automatiquement par le moteur de script. Les charges optimisées présentent certaines limitations. Il est possible de renommer des champs, mais n'importe laquelle de ces opérations entraînera un chargement standard :
|
Exploitation des chargements incrémentiels | Si votre application se connecte à une grande quantité de données provenant de bases de données mises à jour en permanence, le rechargement de l'ensemble de données complet peut se révéler extrêmement fastidieux. Au lieu de cela, vous devriez utiliser le chargement incrémentiel, pour récupérer les enregistrements nouveaux ou modifiés de la base de données. Pour plus d'informations, voir Chargement incrémentiel d'enregistrements nouveaux et mis à jour. |
Consolidation du modèle Snowflake | Si vous avez un modèle de données de type flocon de neige, vous pouvez peut-être réduire le nombre de tables de données en joignant certaines d'entre elles à l'aide du préfixe Join ou d'un autre type de mappage. Cela est particulièrement important pour les tables de faits de grandes tailles. Une bonne règle d'or consiste à avoir une seule table de grande taille. Pour plus d'informations, voir To Join or Not to Join. |
Dénormalisation des tables comportant un petit nombre de champs | Si vous disposez de deux tables avec quelques champs, les joindre peut améliorer les performances. Pour plus d'informations, voir Combinaison de tables grâce à Join et Keep. |
Tables (de feuilles) de recherche dénormalisées avec chargements de mappage | Vous ne devriez pas utiliser le préfixe Join si vous ne devez ajouter qu'un champ d'une table à l'autre. Vous devriez utiliser la fonction de recherche ApplyMap ; voir Don't join - use ApplyMap. |
Suppression ou découplage des horodatages d'un champ de date | Les champs de date peuvent occuper l'espace, en présence de l'horodatage, car la représentation de chaîne est plus grande et le nombre de valeurs distinctes supérieur. Si l'analyse n'a pas besoin d'être précise, vous pouvez arrondir l'horodatage, par exemple, sur l'heure la plus proche, via Timestamp(Floor(YourTimestamp,1/24)), ou supprimer totalement le composant horaire via Date(Floor(YourTimestamp)). Si vous souhaitez utiliser l'horodatage, vous pouvez le découpler de la date elle-même. Vous pouvez utiliser la même fonction Floor(), puis créer un champ avec l'heure extraite en utilisant une fonction telle que la suivante : Time(Frac(YourTimestamp)). |
Suppression des champs inutiles du modèle de données | Vous ne devriez charger que les champs nécessaires dans votre modèle de données. Évitez d'utiliser Load * et SELECT. Assurez-vous de conserver :
|
Éviter les tables de liaison avec de grands volumes de données | Vous devriez utiliser autant que possible des tables de liaison. Cependant, si vous avez affaire à de grands volumes de données, notez que les tables concaténées peuvent surpasser les performances des tables de liaison. |
Division des dimensions concaténées en nouveaux champs | Vous devriez diviser les dimensions concaténées en champs distincts. Cela réduit le nombre d'occurrences de valeurs uniques dans vos champs. Cette opération est similaire à l'optimisation des horodatages. |
Utilisation autant que possible d'AutoNumber | Vous pouvez créer un chargement optimisé en commençant par charger les données à partir d'un fichier QVD, puis en convertissant les valeurs en clés de symbole à l'aide de l'instruction AutoNumber. Pour plus d'informations, voir AutoNumber. |
Éviter les îlots de données | Les îlots de données peuvent s'avérer utiles, mais ils affectent généralement les performances. Si vous créez des îlots pour les valeurs de sélection, utilisez des variables. |
Stockage des QVD en fonction de plages de temps incrémentielles | Vous devriez stocker les QVD dans des segments, par exemple, mensuels. Ces QVD mensuels plus petits peuvent ensuite prendre en charge de nombreuses applications différentes qui n'auront peut-être pas besoin de la totalité des données. |
Performances des feuilles
Voici quelques meilleures pratiques qui amélioreront les performances des feuilles et des visualisations.
| Action | Description |
|---|---|
Éviter autant que possible d'utiliser la fonction If() | Si la fonction If() est utilisée dans une fonction d'agrégation, elle s'applique au niveau des enregistrements et est évaluée de nombreuses fois. Par exemple, si vous disposez de 1 000 enregistrements dans une agrégation, une condition If() sera évaluée 1 000 fois. Si vous imbriquez les instructions, cela devrait augmenter rapidement. Utilisez plutôt l'analyse d'ensembles. Un filtre d'analyse d'ensembles est appliqué avant l'agrégation, accélérant ainsi la réponse. L'analyse d'ensembles permet également de mettre ces réponses en cache, alors que If() ne le permet pas. Vous pouvez également envisager d'utiliser d'autres fonctions et modifications du modèle de données. |
| Évitez, si possible, d'utiliser des champs provenant de tables différentes à l'intérieur d'une table d'agrégation. | Lors de l'évaluation d'une agrégation, le calcul s'effectue en deux étapes :
La partie monothread peut considérablement affecter les performances. Par exemple, si vous avez plusieurs champs à l'intérieur de l'agrégation comme Sum(Quantity*ListPrice). Si Quantity se trouve dans la table de faits et si ListPrice se trouve dans la table de produits principale, le moteur doit commencer par joindre les deux tables pour rechercher les combinaisons avant de pouvoir lancer la somme du produit. La jointure constitue la partie monothread, tandis que la somme représente la partie multithread. Si les deux champs se trouvent dans la même table, aucune jointure n'est nécessaire et l'agrégation est évaluée beaucoup plus vite. |
Utilisation minimale des fonctions Aggr() et Aggr() imbriquées | La fonction Aggr() affecte énormément les performances. Son utilisation de manière incorrecte peut donner des résultats erronés. Par exemple, dans une table contenant des dimensions différentes des dimensions de la fonction Aggr(). Pour plus d'informations, voir When should AGGR not be used? |
Utilisation autant que possible de l'analyse d'ensembles | Vous pouvez utiliser l'analyse d'ensembles pour définir un ensemble de valeurs de données différent de l'ensemble normal défini par les sélections actives. Pour plus d'informations, voir Analyse d'ensembles. |
Éviter autant que possible les comparaisons de chaînes | Les comparaisons de chaînes ne sont pas aussi efficaces que l'analyse d'ensembles. Par exemple, vous devriez éviter Match(), MixMatch(), WildMatch()et Pick(). Créez des indicateurs dans le script ou utilisez plutôt l'analyse d'ensembles. Pour plus d'informations, voir Fonctions conditionnelles et Performance of conditional aggregations. |
Utilisation de conditions de calcul sur des objets contenant des calculs intensifs | Vous avez peut-être des visualisations contenant de nombreux enregistrements sans sélections. Comme meilleure pratique, ajoutez des conditions de calcul aux objets, de sorte qu'ils n'apparaissent que lorsque certaines sélections sont effectuées. Cela empêche la création d'hypercubes très volumineux. Par exemple : GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. Dans ce scénario, la visualisation ne s'affiche pas, sauf si l'utilisateur sélectionne un seul pays ou s'il effectue d'autres sélections dans lesquelles un seul pays est possible. |
Calcul préalable, autant que possible, des mesures dans le script | Toute mesure au niveau de granularité le plus bas du modèle de données doit être calculée dans le script. Par exemple, si, dans le même enregistrement d'une table, vous avez Sales et Cost, vous devriez dériver la marge en calculant Sales - Cost AS Margin. Vous pouvez également agréger d'autres valeurs à l'avance, si vous savez qu'elles ne varieront pas en fonction de la sélection, ou qu'elles sont liées à un niveau de granularité différent. |
Tables comptant moins de quinze colonnes et des conditions de calcul | Une table contenant quinze colonnes peut être considérée comme large. Si vos tables comportent de nombreux enregistrements, vous devriez utiliser des conditions de calcul sur l'objet table afin de ne l'afficher que lorsque certaines sélections sont effectuées ou lorsque certains critères sont remplis. Si votre table est très large, vous pouvez :
|
Feuilles sans nombre excessif d'objets | Les objets sont calculés lorsqu'un utilisateur accède à la feuille. Chaque fois qu'un utilisateur effectue une sélection sur cette feuille, chaque objet est recalculé, si cet état actif ne figure pas dans le cache. Si vous disposez d'une feuille contenant de nombreux graphiques, l'utilisateur devra attendre que chaque objet soit calculé à quasiment toutes les sélections. Cela exerce une charge considérable sur le moteur. Comme meilleure pratique, suivez le concept Dashboard/Analysis/Reporting (DAR) pour développer une application propre et minimale. Pour plus d'informations, voir DAR methodology. |
Utilisation d'indicateurs numériques dans le script pour les utiliser dans l'analyse d'ensembles | L'analyse d'ensembles avec des indicateurs peut s'avérer plus efficace que l'utilisation de multiplications ou de comparaisons de chaînes. |
Utilisation d'éléments principaux ou de variables pour les expressions | Les éléments principaux permettent de glisser-déposer des métriques gouvernées et de garantir la mise en cache des expressions. Par exemple, Sum(Sales) est différent de SUM(Sales). Les expressions sont mises en cache en fonction de leur orthographe et de leur casse, et elles doivent correspondre exactement afin de pouvoir être réutilisées. |
Performances des chargements de données
Il est important d'optimiser le chargement de données pour profiter d'une expérience transparente et réactive lorsque vous utilisez des applications dans Qlik Cloud. Cette section souligne les facteurs qui affectent les performances et fournit des conseils pour prévenir les problèmes de performance.
Qlik Data Gateway - Accès direct
Lorsque vous utilisez Qlik Data Gateway - Accès direct pour actualiser les données de votre application, sachez que les facteurs suivants affectent les performances :
La latence et la vitesse de connexion entre le poste hébergeant la passerelle de données et la base de données.
La latence et la vitesse de connexion entre le poste hébergeant la passerelle de données et votre client Qlik Cloud. Dans l'idéal, pour améliorer les performances, hébergez la passerelle de données dans la même région que celle de votre client Qlik Cloud.
Stockage de base de données
Les connexions de stockage lentes peuvent augmenter les temps d'actualisation. En ce qui concerne les bases de données hébergées sur site ou dans le cloud, gardez à l'esprit les points suivants :
Sur site : Si votre base de données se trouve sur site et partage un serveur avec d'autres applications, ses performances risquent d'être affectées par les activités de ces autres applications.
Cloud : Lorsqu'elles sont correctement dimensionnées, les bases de données cloud offrent généralement de meilleures performances que les bases de données sur site. Pour des résultats optimaux, pour votre stockage cloud, sélectionnez une région proche de celle de votre client Qlik Cloud.