Partager via

Optimiser les performances grâce à OData

  • Article

Cet article décrit les moyens par lesquels vous pouvez optimiser les performances lors de la récupération de données Dataverse. Ces principes s’appliquent également lors de l’utilisation d’OData.

Modèles à éviter

La composition de requêtes optimisées pour Dataverse est essentielle pour garantir que les applications offrent une expérience rapide, réactive et fiable. Cette section décrit les modèles à éviter et les concepts à comprendre lors de la composition de requêtes pour des tables standard à l’aide du RetrieveMultiple message ou de messages dont le paramètre hérite de la classe QueryBase. Ces conseils s’appliquent également lors de l’envoi d’une requête sur une collection d’enregistrements à l’aide d’OData. GET Les conseils présentés ici peuvent ne pas s’appliquer aux tableaux Elastic ou lors de l’utilisation de Dataverse recherche.

Minimiser le nombre de colonnes sélectionnées

N’incluez pas les colonnes dont vous n’avez pas besoin dans votre requête. Les requêtes qui renvoient toutes les colonnes ou incluent un grand nombre de colonnes peuvent rencontrer des problèmes de performances en raison de la taille du jeu de données ou de la complexité de la requête.

Cette pratique est particulièrement vraie pour les colonnes logiques. Une colonne logique contient des valeurs stockées dans différentes tables de base de données. La propriété AttributeMetadata.IsLogical vous indique si une colonne est une colonne logique. Les requêtes qui contiennent de nombreuses colonnes logiques sont plus lentes car Dataverse doivent combiner les données d’autres tables de base de données.

Évitez les caractères génériques en tête dans les conditions de filtrage

Les requêtes qui utilisent des conditions avec des caractères génériques de début (soit explicitement, soit implicitement avec un opérateur tel que ends-with) peuvent entraîner de mauvaises performances. Dataverse ne peut pas profiter des index de base de données lors d’une requête utilisant des caractères génériques de premier plan, ce qui oblige SQL à analyser la table entière. Les analyses de table peuvent avoir lieu même s’il existe d’autres requêtes génériques non principales qui limitent l’ensemble de résultats.

L’exemple suivant est un élément de condition FetchXml qui utilise un caractère générique de début :

<condition attribute='accountnumber'
   operator='like'
   value='%234' />

L’exemple suivant est un QueryExpression ConditionExpression qui utilise un caractère générique de début :

new ConditionExpression("accountnumber", ConditionOperator.Like, "%234")

L’exemple suivant est une requête OData qui utilise un caractère générique de début carte :

$filter=startswith(accountnumber,'%234')

Lorsque le délai d’attente des requêtes expire et que ce modèle est détecté, Dataverse renvoie une erreur unique pour aider à identifier les requêtes qui utilisent ce modèle :

Nom: LeadingWildcardCauseTimeout
Code : 0x80048573
Nombre : -2147187341
Message : The database operation timed out; this may be due to a leading wildcard value being used in a filter condition. Please consider removing filter conditions on leading wildcard values, as these filter conditions are expensive and may cause timeouts.

Dataverse limite fortement les principales requêtes génériques identifiées comme un risque pour la santé de l’organisation afin d’aider à prévenir les pannes. En savoir plus sur les limitation de requêtes

Si vous utilisez des requêtes génériques de premier plan, étudiez ces options :

  • Utiliser Dataverse la recherche à la place.
  • Modifiez votre modèle de données pour aider les gens à éviter d’avoir besoin de caractères génériques de premier plan.

En savoir plus sur l’utilisation de caractères génériques dans les conditions pour les valeurs de chaîne

Évitez d’utiliser des formules ou des colonnes calculées dans des conditions de filtre

Les valeurs des formules et colonnes calculées en temps réel quand elles sont récupérées. Les requêtes qui utilisent des filtres sur ces colonnes obligent Dataverse à calculer la valeur de chaque enregistrement possible pouvant être renvoyé afin que le filtre puisse être appliqué. Les requêtes sont plus lentes car Dataverse ne peut pas améliorer les performances de ces requêtes à l’aide de SQL.

Lorsque le délai d’attente des requêtes expire et que ce modèle est détecté, Dataverse renvoie une erreur unique pour aider à identifier les requêtes qui utilisent ce modèle :

Nom: ComputedColumnCauseTimeout
Code : 0x80048574
Nombre : -2147187340
Message : The database operation timed out; this may be due to a computed column being used in a filter condition. Please consider removing filter conditions on computed columns, as these filter conditions are expensive and may cause timeouts.

Pour éviter les pannes, Dataverse applique des limitations aux requêtes comportant des filtres sur les colonnes calculées identifiées comme présentant un risque pour la santé de l’environnement. En savoir plus sur les limitation de requêtes

Évitez de trier par colonnes de choix

Lorsque vous utilisez FetchXml ou QueryExpression, lorsque vous triez les résultats de la requête à l’aide d’une colonne de choix, les résultats sont triés à l’aide de l’étiquette localisée pour chaque option de choix. Trier par la valeur numérique stockée dans la base de données ne fournirait pas une bonne expérience dans votre application. Vous devez savoir que le classement des colonnes de choix nécessite davantage de ressources de calcul pour joindre et trier les lignes en fonction de la valeur d’étiquette localisée. Ce travail supplémentaire ralentit la requête. Si possible, essayez d’éviter de trier les résultats par valeurs de colonne de choix.

Notes

OData est différent. Avec l’ Dataverse API Web, $orderby trie les lignes à l’aide de la valeur entière de la colonne de choix plutôt que de l’étiquette localisée.

Le classement par colonnes sur les tables associées ralentit la requête en raison de la complexité supplémentaire.

Le classement par tables associées ne doit être effectué qu’en cas de besoin, comme décrit ici :

Évitez d’utiliser des conditions sur de grandes colonnes de texte

Dataverse dispose de deux types de colonnes pouvant stocker de grandes chaînes de texte :

La limite pour ces deux colonnes est spécifiée à l’aide de la propriété MaxLength .

Vous pouvez utiliser des conditions sur les colonnes de chaîne dont a MaxLength est configuré pour moins de 850 caractères.

Toutes les colonnes mémo ou colonnes de chaîne avec un MaxLength supérieur à 850 sont définies dans Dataverse en tant que grandes colonnes de texte. Les grandes colonnes de texte sont trop volumineuses pour être indexées efficacement, ce qui entraîne de mauvaises performances lorsqu’elles sont incluses dans une condition de filtre.

Dataverse La recherche est un meilleur choix pour interroger des données dans ce type de colonnes.

Voir aussi

Interroger des données à l’aide d’OData
Colonnes Sélectionner utilisant OData
Joindre des tables à l’aide d’OData
Trier les lignes à l’aide d’OData
Filtrer les lignes à l’aide d’OData
Résultats de la page utilisant OData
Agréger des données à l’aide d’OData
Compter les lignes avec OData

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).