Réduction du temps de réponse des requêtes SQL
Gardez à l'esprit que plus le nombre d'éléments est faible, plus le traitement est rapide. A facteurs identiques, le traitement d'une instruction SQL simple prend moins de temps que le traitement d'une instruction SQL complexe. De même, les requêtes portant sur une quantité de données plus importante peuvent demander plus de temps qu'avec une quantité de données moindre si tous les autres facteurs sont égaux.
Lors de l'exécution des rapports ou de l'ouverture des tableaux de bord, le service Cognos® Analytics planifie les instructions SQL nécessaires pour obtenir des données à partir d'une ou plusieurs sources. Les instructions SQL physiques générées dépendent de la sémantique SQL et des types de données pris en charge par la base de données sous-jacente. La complexité des instructions SQL générées peut entraîner des coûts de performance à la fois pour le serveur de données sous-jacent et pour le serveur lorsqu'il doit effectuer un traitement supplémentaire localement Cognos Analytics lorsqu'il doit effectuer des traitements supplémentaires au niveau local.
Cognos Analytics qui s'appuient sur des bases de données opérationnelles nécessitent souvent des jointures et des expressions complexes pour naviguer dans les données et présenter les valeurs en termes commerciaux. En revanche, les applications disposées en couche sur des structures de génération de rapports nettoyées, telles que des schémas en étoile, peuvent tirer parti des transformations de données appliquées par les processus d'extraction, de transformation et de chargement (ETL) en charge de la publication. La simplification des jointures et des expressions dans les requêtes peut aider le serveur de données sous-jacent à mieux planifier les requêtes et à réduire ainsi l'utilisation du processeur et de la mémoire.
Voici quelques pratiques conseillées par de nombreux fournisseurs de technologie de serveur de données pour améliorer les performances lors de l'exécution.
Eviter les expressions de jointure et de filtre complexes
La complexité des expressions dans les clauses WHERE et JOIN ON d'une instruction SQL peut ralentir la planification du serveur de données, la réécritures de requêtes pour obtenir des vues matérialisées ou d'autres types d'accélération de requête.
Limiter les conversions de types de données explicites ou implicites
La conversion des types de données nécessite un traitement qui peut augmenter fortement les temps de réponse de la requête. La conversion des types de données est effectuée explicitement lorsque vous utilisez une fonction comme CAST() dans un calcul ou un filtre, ou implicitement lorsque certaines opérations sont effectuées sur des colonnes avec des types de données différents.
Dans l'idéal, une expression de calcul qui sert de clé dans une relation entre des tables est convertie dans le même type de données que la clé correspondante de l'autre côté de la relation de jointure. Cela permet d'éviter au serveur de données d'appliquer certaines stratégies de jointure, comme les jointures par hachage, en raison de types de données incompatibles.
Eviter d'utiliser des expressions SQL pour transposer des valeurs
Les utilisateurs qui connaissent SQL peuvent construire des expressions qui tentent d'ajuster les valeurs de base de données à afficher. Dans certains cas, ces expressions peuvent être remplacées en utilisant des options de formatage, de mise en forme et d'autres options de présentation disponibles.
L'exemple suivant explique comment effectuer plusieurs conversions de types de données, sous-chaînes et concaténations pour afficher une valeur de date d'une certaine manière au lieu d'utiliser l'option d'affichage du format des données disponible dans différentes interfaces de création.
Substring(Cast ( dateField, char(10)),6,2) || ‘-‘ || Substring(Cast ( dateField,
char(10)),9,2) || Substring(Cast ( dateField, char(10)),1,4)
Eviter les jointures externes inutiles
Les jointures externes permettent aux applications de renvoyer des ensembles de résultats lorsqu'une ou plusieurs tables d'une instruction ne disposent pas des données associées. Les requêtes qui utilisent des jointures externes limitent certaines stratégies d'optimisation des jointures, ainsi que l'ordre de jointure qu'un serveur de données utilise parfois avec des jointures internes. Un modèle peut être construit pour utiliser systématiquement des jointures externes qui peuvent, en fait, ne pas être requises par les questions métier posées dans un rapport ou un tableau de bord.
Appliquer des contraintes aux tables des serveurs de données
Les tables d'un serveur de données peuvent inclure des contraintes qui peuvent être prises en compte par le moteur de requête pour certaines stratégies, telles que les suppressions de jointures, les réécritures de requêtes et les optimisations d'expressions.
Des contraintes de clé primaire, de clé unique et de clé externe (mais pas des contraintes de valeurs null ni des contraintes de table) peuvent être déclarées à cette fin. En fonction de la technologie du serveur de données, ces contraintes peuvent être déclarées comme non appliquées ou appliquées. Dans une conception de table normalisée qui inclut des schémas en flocon, le fonctionnement des colonnes de clé non primaire dépend de la clé primaire.
Pour planifier les instructions SQL à traiter par le serveur de données, le service de requêtes Cognos Analytics utilise les contraintes définies dans un modèle de métadonnées, telles que les déterminants dans Framework Manger ou les dépendances de colonnes dans les modules de données, ainsi que les relations entre les tables. Ces objets sont souvent créés lors des premières étapes de la création d'un modèle, mais en général, ils sont définis manuellement par le modélisateur de métadonnées. Pour plus d'informations, voir Déterminants et dépendances des colonnes.
Utiliser des index et des fonctions d'organisation des tables
L'un des défis qu'un administrateur de base de données doit couramment relever est d'anticiper la manière dont les applications tentent de naviguer dans la base de données. Cela inclut l'identification des tables que les requêtes doivent combiner et des prédicats de table qui seront appliqués.
En utilisant une charge de travail représentative, l'administrateur de base de données peut déterminer quelles tables sont les plus fréquemment consultées et en particulier quel ensemble local de colonnes est utilisé pour filtrer et regrouper des colonnes dans des tables. A l'aide de ces connaissances, l'administrateur peut généralement identifier des index ou des stratégies d'organisation des tables qui permettent à la base de données de sélectionner plus efficacement les lignes requises.
Les charges de travail candidates doivent refléter les analyses et les explorations de données ad hoc qui peuvent être effectuées dans une application. Cet élément est important lorsque l'administrateur de base de données est limité lors de la définition des index ou des organisations de table appropriés, ce qui peut avoir une incidence sur la solution adaptée aux cas les plus fréquents. Par exemple, une application peut catégoriser principalement les mesures en fonction des perspectives de date, de zone géographique du client et de produit pour lesquelles l'administrateur de base de données peut optimiser les conceptions de table.
Un modèle de métadonnées peut également être construit au-dessus des bases de données qui exposent des objets d'application via des vues SQL. Ces vues doivent être examinées par l'administrateur de base de données en fonction des expressions qu'elles contiennent.