> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<div id="what-the-exception-means">
  ## Ce que signifie l'exception
</div>

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`](/fr/reference/settings/merge-tree-settings/parts-to#parts_to_throw_insert), qui limite le nombre de parts actives dans une seule partition.
* [`max_parts_in_total`](/fr/reference/settings/merge-tree-settings/max-parts#max_parts_in_total), qui limite le nombre total de parts actives dans une table.

<div id="diagnose-the-cause">
  ## Identifier la cause
</div>

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

```sql theme={null}
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 :

```sql theme={null}
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`](/fr/reference/system-tables/merges) et consulter les logs du serveur pour repérer les échecs de fusion.

<div id="resolve-the-exception">
  ## Résoudre l’exception
</div>

<div id="batch-synchronous-inserts">
  ### Insertions synchrones par lot
</div>

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.

<div id="use-asynchronous-inserts">
  ### Utiliser l’insertion asynchrone
</div>

Si le regroupement côté client n'est pas envisageable, utilisez [l’insertion asynchrone](/fr/concepts/best-practices/selecting-an-insert-strategy#asynchronous-inserts) afin que ClickHouse puisse regrouper les données reçues sur le serveur :

```sql theme={null}
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.

<div id="review-the-partitioning-key">
  ### Vérifier la clé de partitionnement
</div>

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](/fr/concepts/best-practices/partitioning-keys).

<div id="investigate-merge-bottlenecks">
  ### Analyser les goulots d’étranglement des fusions
</div>

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.

<div id="avoid-increasing-part-limits-as-the-primary-fix">
  ### Évitez d’augmenter les limites de parts comme correctif principal
</div>

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.

<div id="verify-the-recovery">
  ## Vérifier le rétablissement
</div>

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`](/fr/reference/system-tables/merges) jusqu’à ce que le retard accumulé soit résorbé.