Partager via

Stratégie de limites de requête

  • Article

S’applique à : ✅Microsoft Fabric✅Azure Data Explorer

La stratégie de limites de requête d’un groupe de charge de travail permet de limiter les ressources utilisées par la requête pendant son exécution.

Objet de stratégie

Chaque limite se compose des éléments suivants :

  • Un Value typé : valeur de la limite.
  • IsRelaxable : valeur booléenne qui définit si la limite peut être assouplie par l’appelant, dans le cadre des propriétés de requête de la requête.

Les limites suivantes sont configurables :

Propriété Type Description Valeurs prises en charge Propriété de requête client correspondante
DataScope string Étendue des données de la requête. Cette valeur détermine si la requête s’applique à toutes les données ou simplement au cache chaud. All, HotCacheou null query_datascope
MaxMemoryPerQueryPerNode long La quantité maximale de mémoire (en octets) qu’une requête peut allouer. [1, 50% de ram total d’un nœud unique] max_memory_consumption_per_query_per_node
MaxMemoryPerIterator long Quantité maximale de mémoire (en octets) qu’un opérateur de requête peut allouer. [1, 50% de ram total d’un nœud unique] maxmemoryconsumptionperiterator
MaxFanoutThreadsPercentage int Pourcentage de threads sur chaque nœud pour faire en sorte que l’exécution de la requête soit fané. Lorsqu’il est défini sur 100%, le cluster affecte toutes les UC sur chaque nœud. Par exemple, 16 PROCESSEURs sur un cluster déployé sur des nœuds Azure D14_v2. [1, 100] query_fanout_threads_percent
MaxFanoutNodesPercentage int Pourcentage de nœuds sur le cluster pour faire en sorte que l’exécution de la requête soit fané. Fonctions de la même manière que MaxFanoutThreadsPercentage. [1, 100] query_fanout_nodes_percent
MaxResultRecords long Le nombre maximal d’enregistrements qu’une demande est autorisé à revenir à l’appelant, au-delà duquel les résultats sont tronqués. La limite de troncation affecte le résultat final de la requête, tel que remis au client. Toutefois, la limite de troncation ne s’applique pas aux résultats intermédiaires des sous-requêtes, tels que ceux résultant d’avoir des références entre clusters. [1, 9223372036854775807] truncationmaxrecords
MaxResultBytes long La taille maximale des données (en octets) qu’une demande est autorisée à revenir à l’appelant, au-delà de laquelle les résultats sont tronqués. La limite de troncation affecte le résultat final de la requête, tel que remis au client. Toutefois, la limite de troncation ne s’applique pas aux résultats intermédiaires des sous-requêtes, tels que ceux résultant d’avoir des références entre clusters. [1, 9223372036854775807] truncationmaxsize
MaxExecutionTime timespan Durée maximale d’une requête.
remarques :
1) Cela peut être utilisé pour placer davantage de limites au-dessus de la limites de par défaut sur le temps d’exécution, mais pas les étendre.
2) Le traitement du délai d’attente n’est pas à la résolution de secondes, plutôt qu’il est conçu pour empêcher l’exécution d’une requête pendant minutes.
3) Le temps nécessaire à la lecture de la charge utile au niveau du client n’est pas traité dans le cadre du délai d’expiration. Cela dépend de la rapidité avec laquelle l’appelant extrait les données du flux.
4) Le temps d’exécution total peut dépasser la valeur configurée si l’exécution abandonnée prend plus de temps.		 [00:00:00, 01:00:00] servertimeout
Propriété Type Description Valeurs prises en charge Propriété de requête client correspondante
DataScope string Étendue des données de la requête. Cette valeur détermine si la requête s’applique à toutes les données ou simplement au cache chaud. All, HotCacheou null query_datascope
MaxMemoryPerQueryPerNode long La quantité maximale de mémoire (en octets) qu’une requête peut allouer. [1, 50% de ram total d’un nœud unique] max_memory_consumption_per_query_per_node
MaxMemoryPerIterator long Quantité maximale de mémoire (en octets) qu’un opérateur de requête peut allouer. [1, 50% de ram total d’un nœud unique] maxmemoryconsumptionperiterator
MaxFanoutThreadsPercentage int Pourcentage de threads sur chaque nœud pour faire en sorte que l’exécution de la requête soit fané. Quand la valeur est 100%, Eventhouse affecte toutes les UC sur chaque nœud. Par exemple, 16 PROCESSEURs sur un eventhouse déployé sur des nœuds Azure D14_v2. [1, 100] query_fanout_threads_percent
MaxFanoutNodesPercentage int Pourcentage de nœuds sur l’Eventhouse pour faire en sorte que l’exécution de la requête soit fané. Fonctions de la même manière que MaxFanoutThreadsPercentage. [1, 100] query_fanout_nodes_percent
MaxResultRecords long Le nombre maximal d’enregistrements qu’une demande est autorisé à revenir à l’appelant, au-delà duquel les résultats sont tronqués. La limite de troncation affecte le résultat final de la requête, tel que remis au client. Toutefois, la limite de troncation ne s’applique pas aux résultats intermédiaires des sous-requêtes, tels que les résultats de l’utilisation de références inter-événements. [1, 9223372036854775807] truncationmaxrecords
MaxResultBytes long La taille maximale des données (en octets) qu’une demande est autorisée à revenir à l’appelant, au-delà de laquelle les résultats sont tronqués. La limite de troncation affecte le résultat final de la requête, tel que remis au client. Toutefois, la limite de troncation ne s’applique pas aux résultats intermédiaires des sous-requêtes, tels que les résultats de l’utilisation de références inter-événements. [1, 9223372036854775807] truncationmaxsize
MaxExecutionTime timespan Durée maximale d’une requête.
remarques :
1) Cela peut être utilisé pour placer davantage de limites au-dessus de la limites de par défaut sur le temps d’exécution, mais pas les étendre.
2) Le traitement du délai d’attente n’est pas à la résolution de secondes, plutôt qu’il est conçu pour empêcher l’exécution d’une requête pendant minutes.
3) Le temps nécessaire à la lecture de la charge utile au niveau du client n’est pas traité dans le cadre du délai d’expiration. Cela dépend de la rapidité avec laquelle l’appelant extrait les données du flux.
4) Le temps d’exécution total peut dépasser la valeur configurée si l’abandon de l’exécution prend plus de temps.		 [00:00:00, 01:00:00] servertimeout

