max_insert_block_size
max_insert_block_size_rows
Taille maximale des blocs (en nombre de lignes) à former pour l’insertion dans une table.
Ce paramètre contrôle la formation des blocs dans deux contextes :
-
Analyse des formats : lorsque le serveur analyse des formats d’entrée orientés lignes (CSV, TSV, JSONEachRow, etc.) depuis n’importe quelle interface (HTTP, clickhouse-client avec des données intégrées, gRPC, protocole wire de PostgreSQL), les blocs sont émis lorsque :
- Les deux seuils min_insert_block_size_rows AND min_insert_block_size_bytes sont atteints, OR
- L’un des deux seuils max_insert_block_size_rows OR max_insert_block_size_bytes est atteint
-
Opérations INSERT : pendant les requêtes INSERT et lorsque les données transitent par des vues matérialisées, le comportement de ce paramètre dépend de
use_strict_insert_block_limits:-
Lorsqu’il est activé : les blocs sont émis lorsque :
- Seuils minimums (AND) : les deux seuils min_insert_block_size_rows AND min_insert_block_size_bytes sont atteints
- Seuils maximums (OR) : l’un des deux seuils max_insert_block_size_rows OR max_insert_block_size_bytes est atteint
- Lorsqu’il est désactivé : les blocs sont émis lorsque min_insert_block_size_rows OR min_insert_block_size_bytes est atteint. Les paramètres max_insert_block_size ne sont pas appliqués.
-
Lorsqu’il est activé : les blocs sont émis lorsque :
- Entier positif.
max_insert_block_size_bytes
- Entier positif.
- 0 — le paramètre n’entre pas en compte dans la formation des blocs.
max_insert_delayed_streams_for_parallel_write
50.
max_insert_threads
INSERT.
Ce paramètre s’applique à la fois à INSERT SELECT et à un simple INSERT dont les données sont envoyées depuis
clickhouse-client ou via l’interface HTTP. La partie écriture du pipeline
(regroupement des blocs et écriture dans la table de destination) est parallélisée
sur un maximum de ce nombre de threads.
Valeurs possibles :
- 0 — Auto. Utilise le nombre de cœurs de processeur disponibles sur le serveur (la même valeur automatique que
max_threads), réduit en cas de pression mémoire parmax_insert_threads_min_free_memory_per_thread. - 1 — l’
INSERTest exécuté dans un seul thread (sans exécution parallèle). Utilisez cette valeur pour préserver l’ordre d’insertion deINSERT ... SELECT. - Entier positif supérieur à 1 — Exécution parallèle avec le nombre de threads indiqué.
1 (sans exécution parallèle). Depuis la version 26.8, la valeur par défaut (0) correspond au nombre de cœurs de processeur ; INSERT est donc parallélisé par défaut. Définissez max_insert_threads sur 1 (ou utilisez le paramètre compatibility) pour restaurer le comportement précédent.
Valeur par défaut dans Cloud :
1pour les nœuds disposant de 8 Gio de mémoire2pour les nœuds disposant de 16 Gio de mémoire4pour les nœuds plus grands
INSERT SELECT parallèle n’a d’effet que si la partie SELECT est exécutée en parallèle ; consultez le paramètre max_threads.
Pour un simple INSERT, les données d’entrée sont lues et analysées dans un seul flux, puis le pipeline est redimensionné en ce nombre de flux pour l’écriture.
La parallélisation de la partie écriture s’applique uniquement aux simples INSERT synchrones : les insertions asynchrones (async_insert = 1) sont placées dans une file d’attente et flushées en arrière-plan ; elles ne sont donc pas affectées par ce paramètre et restent toujours sur un seul flux.
La partie écriture n’est parallélisée que lorsque cela ne pose aucun risque ; sinon, elle reste sur un seul flux et ce paramètre n’a aucun effet. En particulier, l’écriture reste sur un seul flux lorsque use_strict_insert_block_limits est activé, qu’une table de destination (ou une table vers laquelle elle redirige) déduplique les blocs insérés et que la déduplication des insertions est activée pour la requête (consultez deduplicate_insert), lorsque la destination possède des vues matérialisées dépendantes — y compris des vues d’une table vers laquelle la destination redirige, par exemple derrière un Alias — (sauf si parallel_view_processing est activé et que les chaînes de vues dépendantes ne présentent aucun risque de déduplication — la déduplication dans les vues est désactivée (deduplicate_blocks_in_dependent_materialized_views) ou aucun chemin de vue dépendante ne peut dédupliquer), et systématiquement pour les destinations Buffer et Distributed. Un Buffer effectue son flush dans son propre contexte et un Distributed transmet l’écriture à un fragment distant (qui peut lui-même mettre les données en mémoire tampon) ; les paramètres de déduplication de cette requête ne régissent donc pas l’écriture finale, qui reste sur un seul flux indépendamment de ces paramètres. Une insertion par quorum non parallèle (insert_quorum est égal à 2 ou plus, ou à 'auto', et insert_quorum_parallel est désactivé) reste également sur un seul flux, car elle n’autorise qu’une seule part de quorum en cours par table.
Des valeurs plus élevées entraînent une utilisation accrue de la mémoire.
max_insert_threads_min_free_memory_per_thread
max_threads_min_free_memory_per_thread, mais appliqué à max_insert_threads plutôt qu’à max_threads. La valeur par défaut est plus élevée, car les pipelines d’insertion utilisent généralement des buffers par thread plus volumineux (parts MergeTree, blocs de compression) que les pipelines de lecture.
Si la quantité de mémoire libre est inférieure à max_insert_threads multiplié par cette valeur, max_insert_threads est réduit en conséquence, avec un minimum de 1.
Définissez cette valeur sur 0 pour désactiver cette limite.