max_bytes_before_external_distinct
Seuil de mémoire de la requête, en octets, à partir duquel les donnéesDISTINCT sont déversées sur disque. L’utilisation réelle de la mémoire peut dépasser
ce seuil.
0 désactive ce seuil. Si max_bytes_ratio_before_external_distinct définit lui aussi un seuil,
c’est le plus petit des deux qui est retenu. Définissez les deux paramètres à 0 pour désactiver le déversement.
Voir DISTINCT en mémoire externe.
max_bytes_before_external_group_by
Valeur par défaut dans Cloud : la moitié de la quantité de mémoire de chaque réplique. Active ou désactive l’exécution des clausesGROUP BY en mémoire externe.
(Voir GROUP BY en mémoire externe)
Valeurs possibles :
- Volume maximal de RAM (en octets) pouvant être utilisé par une seule opération GROUP BY.
0—GROUP BYen mémoire externe désactivé.
Si l’utilisation de la mémoire pendant les opérations GROUP BY dépasse ce seuil en octets,
le mode « agrégation externe » est activé (écriture des données sur disque).La valeur recommandée est la moitié de la mémoire système disponible.
max_bytes_before_external_join
S’il est défini sur une valeur non nulle, le hash join sera automatiquement converti en grace hash join pour permettre le déversement sur disque lorsque les données du côté droit dépassent ce nombre d’octets. Conjointement avecmax_bytes_ratio_before_external_join, il constitue le déclencheur de déversement basé sur un seuil pour tout join_algorithm reposant sur le hachage, y compris grace_hash, qui exige que l’un des deux soit non nul. Dès qu’un seuil non nul rend une join capable de déverser sur disque, enable_adaptive_memory_spill_scheduler peut la forcer à déverser sous pression mémoire avant que le seuil ne soit atteint ; si les deux paramètres valent 0, la join ne déverse jamais et le scheduler n’a donc rien à déclencher. L’exception est legacy_join_size_limits_trigger_spilling : lorsqu’il est activé, un grace_hash standalone ignore les deux et déverse en fonction de max_rows_in_join / max_bytes_in_join à la place. Lorsqu’il est défini sur 0 (valeur par défaut), ce seuil absolu en octets est désactivé, mais un déversement sur disque automatique peut toujours se produire via max_bytes_ratio_before_external_join (qui vaut par défaut 0.5) ; définissez les deux sur 0 pour désactiver complètement le déversement sur disque automatique. Cela empêche l’optimisation de lecture read in order via join.
max_bytes_before_external_sort
Valeur par défaut dans Cloud : la moitié de la mémoire par réplique. Active ou désactive l’exécution des clausesORDER BY en mémoire externe. Voir Détails d’implémentation de ORDER BY
Si l’utilisation de la mémoire pendant l’opération ORDER BY dépasse ce seuil en octets, le mode de « tri externe » (écriture des données sur disque) est activé.
Valeurs possibles :
- Volume maximal de RAM (en octets) pouvant être utilisé par une seule opération ORDER BY. La valeur recommandée est la moitié de la mémoire système disponible
0—ORDER BYen mémoire externe désactivé.
max_bytes_before_remerge_sort
Dans le cas d’un ORDER BY avec LIMIT, lorsque l’utilisation de la mémoire dépasse le seuil spécifié, effectuez des étapes supplémentaires de fusion de blocs avant la fusion finale afin de ne conserver que les LIMIT premières lignes.max_bytes_for_lazy_final
Nombre maximal d’octets dans l’ensemble utilisé pour l’optimisation lazy FINAL. Au-delà de cette limite, le système revient à FINAL standard.max_bytes_in_distinct
Nombre maximal d’octets de l’état (en octets non compressés) en mémoire, utilisé par une table de hachage avec DISTINCT.max_bytes_in_join
La taille maximale, en octets, de la structure de données située du côté droit (généralement une table de hachage) utilisée lors de la jointure de tables. Ce paramètre s’applique aux opérations SELECT … JOIN et au moteur de table Join. Si une requête contient plusieurs jointures, ClickHouse vérifie ce paramètre pour chaque résultat intermédiaire. Il s’agit d’un plafond strict pour toutjoin_algorithm fondé sur le hachage : lorsque la limite est atteinte, la requête lève une exception ou s’interrompt selon join_overflow_mode.
Il ne provoque jamais le spill d’une jointure sur disque — cette décision relève de
max_bytes_before_external_join
et de
max_bytes_ratio_before_external_join.
Comme il s’agit d’un plafond et non d’un déclencheur, le définir au niveau du seuil de spill ou en dessous fait normalement échouer la requête avant même que la jointure puisse faire du spill — sauf si la jointure est capable de spill et que enable_adaptive_memory_spill_scheduler force d’abord un spill, ou si legacy_join_size_limits_trigger_spilling reconvertit cette limite en déclencheur de spill pour la partie d’une jointure qui s’exécute déjà sur disque.
La limite comptabilise le contenu des tables de hachage : ainsi, une jointure ayant fait du spill l’atteint au fur et à mesure du chargement de chaque bucket plutôt que pendant la lecture du côté droit ; elle peut donc lire une plus grande part du côté droit avant de s’arrêter qu’une hash join en mémoire.
Valeurs possibles :
- Entier positif.
- 0 — Le contrôle de la mémoire est désactivé.
max_bytes_in_set
Le nombre maximal d’octets (de données non compressées) qu’un ensemble dans la clause IN créé à partir d’une sous-requête peut utiliser.max_bytes_ratio_before_external_distinct
Fraction de la mémoire disponible du serveur ou de l’utilisateur servant à calculer le seuil deDISTINCT externe
au début de l’exécution. Par exemple, 0.5 utilise la moitié de la mémoire disponible.
Les valeurs doivent être supérieures ou égales à 0 et inférieures à 1. La valeur 0 désactive ce seuil. En l’absence de limite
de mémoire applicable au serveur ou à l’utilisateur, le ratio n’a aucun effet.
max_memory_usage n’intervient pas dans ce calcul. Pour configurer le déversement par rapport à cette limite,
utilisez max_bytes_before_external_distinct, en laissant de la marge pour une utilisation supplémentaire de la mémoire.
max_bytes_ratio_before_external_group_by
La proportion de mémoire disponible pouvant être utilisée parGROUP BY. Une fois ce seuil atteint,
la mémoire externe est utilisée pour l’agrégation.
Par exemple, si cette valeur est définie sur 0.6, GROUP BY pourra utiliser 60 % de la mémoire disponible
(pour server/user/merges) au début de l’exécution ; ensuite, il
commencera à utiliser l’agrégation externe.
max_bytes_ratio_before_external_join
Ratio de mémoire disponible autorisé pourJOIN. Une fois ce seuil atteint, le hash join est converti en grace hash join afin de déverser les données du côté droit sur disque.
Par exemple, si cette valeur est définie sur 0.6, JOIN autorise l’utilisation de 60% de la mémoire disponible (pour le serveur/l’utilisateur/les fusions) pour la table de hachage du côté droit au début de l’exécution ; au-delà, le déversement sur disque commence.
Si max_bytes_before_external_join et max_bytes_ratio_before_external_join sont tous deux définis, c’est le plus petit seuil obtenu qui est utilisé. Si le ratio vaut 0, seule la valeur absolue s’applique.
A un effet pour tous les join_algorithm basés sur le hachage, y compris grace_hash, à condition qu’un chemin de données temporaire soit configuré.
max_bytes_ratio_before_external_sort
Rapport de la mémoire disponible pouvant être utilisé pourORDER BY. Une fois cette limite atteinte, le tri externe est utilisé.
Par exemple, s’il est défini sur 0.6, ORDER BY pourra utiliser 60% de la mémoire disponible (pour server/user/merges) au début de l’exécution, puis il commencera à utiliser le tri externe.
Notez que max_bytes_before_external_sort reste pris en compte : le déversement sur disque n’a lieu que si le bloc de tri est plus grand que max_bytes_before_external_sort.
max_bytes_to_read
Le nombre maximal d’octets (de données non compressées) pouvant être lus à partir d’une table lors de l’exécution d’une requête. La restriction est vérifiée pour chaque fragment de données traité, s’applique uniquement à l’expression de table la plus imbriquée et, lors d’une lecture depuis un serveur distant, elle est vérifiée uniquement sur le serveur distant.max_bytes_to_read_leaf
Le nombre maximal d’octets (de données non compressées) pouvant être lus à partir d’une table locale sur un nœud feuille lors de l’exécution d’une requête distribuée. Bien que les requêtes distribuées puissent envoyer plusieurs sous-requêtes à chaque shard (feuille), cette limite n’est vérifiée qu’à l’étape de lecture sur les nœuds feuille et est ignorée lors de l’étape de fusion des résultats sur le nœud racine. Par exemple, un cluster se compose de 2 shards et chaque shard contient une table avec 100 octets de données. Une requête distribuée censée lire toutes les données des deux tables avec le paramètremax_bytes_to_read=150 échouera, car le total
sera de 200 octets. Une requête avec max_bytes_to_read_leaf=150 réussira puisque les
nœuds feuille liront au maximum 100 octets.
La restriction est vérifiée pour chaque fragment de données traité.
Ce paramètre est instable avec
prefer_localhost_replica=1.max_bytes_to_sort
Le nombre maximal d’octets avant le tri. Si l’opération ORDER BY doit traiter plus d’octets non compressés que la quantité spécifiée, le comportement sera déterminé parsort_overflow_mode, qui est défini par défaut sur throw.