Note

Une limite qui n’est pas définie ou qui est définie comme null, est extraite de la stratégie de limites de requête du groupe de charge de travail default.

Utilisation des ressources processeur

Les requêtes peuvent utiliser toutes les ressources processeur au sein du cluster. Par défaut, lorsque plusieurs requêtes s’exécutent simultanément, le système utilise une approche de tourniquet équitable pour distribuer des ressources. Cette stratégie est optimale pour atteindre des performances élevées avec des requêtes ad hoc.

Les requêtes peuvent utiliser toutes les ressources uc dans Eventhouse. Par défaut, lorsque plusieurs requêtes s’exécutent simultanément, le système utilise une approche de tourniquet équitable pour distribuer des ressources. Cette stratégie est optimale pour atteindre des performances élevées avec des requêtes ad hoc.

Toutefois, il existe des scénarios où vous souhaiterez peut-être restreindre les ressources processeur allouées à une requête spécifique. Par exemple, si vous exécutez un travail en arrière-plan qui peut prendre en charge des latences plus élevées. La stratégie de limites de requête offre la possibilité de spécifier un pourcentage inférieur de threads ou de nœuds à utiliser lors de l’exécution d’opérations de sous-requête distribuées. Le paramètre par défaut est 100%.

Groupe de charge de travail default

Le groupe de charge de travail default a la stratégie suivante définie par défaut. Cette stratégie peut être modifiée.

{
  "DataScope": {
    "IsRelaxable": true,
    "Value": "All"
  },
  "MaxMemoryPerQueryPerNode": {
    "IsRelaxable": true,
    "Value": < 50% of a single node's total RAM >
  },
  "MaxMemoryPerIterator": {
    "IsRelaxable": true,
    "Value": 5368709120
  },
  "MaxFanoutThreadsPercentage": {
    "IsRelaxable": true,
    "Value": 100
  },
  "MaxFanoutNodesPercentage": {
    "IsRelaxable": true,
    "Value": 100
  },
  "MaxResultRecords": {
    "IsRelaxable": true,
    "Value": 500000
  },
  "MaxResultBytes": {
    "IsRelaxable": true,
    "Value": 67108864
  },
  "MaxExecutiontime": {
    "IsRelaxable": true,
    "Value": "00:04:00"
  }
}

Note

  • Les limites du groupe de charge de travail default doivent être définies et avoir une valeur nonnull.
  • Toutes les limites du groupe de charge de travail default ont IsRelaxable définies sur true.
  • Les limites de requête sont désactivées pour des types de commandes spécifiques au sein du groupe de charge de travail default, tels que les commandes .export et ingérer à partir de commandes de requête telles que .set-or-append et .set-or-replace. Lorsque ces commandes sont affectées à un groupe de charge de travail non défini par défaut, les limites de requête spécifiées dans la stratégie deviennent applicables.

Exemple

Le code JSON suivant représente un objet de stratégie de limites de demandes personnalisées :

{
  "DataScope": {
    "IsRelaxable": true,
    "Value": "HotCache"
  },
  "MaxMemoryPerQueryPerNode": {
    "IsRelaxable": true,
    "Value": 2684354560
  },
  "MaxMemoryPerIterator": {
    "IsRelaxable": true,
    "Value": 2684354560
  },
  "MaxFanoutThreadsPercentage": {
    "IsRelaxable": true,
    "Value": 50
  },
  "MaxFanoutNodesPercentage": {
    "IsRelaxable": true,
    "Value": 50
  },
  "MaxResultRecords": {
    "IsRelaxable": true,
    "Value": 1000
  },
  "MaxResultBytes": {
    "IsRelaxable": true,
    "Value": 33554432
  },
  "MaxExecutiontime": {
    "IsRelaxable": true,
    "Value": "00:01:00"
  }
}

Contenu connexe