Passer au contenu principal
Les tables ClickHouse utilisant le moteur MergeTree stockent les données sur disque sous forme de parts immuables, créées à chaque insertion de données. Chaque insertion crée une nouvelle part contenant des fichiers de colonnes triés et compressés, ainsi que des métadonnées telles que des index et des checksums. Pour une description détaillée de la structure des parts et de la manière dont elles sont formées, nous vous recommandons ce guide. Au fil du temps, des processus d’arrière-plan fusionnent les petites parts en parts plus grandes afin de réduire la fragmentation et d’améliorer les performances des requêtes. Même s’il peut être tentant de déclencher manuellement cette fusion à l’aide de : 
OPTIMIZE TABLE <table> FINAL;
il faut éviter l’opération OPTIMIZE FINAL dans la plupart des cas, car elle lance des opérations gourmandes en ressources qui peuvent affecter les performances du cluster.
OPTIMIZE FINAL vs FINALOPTIMIZE FINAL n’est pas la même chose que FINAL, dont l’utilisation est parfois nécessaire pour obtenir des résultats sans doublons, notamment avec ReplacingMergeTree. En général, FINAL peut être utilisé sans problème si vos requêtes appliquent des filtres sur les mêmes colonnes que celles de votre clé primaire.

​
Pourquoi l’éviter ?

​
C’est coûteux

L’exécution de OPTIMIZE FINAL force ClickHouse à fusionner toutes les active parts en une seule part, même si des fusions importantes ont déjà eu lieu. Cela implique :
  1. Décompresser toutes les parts
  2. Fusionner les données
  3. Les recomprimer
  4. Écrire la part finale sur disque ou dans le stockage objet
Ces étapes sont très gourmandes en CPU et en E/S et peuvent fortement solliciter votre système, en particulier avec de grands volumes de données.

​
Il ignore les garde-fous de sécurité

Normalement, ClickHouse évite de fusionner des parts de plus de ~150 Go (paramétrable via max_bytes_to_merge_at_max_space_in_pool). Mais OPTIMIZE FINAL ignore ce garde-fou, ce qui signifie :
  • Il peut tenter de fusionner plusieurs parts de 150 Go en une seule part énorme
  • Cela peut entraîner des temps de fusion très longs, une forte pression sur la mémoire ou même des erreurs de mémoire insuffisante
  • Ces grosses parts peuvent ensuite devenir difficiles à fusionner davantage : les tentatives de fusion ultérieures échouent alors pour les raisons indiquées ci-dessus. Lorsque des fusions sont nécessaires pour garantir un comportement correct au moment de la requête, cela peut avoir des conséquences indésirables, comme l’accumulation de doublons dans un ReplacingMergeTree, ce qui dégrade les performances au moment de la requête.

​
Laissez les fusions en arrière-plan faire le travail

ClickHouse effectue déjà des fusions en arrière-plan intelligentes pour optimiser le stockage et l’efficacité des requêtes. Elles sont incrémentales, s’adaptent aux ressources disponibles et respectent les seuils configurés. Sauf si vous avez un besoin très spécifique (par exemple, finaliser les données avant de figer une table ou de les exporter), mieux vaut laisser ClickHouse gérer lui-même les fusions.
Dernière modification le 25 juin 2026