ClickHouse/docs/fr/operations/settings/query-complexity.md
2020-10-13 20:23:29 +03:00

15 KiB
Raw Blame History

machine_translated machine_translated_rev toc_priority toc_title
true 72537a2d52 59 Restrictions sur la complexité des requêtes

Restrictions sur la complexité des requêtes

Les Restrictions sur la complexité des requêtes font partie des paramètres. Ils sont utilisés pour fournir une exécution plus sûre à partir de l'interface utilisateur. Presque toutes les restrictions ne s'appliquent qu'à SELECT. Pour le traitement des requêtes distribuées, des restrictions sont appliquées sur chaque serveur séparément.

ClickHouse vérifie les restrictions pour les parties de données, pas pour chaque ligne. Cela signifie que vous pouvez dépasser la valeur de restriction de la taille de la partie données.

Restrictions sur l' “maximum amount of something” peut prendre la valeur 0, ce qui signifie “unrestricted”. La plupart des restrictions ont également un overflow_mode paramètre signification que faire lorsque la limite est dépassée. Il peut prendre deux valeurs: throw ou break. Les Restrictions sur l'agrégation (group_by_overflow_mode) ont également la valeur any.

throw Throw an exception (default).

break Stop executing the query and return the partial result, as if the source data ran out.

any (only for group_by_overflow_mode) Continuing aggregation for the keys that got into the set, but don't add new keys to the set.

max_memory_usage

La quantité maximale de RAM à utiliser pour exécuter une requête sur un seul serveur.

Dans le fichier de configuration par défaut, le maximum est de 10 Go.

Le réglage ne tient pas compte du volume de mémoire disponible ou du volume total de mémoire sur la machine. La restriction s'applique à une seule requête au sein d'un seul serveur. Vous pouvez utiliser SHOW PROCESSLIST pour vérifier la consommation de mémoire pour chaque requête. En outre, la consommation de mémoire maximale est suivie pour chaque requête et écrite dans le journal.

L'utilisation de la mémoire n'est pas surveillée pour les membres de certaines fonctions d'agrégation.

L'utilisation de la mémoire n'est pas totalement suivies pour les états des fonctions d'agrégation min, max, any, anyLast, argMin, argMax de String et Array argument.

La consommation de mémoire est également limitée par les paramètres max_memory_usage_for_user et max_memory_usage_for_all_queries.

max_memory_usage_for_user

Quantité maximale de RAM à utiliser pour exécuter les requêtes d'un utilisateur sur un seul serveur.

Les valeurs par défaut sont définies dans Paramètre.h. Par défaut, le montant n'est pas limité (max_memory_usage_for_user = 0).

Voir aussi la description de max_memory_usage.

max_memory_usage_for_all_queries

La quantité maximale de RAM à utiliser pour exécuter toutes les requêtes sur un seul serveur.

Les valeurs par défaut sont définies dans Paramètre.h. Par défaut, le montant n'est pas limité (max_memory_usage_for_all_queries = 0).

Voir aussi la description de max_memory_usage.

max_rows_to_read

Les restrictions suivantes peut être vérifiée sur chaque bloc (au lieu de sur chaque ligne). Autrement dit, les restrictions peuvent être brisées un peu. Lors de l'exécution d'une requête dans plusieurs threads, les restrictions suivantes s'appliquent à chaque thread séparément.

Un nombre maximum de lignes pouvant être lues à partir d'un tableau lors de l'exécution d'une requête.

max_bytes_to_read

Nombre maximal d'octets (données non compressées) pouvant être lus à partir d'une table lors de l'exécution d'une requête.

read_overflow_mode

Que faire lorsque le volume de lecture de données dépasse l'une des limites: throw ou break. Par défaut, les jeter.

max_rows_to_group_by

Un nombre maximum de clés uniques reçues de l'agrégation. Ce paramètre permet de limiter la consommation de mémoire lors de l'agrégation.

group_by_overflow_mode

Que faire lorsque le nombre de clés uniques pour l'agrégation dépasse la limite: throw, break, ou any. Par défaut, les jeter. À l'aide de la any valeur vous permet d'exécuter une approximation de GROUP BY. La qualité de cette approximation dépend de la nature statistique des données.

max_bytes_before_external_group_by

