DB::Exception : Too many parts (Erreur : 252). Les fusions s’effectuent nettement plus lentement que les insertions
parts_to_throw_insert dans une table MergeTree.
Vous pouvez surveiller le nombre de parts actives d’une table donnée avec :
INSERT par seconde. L’idéal est de faire une insertion par seconde, ou toutes les quelques secondes.
Vous pouvez donc insérer 100K lignes par seconde, mais uniquement avec une seule grosse instruction INSERT en bloc. Lorsque vous envoyez des centaines / milliers d’instructions d’insertion par seconde vers une table *MergeTree, vous finirez toujours par obtenir des erreurs, et cela ne peut pas être corrigé en ajustant quelques paramètres.
Si vous ne pouvez pas regrouper de nombreuses insertions en une seule grosse instruction INSERT en bloc en amont, vous devez alors créer une table Buffer avant la table *MergeTree.
-
Chaque insertion crée un dossier dans
/var/lib/clickhouse/.../table_name/. À l’intérieur de ce dossier, il y a 2 fichiers pour chaque colonne : un avec les données (compressées), le second avec l’index. Les données sont physiquement triées par clé primaire à l’intérieur de ces fichiers. Ces dossiers sont appelés des ‘parts’. - ClickHouse fusionne ces petites parts en parts plus grandes en arrière-plan. Il choisit les parts à fusionner selon certaines règles. Après la fusion de deux parts (ou plus), une part plus grande est créée et les anciennes parts sont mises en file d’attente pour être supprimées. Les paramètres que vous listez permettent d’affiner les règles de fusion des parts. L’objectif du processus de fusion est de ne laisser qu’une grosse part pour chaque partition (ou quelques grosses parts par partition qui ne valent pas la peine d’être fusionnées parce qu’elles sont trop grandes). Veuillez également consulter ce commentaire.
- Si vous créez de nouvelles parts trop vite (par exemple en effectuant beaucoup de petites insertions) et que ClickHouse n’est pas capable de les fusionner assez rapidement (autrement dit, si de nouvelles parts arrivent plus vite que ClickHouse ne peut les fusionner), vous obtenez alors l’exception ‘Merges are processing significantly slower than inserts’. Vous pouvez essayer d’augmenter la limite, mais vous risquez alors de vous retrouver avec des problèmes de système de fichiers causés par un trop grand nombre de fichiers / répertoires (comme la limite d’inodes).
- Si vous insérez dans beaucoup de partitions à la fois, le problème est multiplié par le nombre de partitions affectées par l’insertion.
- Vous pouvez essayer d’ajuster le comportement de ClickHouse avec l’un des paramètres listés, ou avec max_insert_block_size / max_block_size / insert_format_max_block_size / max_client_network_bandwidth. Mais : la meilleure solution consiste simplement à insérer les données au rythme attendu. Le rythme attendu est le suivant : une insertion toutes les 1-2 s, chaque insertion contenant 10K-500K lignes de données.
- La solution appropriée pour résoudre “Merges are processing significantly slower than inserts” consiste donc à ajuster le nombre d’insertions par seconde et le nombre de lignes dans chaque insertion. Utilisez des insertions par lot pour regrouper de petites insertions en une plus grande si les données arrivent ligne par ligne. Limitez le débit des très grosses insertions si vous avez trop de données à insérer d’un coup. Ne modifiez pas les mécanismes internes de ClickHouse, sauf si vous comprenez vraiment bien ce que cela implique.
- Si vos données arrivent à un rythme supérieur à 500K lignes par seconde, vous avez très probablement besoin de plus de serveurs dans le cluster pour absorber ce trafic, et non d’un ajustement des paramètres.
- La vitesse des fusions en arrière-plan dépend généralement de la vitesse du stockage, des paramètres de compression utilisés, de l’option MergeTree (l’algorithme de fusion — fusion simple / agrégation / sommation / collapsing, etc.) et de la clé de tri utilisée.