Résoudre l’exception « Too many parts » dans ClickHouse

Découvrez comment diagnostiquer et résoudre l’exception « Too many parts » en regroupant les insertions par lots, en utilisant les insertions asynchrones et en choisissant une clé de partitionnement appropriée.

​

Ce que signifie l’exception

ClickHouse lève l’exception Too many parts lorsqu’un INSERT ferait dépasser une limite configurée du nombre de parts de données actives dans une table MergeTree. L’exception inclut souvent le message Merges are processing significantly slower than inserts.

Chaque INSERT synchrone crée au moins une part de données. Si une insertion contient des lignes pour plusieurs valeurs de partition, ClickHouse peut créer une part pour chaque partition concernée. Les fusions en arrière-plan combinent les petites parts en parts plus volumineuses, mais si de nouvelles parts sont créées plus rapidement que ClickHouse ne peut les fusionner, le nombre de parts actives continue d’augmenter.

L’exception peut être déclenchée par l’un ou l’autre de ces paramètres :

• parts_to_throw_insert, qui limite le nombre de parts actives dans une seule partition.
• max_parts_in_total, qui limite le nombre total de parts actives dans une table.

​

Identifier la cause

Utilisez la requête suivante pour trouver les partitions qui comportent le plus de parties de données actives :

SELECT
    database,
    table,
    partition_id,
    count() AS active_parts,
    sum(rows) AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size_on_disk
FROM system.parts
WHERE active
  AND database = '<database_name>'
  AND table = '<table_name>'
GROUP BY
    database,
    table,
    partition_id
ORDER BY active_parts DESC;

Pour vérifier la limite globale de la table appliquée par max_parts_in_total, comptez toutes les parts actives de la table :

SELECT
    database,
    table,
    count() AS active_parts,
    sum(rows) AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size_on_disk
FROM system.parts
WHERE active
  AND database = '<database_name>'
  AND table = '<table_name>'
GROUP BY
    database,
    table;

Les causes courantes sont les suivantes :

• Des insertions synchrones fréquentes et de petite taille.
• Une clé de partitionnement à forte cardinalité.
• Des insertions contenant des lignes pour de nombreuses valeurs de partition.
• Des fusions en arrière-plan qui n’arrivent pas à suivre en raison d’un débit de stockage limité, d’un espace disque libre insuffisant ou d’une contention sur d’autres ressources.

Vous pouvez examiner les fusions actuellement en cours dans system.merges et consulter les logs du serveur pour repérer les échecs de fusion.

​

Résoudre l’exception

​

Insertions synchrones par lot

Regroupez les lignes côté client avant de les insérer. Chaque lot doit contenir au moins 1 000 lignes et idéalement entre 10 000 et 100 000 lignes. Visez environ un INSERT synchrone par seconde. Des insertions moins fréquentes mais plus volumineuses créent moins de parts et réduisent le travail des fusions en arrière-plan.

​

Utiliser l’insertion asynchrone

Si le regroupement côté client n’est pas envisageable, utilisez l’insertion asynchrone afin que ClickHouse puisse regrouper les données reçues sur le serveur :

INSERT INTO <table_name>
SETTINGS
    async_insert = 1,
    wait_for_async_insert = 1
VALUES (...);

Conservez wait_for_async_insert = 1 afin que ClickHouse ne confirme une insertion qu’après l’écriture réussie des données.

​

Vérifier la clé de partitionnement

Utilisez une clé de partitionnement à faible cardinalité et évitez de partitionner selon des valeurs telles que des identifiants d’utilisateur ou de requête. ClickHouse fusionne les parts uniquement au sein d’une même partition. Un grand nombre de partitions empêche donc une fusion efficace. Pour en savoir plus, consultez Choisir une clé de partitionnement.

​

Analyser les goulots d’étranglement des fusions

Si les insertions sont déjà correctement regroupées par lots, vérifiez les performances du stockage, l’espace disque disponible et les tâches en arrière-plan concurrentes. Le rythme des fusions dépend du système de stockage, du moteur de table, de la clé de tri, de la compression, ainsi que de la capacité disponible en CPU et en E/S.

​

Évitez d’augmenter les limites de parts comme correctif principal

Augmenter parts_to_throw_insert ou max_parts_in_total ne résout pas la cause de la création excessive de parts. Des limites plus élevées peuvent retarder l’exception, mais aussi augmenter la surcharge du système de fichiers et des métadonnées, tout en dégradant les performances des requêtes. Ne modifiez ces paramètres qu’après avoir identifié la cause et vérifié que le système dispose d’une capacité suffisante.

​

Vérifier le rétablissement

Exécutez de nouveau la requête de diagnostic après avoir modifié la stratégie d’insertion ou le schéma de partitionnement. Le nombre de parts actives devrait se stabiliser, puis diminuer à mesure que les fusions en arrière-plan résorbent leur retard. Continuez à surveiller les échecs d’insertion, l’espace disque disponible et system.merges jusqu’à ce que le retard accumulé soit résorbé.