Active ou désactive l'exécution de GROUP BY clauses dans la mémoire externe. Voir Groupe par dans la mémoire externe.

Valeurs possibles:

  • Volume maximal de RAM (en octets) pouvant être utilisé par le GROUP BY opération.
  • 0 — GROUP BY dans la mémoire externe désactivé.

Valeur par défaut: 0.

max_rows_to_sort

Un nombre maximum de lignes avant le tri. Cela vous permet de limiter la consommation de mémoire lors du tri.

max_bytes_to_sort

Un nombre maximal d'octets avant le tri.

sort_overflow_mode

Que faire si le nombre de lignes reçues avant le tri dépasse l'une des limites: throw ou break. Par défaut, les jeter.

max_result_rows

Limite sur le nombre de lignes dans le résultat. Également vérifié pour les sous-requêtes, et sur des serveurs distants lors de l'exécution de parties d'une requête distribuée.

max_result_bytes

Limite sur le nombre d'octets dans le résultat. Le même que le réglage précédent.

result_overflow_mode

Que faire si le volume du résultat dépasse l'une des limites: throw ou break. Par défaut, les jeter.

Utiliser break est similaire à L'utilisation de LIMIT. Break interrompt l'exécution seulement au niveau du bloc. Cela signifie que la quantité de lignes renvoyées est supérieure à max_result_rows multiples de max_block_size et dépend de l' max_threads.

Exemple:

SET max_threads = 3, max_block_size = 3333;
SET max_result_rows = 3334, result_overflow_mode = 'break';

SELECT *
FROM numbers_mt(100000)
FORMAT Null;

Résultat:

6666 rows in set. ...

max_execution_time

Durée maximale d'exécution de la requête en secondes. Pour le moment, il n'est pas vérifié pour l'une des étapes de tri, ni lors de la fusion et de la finalisation des fonctions d'agrégat.

timeout_overflow_mode

Que faire si la requête est exécutée plus de max_execution_time: throw ou break. Par défaut, les jeter.

min_execution_speed

Vitesse d'exécution minimale en lignes par seconde. Vérifié sur chaque bloc de données quand timeout_before_checking_execution_speed expirer. Si la vitesse d'exécution est inférieure, une exception est levée.

min_execution_speed_bytes

Un nombre minimum d'exécution d'octets par seconde. Vérifié sur chaque bloc de données quand timeout_before_checking_execution_speed expirer. Si la vitesse d'exécution est inférieure, une exception est levée.

max_execution_speed

Un nombre maximal d'exécution de lignes par seconde. Vérifié sur chaque bloc de données quand timeout_before_checking_execution_speed expirer. Si la vitesse d'exécution est élevée, la vitesse d'exécution sera réduit.

max_execution_speed_bytes

Un nombre maximal d'exécution d'octets par seconde. Vérifié sur chaque bloc de données quand timeout_before_checking_execution_speed expirer. Si la vitesse d'exécution est élevée, la vitesse d'exécution sera réduit.

timeout_before_checking_execution_speed

Vérifie que la vitesse d'exécution n'est pas trop lent (pas moins de min_execution_speed), après l'expiration du temps spécifié en secondes.

max_columns_to_read

Nombre maximal de colonnes pouvant être lues à partir d'une table dans une seule requête. Si une requête nécessite la lecture d'un plus grand nombre de colonnes, il lève une exception.

max_temporary_columns

Nombre maximal de colonnes temporaires qui doivent être conservées en RAM en même temps lors de l'exécution d'une requête, y compris les colonnes constantes. S'il y a plus de colonnes temporaires que cela, il lève une exception.

max_temporary_non_const_columns

La même chose que max_temporary_columns mais sans compter constante colonnes. Notez que les colonnes constantes sont formées assez souvent lors de l'exécution d'une requête, mais elles nécessitent environ zéro ressource informatique.

max_subquery_depth

Profondeur maximale de sous-requêtes. Si les sous-requêtes sont plus profondes, une exception est levée. Par défaut, 100.

max_pipeline_depth

Profondeur maximale du pipeline. Correspond au nombre de transformations que chaque bloc de données lors du traitement des requêtes. Compté dans les limites d'un seul serveur. Si la profondeur du pipeline est supérieure, une exception est levée. Par défaut, 1000.

max_ast_depth

