ClickHouse applies this setting when the query contains the product of distributed tables, i.e.when the query for a distributed table contains a non-GLOBAL subquery for the distributed table.
Restriction:
- Uniquement appliqué pour les sous-requêtes IN et JOIN.
Si `enable_optimize_predicate_expression = 1`, alors le temps d'exécution de ces requêtes est égal car ClickHouse s'applique `WHERE` à la sous-requête lors du traitement.
Si `enable_optimize_predicate_expression = 0` puis le temps d'exécution de la deuxième requête est beaucoup plus long, parce que le `WHERE` la clause s'applique à toutes les données après la sous-requête des finitions.
Force une requête à un réplica obsolète si les données mises à jour ne sont pas disponibles. Voir [Réplication](../../engines/table-engines/mergetree-family/replication.md).
Si `force_index_by_date=1`, Clickhouse vérifie si la requête a une condition de clé de date qui peut être utilisée pour restreindre les plages de données. S'il n'y a pas de condition appropriée, il lève une exception. Cependant, il ne vérifie pas si la condition réduit la quantité de données à lire. Par exemple, la condition `Date != ' 2000-01-01 '` est acceptable même lorsqu'il correspond à toutes les données de la table (c'est-à-dire que l'exécution de la requête nécessite une analyse complète). Pour plus d'informations sur les plages de données dans les tables MergeTree, voir [MergeTree](../../engines/table-engines/mergetree-family/mergetree.md).
Si `force_primary_key=1`, Clickhouse vérifie si la requête a une condition de clé primaire qui peut être utilisée pour restreindre les plages de données. S'il n'y a pas de condition appropriée, il lève une exception. Cependant, il ne vérifie pas si la condition réduit la quantité de données à lire. Pour plus d'informations sur les plages de données dans les tables MergeTree, voir [MergeTree](../../engines/table-engines/mergetree-family/mergetree.md).
Ce paramètre est utile lorsque vous utilisez des formats nécessitant une définition de schéma, tels que [Cap'n Proto](https://capnproto.org/) ou [Protobuf](https://developers.google.com/protocol-buffers/). La valeur dépend du format.
Active ou désactive [fsync](http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html) lors de l'écriture `.sql` fichier. Activé par défaut.
Active ou désactive la vérification de la somme de contrôle lors de la décompression des données HTTP POST du client. Utilisé uniquement pour le format de compression natif ClickHouse (non utilisé avec `gzip` ou `deflate`).
Limite le nombre maximal de sauts de redirection HTTP GET pour [URL](../../engines/table-engines/special/url.md)-tables de moteur. Le paramètre s'applique aux deux types de tables: celles créées par [CREATE TABLE](../../sql-reference/statements/create.md#create-table-query) requête et par la [URL](../../sql-reference/table-functions/url.md) table de fonction.
Si une erreur s'est produite lors de la lecture de lignes mais que le compteur d'erreurs est toujours inférieur à `input_format_allow_errors_num`, ClickHouse ignore la ligne et passe à la suivante.
Si une erreur s'est produite lors de la lecture de lignes mais que le compteur d'erreurs est toujours inférieur à `input_format_allow_errors_ratio`, ClickHouse ignore la ligne et passe à la suivante.
Active ou désactive L'analyseur SQL complet si l'analyseur de flux rapide ne peut pas analyser les données. Ce paramètre est utilisé uniquement pour la [Valeur](../../interfaces/formats.md#data-format-values) format lors de l'insertion des données. Pour plus d'informations sur l'analyse syntaxique, consultez [Syntaxe](../../sql-reference/syntax.md) section.
Dans ce cas, vous pouvez utiliser une expression SQL en tant que valeur, mais l'insertion de données est beaucoup plus lente de cette façon. Si vous insérez uniquement des données formatées, ClickHouse se comporte comme si la valeur de réglage était 0.
Active ou désactive la déduction de modèle pour les expressions SQL dans [Valeur](../../interfaces/formats.md#data-format-values) format. Il permet d'analyser et d'interpréter des expressions dans `Values` beaucoup plus rapide si les expressions dans des lignes consécutives ont la même structure. ClickHouse tente de déduire le modèle d'une expression, d'analyser les lignes suivantes à l'aide de ce modèle et d'évaluer l'expression sur un lot de lignes analysées avec succès.
- Si `input_format_values_interpret_expressions=1` et `format_values_deduce_templates_of_expressions=0`, les expressions sont interprétées séparément pour chaque ligne (c'est très lent pour un grand nombre de lignes).
- Si `input_format_values_interpret_expressions=0` et `format_values_deduce_templates_of_expressions=1`, les expressions des première, deuxième et troisième lignes sont analysées à l'aide de template `lower(String)` et interprété ensemble, l'expression dans la quatrième ligne est analysée avec un autre modèle (`upper(String)`).
- Si `input_format_values_interpret_expressions=1` et `format_values_deduce_templates_of_expressions=1`, le même que dans le cas précédent, mais permet également d'interpréter les expressions séparément s'il n'est pas possible de déduire le modèle.
Ce paramètre est utilisé uniquement lorsque `input_format_values_deduce_templates_of_expressions = 1`. Il peut arriver que les expressions pour une colonne aient la même structure, mais contiennent des littéraux numériques de types différents, par exemple
In this case, ClickHouse may use a more general type for some literals (e.g.,`Float64` ou `Int64` plutôt `UInt64` pour `42`), mais cela peut causer des problèmes de débordement et de précision.
- 1 — Enabled.
Dans ce cas, ClickHouse vérifie le type réel de littéral et utilise un modèle d'expression du type correspondant. Dans certains cas, cela peut considérablement ralentir l'évaluation de l'expression dans `Values`.
Lors de l'exécution de `INSERT` requêtes, remplacez les valeurs de colonne d'entrée omises par les valeurs par défaut des colonnes respectives. Cette option s'applique uniquement aux [JSONEachRow](../../interfaces/formats.md#jsoneachrow), [CSV](../../interfaces/formats.md#csv) et [TabSeparated](../../interfaces/formats.md#tabseparated) format.
Lorsque cette option est activée, les métadonnées de table étendues sont envoyées du serveur au client. Il consomme des ressources informatiques supplémentaires sur le serveur et peut réduire les performances.
Lorsque cette option est activée, remplacez les champs de saisie vides dans TSV par des valeurs par défaut. Pour les expressions par défaut complexes `input_format_defaults_for_omitted_fields` doit être activé en trop.
Active ou désactive l'utilisation des valeurs par défaut si les données `NULL` mais le type de données de la colonne correspondante dans pas `Nullable(T)` (pour les formats de saisie de texte).
Lors de l'écriture de données, ClickHouse lève une exception si les données d'entrée contiennent des colonnes qui n'existent pas dans la table cible. Si le saut est activé, ClickHouse n'insère pas de données supplémentaires et ne lance pas d'exception.
Pour améliorer les performances d'insertion, nous vous recommandons de désactiver cette vérification si vous êtes sûr que l'ordre des colonnes des données d'entrée est le même que dans la table cible.
ClickHouse peut analyser la base `YYYY-MM-DD HH:MM:SS` format et tous [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) formats de date et heure. Exemple, `'2018-06-08T01:02:03.000Z'`.
-`'basic'` — Use basic parser.
ClickHouse ne peut analyser que la base `YYYY-MM-DD HH:MM:SS` format. Exemple, `'2019-08-20 10:18:56'`.
-`ALL` — If the right table has several matching rows, ClickHouse creates a [Produit cartésien](https://en.wikipedia.org/wiki/Cartesian_product) à partir des lignes correspondantes. C'est normal `JOIN` comportement de SQL standard.
-`ANY` — If the right table has several matching rows, only the first one found is joined. If the right table has only one matching row, the results of `ANY` et `ALL` sont les mêmes.
-`ASOF` — For joining sequences with an uncertain match.
Définit le type de [JOIN](../../sql-reference/statements/select/join.md) comportement. Lors de la fusion de tables, des cellules vides peuvent apparaître. ClickHouse les remplit différemment en fonction de ce paramètre.
- 1 — `JOIN` se comporte de la même manière que dans SQL standard. Le type du champ correspondant est converti en [Nullable](../../sql-reference/data-types/nullable.md#data_type-nullable) et les cellules vides sont remplis avec [NULL](../../sql-reference/syntax.md).
Dans ClickHouse, les données sont traitées par Blocs (Ensembles de parties de colonne). Les cycles de traitement internes pour un seul bloc sont assez efficaces, mais il y a des dépenses notables sur chaque bloc. Le `max_block_size` le paramètre est une recommandation pour la taille du bloc (dans un nombre de lignes) à charger à partir des tables. La taille du bloc ne doit pas être trop petite, de sorte que les dépenses sur chaque bloc sont toujours perceptibles, mais pas trop grande pour que la requête avec limite qui est terminée après le premier bloc soit traitée rapidement. L'objectif est d'éviter de consommer trop de mémoire lors de l'extraction d'un grand nombre de colonnes dans plusieurs threads et de préserver au moins certains localité de cache.
Les blocs de la taille de `max_block_size` ne sont pas toujours chargées de la table. Si il est évident que moins de données doivent être récupérées, un bloc plus petit est traitée.
Si le nombre de lignes à lire à partir d'un fichier d'un [MergeTree](../../engines/table-engines/mergetree-family/mergetree.md) table dépasse `merge_tree_min_rows_for_concurrent_read` ensuite, ClickHouse essaie d'effectuer une lecture simultanée de ce fichier sur plusieurs threads.
Si le nombre d'octets à lire à partir d'un fichier d'un [MergeTree](../../engines/table-engines/mergetree-family/mergetree.md)- table de moteur dépasse `merge_tree_min_bytes_for_concurrent_read` puis ClickHouse essaie de lire simultanément à partir de ce fichier dans plusieurs threads.
Si la distance entre deux blocs de données à lire dans un fichier est inférieure à `merge_tree_min_rows_for_seek` lignes, puis ClickHouse ne cherche pas à travers le fichier mais lit les données séquentiellement.
Si la distance entre deux blocs de données à lire dans un fichier est inférieure à `merge_tree_min_bytes_for_seek` octets, puis ClickHouse lit séquentiellement une plage de fichier qui contient les deux blocs, évitant ainsi la recherche supplémentaire.
Lors de la recherche de données, ClickHouse vérifie les marques de données dans le fichier d'index. Si ClickHouse trouve que les clés requises sont dans une certaine plage, il divise cette plage en `merge_tree_coarse_index_granularity` subranges et recherche les clés requises récursivement.
Le cache des blocs non compressés stocke les données extraites pour les requêtes. ClickHouse utilise ce cache pour accélérer les réponses aux petites requêtes répétées. Ce paramètre protège le cache contre le saccage par les requêtes qui lisent une grande quantité de données. Le [uncompressed\_cache\_size](../server-configuration-parameters/settings.md#server-settings-uncompressed_cache_size) le paramètre serveur définit la taille du cache des blocs non compressés.
Le cache des blocs non compressés stocke les données extraites pour les requêtes. ClickHouse utilise ce cache pour accélérer les réponses aux petites requêtes répétées. Ce paramètre protège le cache contre le saccage par les requêtes qui lisent une grande quantité de données. Le [uncompressed\_cache\_size](../server-configuration-parameters/settings.md#server-settings-uncompressed_cache_size) le paramètre serveur définit la taille du cache des blocs non compressés.
ClickHouse utilise ce paramètre lors de la lecture de données à partir de tables. Si le volume total de stockage de toutes les données à lire dépasse `min_bytes_to_use_direct_io` octets, puis ClickHouse lit les données du disque de stockage avec le `O_DIRECT` option.
Les requêtes envoyées à ClickHouse avec cette configuration sont enregistrées selon les règles du [query\_log](../server-configuration-parameters/settings.md#server_configuration_parameters-query-log) paramètre de configuration du serveur.
Peut être utilisé pour limiter le nombre de entiries va va `query_log`, dites que vous êtes intéressant que dans les erreurs, alors vous pouvez utiliser `EXCEPTION_WHILE_PROCESSING`:
Les threads de requêtes exécutés par ClickHouse avec cette configuration sont journalisés selon les règles du [query\_thread\_log](../server-configuration-parameters/settings.md#server_configuration_parameters-query-thread-log) paramètre de configuration du serveur.
La taille des blocs à former pour l'insertion dans une table.
Ce paramètre s'applique uniquement dans les cas où le serveur formes les blocs.
Par exemple, pour une insertion via L'interface HTTP, le serveur analyse le format de données et forme des blocs de la taille spécifiée.
Mais lors de l'utilisation de clickhouse-client, le client analyse les données ‘max\_insert\_block\_size’ le réglage sur le serveur n'affecte pas la taille des blocs insérés.
Le paramètre n'a pas non plus de but lors de L'utilisation D'INSERT SELECT, car les données sont insérées à l'aide des mêmes blocs qui sont formés après SELECT.
La valeur par défaut est légèrement supérieure à `max_block_size`. La raison en est que certains moteurs de table (`*MergeTree`) former une partie de données sur le disque pour chaque bloc inséré, qui est une entité assez grande. Pareillement, `*MergeTree` les tables trient les données lors de l'insertion et une taille de bloc suffisamment grande permet de trier plus de données dans la RAM.
Définit le nombre minimum de lignes dans le bloc qui peut être inséré dans un tableau par un `INSERT` requête. Les blocs de plus petite taille sont écrasés en plus gros.
Définit le nombre minimal d'octets dans le bloc qui peut être inséré dans un tableau par un `INSERT` requête. Les blocs de plus petite taille sont écrasés en plus gros.
Nombre maximal de threads de traitement des requêtes, à l'exclusion des threads de récupération de données à partir de serveurs distants (voir ‘max\_distributed\_connections’ paramètre).
Ce paramètre s'applique aux threads qui effectuent les mêmes étapes du pipeline de traitement des requêtes en parallèle.
Par exemple, lors de la lecture d'une table, s'il est possible d'évaluer des expressions avec des fonctions, filtrer avec WHERE et pré-agréger pour GROUP BY en parallèle en utilisant au moins ‘max\_threads’ nombre de threads, puis ‘max\_threads’ sont utilisés.
Si moins d'une requête SELECT est normalement exécutée sur un serveur à la fois, définissez ce paramètre sur une valeur légèrement inférieure au nombre réel de cœurs de processeur.
Pour les requêtes qui sont terminées rapidement en raison d'une limite, vous pouvez définir une valeur inférieure ‘max\_threads’. Par exemple, si le nombre d'entrées se trouvent dans chaque bloc et max\_threads = 8, 8 blocs sont récupérées, même s'il aurait été suffisante pour lire un seul.
La taille maximale des blocs de données non compressées avant la compression pour l'écriture dans une table. Par défaut, 1 048 576 (1 MiB). Si la taille est réduite, le taux de compression est considérablement réduit, la vitesse de compression et de décompression augmente légèrement en raison de la localisation du cache, et la consommation de mémoire est réduite. Il n'y aucune raison de modifier ce paramètre.
Ne confondez pas les blocs pour la compression (un morceau de mémoire constitué d'octets) avec des blocs pour le traitement des requêtes (Un ensemble de lignes d'une table).
Pour [MergeTree](../../engines/table-engines/mergetree-family/mergetree.md)" table. Afin de réduire la latence lors du traitement des requêtes, un bloc est compressé lors de l'écriture de la marque suivante si sa taille est au moins ‘min\_compress\_block\_size’. Par défaut, 65 536.
La taille réelle du bloc, si les données non compressées sont inférieures à ‘max\_compress\_block\_size’ pas moins de cette valeur et pas moins que le volume de données pour une marque.
Regardons un exemple. Supposons que ‘index\_granularity’ a 8192 lors de la création de la table.
Nous écrivons une colonne de type UInt32 (4 octets par valeur). Lors de l'écriture de 8192 lignes, le total sera de 32 KO de données. Puisque min\_compress\_block\_size = 65 536, un bloc compressé sera formé pour toutes les deux marques.
Nous écrivons une colonne URL avec le type de chaîne (taille moyenne de 60 octets par valeur). Lors de l'écriture de 8192 lignes, la moyenne sera légèrement inférieure à 500 Ko de données. Comme il s'agit de plus de 65 536, un bloc compressé sera formé pour chaque marque. Dans ce cas, lors de la lecture de données du disque dans la plage d'une seule marque, les données supplémentaires ne seront pas décompressées.
La partie maximale d'une requête qui peut être prise en RAM pour l'analyse avec L'analyseur SQL.
La requête INSERT contient également des données pour INSERT qui sont traitées par un analyseur de flux séparé (qui consomme O (1) RAM), qui n'est pas inclus dans cette restriction.
Nombre maximal de connexions simultanées avec des serveurs distants pour le traitement distribué d'une seule requête vers une seule table distribuée. Nous vous recommandons de définir une valeur au moins égale au nombre de serveurs dans le cluster.
Les paramètres suivants ne sont utilisés que lors de la création de tables distribuées (et lors du lancement d'un serveur), il n'y a donc aucune raison de les modifier lors de l'exécution.
Nombre maximal de connexions simultanées avec des serveurs distants pour le traitement distribué de toutes les requêtes vers une seule table distribuée. Nous vous recommandons de définir une valeur au moins égale au nombre de serveurs dans le cluster.
Délai d'attente en millisecondes pour la connexion à un serveur distant pour un moteur de table distribué, si ‘shard’ et ‘replica’ les sections sont utilisées dans la définition du cluster.
En cas d'échec, plusieurs tentatives sont faites pour se connecter à diverses répliques.
Indique s'il faut compter les valeurs extrêmes (les minimums et les maximums dans les colonnes d'un résultat de requête). Accepte 0 ou 1. Par défaut, 0 (désactivé).
Pour plus d'informations, consultez la section “Extreme values”.
Indique s'il faut utiliser un cache de blocs non compressés. Accepte 0 ou 1. Par défaut, 0 (désactivé).
L'utilisation du cache non compressé (uniquement pour les tables de la famille MergeTree) peut réduire considérablement la latence et augmenter le débit lorsque vous travaillez avec un grand nombre de requêtes courtes. Activez ce paramètre pour les utilisateurs qui envoient des requêtes courtes fréquentes. Faites également attention à la [uncompressed\_cache\_size](../server-configuration-parameters/settings.md#server-settings-uncompressed_cache_size) configuration parameter (only set in the config file) – the size of uncompressed cache blocks. By default, it is 8 GiB. The uncompressed cache is filled in as needed and the least-used data is automatically deleted.
Pour les requêtes qui lisent au moins un volume de données assez important (un million de lignes ou plus), le cache non compressé est désactivé automatiquement pour économiser de l'espace pour les requêtes vraiment petites. Cela signifie que vous pouvez garder la ‘use\_uncompressed\_cache’ toujours la valeur 1.
Lors de l'utilisation de L'interface HTTP, le ‘query\_id’ le paramètre peut être passé. C'est n'importe quelle chaîne qui sert d'Identificateur de requête.
Si une requête d'un utilisateur avec le même ‘query\_id’ il existe déjà à ce moment, le comportement dépend de la ‘replace\_running\_query’ paramètre.
Yandex.Metrica utilise ce paramètre défini sur 1 pour implémenter des suggestions de conditions de segmentation. Après avoir entré le caractère suivant, si l'ancienne requête n'est pas encore terminée, elle doit être annulée.
Fonctionne pour les tables avec des flux dans le cas d'une expiration, ou lorsqu'un thread génère [max\_insert\_block\_size](#settings-max_insert_block_size) rangée.
Le nombre d'erreurs est compté pour chaque réplique. La requête est envoyée au réplica avec le moins d'erreurs, et s'il y en a plusieurs, à n'importe qui d'entre eux.
Inconvénients: la proximité du serveur n'est pas prise en compte; si les répliques ont des données différentes, vous obtiendrez également des données différentes.
The number of errors is counted for each replica. Every 5 minutes, the number of errors is integrally divided by 2. Thus, the number of errors is calculated for a recent time with exponential smoothing. If there is one replica with a minimal number of errors (i.e.errors occurred recently on the other replicas), the query is sent to it. If there are multiple replicas with the same minimal number of errors, the query is sent to the replica with a hostname that is most similar to the server's hostname in the config file (for the number of different characters in identical positions, up to the minimum length of both hostnames).
Par exemple, exemple01-01-1 et example01-01-2.yandex.ru sont différents dans une position, tandis que l'exemple01-01-1 et l'exemple01-02-2 diffèrent dans deux endroits.
Cette méthode peut sembler primitive, mais elle ne nécessite pas de données externes sur la topologie du réseau, et elle ne compare pas les adresses IP, ce qui serait compliqué pour nos adresses IPv6.
Ainsi, s'il existe des répliques équivalentes, la plus proche par son nom est préférée.
Nous pouvons également supposer que lors de l'envoi d'une requête au même serveur, en l'absence d'Échecs, une requête distribuée ira également aux mêmes serveurs. Ainsi, même si des données différentes sont placées sur les répliques, la requête retournera principalement les mêmes résultats.
Cet algorithme choisit la première réplique de l'ensemble ou une réplique aléatoire si la première n'est pas disponible. Il est efficace dans les configurations de topologie de réplication croisée, mais inutile dans d'autres configurations.
Le `first_or_random` algorithme résout le problème de la `in_order` algorithme. Avec `in_order`, si une réplique tombe en panne, la suivante obtient une double charge tandis que les répliques restantes gèrent la quantité habituelle de trafic. Lors de l'utilisation de la `first_or_random` algorithme, la charge est répartie uniformément entre les répliques qui sont encore disponibles.
Nombre maximal de répliques pour chaque fragment lors de l'exécution d'une requête.
Par souci de cohérence (pour obtenir différentes parties du même partage de données), Cette option ne fonctionne que lorsque la clé d'échantillonnage est définie.
La compilation n'est utilisée que pour une partie du pipeline de traitement des requêtes: pour la première étape de l'agrégation (GROUP BY).
Si cette partie du pipeline a été compilée, la requête peut s'exécuter plus rapidement en raison du déploiement de cycles courts et des appels de fonction d'agrégation intégrés. L'amélioration maximale des performances (jusqu'à quatre fois plus rapide dans de rares cas) est observée pour les requêtes avec plusieurs fonctions d'agrégat simples. Typiquement, le gain de performance est insignifiant. Dans de très rares cas, il peut ralentir l'exécution de la requête.
For testing, the value can be set to 0: compilation runs synchronously and the query waits for the end of the compilation process before continuing execution. For all other cases, use values starting with 1. Compilation normally takes about 5-10 seconds.
Si la valeur est 1 ou plus, la compilation se produit de manière asynchrone dans un thread séparé. Le résultat sera utilisé dès qu'il sera prêt, y compris les requêtes en cours d'exécution.
Le code compilé est requis pour chaque combinaison différente de fonctions d'agrégat utilisées dans la requête et le type de clés dans la clause GROUP BY.
The results of the compilation are saved in the build directory in the form of .so files. There is no restriction on the number of compilation results since they don't use very much space. Old results will be used after server restarts, except in the case of a server upgrade – in this case, the old results are deleted.
Si la valeur est true, les entiers apparaissent entre guillemets lors de l'utilisation des formats JSON\* Int64 et UInt64 (pour la compatibilité avec la plupart des implémentations JavaScript); sinon, les entiers sont sortis sans les guillemets.
`INSERT` ne réussit que lorsque ClickHouse parvient à écrire correctement les données `insert_quorum` des répliques au cours de la `insert_quorum_timeout`. Si, pour une raison quelconque, le nombre de répliques avec succès écrit n'atteint pas le `insert_quorum`, l'écriture est considérée comme ayant échoué et ClickHouse supprimera le bloc inséré de toutes les répliques où les données ont déjà été écrites.
Toutes les répliques du quorum sont cohérentes, c'est-à-dire qu'elles contiennent des données de toutes les `INSERT` requête. Le `INSERT` la séquence est linéarisé.
Lors de la lecture des données écrites à partir du `insert_quorum`, vous pouvez utiliser le [select\_sequential\_consistency](#settings-select_sequential_consistency) option.
Clickhouse génère une exception
- Si le nombre de répliques au moment de la requête est inférieure à la `insert_quorum`.
- Lors d'une tentative d'écriture de données lorsque le bloc précédent n'a pas encore été inséré dans le `insert_quorum` des répliques. Cette situation peut se produire si l'utilisateur tente d'effectuer une `INSERT` avant le précédent avec le `insert_quorum` est terminé.
Ecrire dans quorum timeout en secondes. Si le délai d'attente est passé et qu'aucune écriture n'a encore eu lieu, ClickHouse génère une exception et le client doit répéter la requête pour écrire le même bloc dans le même réplica ou tout autre réplica.
Lorsque la cohérence séquentielle est activée, ClickHouse permet au client d'exécuter `SELECT` requête uniquement pour les répliques qui contiennent des données de toutes les `INSERT` requêtes exécutées avec `insert_quorum`. Si le client fait référence à une réplique partielle, ClickHouse génère une exception. La requête SELECT n'inclut pas les données qui n'ont pas encore été écrites dans le quorum des répliques.
Par défaut, les blocs insérés dans les tables répliquées `INSERT` déclaration sont dédupliquées (voir [Réplication Des Données](../../engines/table-engines/mergetree-family/replication.md)).
Par défaut, la déduplication n'est pas effectuée pour les vues matérialisées mais en amont, dans la table source.
Si un bloc inséré est ignoré en raison de la déduplication dans la table source, il n'y aura pas d'insertion dans les vues matérialisées attachées. Ce comportement existe pour permettre l'insertion de données hautement agrégées dans des vues matérialisées, dans les cas où les blocs insérés sont les mêmes après l'agrégation de vues matérialisées mais dérivés de différentes insertions dans la table source.
Dans le même temps, ce comportement “breaks” `INSERT` idempotence. Si un `INSERT` dans la table principale a été un succès et `INSERT` into a materialized view failed (e.g.because of communication failure with Zookeeper) a client will get an error and can retry the operation. However, the materialized view won't receive the second insert because it will be discarded by deduplication in the main (source) table. The setting `deduplicate_blocks_in_dependent_materialized_views` permet de changer ce comportement. Lors d'une nouvelle tentative, une vue matérialisée recevra l'insertion répétée et effectuera une vérification de déduplication par elle-même,
Limite le volume de données (en octets) qui est reçu ou transmis sur le réseau lors de l'exécution d'une requête. Ce paramètre s'applique à chaque individu requête.
Limite la vitesse de l'échange de données sur le réseau en octets par seconde. Ce paramètre s'applique à toutes les requêtes exécutées simultanément par un seul utilisateur.
Limite la vitesse à laquelle les données sont échangées sur le réseau en octets par seconde. Ce paramètre s'applique à toutes les requêtes exécutées simultanément sur le serveur.
Spécifie de l' `uniq*` les fonctions doivent être utilisées pour [COUNT(DISTINCT …)](../../sql-reference/aggregate-functions/reference.md#agg_function-count) construction.
- ClickHouse ne peut pas se connecter à la réplique pour une raison quelconque.
Lors de la connexion à une réplique, ClickHouse effectue plusieurs tentatives. Si toutes ces tentatives échouent, la réplique est considéré comme indisponible.
- La réplique ne peut pas être résolue via le DNS.
- L'hôte de la réplique n'a pas d'enregistrement DNS. Il peut se produire dans les systèmes avec DNS dynamique, par exemple, [Kubernetes](https://kubernetes.io), où les nœuds peuvent être insolubles pendant les temps d'arrêt, et ce n'est pas une erreur.
Si un fragment n'est pas disponible, ClickHouse renvoie un résultat basé sur des données partielles et ne signale pas les problèmes de disponibilité des nœuds.
Active ou désactive le saut des fragments inutilisés pour les requêtes SELECT qui ont la condition de clé de sharding dans PREWHERE/WHERE (suppose que les données sont distribuées par la clé de sharding, sinon ne rien faire).
Active ou désactive l'exécution de la requête si [`optimize_skip_unused_shards`](#settings-optimize_skip_unused_shards) activé et sauter des fragments inutilisés n'est pas possible. Si le saut n'est pas possible et le paramètre est activé, une exception sera levée.
Active ou désactive le lancement d'une exception si [OPTIMIZE](../../sql-reference/statements/misc.md#misc_operations-optimize) la requête n'a pas effectué de fusion.
Par défaut, `OPTIMIZE` retourne avec succès même s'il n'a rien fait. Ce paramètre vous permet de différencier ces situations et d'obtenir la raison dans un message d'exception.
Contrôle la vitesse à laquelle les erreurs dans les tables distribuées sont mises à zéro. Si une réplique est indisponible pendant un certain temps, accumule 5 erreurs et distributed\_replica\_error\_half\_life est défini sur 1 seconde, la réplique est considérée comme normale 3 secondes après la dernière erreur.
Intervalle de Base pour le [Distribué](../../engines/table-engines/special/distributed.md) tableau moteur à envoyer des données. L'intervalle réel augmente de façon exponentielle en cas d'erreurs.
Intervalle maximal pour le [Distribué](../../engines/table-engines/special/distributed.md) tableau moteur à envoyer des données. Limite la croissance exponentielle de l'intervalle défini dans [distributed\_directory\_monitor\_sleep\_time\_ms](#distributed_directory_monitor_sleep_time_ms) paramètre.
Lorsque l'envoi par lots est activé, le [Distribué](../../engines/table-engines/special/distributed.md) tableau moteur essaie d'envoyer plusieurs fichiers de données insérées dans une seule opération au lieu de les envoyer séparément. L'envoi par lots améliore les performances du cluster en utilisant mieux les ressources du serveur et du réseau.
Définit la priorité ([beau](https://en.wikipedia.org/wiki/Nice_(Unix))) pour les threads qui exécutent des requêtes. Le planificateur du système d'exploitation considère cette priorité lors du choix du prochain thread à exécuter sur chaque noyau CPU disponible.
Pour utiliser ce paramètre, vous devez définir l' `CAP_SYS_NICE` capacité. Le `clickhouse-server` paquet configure lors de l'installation. Certains environnements virtuels ne vous permettent pas de définir `CAP_SYS_NICE` capacité. Dans ce cas, `clickhouse-server` affiche un message à ce sujet au début.
Des valeurs plus faibles signifient une priorité plus élevée. Les discussions avec des bas `nice` les valeurs de priorité sont effectués plus fréquemment que les discussions avec des valeurs élevées. Les valeurs élevées sont préférables pour les requêtes non interactives de longue durée, car elles leur permettent d'abandonner rapidement des ressources au profit de requêtes interactives courtes lorsqu'elles arrivent.
Définit la période pour une horloge réelle de la [requête profiler](../../operations/optimizing-performance/sampling-query-profiler.md). La vraie minuterie d'horloge compte le temps d'horloge murale.
Définit la période pour une minuterie D'horloge CPU du [requête profiler](../../operations/optimizing-performance/sampling-query-profiler.md). Cette minuterie ne compte que le temps CPU.
Définit le nombre de threads effectuant des opérations d'arrière-plan dans les moteurs de table (par exemple, fusionne dans [Moteur MergeTree](../../engines/table-engines/mergetree-family/index.md) table). Ce paramètre est appliqué au démarrage du serveur ClickHouse et ne peut pas être modifié dans une session utilisateur. En ajustant ce paramètre, vous gérez la charge du processeur et du disque. Une taille de pool plus petite utilise moins de ressources CPU et disque, mais les processus d'arrière-plan avancent plus lentement, ce qui pourrait éventuellement avoir un impact sur les performances des requêtes.