Profondeur maximale d'une requête arbre syntaxique. En cas de dépassement, une exception est levée. À ce moment, il n'est pas vérifié pendant l'analyse, mais seulement après l'analyse de la requête. Autrement dit, un arbre syntaxique trop profond peut être créé pendant l'analyse, mais la requête échouera. Par défaut, 1000.

max_ast_elements

Un nombre maximal d'éléments dans une requête arbre syntaxique. En cas de dépassement, une exception est levée. De la même manière que le paramètre précédent, il est vérifié qu'après l'analyse de la requête. Par défaut, 50 000.

max_rows_in_set

Nombre maximal de lignes pour un ensemble de données dans la clause in créée à partir d'une sous-requête.

max_bytes_in_set

Nombre maximal d'octets (données non compressées) utilisés par un ensemble de la clause in créé à partir d'une sous-requête.

set_overflow_mode

Que faire lorsque la quantité de données dépasse l'une des limites: throw ou break. Par défaut, les jeter.

max_rows_in_distinct

Un nombre maximum de lignes différentes lors de L'utilisation de DISTINCT.

max_bytes_in_distinct

Nombre maximal d'octets utilisés par une table de hachage lors de L'utilisation de DISTINCT.

distinct_overflow_mode

Que faire lorsque la quantité de données dépasse l'une des limites: throw ou break. Par défaut, les jeter.

max_rows_to_transfer

Nombre maximal de lignes pouvant être transmises à un serveur distant ou enregistrées dans une table temporaire lors de L'utilisation de GLOBAL IN.

max_bytes_to_transfer

Nombre maximal d'octets (données non compressées) pouvant être transmis à un serveur distant ou enregistrés dans une table temporaire lors de L'utilisation de GLOBAL IN.

transfer_overflow_mode

Que faire lorsque la quantité de données dépasse l'une des limites: throw ou break. Par défaut, les jeter.

max_rows_in_join

Limite le nombre de lignes dans la table de hachage utilisée lors de la jonction de tables.

Ce réglage s'applique à SELECT … JOIN les opérations et les Rejoindre tableau moteur.

Si une requête contient plusieurs jointures, ClickHouse vérifie ce paramètre pour chaque résultat intermédiaire.

ClickHouse peut procéder à différentes actions lorsque la limite est atteinte. L'utilisation de la join_overflow_mode réglage pour choisir l'action.

Valeurs possibles:

  • Entier positif.
  • 0 — Unlimited number of rows.

Valeur par défaut: 0.

max_bytes_in_join

Limite la taille en octets de la table de hachage utilisée lors de l'assemblage de tables.

Ce réglage s'applique à SELECT … JOIN les opérations et les Rejoindre le moteur de table.

Si la requête contient des jointures, ClickHouse vérifie ce paramètre pour chaque résultat intermédiaire.

ClickHouse peut procéder à différentes actions lorsque la limite est atteinte. Utiliser join_overflow_mode paramètres pour choisir l'action.

Valeurs possibles:

  • Entier positif.
  • 0 — Memory control is disabled.

Valeur par défaut: 0.

join_overflow_mode

Définit l'action que ClickHouse effectue lorsque l'une des limites de jointure suivantes est atteinte:

Valeurs possibles:

  • THROW — ClickHouse throws an exception and breaks operation.
  • BREAK — ClickHouse breaks operation and doesn't throw an exception.

Valeur par défaut: THROW.

Voir Aussi

max_partitions_per_insert_block

Limite le nombre maximal de partitions dans un seul bloc inséré.

  • Entier positif.
  • 0 — Unlimited number of partitions.

Valeur par défaut: 100.

Détail

Lors de l'insertion de données, ClickHouse calcule le nombre de partitions dans le bloc inséré. Si le nombre de partitions est plus que max_partitions_per_insert_block, ClickHouse lève une exception avec le texte suivant:

“Too many partitions for single INSERT block (more than” + toString (max_parts) + “). The limit is controlled by max_partitions_per_insert_block setting. A large number of partitions is a common misconception. It will lead to severe negative performance impact, including slow server startup, slow INSERT queries and slow SELECT queries. Recommended total number of partitions for a table is under 1000..10000. Please note, that partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). Partitions are intended for data manipulation (DROP PARTITION, etc).”

Article Original